The US CLOUD Act and your European data
The US CLOUD Act is frequently discussed and frequently misunderstood. It is worth being precise, because the imprecision leads organisations to both overreact and underreact.
What the CLOUD Act actually says
The Clarifying Lawful Overseas Use of Data Act, passed in 2018, amended US stored-communications law to confirm that a provider subject to US jurisdiction must produce data in its possession, custody or control when served with valid US legal process — regardless of whether that data is stored inside or outside the United States.
Two things follow, and they are the whole of the practical issue:
- The obligation attaches to the provider, not to the data centre. It follows corporate nationality.
- Therefore EU data residency does not remove it. A US-headquartered provider storing your data in Frankfurt or Dublin is still a US-headquartered provider.
That is the entire mechanism. Everything else is a question of how much it matters to you.
What it does not mean
It does not mean US authorities routinely trawl European corporate data. It does not mean using US cloud providers breaches GDPR — transfers are lawful under the EU-US Data Privacy Framework adequacy decision adopted in 2023 and other mechanisms. It does not mean your data is being read.
It means there exists a legal route, under a foreign jurisdiction, to data you are accountable for, which you cannot fully control through contract or configuration.
For a great many workloads, that is a perfectly acceptable risk, accepted knowingly. The problem is when it is accepted unknowingly — or when an organisation that genuinely cannot accept it believes an EU region has solved the problem.
Why this has become a live procurement question
Three things changed the temperature in Europe:
- Schrems II (2020). The Court of Justice invalidated Privacy Shield and required organisations to assess the legal regime of the destination country, not just sign standard contractual clauses. The habit of assessing jurisdiction started there.
- NIS2 and DORA. Both push supply-chain and concentration risk onto the board's agenda for in-scope organisations. Dependency on a small number of foreign providers is exactly the concentration risk they are aimed at.
- The EU Data Act. Its cloud-switching provisions, applicable from September 2025, target the practical lock-in that made provider choice theoretical — egress charges and switching friction.
The result is that "where is our data and whose law reaches it?" has moved from a legal footnote to a tender question.
Working out whether it matters for you
Do this by workload, not by organisation. A blanket "no US cloud" policy is usually unaffordable; a blanket "it's fine" is usually undefended.
| Workload characteristic | Sovereignty pressure | Typical answer |
|---|---|---|
| Public sector or citizen data | High | EU-owned provider |
| Healthcare, defence supply chain | High | EU-owned provider |
| In scope of NIS2 / DORA | Medium to high | Explicit, documented decision per system |
| Commercial IP, internal operations | Medium | Risk-accepted, reviewed periodically |
| Public marketing content | Low | No constraint |
Most organisations find a small number of systems in the top rows and a large number in the bottom. The work is identifying which is which — and then actually deciding, rather than leaving it implicit.
What "EU alternative" should mean
The label is applied loosely. When evaluating, the questions that separate the offers are:
- Who owns the operating company, and where is it headquartered? This is the CLOUD Act question. Nothing else substitutes for it.
- Who holds the encryption keys, and can the provider technically access the data?
- Where does support operate from, and can support staff access production data?
- If AI features are involved, where does inference run and is your data used for training?
- What are the exit terms — export formats, egress costs, notice periods?
The last one matters more than it looks. Sovereignty that you cannot leave is just a different lock-in.
What we do about it
This is not an abstract position for us. TransformRadar, the platform behind our advisory work, is hosted entirely in the EU — in Paris, on Clever Cloud, on European-owned infrastructure — with no CLOUD Act exposure and no customer data used to train foreign AI models. We built it that way because we were not willing to advise clients on sovereignty from a US-hosted tool.
On the advisory side, the work is usually helping an organisation classify its estate honestly, decide per workload, and then execute the moves that follow — which is the same transformation discipline as any other platform change. Replacing ServiceNow is one common instance of it.
The summary
The CLOUD Act creates a real, narrow, well-defined exposure: US corporate nationality reaches data wherever it sits. EU regions do not fix it. Whether it matters depends entirely on what the data is.
The failure is not choosing a US provider. The failure is not having made the choice.
Frequently asked questions
- Does storing data in an EU region protect it from the CLOUD Act?
- No. The CLOUD Act applies to providers subject to US jurisdiction based on their corporate nationality, and reaches data in their possession, custody or control wherever it is stored. An EU region reduces latency and helps with GDPR data residency expectations, but it does not by itself place the data outside US legal reach.
- Is using AWS, Microsoft or Google illegal under GDPR?
- No. Transfers are lawful under the EU-US Data Privacy Framework adequacy decision and other transfer mechanisms. The question is not legality but risk: whether your organisation is comfortable with a foreign jurisdiction having a legal route to data you are responsible for.
- What is a sovereign cloud offering?
- A range of arrangements, and the differences matter. Some are US providers with EU regions and contractual commitments; some are joint ventures with EU operators holding the keys; some are wholly EU-owned providers. Only the last removes the corporate-nationality question entirely — so read what is actually being offered rather than the label.
- How do I decide whether this matters for us?
- Classify by workload rather than by organisation. Most organisations have a small set of genuinely sensitive systems and a large set where the risk is acceptable. Deciding per workload is cheaper and more defensible than a blanket policy in either direction.