Data Residency Is Not Data Sovereignty: The Real Story Behind Cloud Control in the EU

A customer asked me recently whether they needed to worry about the US CLOUD Act if their Azure tenant was based in the Netherlands. They had read that their data stays in Europe, saw the "EU Data Boundary" label in the admin portal, and assumed that settled it.
It doesn't. Not completely. And the gap between what they assumed and what the law actually says is exactly where digital sovereignty conversations go wrong.

This post is about that gap: the difference between where your data physically sits and who has the legal authority to access it. They are not the same question, and treating them as one is a planning mistake that shows up later as a compliance problem.

Two Terms That Sound the Same and Mean Different Things

Data Residency

A geographic question

• Where is the data physically stored?
• In which datacenter region does processing happen?
• Can I choose a specific country for my tenant?
• Answered by your provider's regional configuration

Data Sovereignty

A legal and jurisdictional question

• Which country's laws govern access to this data?
• Can a foreign government compel access to it?
• Who controls the encryption keys?
• Answered by your provider's corporate structure and applicable law

Residency is about geography. Sovereignty is about authority. A provider can offer you full data residency within the EU and still be subject to foreign jurisdiction. Location does not equal control.

The Elephant in the Room: The US CLOUD Act

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act) is a US federal law passed in 2018. It gives US law enforcement the power to compel American technology companies to hand over data stored abroad, regardless of where it physically sits. The key word is "American companies." If your provider is incorporated in the United States, the CLOUD Act applies to their infrastructure everywhere, including datacenters in Frankfurt, Amsterdam, and Dublin.

This means that when Microsoft, Google, or Amazon tells you your data stays in the EU, they are telling you something true about geography and something incomplete about jurisdiction. The data does stay in the EU. But a US warrant can still reach it.

What the CLOUD Act actually allows US law enforcement can issue warrants to US-based providers for data held abroad, without requiring the cooperation of the country where the data is located, without judicial review in that country, and without prior notice to the affected users or European regulators. It bypasses Mutual Legal Assistance Treaties (MLATs) entirely.

How This Collides With GDPR

Article 48 of the GDPR is specific: court orders from third countries (like the US) are only valid for transferring EU personal data if they are recognized through an international agreement, such as an MLAT. The CLOUD Act does not use MLATs. It is unilateral.

This creates a genuine legal dilemma for companies using US-based cloud providers:

• ⚖️Comply with a US warrant. The provider hands over data. The organization may face GDPR enforcement action for unauthorized data transfer to a third country.
• ⚖️Refuse the US warrant. The provider faces legal consequences in the US. In practice, large US providers rarely refuse.
• ⚖️Use the "quash or modify" clause. The CLOUD Act allows providers to challenge warrants that conflict with foreign law. But this option is discretionary, complex, and rarely used in practice.

The European Data Protection Board has been clear: service providers subject to EU law cannot legally base data transfers to the US solely on CLOUD Act requests. But GDPR applies to the data subject's rights, not directly to what the US government demands of a US company. The gap between those two jurisdictions is where sovereignty actually lives.

What Microsoft Has Actually Built

To Microsoft's credit, they have not ignored this. Over the last several years they have built real technical and contractual mechanisms to address sovereignty concerns. These are worth understanding carefully, because they are genuine progress on a hard problem, but they are also not a complete answer to the CLOUD Act question.

The EU Data Boundary

The EU Data Boundary is Microsoft's commitment to store and process Customer Data and personal data for their enterprise online services (Azure, Dynamics 365, Power Platform, and Microsoft 365) within the EU and EFTA countries. The EFTA countries included are Switzerland, Norway, Iceland, and Liechtenstein, in addition to all 27 EU member states.

As of February 2025, this covers:

• ✅Customer Data at rest and in processing. The actual content you store and work with stays within EU/EFTA datacenters.
• ✅Pseudonymized system-generated logs. Microsoft requires all personal data in operational logs to be pseudonymized before it leaves the EU Data Boundary. Techniques include encryption, masking, tokenization, and data blurring.
• ✅Professional Services Data at rest. Data from Microsoft consulting and support engagements is stored within the boundary.

Important: the EU Data Boundary has documented exceptions There are specific circumstances where Customer Data will continue to be transferred outside the EU Data Boundary. Microsoft publishes these exceptions in detail on the EU Data Boundary documentation site. Architects should review the specific services they rely on, as coverage is not uniform across all Azure capabilities.

Microsoft Cloud for Sovereignty

The EU Data Boundary handles residency. Microsoft Cloud for Sovereignty is Microsoft's answer to the broader sovereignty question. It comes in three tiers:

Sovereign Public Cloud

Built-in sovereignty controls within the standard Azure public cloud. Customer-managed encryption keys, European personnel approving operational access, tamper-evident access logs, and Azure Policy for governance alignment.

Sovereign Private Cloud

Azure Local deployed on-premises or in a sovereign facility. Workloads operate in a hybrid or fully disconnected environment under local physical control. Designed for classified or highly regulated data.

National Partner Clouds

Microsoft cloud capabilities operated by an independent, nationally licensed partner. The operator is not a US entity, which changes the jurisdictional picture materially. Examples include operator clouds in Germany and France.

The Sovereign Landing Zone (SLZ) is the Azure landing zone reference architecture that applies these controls prescriptively, with built-in Azure Policies for sovereignty alignment out of the box. If you are designing a sovereign-compliant environment on Azure, SLZ is the right starting point rather than building governance from scratch.

