EU data sovereignty is not a region setting
Thomas Thejn4 min read
A European data region is not the same as European jurisdiction. The US CLOUD Act binds the provider, not the data centre, so a US-owned platform can be compelled to produce programme data held in Frankfurt or Paris. Removing that exposure means removing the US provider from the processing chain entirely.
Every enterprise procurement questionnaire I have filled in over the last three years has a question that looks like it settles the matter: where is the data stored? The expected answer is a city. Frankfurt, Dublin, Paris, Stockholm. Tick the box, move to the next section.
It is the wrong question, and answering it well can leave an organisation believing it has a sovereignty position it does not have.
The obligation attaches to the provider
The US CLOUD Act — the Clarifying Lawful Overseas Use of Data Act — allows US authorities to compel a US-based provider to produce data that provider controls, regardless of where in the world the bytes physically sit. The legal duty runs to the company, not to the disk.
That distinction is the whole point. Selecting the Frankfurt region of a US hyperscaler moves the storage. It does not move the corporate entity that holds the keys, signs the contract, and would receive the order. The data is in Germany; the obligation is in the United States.
This is not a hypothetical about surveillance. It is a mundane observation about which legal system a supplier answers to, and it is the observation that most "EU region" claims quietly skip.
Why this bites hardest on programme data
Plenty of systems hold data where this is an acceptable risk. A transformation programme's record is usually not one of them, and the reason is what is in it rather than how much of it there is.
- The business case, including the benefits leadership committed to and the
assumptions underneath them.
- The risk and issue log — which is to say, the honest version of how the
programme is going, written down.
- Decisions and their rationale, including the ones that were politically
difficult.
- Named people, their roles, and in a health assessment their candid
assessment of whether the programme is working.
That last one is worth sitting with. A Programme Health assessment asks a panel whether the sponsor is genuinely engaged and whether the steering group actually decides anything. The value of the exercise depends entirely on people answering honestly. Honest answers about senior stakeholders are exactly the material people stop producing when they are unsure who can read them.
Governance data is only useful when it is candid, and candour depends on knowing where the record lives.
What actually removes the exposure
There is no clever contractual construction that makes a US provider not a US provider. Standard contractual clauses, encryption-at-rest with provider-managed keys, EU subsidiary structures — these change the paperwork and the difficulty, not the jurisdiction of the entity being compelled.
The only structural answer is to have no US provider in the chain. Not in hosting, not in the database, not in object storage, not in email delivery, and — increasingly the one people forget — not in AI inference.
That last omission is common right now. An organisation moves its application to a European host, congratulates itself, and then routes every AI feature through a US model provider. Prompts carrying programme context leave the jurisdiction on every call, and in many cases the provider reserves the right to train on them.
The questions worth asking a supplier
If you are evaluating anything that will hold programme governance data, these four get you further than "where is it stored":
- Which legal entity operates the infrastructure, and under which country's
law is it incorporated?
- Name every subprocessor, including email delivery and any AI provider, and
the jurisdiction of each.
- Does any provider in that chain reserve the right to train models on
customer data?
- If a subprocessor changes, how and when are we told, and can we object?
A supplier with a genuine position answers all four in a paragraph. A supplier with a region setting answers the first one and starts talking about certifications.
Where TransformRadar stands
We built TransformRadar on European providers end to end because retrofitting this is close to impossible. Hosting and PostgreSQL run on Clever Cloud in Paris, a French company. Object storage is Clever Cloud Cellar. Transactional email goes through Brevo in France. AI inference runs on Mistral La Plateforme in Paris, and no provider that reserves the right to train on customer data is eligible to be in the chain at all.
There is exactly one way data can leave that boundary, and it is a decision the customer makes: an organisation may connect its own external AI agent over the Model Context Protocol. It is off by default, and an organisation administrator has to acknowledge the egress before it can be switched on. We would rather have one explicit, opt-in exception than a footnote in a subprocessor list.
You can read the full detail on the EU hosting page, including how tenant isolation is enforced in the database rather than in application code.
- EU sovereignty
- governance
- procurement