Why EU Data Residency Actually Matters for GDPR

"GDPR-compliant" is not a checkbox

Almost every hosting provider's homepage says "GDPR-compliant" somewhere. It's not a certification a provider can just claim — GDPR is a regulation about how personal data is collected, stored, and moved, and it places specific, enforceable obligations on anyone processing that data on a company's behalf. A hosting provider is a processor under the regulation, and processors have their own duties, separate from whatever the customer (the "controller") is doing with the app itself.

What GDPR actually requires of a hosting provider

Two parts of the regulation matter most for infrastructure decisions:

• Article 28 — processor obligations. A provider processing personal data on your behalf must operate under a written Data Processing Agreement (DPA), implement appropriate technical and organisational security measures (Article 32), assist with breach notification (Articles 33-34), disclose its sub-processors, and allow the controller to audit compliance.
• Articles 44-49 — restrictions on international transfers. Personal data can't be freely moved outside the European Economic Area. A transfer needs either an adequacy decision, or a safeguard like Standard Contractual Clauses (SCCs). This is the part that gets legally messy: the "Schrems II" ruling in 2020 invalidated the EU-US Privacy Shield over concerns about US government access to data, and its successor framework, the EU-US Data Privacy Framework (2023), is already the subject of fresh legal challenges.

Why data residency is the practical shortcut

None of this means data can never leave the EU — plenty of companies run on US hyperscalers with a valid transfer mechanism in place. But every one of those mechanisms is negotiated, audited, and periodically challenged in court. If your infrastructure — compute, storage, backups, application logs — never leaves the EU in the first place, the cross-border transfer question simply doesn't arise for that layer of your stack.

There's a second, subtler point worth knowing: choosing a cloud provider's "EU region" doesn't automatically settle the question. If the entity that owns and operates that region is headquartered outside the EU, US legal instruments like the CLOUD Act can, in some circumstances, still compel that company to produce data it controls, regardless of where the servers physically sit. Whether and how that applies is genuinely contested among lawyers, and it's a question worth putting to any provider directly rather than taking a regional flag as the final answer.

What this looks like on Partiri

Partiri i.G. is registered in Berlin, Germany. Deployments run on regions in Nuremberg, Germany and Helsinki, Finland — both live today — with compute, persistent storage, and logs kept on infrastructure physically located in the EU. Storage on Partiri is persistent volumes attached to your service, plus Managed PostgreSQL databases (single-instance, EU-hosted, private in-cluster networking) provisioned on that same EU infrastructure.

Questions worth asking any hosting provider

• Is there a signed Data Processing Agreement available, and does it list sub-processors?
• Where do backups and application logs actually live — is it the same region as the primary data?
• Is the legal entity operating the region itself incorporated in the EU?
• If data ever needs to leave the EU, what transfer mechanism applies, and who decides when that happens?

This post is informational and isn't legal advice — if data residency is a hard requirement for your organisation, get your own counsel to review the specifics against your obligations.