EU data residency is not EU jurisdiction

Almost every large authentication provider now offers to store your users’ data in Frankfurt or Dublin. It is a real feature and it solves real problems — latency, and the parts of the GDPR that concern where data physically sits.

It does not answer the question a procurement or legal reviewer is actually asking, which is not where is the data but whose law can compel its disclosure. Those are different questions, and one statute and two judgments explain why.

The statute says the location of the data is irrelevant

The CLOUD Act of 2018 added § 2713 to the United States Code. It is one sentence, and the last twelve words are the whole issue:

The operative test is possession, custody, or control — a property of the provider, not of the disk. A company subject to US jurisdiction that controls data stored in Frankfurt is, by the plain text of the section, obliged to produce it. Choosing the German region does not change which company controls the data, and therefore does not change the answer.

The Court has struck the bridge down twice

Transfers of personal data out of the EU are governed by Chapter V of the GDPR, which permits them on a small set of grounds — chiefly an adequacy decision, or appropriate safeguards such as standard contractual clauses. The comfortable path has always been an adequacy decision covering the United States. That path has now been closed twice.

In 2015, the Court of Justice declared the Safe Harbour decision invalid. Its reasoning was structural rather than incidental: the scheme bound US companies that signed up to it, but not the US public authorities, and national security and law enforcement requirements took precedence over the scheme itself.

In 2020, the Court did it again to the framework that had replaced it: the Grand Chamber invalidated the Privacy Shield adequacy decision, while holding that the standard contractual clauses decision remained valid. That combination is what created the position European buyers have been in ever since — the clauses are lawful instruments, but using them obliges the exporter to assess whether the destination country’s law actually permits the guarantees to be honoured.

We are not predicting the fate of the current framework, and nobody honest can. The point is narrower and it is historical: a European company that built on the assumption of a stable adequacy decision has now had to re-paper its transfers twice in a decade. That is a real operational cost, and it recurs.

What actually differs between “EU region” and “EU company”

What we will not claim, and why

There is a version of this argument that overreaches, and it is common enough in European sovereignty marketing to be worth naming.

• “Immune to the CLOUD Act.” Nobody can promise this. What is defensible is a structural statement: an EU-incorporated provider with no US entity in its ownership chain is not the addressee of § 2713. That is a statement about who the law reaches, not a guarantee about every conceivable legal process anywhere.
• “Sovereign” as a certification. It is not one. There are real qualifications — SecNumCloud in France, BSI C5 in Germany, ISO 27001 everywhere — and a provider either holds one or does not. A scheme that is in process is not a scheme that is held.
• “GDPR compliant” as a product property. Compliance is a property of your processing, not of a vendor’s logo. What a processor can honestly offer is an Article 28 agreement, a published sub-processor list, documented sub-processor change notice, and the technical measures under Article 32 — all of which are checkable.

The checks worth running on any provider

None of these require a sales call, and all of them are answerable from public documents. If a vendor makes them hard to find, that is itself the answer.

1. Which legal entity signs the contract, and where is it incorporated? Read the terms of service or the imprint, not the marketing page. A European sales entity fronting a US contracting entity is common and entirely legal — it just does not change the jurisdiction.
2. Is there a published sub-processor list, and what is on it? A single US sub-processor in the authentication path — an email provider, an error tracker, a support tool — reopens the whole question no matter where the primary database lives.
3. Is EU residency available on your plan, or only on enterprise? Residency gated behind the top tier is a pricing decision that becomes a compliance problem the moment you scale down.
4. Can you get your users out, including password hashes? Portability is what turns a compliance argument into a negotiating position. If an export omits the hashes, migrating means asking every user to reset their password — which in practice means not migrating.
5. Which certifications are held, and which are “planned”? Both answers are acceptable. Presenting the second as the first is not.

Adetio exists because of the second row of that table: we are building an identity platform whose operating entity, infrastructure and data all sit under EU law, so that the transfer question does not arise rather than being managed. Where we are not yet finished, the trust centre says so — with what is in place today and what is on the roadmap stated separately, because a compliance page that blurs the two is the exact thing this article is arguing against.