The statement “your data stays in Europe” appears in nearly every hyperscaler sovereign cloud pitch. Stored in Europe, yes. Protected by European law from US government access? Not necessarily — and the difference matters more than most cloud buying decisions acknowledge. The gap between where your data sits and who can legally access it is the core question this guide addresses. Below, you will find a framework for evaluating sovereignty claims across three layers — data residency, data sovereignty, and jurisdictional control — with links to the right guide for your current decision stage.
In this hub:
- Data Residency, Sovereignty & Jurisdictional Control — the vocabulary layer
- How the CLOUD Act and FISA 702 create legal exposure for EU data
- AWS and Azure sovereign offerings assessed against the three-layer framework
- EU-native cloud providers compared — Hetzner, OVHcloud, Scaleway, T-Systems
- DORA, NIS2, and the EU AI Act: when sovereignty becomes mandatory
- Sovereign cloud due diligence playbook — workload classification, exit architecture, BYOK
- Why 61% of European CIOs want to reduce US cloud dependency
What Is Sovereign Cloud and Why Does the Definition Matter?
Sovereign cloud refers to cloud infrastructure where data storage, processing, and governance fall exclusively under a defined jurisdiction’s legal system. It goes beyond a standard public cloud region — covering not just where servers sit, but which laws govern access and who can compel disclosure. Two clouds can share the same physical building and carry entirely different legal exposure.
Start here: Data Residency, Data Sovereignty, and Jurisdictional Control Are Not the Same Thing — defines the three-layer sovereignty framework and introduces sovereign washing as a named concept.
What Is the Difference Between Data Residency, Data Sovereignty, and Jurisdictional Control?
Data residency is the physical fact of where servers are located. Data sovereignty is the legal question of which jurisdiction’s laws govern the data. Jurisdictional control is the layer that determines your actual protection: which courts or government agencies can compel access, regardless of data location. You can have residency without sovereignty, and sovereignty without full jurisdictional control. Most hyperscaler “sovereign cloud” offerings deliver residency and partial sovereignty but leave jurisdictional control unresolved. The framework gives you a consistent test: for each layer, ask whether the provider’s claim is verified, partial, or unresolved.
Deep dive: Data Residency, Data Sovereignty, and Jurisdictional Control Are Not the Same Thing
How Does the US CLOUD Act Create Legal Exposure for EU Cloud Data?
The US CLOUD Act (2018) allows US authorities to compel data disclosure from US-based cloud providers regardless of where data is physically stored. If a provider’s parent company is incorporated in the United States — as AWS, Microsoft, and Google all are — US courts can order data access even when the data resides on European servers. The EU-US Data Privacy Framework does not modify this provision.
FISA Section 702 operates in parallel, authorising warrantless collection of foreign nationals’ communications by US intelligence agencies. Microsoft’s own legal officer admitted before the French Senate an inability to guarantee EU customer data protection from US law enforcement access. The CLOUD Act versus GDPR Article 48 conflict remains unresolved.
Full legal analysis: How the US CLOUD Act and FISA 702 Create Legal Exposure for EU Cloud Data
What Do Hyperscaler Sovereign Cloud Offerings Actually Deliver?
Hyperscaler sovereign offerings — AWS European Sovereign Cloud, Microsoft Azure EU Data Boundary, Google Cloud’s partner-led model (S3NS) — deliver capability gains: EU-domiciled legal entities, EU-only operational staff, EU-based key management, and BSI C5 attestation in some cases. What they do not deliver is resolution of the CLOUD Act exposure. As long as the parent company is US-incorporated, US authorities can compel access. The term “guardrail sovereign model” describes this category: improved operational separation with residual legal risk. It is a better posture than a standard hyperscaler region, but it is not the same as full jurisdictional isolation.
Full assessment: AWS European Sovereign Cloud and Azure Sovereign Options Assessed Against the Three-Layer Framework
What Are the EU-Native Cloud Alternatives to Hyperscalers?
EU-native cloud providers — Hetzner, OVHcloud, Scaleway, T-Systems/Open Telekom Cloud, Aruba Cloud, Exoscale — are incorporated and operated entirely under EU law with no US parent company exposure. They represent the full EU isolation model: 100% EU-owned, EU-operated infrastructure with no foreign jurisdictional risk. The tradeoff is service breadth — EU-native providers cannot yet match hyperscaler managed service catalogues, though the gap is narrowing.
EU location alone does not guarantee absolute protection — provider jurisdiction, not just server location, is what determines your exposure. The cluster article below covers provider selection by company profile and the certification landscape.
Provider comparison: EU-Native Cloud Providers Compared — Hetzner, OVHcloud, Scaleway, and T-Systems
Which EU Regulations Are Making Sovereign Cloud Mandatory?
Three EU regulations are transforming sovereign cloud from optional to mandatory for specific workload categories. DORA (Digital Operational Resilience Act) requires financial entities — potentially including your company — to maintain documented exit strategies from cloud providers. NIS2 imposes sovereignty requirements on essential services operators. The EU AI Act introduces data governance and localisation obligations for AI systems. GDPR remains the baseline, requiring Transfer Impact Assessments for any US-controlled provider.
Regulatory mapping: DORA, NIS2, and the EU AI Act Are Making Sovereign Cloud Mandatory for Some Workloads
How Do You Assess Your Own Cloud Sovereignty Posture?
Start with workload classification: map every cloud workload into sovereignty risk tiers — regulated or sensitive data requiring sovereign infrastructure versus non-critical workloads where standard hyperscaler regions are acceptable. For each regulated tier, apply the three-layer test: confirm data residency, verify which legal system governs, and assess who can compel access. Where full jurisdictional isolation is required, EU-native providers are the correct solution. Where the guardrail model is sufficient, hyperscaler sovereign offerings may be viable.
The multi-cloud approach most companies land on: EU-native providers for regulated or sensitive workloads, hyperscaler regions for everything else.
Full playbook: A Sovereign Cloud Due Diligence Playbook — Workload Classification, Exit Architecture, and BYOK
Why Are European Organisations Rethinking Their Cloud Dependency?
Sixty-one percent of European CIOs say they want to reduce dependency on US cloud providers, according to Gartner. Sixty-two percent of EU organisations are actively seeking sovereign cloud solutions, according to Accenture. US hyperscalers currently hold approximately 70% of the EU cloud market. The shift is driven by regulatory pressure, geopolitical risk awareness, and sovereign cloud posture becoming a competitive differentiator when selling to regulated enterprise buyers.
If you sell to regulated enterprises, your buyers’ sovereignty posture affects their vendor selection. A customer subject to DORA or NIS2 may prefer a supplier whose data processing arrangements do not introduce additional cross-border transfer risk.
Market context: Why 61 Percent of European CIOs Want to Reduce US Cloud Dependency and What It Means
Resource Hub: Sovereign Cloud Library
Foundations — Vocabulary and Legal Framework
- Data Residency, Data Sovereignty, and Jurisdictional Control Are Not the Same Thing — Establishes the three-layer framework and defines sovereign washing. Start here if you’re building shared vocabulary with your team before evaluating any provider claims.
- How the US CLOUD Act and FISA 702 Create Legal Exposure for EU Cloud Data — Translates the legal mechanisms into practical CTO-level risk framing. Essential reading before evaluating any hyperscaler sovereign offering.
Provider Evaluation — Hyperscalers and EU-Native Alternatives
- AWS European Sovereign Cloud and Azure Sovereign Options Assessed Against the Three-Layer Framework — Applies the three-layer test directly to AWS ESC, Microsoft Azure, and Google Cloud’s partner model. What each offering delivers and what it leaves unresolved.
- EU-Native Cloud Providers Compared — Hetzner, OVHcloud, Scaleway, and T-Systems — Practical comparison of EU-native providers by company profile. Includes the OVHcloud Canadian court order nuance.
Regulatory Drivers and Decision Frameworks
- DORA, NIS2, and the EU AI Act Are Making Sovereign Cloud Mandatory for Some Workloads — Identifies which regulations apply to which workloads and what each requires in practice for FinTech, HealthTech, and SaaS.
- A Sovereign Cloud Due Diligence Playbook — Workload Classification, Exit Architecture, and BYOK — The end-to-end decision framework: classify workloads, evaluate providers, implement encryption mitigations, design for exit. Start here if you’re ready to act.
Market Context and Strategic Framing
- Why 61 Percent of European CIOs Want to Reduce US Cloud Dependency and What It Means — Market context, strategic framing, and why sovereign cloud posture increasingly affects enterprise sales pipelines.
Frequently Asked Questions
What is sovereign washing and how do I identify it?
Sovereign washing is the marketing practice of presenting data residency features — physical EU server locations — as equivalent to data sovereignty and full jurisdictional protection. You can identify it by applying the three-layer test: does the provider clearly confirm which legal system governs the data, and who can compel access? If a marketing claim stops at “your data stays in Europe” without addressing the parent company’s legal jurisdiction, that is sovereign washing. For a full taxonomy of sovereign washing signals in hyperscaler marketing, see Data Residency, Data Sovereignty, and Jurisdictional Control Are Not the Same Thing.
Can the US government access my data if it is stored in Europe?
Yes, if your cloud provider’s parent company is US-incorporated. Under the CLOUD Act, US authorities can compel data disclosure from US-based service providers regardless of where the data physically sits. The EU location of the servers does not override the US legal obligation on the provider. BYOK/HYOK encryption reduces the practical impact of a successful access order but does not remove the legal exposure. Full analysis: How the US CLOUD Act and FISA 702 Create Legal Exposure for EU Cloud Data.
Is the EU-US Data Privacy Framework sufficient protection?
No. The EU-US Data Privacy Framework (the successor to Privacy Shield, itself the successor to Safe Harbor) governs commercial data transfer arrangements between EU and US entities. It does not modify the CLOUD Act or FISA Section 702. US law enforcement and intelligence agencies can still compel data access under those statutes regardless of the Privacy Framework status. The European Court of Justice has already invalidated two previous EU-US transfer frameworks on precisely this basis.
Should my company use AWS or Azure for sensitive customer data?
It depends on which layer of sovereignty your workload requires. For workloads requiring full jurisdictional isolation — financial data under DORA, health data under the European Health Data Space regulations, government-classified information — hyperscaler sovereign offerings do not resolve the CLOUD Act exposure. For workloads where the guardrail model is sufficient — improved operational separation, EU-domiciled legal entity, EU key management — AWS ESC and Azure sovereign options represent a materially better posture than a standard hyperscaler region. The due diligence playbook provides a workload classification framework.
What sovereign cloud certifications should I look for?
BSI C5 (Germany’s Federal Office for Information Security Cloud Computing Compliance Criteria Catalogue) and SecNumCloud (France’s ANSSI certification framework) are the primary national-level standards. BSI C5 is an attestation confirming specific security and operational controls — it does not certify full jurisdictional isolation. SecNumCloud is stricter, requiring that providers and their supply chains have no non-EU jurisdictional exposure. ISO 27001 is a necessary baseline but does not address sovereignty specifically. Certification scope matters: always verify what a certification confirms and what it does not.
How do I know if my company is affected by DORA, NIS2, or the EU AI Act?
DORA applies to EU financial entities and their ICT third-party service providers from January 2025. If your company is a bank, insurer, investment firm, payment institution, or provides ICT services to those entities in the EU, DORA applies. NIS2 applies to medium and large organisations in 18 essential and important sectors including energy, transport, finance, healthcare, digital infrastructure, and ICT services. The EU AI Act applies to any organisation placing AI systems on the EU market or using AI systems in the EU. For a full regulatory mapping by company type, see DORA, NIS2, and the EU AI Act Are Making Sovereign Cloud Mandatory for Some Workloads.
What is the practical first step for a company reviewing its sovereignty posture?
Workload classification. Map every current cloud workload into sovereignty risk tiers before evaluating any provider or making any migration decision. Identify which workloads involve regulated data (personal data, financial records, health records, AI training data for EU-market systems), which involve sensitive but unregulated data, and which are non-critical. Once you know which workloads carry sovereignty risk, you can apply the three-layer test to your current provider and determine the gap. The full classification framework is in A Sovereign Cloud Due Diligence Playbook.
