Is an EU region of a US cloud provider sovereign?

It gives you data residency, not legal sovereignty. The data stays in the EU, but the US parent remains subject to US law, including the CLOUD Act, so it can be compelled to produce data held anywhere in its estate. If your requirement is immunity from non-EU jurisdiction, an EU region alone does not meet it.

Does encryption make a cloud sovereign?

Only if you exclusively hold the keys, outside the provider’s reach. If the provider manages the keys, or can be compelled to produce them along with the data, encryption raises the effort but does not change who has legal control. Customer-held keys help operational sovereignty; they do not by themselves grant jurisdictional immunity.

Which sovereignty layer does my regulator care about?

It depends on the regime. GDPR concerns lawful transfer and access to personal data. Sector rules like DORA and NIS2 focus on operational resilience and third-party control. French state doctrine and SecNumCloud target legal immunity for sensitive data. Map your requirement to the layer before you shortlist providers.

Sovereignty explained

What sovereign cloud actually means

"Sovereign cloud" is sold as a single feature. It is really three separate guarantees, and a provider can offer one while quietly missing the other two. This page separates data residency, operational sovereignty and legal immunity, so you can tell which one a vendor is actually selling you, and which one your regulator or your board actually asked for.

This is general information about cloud sovereignty, not legal advice. For a binding view on your obligations, ask a qualified lawyer.

The three layers people conflate

Sovereignty is not one property. Data residency is about where bytes sit at rest. Operational sovereignty is about who can touch the running system: which staff, under which jurisdiction, with which support and administrative access. Legal sovereignty, sometimes called jurisdictional immunity, is about whose law can compel the provider to hand data over, regardless of where it is stored.

A vendor can pass the first and fail the last. An EU region owned by a US company keeps your data in Frankfurt and still leaves the parent subject to US production orders. Residency answers a storage question; immunity answers a control question. Buyers routinely ask for the first when their regulator meant the third.

Data residency: necessary, not sufficient

Data residency means the provider commits to storing, and often processing, your data inside a chosen geography, typically the EU or a single member state. It is the easiest layer to deliver and the easiest to verify: you pick an EU region and your objects, databases and backups stay there.

It stops there. Residency says nothing about who administers the platform, where support engineers sit, or which government can lawfully demand a copy. Treating an "EU region" as sovereignty is the most common and most expensive misreading, because it feels like the box is ticked when only the shallowest layer is.

Operational sovereignty: who holds the keys

Operational sovereignty covers the humans and processes with privileged access. Can a support engineer outside the EU assume an administrative role on your tenant? Are encryption keys held by you, by the provider, or by a hardware module the provider ultimately controls? Is the control plane, the APIs that create and destroy your resources, operated from inside the same jurisdiction as the data?

This is where residency-only "sovereign" offers tend to leak. The data sits in-region, but the platform is still administered globally, patched globally and supported globally. For a regulated workload, the administrative boundary matters as much as the storage boundary.

Legal sovereignty: whose law reaches the provider

Legal sovereignty is the layer residency cannot buy. It asks a single question: if a non-EU authority serves a lawful order on the provider or its parent, is the provider compelled to comply? For a company subject to US law, the answer under the CLOUD Act is yes, wherever the servers are.

Immunity from extra-EU law is therefore a function of ownership and control, not geography. It is the criterion the French SecNumCloud qualification puts at its centre, and the one a data-residency guarantee, on its own, never addresses.

What "sovereign" does not guarantee

There is no single legal definition of "sovereign cloud" in EU law, which is exactly why the word is contested. The EU cloud certification scheme (EUCS) spent years debating whether a "high" assurance level should require immunity from non-EU law at all, and the sovereignty criteria were softened and reintroduced more than once. A vendor calling itself sovereign is describing a marketing position, not a certified fact, unless it names a specific scheme and level.

So the honest answer is to ask which layer. "Sovereign" with no qualifier usually means residency. If your requirement is legal immunity, residency will not satisfy it, and no number of EU datacentres changes the jurisdiction the provider’s parent answers to.

Common questions about sovereign cloud

Is an EU region of a US cloud provider sovereign?: It gives you data residency, not legal sovereignty. The data stays in the EU, but the US parent remains subject to US law, including the CLOUD Act, so it can be compelled to produce data held anywhere in its estate. If your requirement is immunity from non-EU jurisdiction, an EU region alone does not meet it.
Does encryption make a cloud sovereign?: Only if you exclusively hold the keys, outside the provider’s reach. If the provider manages the keys, or can be compelled to produce them along with the data, encryption raises the effort but does not change who has legal control. Customer-held keys help operational sovereignty; they do not by themselves grant jurisdictional immunity.
Which sovereignty layer does my regulator care about?: It depends on the regime. GDPR concerns lawful transfer and access to personal data. Sector rules like DORA and NIS2 focus on operational resilience and third-party control. French state doctrine and SecNumCloud target legal immunity for sensitive data. Map your requirement to the layer before you shortlist providers.