Most cloud providers market “sovereign cloud” as though storing data in Europe automatically grants legal protection under European law. It does not. There are three distinct terms here — data residency, data sovereignty, and jurisdictional control — and they describe three separate layers of protection, each answering a different question. Vendors routinely conflate these layers in marketing. That practice has a name now: “sovereign washing,” coined by VMware/Broadcom.
This article gives you the vocabulary to tell genuine sovereign protection apart from marketing claims. By the end of it, you should be able to pick up any “sovereign cloud” press release and identify exactly which layers the announcement covers — and which ones it quietly leaves unaddressed. For broader context, take a look at our sovereign cloud overview.
What Is Data Residency and Why Does It Not Equal Protection?
Data residency answers one question only: where does my data physically sit? It is a geographic and contractual property — not a legal one.
A cloud provider can guarantee your data is stored on servers in Frankfurt, Dublin, or Amsterdam. That guarantee is real and measurable. It is also the easiest layer to deliver: pick an EU region, configure deployment, done. Residency is a configuration choice, not a legal structure.
Here is the gap. Data residency says nothing about which legal system governs that data or who can compel its disclosure. AWS operates data centres in Frankfurt. Your data resides in Germany. AWS is a US-incorporated company subject to US federal law. German address, American jurisdiction.
This is the default architecture of the global cloud market. Amazon, Microsoft, and Google together control nearly 70 percent of the European cloud market, and every one of them is incorporated in the United States.
VMware/Broadcom put it precisely: “Data residency is a necessary but insufficient step. Hyperscalers can offer residency, but they cannot offer true sovereignty to their European customers because they cannot exempt themselves from extra-territorial application of certain laws.”
Servers in Frankfurt are visible and auditable. Legal jurisdiction is invisible until a court order arrives.
Data residency is layer one of three. It is a precondition for legal protection — not the protection itself.
What Is Data Sovereignty and Which Legal System Actually Governs Your Data?
Data sovereignty answers a different question: which legal system governs my data? It is a legal property, determined by applicable laws — not by server location.
Where residency is about geography, sovereignty is about law. GDPR establishes sovereignty obligations for EU residents’ data, applying to any company that processes data belonging to EU citizens regardless of where it is headquartered.
Here is the problem. Hyperscalers typically define “sovereignty” as “data that stays in a region.” The EU Cloud Sovereignty Framework defines it across eight distinct dimensions — Strategic Sovereignty, Legal and Jurisdictional Sovereignty, Data and AI Sovereignty, Operational Sovereignty, Supply Chain Sovereignty, Technology Sovereignty, Security and Compliance Sovereignty, and Environmental Sustainability. The two definitions are not compatible.
The EU framework’s Legal and Jurisdictional Sovereignty dimension specifically assesses exposure to non-EU laws with cross-border reach — explicitly naming the US CLOUD Act. That dimension alone disqualifies most US hyperscaler offerings from claiming full sovereignty under the EU’s own definition.
GDPR Article 48 states that EU data cannot be transferred to non-EU authorities based solely on a foreign court order. But the US CLOUD Act inverts this logic entirely, and GDPR does not override it.
Data sovereignty tells you which laws are supposed to apply. It does not tell you who can override those laws from outside the jurisdiction. That is layer two of three.
What Is Jurisdictional Control and Who Can Legally Compel Access to Your Data?
Jurisdictional control answers the hardest question: who can legally force my cloud provider to hand over my data?
The answer is determined by the corporate nationality of the provider — not where the servers are. This is the layer that sovereign washing most consistently obscures, and the one most buyers never think to ask about.
The US CLOUD Act, passed in 2018, established one clarifying principle: jurisdiction follows the provider, not the server. US warrants and court orders can compel any US-based provider to produce data in their possession, custody, or control. Storage location is irrelevant.
FISA Section 702 reinforces this through a parallel mechanism, enabling warrantless intelligence collection from US-based cloud providers even when data is stored outside US borders.
The practical consequence: a US-headquartered company operating servers in Frankfurt is still subject to US compelled disclosure, even if the data resides in Germany and is sovereign under EU law. Comply with a US order and risk violating GDPR; refuse and risk US sanctions.
The general manager of Microsoft France testified under oath before the French Senate that he cannot guarantee French citizens’ data is safe from US authorities. Representatives from Google, Amazon, and Salesforce gave similar testimony: they would hand over European citizens’ data to US authorities if required by court order. This is documented practice, not speculation.
This makes jurisdictional control the determining question in any genuine sovereignty evaluation. For a detailed treatment of how these mechanisms operate, see the specific laws that exploit this gap.
What Is Sovereign Washing and How Does Marketing Language Exploit the Confusion?
Sovereign washing is the marketing practice of conflating data residency with data sovereignty or full jurisdictional protection — selling cloud services with incomplete legal safeguards as “sovereign.”
The term was named by VMware/Broadcom in their November 2025 blog post “The Great Cloud Charade.” Lawfare Media and VSHN independently confirmed the practice. All three reach the same conclusion: the major hyperscalers are US companies, and SLAs committing to store data in Europe cannot override their legal obligations under the CLOUD Act or FISA.
AWS European Sovereign Cloud: Launched in Brandenburg, Germany in January 2026 as a physically and logically separate infrastructure operated by EU residents under German legal entities. The marketing focuses on physical and operational separation — all elements of data residency. VMware/Broadcom identified the “fatal flaw”: despite its German parent company structure, the entity remains a subsidiary of a US corporation, subject to the CLOUD Act.
Microsoft EU Data Boundary: Microsoft committed to storing and processing all customer data within the EU — with exceptions for some security services that transfer data globally. None of this changes the underlying US jurisdictional exposure. Microsoft remains a US-headquartered company subject to US law.
VSHN identifies the structural pattern: “If the control plane, billing systems, or support teams still depend on a non-European parent company, then even a ‘local’ cloud can be forced to comply with foreign jurisdiction.”
Sovereign washing is not always deliberate deception. The vendor’s legal team may understand the exposure while the marketing team genuinely believes “EU data centre = EU protection.” The effect on the buyer is identical regardless.
How to spot it: if a vendor claims “sovereign cloud” but cannot answer “which government can legally compel you to disclose my data?” without deflecting, they are selling residency as sovereignty.
For a detailed assessment of what hyperscaler sovereign offerings actually deliver across the three layers, see what hyperscaler sovereign offerings actually deliver.
How Do the Guardrail and Full EU Isolation Models Address the Gap?
Two broad architectural responses have emerged to address the sovereignty gap.
The guardrail sovereign model uses US hyperscaler infrastructure with added contractual, operational, and technical controls designed to limit — but not eliminate — jurisdictional exposure. AWS ESC and Microsoft EU Data Boundary are the primary examples. These strengthen layer one and partially address layer two, but they do not fully sever layer three because the underlying corporate nationality remains US.
The full EU isolation model uses infrastructure owned and operated by EU-incorporated entities with no corporate link to US-headquartered parent companies. Examples include Swiss-based Exoscale, France’s Cloud de Confiance initiative, and Germany’s T-Systems Sovereign Cloud. Under the EU Cloud Sovereignty Framework’s SEAL scale, only the full isolation model can achieve SEAL-4 — Full Digital Sovereignty, subject only to EU law, no critical non-EU dependencies.
Google has pursued a hybrid approach through partnerships with European entities — Thales via S3NS in France, T-Systems in Germany. VMware/Broadcom notes this “does not change the legal obligations of the parent company.”
Neither model is inherently right or wrong. The guardrail model gives you hyperscaler service breadth with improved residency controls; the full isolation model gives you cleaner jurisdictional protection with a smaller service catalogue.
Detailed analysis of each model is covered in dedicated cluster articles.
Why Does the Three-Layer Framework Change What Questions to Ask?
The conventional vendor evaluation question is “Where is my data stored?” The three-layer framework makes clear that this is only one-third of the question.
With the framework, you ask three questions in sequence:
- Where does my data physically reside? (Residency — the geography question)
- Which legal system governs my data? (Sovereignty — the legal framework question)
- Who can legally compel my provider to disclose my data? (Jurisdictional control — the due diligence question)
If a vendor answers question one confidently but deflects on question three, the offering has a sovereignty gap. Vendors who have genuinely addressed jurisdictional control can answer question three directly. Those who have not redirect to question one.
The framework is deliberately simple — its purpose is triage, not deep legal analysis. Fast enough to apply during a vendor call, precise enough to catch sovereign washing in a press release.
For the broader context of how these decisions fit into a complete sovereign cloud strategy, see our sovereign cloud overview.
Frequently Asked Questions
Does storing data in the EU automatically protect it from US law?
No. If the cloud provider is US-incorporated, the CLOUD Act and FISA Section 702 can compel disclosure regardless of where the data physically sits. Residency is layer one; jurisdictional control depends on corporate nationality, not server geography.
What is the difference between data residency and data sovereignty?
Data residency is where data physically lives — a geographic property. Data sovereignty is which legal system governs that data — a legal property. A provider can offer EU residency while the data remains subject to non-EU law if the provider is incorporated outside the EU.
Can the US government access my data if it is stored in a German data centre?
Yes, if the cloud provider is US-headquartered. The CLOUD Act grants US law enforcement authority to compel US companies to produce data regardless of storage location. FISA Section 702 enables warrantless intelligence collection from US providers. Where the data sits does not override the provider’s US corporate obligations.
What does “sovereign cloud” actually mean?
There is no single agreed definition. The EU Cloud Sovereignty Framework defines it across eight dimensions including operational control, legal enforceability, and supply chain transparency. Hyperscalers often use it to mean EU-region deployment with added controls. The three-layer framework lets you assess what any specific claim actually covers.
Is AWS European Sovereign Cloud truly sovereign?
AWS ESC addresses data residency and some sovereignty measures, but AWS remains a US-incorporated company subject to the CLOUD Act and FISA Section 702. Under the three-layer framework, AWS ESC strengthens layers one and two but does not fully sever layer three. Whether this is sufficient depends on your risk profile and regulatory obligations.
What questions should I ask a cloud provider about data sovereignty?
Use the three-layer sequence: (1) Where does my data physically reside? (2) Which legal system governs my data? (3) Which governments can legally compel you to disclose my data? If they answer question one confidently but deflect on question three, the offering delivers residency without full jurisdictional protection.
What is the difference between data sovereignty and digital sovereignty?
Data sovereignty concerns which legal system governs data. Digital sovereignty is broader — operational independence, technology supply chain control, strategic autonomy in digital infrastructure. This article focuses on data sovereignty as one layer within the three-layer framework.
Does GDPR protect my data from the CLOUD Act?
GDPR establishes data protection obligations within the EU, but it does not block US legal compulsion orders. The CLOUD Act explicitly allows US authorities to demand data from US providers regardless of storage location. GDPR protects against misuse, not against foreign jurisdictional compulsion.
How do I know if a vendor is sovereign washing?
Apply the three-layer test: if a vendor claims “sovereign cloud” but can only confirm data residency without addressing who can compel disclosure, the claim is likely sovereign washing.
What is the difference between a guardrail sovereign model and a full EU isolation model?
A guardrail model uses US hyperscaler infrastructure with added controls to limit jurisdictional exposure — examples include AWS ESC and Microsoft EU Data Boundary. A full EU isolation model uses infrastructure owned by EU-incorporated entities with no US corporate parent, aiming to sever US jurisdictional reach entirely.
Why do most sources only discuss residency and sovereignty but not jurisdictional control?
Jurisdictional control requires examining corporate structure and international law — harder to market and less comfortable for vendors to discuss. Naming it as a distinct third layer is this article’s core contribution.
Is a Swiss cloud provider automatically sovereign?
Not automatically. Switzerland is not subject to the CLOUD Act, which helps at the jurisdictional control layer. But sovereignty also depends on corporate ownership structure, partnerships with US entities, and the specific legal agreements in place. Assess all three layers, not just the provider’s country of incorporation.
