Sovereign Cloud in Europe: Residency, Sovereignty, and Control

Sovereign cloud is often used as a broad label, but the term covers multiple concerns. For most organisations, the useful distinction is between where data is stored, who can control it, and how dependent the organisation is on external providers.

Key Takeaways

• A CJEU ruling, not a policy preference, is why "adequate legal protection" became a hard requirement for EU data transfers. The Schrems II judgment (July 2020) invalidated the EU-US Privacy Shield specifically because of concerns about US government surveillance access to EU personal data, and required that any alternative transfer mechanism (such as Standard Contractual Clauses) guarantee protection "essentially equivalent" to GDPR and the EU Charter of Fundamental Rights (European Parliament Think Tank).
• The EU's own cloud certification scheme still hasn't resolved sovereignty requirements at its highest level. As of the most recent available analysis, the dispute over mandatory EU-only data localization in EUCS's top assurance tier remains a live policy question, with one EU policy institute describing the scheme as legally "tricky" to resolve through implementing regulation alone (cep — "EU Cloud Certification at an Impasse").
• The three major hyperscalers have taken visibly different approaches to EU sovereignty, which is itself informative: Microsoft layers sovereignty controls (EU Data Boundary, Sovereign Private Cloud, National Partner Clouds) on top of shared global infrastructure (Microsoft Learn); AWS launched a physically and logically separate European Sovereign Cloud in January 2026, incorporated as new German legal entities operated exclusively by EU residents (AWS); Google Cloud delegates operations to vetted regional partners — S3NS in France, T-Systems in Germany, Polo Strategico Nazionale in Italy — through its Sovereign Controls by Partners model (Google Cloud documentation).
• Residency, sovereignty, and operational independence are genuinely different problems, and an architecture can satisfy one while failing another — data stored in an EU region (residency) does not by itself resolve whether a non-EU parent company could be compelled to disclose it (sovereignty), or whether you could actually migrate off that provider if needed (operational sovereignty).
• This is a live, evolving legal area, not a fixed checklist. The EUCS scheme's sovereignty provisions and the broader EU "Cloud Sovereignty Framework" discussion remain unresolved — architecture decisions made today should anticipate further regulatory movement, not treat current requirements as final.
• European organisations often need a more precise answer than "the cloud is compliant." The architecture should make control boundaries explicit and legible, so the discussion can stay grounded in specific, verifiable facts rather than broad reassurance.

Four Terms Worth Separating

Data residency describes where data is held. Data sovereignty is about the legal and governance context around that data. Cloud sovereignty is about control over the cloud environment. Operational sovereignty is about the ability to run and change the environment without unacceptable dependency.

• Residency is location — which physical region or data center holds the data.
• Sovereignty is control and jurisdiction — which country's laws actually govern access to the data, regardless of where it physically sits.
• Operational sovereignty is practical independence — whether you could actually operate, migrate, or replace the underlying provider if you needed to, without the provider's continued cooperation.

Why This Distinction Has Real Legal Weight

Schrems II: why "adequate protection" became a hard line

In July 2020, the Court of Justice of the European Union (CJEU) invalidated the EU-US Privacy Shield framework — the mechanism many organisations had relied on for transferring personal data to the United States — specifically because of concerns about the reach of US government surveillance programmes into that data (European Parliament Think Tank — summary of the CJEU Schrems II judgment). The Court did not invalidate Standard Contractual Clauses (SCCs) as a transfer mechanism, but it required that any transfer under SCCs guarantee a level of protection "essentially equivalent" to that guaranteed by the GDPR and the EU Charter of Fundamental Rights — and made clear that where a third country's legal system creates a gap in that protection, additional safeguards are required, and if adequate protection genuinely cannot be achieved, the transfer must be suspended.

This ruling is the legal backbone behind why "where is the server" is an incomplete question — the deciding factor the Court focused on was whether a foreign government could compel access to the data regardless of contractual promises, which is a sovereignty question, not merely a residency one.

EUCS: the EU's own certification scheme has struggled with this exact distinction