Operational Access Controls

One of the more substantive commitments Microsoft has made is around who can access your data for operational purposes. For European Microsoft Cloud services, operational access is approved by European personnel and tracked in tamper-evident logs. Customers can also bring and manage their own encryption keys on hardware security modules, which means that even Microsoft cannot decrypt data without explicit customer authorization.

This is meaningful. If Microsoft cannot technically read your data, a CLOUD Act warrant demanding that data becomes significantly harder to fulfill. "We cannot access it" is a defensible technical position, not just a contractual promise.

The Honest Assessment: Marketing vs. Reality

Several major US cloud providers now market offerings with "sovereign" in the name. It is worth being specific about what these actually deliver, because the term is used loosely enough that it requires scrutiny.

• □Microsoft 365 EU Data Boundary. Genuine commitment to data residency within EU/EFTA. Combined with customer-managed keys and the European operational access approvals, this is among the more substantive offerings from a US hyperscaler. The CLOUD Act still applies at the corporate level, but the technical controls reduce practical access.
• □Amazon European Sovereign Cloud. AWS launched a European Sovereign Cloud for the EU, designed to operate independently of AWS commercial operations with data stored in Germany. AWS employees in the EU manage it. This changes the operational picture, but the parent company is still a US entity, which means the CLOUD Act question is not fully resolved.
• □"Sovereign cloud" as a marketing label. The term appears in many places where the underlying architecture has not materially changed. Data residency in an EU datacenter operated by a US company, without customer-managed encryption or separated operational control, is data residency. It is not sovereignty in any meaningful legal sense.

Sovereignty is not a marketing claim, it's a legal reality. If your provider is subject to US jurisdiction, your data may not be safe, even if stored within the EU. Wire Security Blog, July 2025

What This Means for Azure Architects

If you are designing solutions on Azure for EU public sector clients, regulated industries, or organizations with explicit sovereignty requirements, the framework has improved significantly but still requires deliberate design choices. Here is how I think about it:

• □Customer-managed keys are not optional for sensitive workloads. If Microsoft cannot read your data, the CLOUD Act becomes a much weaker lever. Azure Key Vault with customer-managed keys, or Bring Your Own Key (BYOK) stored on HSMs, should be standard for anything touching personal or regulated data. This is not just a compliance checkbox - it is a technical barrier that matters.
• □️Use the Sovereign Landing Zone if sovereignty is a stated requirement. Do not design custom governance from scratch. The SLZ gives you Azure Policies pre-configured for sovereignty alignment, region restrictions, and operational controls. Start there and adapt to your specific regulatory context.
• □Understand the EU Data Boundary exceptions for your specific services. Not every Azure service is covered equally. Before making commitments to a client about where data lives, check the Microsoft EU Data Boundary documentation for the specific services in scope. Coverage continues to expand but is not yet uniform.
• □Sovereign Private Cloud for classified or highly regulated scenarios. If the requirement is "no US entity can even theoretically be compelled to access this data," the public cloud with enhanced controls is not sufficient. Azure Local in a national facility, or a national partner cloud operated by a non-US entity, is the architecture that actually addresses that requirement.
• □Know what MLAT means and when it applies. When a US legal request arrives, the correct response for EU organizations is to refer the case through the Mutual Legal Assistance Treaty process, which includes EU judicial oversight and GDPR-compatible safeguards. Organizations and their legal counsel should be familiar with this before it becomes urgent.

The good news for Azure architects The tooling has genuinely improved. Customer-managed keys, European operational access approvals, tamper-evident logs, the EU Data Boundary commitment, and the Sovereign Landing Zone together form a defensible architecture for most regulated EU workloads. The combination of technical controls and contractual commitments is stronger in 2025 than it was in 2020. The CLOUD Act has not gone away, but the practical surface area it can reach has been reduced for organizations that architect deliberately.

My Take

Digital sovereignty is one of those topics where the terminology creates false confidence. "EU Data Boundary" sounds definitive. "Microsoft Cloud for Sovereignty" sounds like it closes all the gaps. Neither is the full story.

The CLOUD Act is a real constraint. It has not been legislated away, and the EU-US Data Privacy Framework that replaced Privacy Shield has already faced legal challenges. Organizations that assume their provider's marketing language resolves the jurisdiction question are carrying risk they have not accounted for.

At the same time, writing off Microsoft's sovereign cloud investments as pure marketing underestimates what has actually been built. Customer-managed encryption, separated operational control, and the EU Data Boundary commitment are technical commitments, not just contractual ones. They change what is practically possible even under a legal demand.

The right framing for architects is this: use the tools that exist, understand what they do and do not cover, and match the architecture to the actual regulatory requirement. For most commercial EU workloads with GDPR obligations, the combination of EU Data Boundary plus customer-managed keys plus the Sovereign Landing Zone gets you to a defensible position. For government or classified data where the standard is "no foreign jurisdiction, period," the answer is a national partner cloud or private deployment where the operator is not a US entity. That requirement is different, and the architecture needs to reflect it.

References
EU Data Boundary Overview - Microsoft Learn (Updated February 2025)
Microsoft Sovereign Cloud - microsoft.com
Europe Digital Sovereignty - AWS Compliance
Sovereign Landing Zone - Azure CAF Documentation