It is a statement about geography. And geography, under US law, is not the variable that matters.
There's a common assumption in how companies talk about data compliance. They pick a cloud provider with European data centres, maybe choose Frankfurt or Amsterdam as their region, tick the relevant boxes in their procurement process, and consider the matter settled.
The data is in the EU. GDPR applies.
Job done.
Most organisations making this claim are not wrong about the fact. Their data is, physically, in a European data centre. What they have misunderstood is the legal framework that determines who can access it. The two things are not the same, and the gap between them creates a risk that is rarely on the architecture diagram.
In 2018, the United States enacted the Clarifying Lawful Overseas Use of Data Act, the CLOUD Act. The core mechanism is straightforward. US law enforcement can compel a US-based company to produce data it stores or controls, regardless of where that data physically sits. The country where the servers are located is not a defence. The data protection laws of that country do not override the order. The company receiving the warrant cannot decline on the basis that the data is in Frankfurt or Amsterdam or Dublin.
The CLOUD Act does not require that the request go through an international treaty or a foreign court. It goes directly to the company.
If your data lives on AWS, Azure, Google Cloud, or any other US-headquartered provider, American authorities can compel access to it. The Frankfurt data centre doesn't change that. That's the part most organisations miss.
The jurisdiction question is not about where your data lives. It is about who controls it. If your cloud provider is incorporated in the United States or has a US parent, a US subsidiary, or operates as a US legal entity your data falls within reach of a CLOUD Act request, irrespective of which region you selected when you provisioned the service.
AWS is an American company. Microsoft Azure is an American company. Google Cloud is an American company. Their EU regions are datacentres run by US entities. Selecting "eu-central-1" or "West Europe" solves a GDPR compliance requirement. It does not change the legal jurisdiction of the controlling company.
This distinction matters because most enterprise data residency strategies are built around GDPR logic. GDPR is a geography-first framework: it governs how data about EU residents is processed and where it is transferred. The CLOUD Act operates on a different axis entirely. GDPR asks where the data is. The CLOUD Act asks who controls the entity that holds it.
The two frameworks do not cancel each other out. They address different things. And organisations that have solved one have not automatically solved the other.
This is not a theoretical concern. It was the structural problem at the centre of the Schrems II ruling in 2020, when the Court of Justice of the European Union invalidated the EU-US Privacy Shield framework. One of the central findings was that US surveillance law including mechanisms that compel US companies to produce data could not be reconciled with European data protection standards, because the remedies available to EU individuals were insufficient.
The EU-US Data Privacy Framework that replaced Privacy Shield in 2023 introduced new safeguards, but it is already under legal challenge on the same grounds. The underlying tension, US law's reach over US companies operating in Europe has not been architecturally resolved. It has been politically negotiated, which is a different thing.
The organisations most exposed are those handling data that is sensitive by nature and regulated by jurisdiction: client confidentiality in legal and professional services, financial records subject to banking secrecy requirements, clinical data in healthcare, or commercially sensitive IP in competitive industries.
For these organisations, a US government request served to their cloud provider is not a hypothetical edge case. It is a scenario their data architecture should have accounted for.
The less obvious exposure is through adjacent relationships. If your SaaS vendor is a US company, and they store your data in an EU region on your behalf, the same principle applies. The question is not which vendor you chose, it is whether the entity controlling the data is subject to US jurisdiction.
There are architectures that reduce exposure, though none eliminate risk
entirely. Cloud providers with no meaningful US legal presence, European hyperscalers like OVHcloud, Deutsche Telekom's Open Telekom Cloud, or Hetzner are not subject to CLOUD Act requests in the same way. Choosing a non-US infrastructure provider is the most structural solution for data that genuinely requires it.
Encryption where the key is held exclusively by the customer, not the cloud provider, limits what a provider can produce in response to a legal order. If the provider cannot read the data, they cannot meaningfully hand it over.
This requires careful implementation, because many default encryption arrangements involve the provider managing the keys.
Contractual and corporate structures through EU-incorporated entities provide some additional layers, though their protective effect is contested and depends on the specifics of the legal entity relationship.
None of these are drop-in solutions. They involve architectural trade-offs: cost, performance, tooling compatibility, operational complexity. That is the honest picture.
Most modernisation projects treat data residency as a compliance checkbox.
Pick a region, confirm it is in the EU, move on. That approach is sufficient for a narrow reading of GDPR obligations. It is not sufficient if the question is whether your data is beyond the reach of US legal process.
The more useful question to ask is: which data in your environment is sensitive enough to require genuine jurisdictional isolation, and is your current architecture actually providing it?
For many organisations, the answer is that only a subset of their data requires this level of protection. The majority can reasonably sit on major cloud providers without meaningful risk. But knowing which subset requires stricter isolation, and being honest about whether the current architecture delivers it, is a different exercise than selecting an EU region and assuming the problem is solved.
If your team is working through data architecture decisions, particularly in the context of AI workloads, modernisation programmes, or regulated industry requirements, jurisdiction belongs on the design agenda alongside geography. Now, if you are unsure whether your current data architecture actually delivers the jurisdictional protection your compliance position assumes, that is a useful thing to know before it becomes a problem, let’s talk https://itsavirus.com/contact-us
