Hosting in a provider's EU region feels like GDPR compliance. For US-headquartered providers, it isn't — and the gap is where self-hosting comes in.
Most European businesses believe they've solved data sovereignty by ticking a box in their cloud provider's settings: choose an EU region, store the data in Frankfurt or Dublin, done. The data is physically in Europe. GDPR satisfied.
It isn't, and the gap is wider than most teams realise.
The question that actually matters under GDPR isn't where the data physically sits. It's who can be compelled to hand it over. And for any US-headquartered provider — AWS, Microsoft, Google, and the hundreds of SaaS tools built on top of them — the answer involves a US law that doesn't care which data centre your files live in.
The conflict at the centre of this
The US CLOUD Act, passed in 2018, allows American authorities to compel US companies to produce data on demand — regardless of where in the world that data is physically stored. A US company storing your data in its Frankfurt region is still a US company subject to US legal process.
GDPR Article 48 says something close to the opposite: personal data of EU residents may not be handed to a non-EU authority without an international agreement permitting it.
These two laws point in different directions, and a US-headquartered provider operating in the EU sits in the middle of the contradiction. The provider's EU data centre doesn't resolve it. The provider's corporate nationality is the deciding factor, not the server's postcode.
This isn't a fringe legal theory. It's why data protection authorities in Austria, France, and Italy have ruled against specific US-based tools for GDPR violations tied to transatlantic data exposure, and why several EU public-sector bodies have moved to restrict new deployments of US cloud collaboration tools entirely.
Why "EU region" marketing doesn't close the gap
US providers know about this problem, which is why you've seen a wave of "EU Data Boundary," "Sovereign Cloud," and "European region" offerings. These are real engineering efforts and they reduce some risks — data-at-rest location, EU-based support staff, local encryption.
What they don't change is jurisdiction. As long as the entity controlling the infrastructure is a US company, that company remains subject to US legal demands. A sovereign-cloud badge on a US provider's product is mitigating the symptom, not removing the cause. The legal exposure is structural, not configurable.
The honest framing: "EU data residency" tells you where the data sleeps. "EU jurisdiction" tells you who can wake it up and take it. Only the second one is what GDPR actually cares about, and it's the one the region selector doesn't give you.
Where this becomes a real liability, not a theoretical one
For a lot of workloads, none of this matters. A US-hosted analytics tool tracking anonymous pageviews isn't a sovereignty crisis. The calculus changes when the data is personal, sensitive, or regulated:
- —Customer records — names, contact details, behavioural data of EU residents
- —Employee data — HR records, payroll, personal documents
- —Client confidential data — anything a business holds on behalf of its own customers
- —Communications — email and internal messaging, which contain everything
When this category of data lives with a US-headquartered provider, the business carries a documented compliance risk it often hasn't assessed. And GDPR enforcement has shifted from headline fines against big tech toward scrutinising how ordinary businesses handle exactly these transfers. Cumulative GDPR fines crossed into the billions, and data-transfer violations remain one of the highest-risk enforcement areas.
What actually resolves it
There's a spectrum of responses, and they're not equal:
Standard Contractual Clauses. The legal patch most businesses rely on. Valid but conditional — they require case-by-case transfer risk assessments, and after the Schrems II ruling invalidated Privacy Shield, they can't paper over a structural jurisdictional conflict. They reduce exposure; they don't remove it.
EU-owned cloud providers. Moving to a genuinely European provider (not a US provider's EU region) removes the CLOUD Act exposure, because the controlling entity is EU-domiciled. This is a real improvement and the right answer for many teams.
Self-hosted on EU infrastructure. The infrastructure runs on a server the business controls, hosted with an EU provider, operated under EU jurisdiction. There's no US company in the chain that could be compelled to produce the data. There's no third-party processor with its own legal obligations. The data lives where the business puts it, governed only by the laws the business is actually subject to.
The last option is the cleanest resolution to the jurisdiction problem because it removes the foreign-controlled intermediary entirely, rather than contracting around it.
What self-hosting in the EU actually looks like
For a typical business team, the sovereignty-sensitive workloads map onto a handful of self-hosted, open-source tools, all running on EU infrastructure:
- —File storage and collaboration — replacing Google Drive or Dropbox, the most common home for client and customer files
- —Business email — replacing Google Workspace or Microsoft 365, where the most sensitive communications live
- —Internal chat — replacing Slack or Teams
- —CRM and operations — replacing tools that hold the entire customer database
Hosted on European providers — Hetzner, IONOS, OVH, Scaleway, and others — these run on infrastructure that's both physically and jurisdictionally European. The business owns the deployment. No US entity sits in the data path. (We've written separately about what a complete migration off Google Workspace involves and the real cost of running self-hosted infrastructure.)
This isn't the right answer for every workload or every team. It requires the infrastructure to be set up correctly and maintained — an unmaintained self-hosted stack trades a compliance risk for a security one. But for the specific problem of EU data sovereignty, it's the option that resolves the jurisdiction question rather than negotiating around it.
The honest summary
Choosing an EU region in a US provider's console feels like compliance and isn't, because GDPR cares about jurisdiction and the region selector only changes geography. For non-sensitive workloads, that gap doesn't matter. For personal, regulated, or confidential data, it's a liability most teams are carrying without having assessed it.
The resolution is to remove the foreign-controlled intermediary — either by moving to a genuinely EU-domiciled provider, or by self-hosting on EU infrastructure the business actually controls. Both put your data back under the jurisdiction you're legally accountable to. The region selector never did.
If your team holds EU customer, employee, or client data on US-headquartered SaaS and you want to understand your specific exposure and options, the free assessment covers it — what's worth moving, what isn't, and what migration to EU-controlled infrastructure would actually involve for your stack.