The European Cybersecurity Certification Scheme for Cloud Services (EUCS), developed under the EU Cybersecurity Act by ENISA, was intended to standardise cloud security assurance across the EU, with member states able to mandate its use for public bodies and entities in scope of NIS2 and the Data Act. Earlier drafts of the scheme included explicit sovereignty criteria for its highest assurance level — including headquarters-location and jurisdictional-exclusion requirements that would have disadvantaged or excluded non-EU providers. Those explicit nationality-based criteria have since been removed from the draft scheme, but higher assurance levels reportedly retain de facto sovereignty elements — strict data localization, restrictions on non-EU legal access, and requirements for EU-based personnel oversight — and the underlying political debate remains unresolved. A 2025 analysis from the Centre for European Policy Network (cep) frames the core tension directly: including mandatory EU-only data storage requirements in the certification scheme "makes geopolitical sense" but is "legally tricky" to implement through regulation alone, and recommends adopting EUCS without sovereignty requirements first while addressing them separately through formal legislation (cep — "EU Cloud Certification at an Impasse"; ITIF — "The EU's Cloud Service Restrictions").

How the Major Clouds Have Actually Responded

The gap between "the cloud is compliant" and a precise answer becomes concrete when you look at what Microsoft, AWS, and Google Cloud have actually built for EU sovereignty — three genuinely different models, not three versions of the same thing.

Microsoft's approach layers sovereignty controls onto its existing global platform: the EU Data Boundary keeps data and processing within defined EU geographic bounds on Microsoft-operated infrastructure, Sovereign Private Cloud extends this to customer- or partner-operated deployments for disconnected or defense scenarios, and National Partner Clouds add jointly-governed instances with approved national partners (Microsoft Learn). This is a residency-and-governance-controls model rather than a fully separate entity.

AWS took a structurally different path with the AWS European Sovereign Cloud, which launched its first region in Brandenburg, Germany in January 2026: the infrastructure is physically and logically separate from other AWS regions, operated exclusively by EU residents, and run by a new parent company with local German (GmbH) subsidiaries led by EU citizens, overseen by an independent advisory board (AWS; AWS — European Sovereign Cloud overview). This is the closest of the three to genuine operational sovereignty as defined above — designed, per AWS, to keep operating even if disconnected from the rest of AWS globally.

Google Cloud's Sovereign Controls by Partners model takes a third approach: rather than Google operating a separate entity, named regional partners — S3NS in France, T-Systems in Germany, Polo Strategico Nazionale in Italy — operate the sovereignty and access-control layer on top of Google's underlying platform (Google Cloud documentation). This delegates operational control to a local partner without full independence from Google's own infrastructure underneath it.

None of the three is simply "better" in the abstract — they represent different trade-offs between how much you inherit the parent company's global platform versus how independently the sovereign layer can actually operate, and the right fit depends on which of the four concerns above is the one that actually matters for a given workload.

How the Four Concepts Interact

Common Mistakes

• Treating "EU data center" as a complete answer. Residency alone doesn't resolve whether a non-EU parent company can be compelled, under its home country's law, to grant access to that data — which is exactly the concern Schrems II centered on.
• Assuming EUCS or a similar certification is finalized and stable. As of the most recent reporting available, sovereignty requirements in the scheme remained contested and subject to further change — architecture decisions anchored to a specific current requirement should build in room for that requirement to shift.
• Assuming all "sovereign cloud" offerings are structurally equivalent. Microsoft's EU Data Boundary, AWS's separately-incorporated European Sovereign Cloud, and Google's partner-operated model make genuinely different trade-offs on operational independence — the right label to ask a vendor about depends on which of the four concerns actually matters for the workload.
• Conflating cloud sovereignty with operational sovereignty. Having contractual or technical control over an environment doesn't automatically mean the organisation could actually migrate away from the provider without significant, possibly prohibitive, effort.
• Ignoring the question until a specific deal or audit forces it. Sovereignty requirements are far cheaper to design for upfront than to retrofit after data, contracts, and integrations are already committed to a specific provider and region.
• Treating this as purely ideological rather than a genuine legal risk. The legal basis here is a binding CJEU ruling with real transfer-suspension consequences, not merely a political preference — it deserves the same rigor as any other compliance requirement.

Trade-offs and Decision Guidance

Cost, Complexity and Timeline

