Where your employee data actually lives — and why residency is not compliance

Two questions get treated as one, and they are not:

1. Where is our employee data physically stored? That is data residency.
2. Are we handling our employees' personal data lawfully? That is data protection compliance.

You can satisfy the first entirely and fail the second completely. Plenty of organizations have. It is worth separating them properly, because the remedies are different.

What HR data actually is

Start with what is in the system, because the sensitivity is easy to underestimate.

An HR platform holds full legal names, home addresses, dates of birth, national identity or tax numbers, bank account details, salary history, medical absences, disciplinary records, and often next-of-kin details. Under GDPR, some of that is ordinary personal data and some — health-related absence in particular — falls under the special categories that carry stricter handling requirements.

This is a materially more sensitive dataset than most of what your organization runs. It is also the one most likely to be sitting in a product somebody chose on a free trial.

The residency question

Residency is a location question, and it is answerable.

For a hosted product, the honest answer is rarely one location. There is the primary database region. There is the backup region, which is often different. There is wherever the support team sits when they access an account to investigate a ticket. There is each sub-processor — the analytics provider, the email service, the error tracker — and where each of those stores what they receive.

The question to ask a vendor is not "is our data in the EU?" It is:

Name every region where our data is stored or processed, including backups, and give me the current sub-processor list with what each one receives.

A vendor with a clear answer will send you a page. A vendor without one will send you reassurance. The difference tells you a great deal.

Self-hosting collapses this question. The data is in your database, on your server, in whichever jurisdiction you put it. The backups are wherever you send them. There are no sub-processors because there is no processing chain. That is a genuine simplification, and for organizations with residency obligations written into contracts or regulation it is often decisive.

The compliance question

Here is where the reasoning usually goes wrong.

Having solved residency, it is tempting to conclude the data protection problem is solved. It is not, because almost none of GDPR is about location.

The obligations that actually apply to an employer are things like:

• Lawful basis. You need one for each kind of processing. For employment data it is usually contractual necessity or legal obligation — and notably, consent is a weak basis in an employment relationship, because an employee cannot freely refuse their employer.
• Transparency. Employees are entitled to be told what you hold, why, and for how long, in an accessible privacy notice.
• Data minimisation. You should not be collecting fields because the software has boxes for them.
• Retention limits. Records for people who left six years ago should be gone unless something specific requires keeping them. "We kept everything" is a finding, not a defence.
• Subject access. An employee can ask for a copy of what you hold, and you have a deadline to respond.
• Breach notification. If it goes wrong, there is a clock.

Every one of those is an obligation on your organization. None is affected by which continent the server is on. If you self-host and keep leavers' bank details indefinitely with no retention policy, you have perfect residency and a compliance problem.

There is a further wrinkle worth knowing: GDPR's Article 88 lets individual member states add their own employment-specific rules, and several have. So "GDPR compliant" is not even a single standard where employment data is concerned.

What self-hosting genuinely changes

Being precise about this matters, because the honest version is still a strong argument.

It changes your role. With a hosted product you are the controller and the vendor is a processor, which requires a data processing agreement and puts you in the position of relying on their controls. Self-hosted, you are the controller and there is no processor — no agreement to negotiate, no sub-processor list to monitor, no third party to trust.

It makes retention enforceable. You can actually delete things, and verify they are gone, because it is your database. Deletion in a hosted product is a request that produces a confirmation.

It makes subject access answerable. Someone asks what you hold about them; you can query it directly rather than raising a ticket.

It removes the transfer problem. No international transfer, no adequacy decision, no standard contractual clauses, because nothing crosses a border.

What it does not do is write your privacy notice, set your retention schedule, establish your lawful basis, or train your managers not to email spreadsheets of salary data to each other. Those remain yours.

A short diligence list

Whatever you buy, these are worth asking before you sign:

1. Name every region where our data is stored or processed, backups included.
2. Give me the full sub-processor list and what each receives.
3. Can we set retention rules per record type, and does deletion actually delete?
4. Can we export everything, in a usable format, without asking?
5. Who inside your company can read our employee records, under what controls, and is that access logged?
6. What exactly happens to our data if we leave, and how long until it is destroyed?

Question five is the one that gets the most revealing answers, and the one people forget to ask.

The uncomfortable summary

Residency is a question with a factual answer, and self-hosting answers it cleanly. Compliance is an ongoing organizational practice, and no software purchase completes it.

Anyone selling you either one as the other is either confused or hoping you are. The reason to control where employee data lives is that it removes a category of risk and a category of dependency — not that it discharges a legal duty. That is a smaller claim, but it has the advantage of being true.

---

Ace HR is self-hosted: your employee data sits in your PostgreSQL database, on your infrastructure, under your retention policy. How it is deployed · Our own privacy policy