Why Data Residency Doesn't Protect You

The Misconception

Ask most IT and compliance teams how they’ve addressed cloud data jurisdiction risk, and you’ll hear some version of this: “We use the EU region. Our data stays in Europe.”

It sounds reasonable. It is incorrect.

Data residency — the physical location of servers — is not the same as data jurisdiction — the legal system that governs that data. Conflating them is one of the most common and consequential compliance errors in enterprise IT.

What Actually Determines Jurisdiction

Data jurisdiction follows the corporate structure of the entity that controls the data — not the building where the server sits.

When you use Microsoft Azure, your data may be processed in a Frankfurt data center. But Microsoft is a corporation headquartered in Redmond, Washington, USA. Microsoft Germany GmbH, the local operating entity, is a wholly-owned subsidiary of Microsoft Corporation. Under the US CLOUD Act, US law enforcement can compel Microsoft Corporation — and therefore all its subsidiaries — to produce data they control, wherever it is stored.

The principle is straightforward: jurisdiction follows the company, not the server.

This was explicitly tested in the Microsoft Ireland case (2013–2018), where the US government sought emails stored in Microsoft’s Dublin data center. Microsoft challenged the warrant on the grounds that the data was outside the US. The Supreme Court ultimately didn’t rule on the merits because Congress passed the CLOUD Act in 2018 to resolve the question — by confirming that US warrants apply globally to data controlled by US companies.

The Full List of Affected Providers

Any organization using these providers is affected, regardless of which region they use:

Provider	HQ	CLOUD Act Applies?
Microsoft Azure / M365	USA	Yes
Amazon Web Services	USA	Yes
Google Cloud / Workspace	USA	Yes
OpenAI / ChatGPT	USA	Yes
Microsoft Copilot	USA	Yes
Salesforce	USA	Yes
Dropbox / Box	USA	Yes
Anthropic (Claude API)	USA	Yes
Harvey AI	USA	Yes
Thomson Reuters / Westlaw	USA	Yes

This is not a comprehensive list. Any company incorporated in the United States and subject to US law is covered.

Why “EU Data Center” Options Exist

Cloud providers offer EU-region deployments for multiple legitimate reasons — latency, local data sovereignty regulations, marketing differentiation. They are not designed to, and do not, eliminate CLOUD Act exposure.

Some providers have introduced programs with names like “EU Data Boundary” or “Sovereign Cloud” that claim to limit data access. These warrant careful scrutiny:

Microsoft’s EU Data Boundary, for example, still involves US personnel for certain support, security, and operational activities — potentially maintaining CLOUD Act exposure for that data
“Sovereign Cloud” offerings operated by US parent companies remain subject to US corporate law obligations
Contractual commitments (“your data will stay in the EU”) cannot override a valid US court order

The test is not where the data is stored. The test is whether the entity controlling that data can be compelled by US courts. If the answer is yes — regardless of what the contract says — you have CLOUD Act exposure.

For EU organizations, the situation is made worse by the interaction with GDPR.

If a US authority serves a CLOUD Act warrant on your cloud provider, and the provider complies, this transfer of personal data to US law enforcement may violate GDPR Article 48 — which states that judgments of non-EU courts are not a valid legal basis for data transfer without an international agreement (such as an MLAT).

This puts your organization in an impossible position:

Your provider complies with the US warrant (they have no choice)
That compliance may constitute a GDPR violation on your data
You had no notice and no opportunity to object

The European Data Protection Board has confirmed this conflict exists and has not provided a comfortable resolution. CLOUD Act demands and GDPR are, in certain circumstances, genuinely incompatible.

What Actually Protects You

Non-US Cloud Providers

If your cloud provider is headquartered outside the United States and outside US allied jurisdictions with reciprocal data-sharing agreements, it is not subject to CLOUD Act demands. This means choosing providers incorporated in the EU (France, Germany, the Netherlands, etc.) rather than US providers offering EU hosting.

Examples of EU-headquartered cloud infrastructure providers: Scaleway (France), OVHcloud (France), Hetzner (Germany), IONOS (Germany).

Note: UK providers may be subject to similar demands under bilateral US-UK agreements. Verify the corporate structure carefully.

On-Premises Deployment

The most absolute protection is removing the cloud entirely. If AI and document processing run on hardware you own, in your building, with no network connection to any external system, there is no third-party controller to compel. The CLOUD Act cannot reach what doesn’t exist on another company’s infrastructure.

This is the principle behind the Tacitus Cortex: AI infrastructure installed on your premises, processing data entirely under your physical and legal control.

The Questions to Ask

Before relying on any cloud provider’s data residency claims, ask:

Where is the parent company incorporated? Not the local operating entity — the ultimate parent.
Are US-based employees or subsidiaries involved in operating or supporting this system? Even indirectly?
What happens if US law enforcement serves a warrant on the parent company? Read the terms of service carefully. They will not promise CLOUD Act immunity.
Has an independent legal opinion assessed your CLOUD Act exposure? Not a vendor sales document — an actual legal analysis.
What data residency certifications exist, and what do they actually certify? ISO 27001 certifies security practices, not legal jurisdiction.

If you can’t answer question 1 with confidence, you almost certainly have CLOUD Act exposure regardless of what the sales materials say.

Use our Sovereign AI Checklist to assess your organization’s current jurisdiction risk in 15 minutes. Download it here.