Confirming the legal basis for any current cross-border data transfer (whether an adequacy decision applies, or SCCs with the additional safeguards Schrems II requires are in place) is a legal determination with real but bounded effort — it should be resolved with counsel before, not after, committing to a specific provider and region. Building genuine operational sovereignty — the ability to actually migrate or run independently of a specific vendor's proprietary tooling — is significant, ongoing architectural effort, since it generally means favoring portable, open technologies over deeply vendor-specific managed services, a trade-off against convenience that should be made deliberately rather than by default. Tracking EUCS and related EU sovereignty policy developments is a recurring monitoring cost, given the scheme's unresolved status — organisations with material EU regulatory exposure should treat this as an ongoing compliance-watch item, not a one-time read.

How Halden Solutions Approaches This

We separate residency, sovereignty, and operational independence explicitly when scoping a client's cloud architecture, because a design can satisfy one while quietly failing another — and clients deserve a precise answer, not a general "the cloud is compliant" reassurance. Where a genuinely sovereign architecture is warranted, we map the specific requirement against what each provider's model actually offers — Microsoft's boundary-and-governance controls, AWS's separately incorporated entity, Google's partner-operated layer, or a dedicated European provider — rather than assuming any "sovereign cloud" label satisfies the same concern. Where personal data and cross-border transfer are involved, we treat the legal basis (adequacy, or SCCs with appropriate additional safeguards per Schrems II) as a determination to confirm with legal counsel early in the design process, and we track the evolving EUCS and broader EU cloud sovereignty policy landscape as an ongoing input to architecture recommendations rather than a fixed, one-time checklist.

Frequently Asked Questions

Is data residency the same as data sovereignty? No. Residency is about physical location; sovereignty is about which country's laws actually govern access to the data, which can differ from where it's physically stored — for example, if the hosting provider's parent company is subject to a foreign government's legal compulsion regardless of the server's location.

Does using an EU cloud region automatically satisfy GDPR's transfer requirements? Not necessarily — it depends on whether the provider or its corporate structure creates any path for a non-EU authority to compel data access, and on the specific legal basis used for any related cross-border processing. This is a legal determination, not purely an infrastructure one.

What did the Schrems II ruling actually change? It invalidated the EU-US Privacy Shield transfer mechanism specifically over US government surveillance concerns, and required that any alternative mechanism like Standard Contractual Clauses provide protection "essentially equivalent" to GDPR, with additional safeguards where a destination country's laws fall short — and transfer suspension where adequate protection can't be achieved.

Are Microsoft, AWS, and Google's "sovereign cloud" offerings interchangeable? No — they're structurally different. Microsoft's EU Data Boundary and related offerings add sovereignty controls to its existing global platform; AWS's European Sovereign Cloud is a separately incorporated, EU-resident-operated entity designed to run independently of AWS globally; Google Cloud's Sovereign Controls by Partners delegates operations to named regional partners. Which one fits depends on whether the actual requirement is residency, legal jurisdiction, environmental control, or operational independence.

Is EUCS a finalized, mandatory requirement today? As of the most recent public reporting available, EUCS's sovereignty-related provisions remained under active debate and had not settled into a final, stable form — organisations should confirm current status directly rather than assume it is fixed, and should expect the requirement landscape to keep evolving.

Conclusion

"Sovereign cloud" collapses several genuinely different questions — where data sits, whose laws govern it, who controls the cloud environment, and whether you could operate independently of your provider — into one label, and treating it as a single checkbox misses exactly the distinctions that matter legally. The Schrems II ruling, the EU's own unresolved debate over EUCS's sovereignty requirements, and the fact that Microsoft, AWS, and Google Cloud have each built structurally different sovereignty models all point the same way: this is a live, evolving area of law and architecture, not a settled specification. Decisions should be made with that in mind, matched to which specific concern actually applies, and revisited as the regulatory and vendor landscape keeps developing.

If you're assessing what level of sovereignty your organisation actually needs — versus what's being marketed as a requirement — Halden Solutions' Cybersecurity & Sovereign Cloud team can help work through the distinction for your specific data and regulatory exposure.

Sources

• European Parliament Think Tank — "The CJEU judgment in the Schrems II case"
• cep (Centre for European Policy Network) — "EU Cloud Certification at an Impasse"
• ITIF — "The EU's Cloud Service Restrictions"
• Microsoft Learn — "What is Microsoft Sovereign Cloud?"
• AWS — "AWS Launches AWS European Sovereign Cloud and Announces Expansion Across Europe"
• AWS — "Overview of the AWS European Sovereign Cloud" (whitepaper)
• Google Cloud documentation — "Overview of Sovereign Controls by Partners"