GDPR-first, in plain language

Most software calls itself GDPR-compliant. The phrase has worn smooth from overuse, and it rarely tells a works council or a security team anything they can check. We would rather show our work. This is what GDPR-first means inside Office by Elevera, written so that a non-engineer can follow every step and a sceptical engineer can still nod along.

The short version: compliance is not a badge you buy, it is a set of decisions baked into the architecture. A certificate on a wall tells you a vendor passed an audit on one day. The way data is stored, isolated, and logged tells you what actually happens every day after that. We built for the second thing.

The split that explains everything: controller and processor

GDPR draws a line between two roles, and almost every question about responsibility resolves once you know which side you are on. The controller decides why and how personal data is processed. The processor handles that data on the controller's instructions and nothing more.

When you run Office, you are the controller of your employees' data. It is your people, your purposes, your retention rules. Office is the processor: we store and move that data so the product works, strictly under your direction, and we do not repurpose it. That distinction is not a footnote. It decides who answers a data-subject request, who signs the data processing agreement, and who is accountable if something goes wrong. We put it up front so there is never any doubt.

Compliance is not a badge you buy. It is a set of decisions baked into the architecture, and architecture is the part an auditor can actually verify.

Where the data lives, and where it does not

Personal data in Office stays in the EU. EU data residency is not a marketing line for us, it is a hard constraint on where records are stored and processed. For a German or Croatian employer that matters for more than principle: it keeps the lawful basis for processing simple and it keeps cross-border transfer rules out of your way for the data that lives in the core product.

The people who can touch infrastructure are limited and named, and the work they do is logged. We keep the list of companies that process data on our behalf, the subprocessors, current and public, so you can see exactly who is in the chain before you sign anything. You can read the live list on our subprocessors page and the full picture on security.

Isolation enforced in the database, not just the app

This is the part we care about most, because it is the part most products get wrong. In a typical multi-tenant system, every organisation's data sits in shared tables and the application code is trusted to add the right filter to every query. One forgotten clause, one clever bug, and one customer can see another's records. The wall exists only in the code, and code is where mistakes live.

Office enforces row-level isolation per organisation in the database itself. Every row of personal data carries the organisation it belongs to, and the database refuses to return rows that belong to a different organisation, regardless of what the application asks for. The isolation is a property of the data, not a habit of the developers. If a query forgets its filter, it returns nothing rather than someone else's payslips.

Why this beats a badge: a certificate says a process was followed. Isolation in the database says the wrong answer is structurally impossible to return. One is a promise, the other is a guarantee you can point an auditor at.

Least-privilege roles: people see only what their job needs

Isolation keeps organisations apart. Roles keep people inside one organisation honest. Office uses least-privilege roles, which is a plain idea with a precise meaning: nobody gets access by default, access is granted for a reason, and the reason maps to a job.

• An HR administrator manages employee records and documents, because that is the role.
• A line manager sees their own team's absence and reviews, not the whole company's salaries.
• An employee sees their own profile, payslips, and requests through self-service, and nothing belonging to a colleague.
• An external accountant, a Steuerberater, gets a token-scoped, read-only window onto exactly the payroll data they need, and not a login into your HR system.

That last one is worth dwelling on. Sharing payroll with an accountant usually means emailing a spreadsheet or handing over a password, both of which leak more than intended. A token-scoped read-only grant gives them precisely the slice they need, no write access, and it can be revoked the moment the engagement ends.

The audit trail: append-only, immutable, and boring on purpose

Every consequential action in Office is written to an immutable, append-only audit trail. Append-only means entries are added and never edited. Immutable means they cannot be quietly rewritten after the fact, not by a user, not by an administrator. The log records who did what, to which record, and when.

This is the unglamorous backbone of accountability. When a works council asks who viewed a sensitive document, the answer is in the log. When an auditor wants evidence that retention and deletion happened as promised, it is in the log. When you yourself want to understand a change, you do not reconstruct it from memory, you read it. A trail that can be edited proves nothing. One that cannot is the difference between trust and a story.

Data-subject rights, handled like routine work

GDPR gives the people whose data you hold a set of rights: to know what you store about them, to get a copy, to correct it, to have it erased when there is no longer a lawful reason to keep it, and to restrict how it is used. As the controller, those requests come to you. Office's job as processor is to make answering them ordinary rather than a fire drill.

Because the data has one home and a clear owner, a subject access request is a lookup, not an archaeology project. Self-service already gives employees their own profiles, payslips, and documents, which quietly satisfies a good share of access requests before they are even filed. Correction is an edit. Erasure respects the retention rules you set, so you delete what you may and keep what the law requires you to keep, with both actions recorded in the trail.

Why architecture beats a badge

A certification is a snapshot. It says that on the day of the assessment, the controls looked right. It does not follow your data home and watch over it on a Tuesday in March when someone runs an unusual query. Architecture does. Isolation in the database, least-privilege roles, and an immutable trail are not things we promise to keep doing, they are properties of how the system is built, working the same whether or not anyone is watching.

That is the whole philosophy: one source of truth, least access, and a record that cannot be quietly changed. It is the same calm, uncluttered approach we take to the rest of the product, applied to the part where the stakes are highest. If you want the technical detail, the security page goes deeper, and the integration with Fleet by Elevera carries the same guarantees across the closed loop. If you would rather just ask, we are easy to reach.