In January 2026, AWS launched its European Sovereign Cloud: physically isolated infrastructure, a German legal entity, EU-resident staff. It checks every box a compliance officer would look for. Except one.
AWS European Sovereign Cloud GmbH is a 100% subsidiary of Amazon.com, Inc. A US company. And under US law, that single fact means American authorities can still compel access to the data stored there.
This is the distinction that most businesses miss entirely. Your data can sit in Frankfurt, Amsterdam, or Dublin and still be legally reachable by US law enforcement. Not through a loophole. Through explicit legislation.
TL;DR: Data residency (where your server sits) is not data sovereignty (whose laws govern access to your data). The US CLOUD Act compels US-headquartered cloud providers to produce data regardless of server location. GDPR Article 48 says such orders aren't valid without a mutual legal assistance treaty, creating an unresolved legal conflict. The EU-US Data Privacy Framework covers commercial data transfers, not law enforcement access. Dutch businesses in healthcare, government supply chains, and legal services face the most concrete risk. Evaluate your hosting provider on jurisdiction, not data center coordinates.
Table of contents
- Data residency is not data sovereignty
- The CLOUD Act: follow the provider, not the server
- What the EU has done about it
- Which Dutch businesses should care most
- How to evaluate a hosting provider on sovereignty
- When full sovereignty is overkill
- Key takeaways
Data residency is not data sovereignty
Data residency is a geographic concept. Your data is physically stored in a specific country or region. You pick AWS eu-central-1 (Frankfurt) or Azure West Europe (Netherlands), and the bits physically live there.
Data sovereignty is a legal concept. It determines whose courts and laws govern who can access your data. It's about control, not coordinates.
The European Commission's Cloud Sovereignty Framework, published in October 2025, makes this distinction operational. It scores providers across eight sovereignty dimensions (legal, data, supply chain, strategic, and four more) using 32 questions on a 0–4 scale. A server in Frankfurt scores well on residency. It tells you nothing about legal sovereignty if the provider's parent company is incorporated in the US.
Think of it like renting a safe deposit box. A box at a Dutch bank and a box at the Dutch branch of an American bank sit in the same city. The legal exposure is completely different.
The CLOUD Act: follow the provider, not the server
The Clarifying Lawful Overseas Use of Data Act (CLOUD Act), signed on March 23, 2018, explicitly states that US law enforcement can compel any US-based electronic communication or computing service provider to produce stored data, regardless of where that data is physically located.
The law has a specific origin story. In 2013, the FBI sought a warrant for emails stored on Microsoft's servers in Dublin, Ireland. Microsoft fought the order all the way to the Second Circuit, which ruled in their favor: the Stored Communications Act didn't apply to data stored abroad. While the Supreme Court was hearing the government's appeal, Congress passed the CLOUD Act and made the question moot. Overseas data? Fair game.
The principle is simple: follow the provider, not the server. AWS, Microsoft Azure, and Google Cloud are US companies. A CLOUD Act order reaches their Frankfurt data center just as easily as one in Virginia.
And that's only the law enforcement side. FISA Section 702 adds a parallel intelligence surveillance mechanism. It authorizes US intelligence agencies to collect communications of non-US persons from US providers without individual warrants. The Court of Justice of the EU cited FISA 702 as a primary reason for invalidating Privacy Shield in its 2020 Schrems II judgment.
What the EU has done about it
Three legal instruments now address this conflict directly. None of them fully resolve it.
GDPR Article 48
Article 48 states that court judgments and administrative decisions from third countries requiring data transfers can only be enforced if based on an international agreement, such as a mutual legal assistance treaty (MLAT). A CLOUD Act order without an applicable MLAT isn't a valid legal basis for transferring personal data under EU law.
The EDPB confirmed this in its final guidelines on Article 48, adopted in June 2025. Third-country court orders "cannot be automatically or directly recognized or enforced" in an EU member state. The conflict is real: comply with the CLOUD Act and you violate GDPR. Refuse, and you violate US law.
EU Data Act, Article 32
The EU Data Act became fully applicable on September 12, 2025. Article 32 extends the same principle to non-personal data: cloud providers must implement "adequate technical, organisational and legal measures" to prevent third-country governmental access that conflicts with EU law. Providers must now publish what measures they've taken.
The Data Act also created practical switching power through Articles 23–31. Customers can switch cloud providers with two months' notice. Switching fees are capped at direct costs until January 2027, then eliminated entirely.
The EU-US Data Privacy Framework
The Data Privacy Framework (DPF) survived its first legal challenge when the General Court dismissed the Latombe case in September 2025. But its foundations are shaking. President Trump fired the Democratic members of the PCLOB (Privacy and Civil Liberties Oversight Board) in January 2025, gutting the oversight body the European Commission cited 31 times in its adequacy decision. NOYB has signaled a broader challenge is coming.
Here's the part that gets lost in the noise: the DPF governs commercial personal data transfers between businesses. It does not address, and provides no protection against, CLOUD Act law enforcement orders. These are entirely separate legal regimes. Having your cloud provider DPF-certified changes nothing about government access to your data.
Which Dutch businesses should care most
This isn't equally urgent for every organisation. Three sectors face concrete, immediate pressure.
Healthcare. If you process patient data in the Netherlands, NEN 7510 compliance is legally mandatory. Storing medical records with a US-owned cloud provider introduces a CLOUD Act vector that conflicts with the standard's intent. The direction across Europe is clear: Germany made BSI C5 compliance mandatory for healthcare cloud from July 2025.
Government suppliers. The Baseline Informatiebeveiliging Overheid (BIO) applies to all four layers of the Dutch public sector. The Netherlands Court of Audit found in January 2025 that 67% of major government cloud services lacked risk assessments. The Dutch parliament then adopted motions urging the government to move away from US cloud services in March 2025, calling the dependence "a threat to autonomy and cybersecurity." If you supply to government entities, these procurement requirements will reach you.
Legal and financial services. A CLOUD Act disclosure of client data could breach attorney-client privilege or accountant-client confidentiality at a fundamental level. For firms processing sensitive client information, jurisdiction of the hosting provider isn't an IT question. It's a professional liability question.
How to evaluate a hosting provider on sovereignty
Certifications alone don't answer the sovereignty question. ISO 27001 certifies your security management system. SOC 2 attests to control effectiveness. BSI C5 discloses your jurisdiction. None of them prevent a CLOUD Act order from being served. The European Commission's sovereignty framework evaluates sovereignty as a separate dimension from security, and for good reason.
Four questions cut through the marketing:
- Where is the ultimate parent company incorporated? This is the single most important question. A US parent means CLOUD Act jurisdiction, period. Regardless of data center location, subsidiary structure, or "sovereign" branding.
- Who controls the encryption keys? Customer-managed encryption (BYOK) deployed on EU hardware is a meaningful mitigation, though it doesn't address metadata access or account-level information.
- Is the sub-processor chain transparent? Under GDPR Article 28, your provider must disclose all sub-processors with geographic locations. One US-based sub-processor reintroduces the entire CLOUD Act vector.
- What does the transparency report actually say? US law prohibits providers from disclosing exact national security request volumes. You'll see ranges, not numbers. Read the footnotes.
European providers outside CLOUD Act jurisdiction
Several EU-headquartered providers sit structurally outside CLOUD Act reach:
- Hetzner (Germany): privately held, ISO 27001:2022 and BSI C5 Type 2 certified, classified as critical infrastructure under German law. No US parent.
- Leaseweb (Netherlands): Dutch-headquartered, ISO 27001:2022 and NEN 7510 certified, explicitly positioned on sovereignty.
- TransIP (Netherlands): founded in Leiden, part of team.blue, a European hosting group. Worth noting: team.blue's investor structure includes Warburg Pincus (US private equity), which adds complexity to a full sovereignty analysis.
- OVHcloud (France): largest EU-native cloud provider, SecNumCloud-certified by France's ANSSI, selected for the ECB's digital euro project.
Smaller, specialized managed hosting providers operating entirely under Dutch or German jurisdiction offer the same structural advantage. The key is the ownership chain, not the marketing materials.
When full sovereignty is overkill
Not every workload needs this level of analysis. Running a portfolio site, a corporate brochure page, or a blog with no login system and no personal data beyond a contact form? The CLOUD Act risk is theoretical. You're not processing the kind of data that creates real exposure.
The practical threshold: do you handle sensitive personal data (medical records, BSN numbers, financial data, legal files), or do contractual sovereignty requirements flow down to you from government or enterprise clients? If yes, provider jurisdiction should be a primary selection criterion. If not, a well-configured EU region from any reputable provider is fine for most purposes.
There's a cost dimension too. US hyperscalers still control roughly 70% of the European cloud market, with European providers collectively holding about 15%. Moving off AWS or Azure for sovereignty reasons while losing access to managed services like Aurora, Cosmos DB, or BigQuery is a trade-off that demands honest evaluation, not ideological commitment.
The pragmatic approach: classify your workloads. Route sensitive and regulated data through EU-sovereign infrastructure. Keep non-sensitive workloads wherever they perform best. This isn't an all-or-nothing decision.
Key takeaways
- Data residency ≠ data sovereignty. Servers in Frankfurt, Amsterdam, or Dublin don't protect your data if the provider's parent company is subject to the CLOUD Act.
- The CLOUD Act and FISA Section 702 give US authorities access to data held by US companies worldwide. GDPR Article 48 and the EU Data Act's Article 32 say such access conflicts with EU law. The tension is structural and unresolved.
- The EU-US Data Privacy Framework covers commercial transfers. It says nothing about law enforcement or intelligence access.
- Dutch healthcare providers (NEN 7510), government suppliers (BIO), and legal/financial firms face the most immediate regulatory pressure.
- The single most important sovereignty question: where is the provider's ultimate parent company incorporated?
- EU-headquartered providers (Hetzner, Leaseweb, OVHcloud, and specialized managed hosts) are structurally outside CLOUD Act jurisdiction.
Data sovereignty is part of a broader EU regulatory wave, alongside the NIS2 directive and GDPR consent requirements. If you're evaluating hosting infrastructure for regulated workloads and want an independent assessment, feel free to reach out.