What is sovereign cloud, really? The 4 levels of EU cloud sovereignty and what each one guarantees

Key Points

• Sovereign cloud has no single EU-wide legal definition. In practice it comes in four levels: (1) EU data residency, (2) EU operational controls on a US hyperscaler, (3) a locally operated sovereign cloud run by an EU entity under licence, and (4) an EU-owned, EU-operated provider with no non-EU parent.
• EU data residency guarantees only where data sits. Under the US CLOUD Act (2018), a US-headquartered provider must produce data in its possession, custody or control "regardless of whether" it is located inside or outside the United States (18 U.S.C. 2713).
• Only level 4 removes extraterritorial exposure by ownership. Levels 2 and 3 cut practical risk with EU-resident operators, customer-held keys and EU-only support, but the parent company's jurisdiction is a legal fact, not a configuration setting.
• Certifications turn a claim into an audit. France's SecNumCloud 3.2 tests ownership and immunity from non-EU law, Germany's BSI C5 tests controls but ignores jurisdiction, and the EU-wide EUCS scheme is still unfinished because member states disagree on exactly this point.
• Most companies do not need level 4 everywhere. Decide per workload, then keep the level reversible: containers on Kubernetes, infrastructure in Terraform or OpenTofu, in a cloud account you own. Qovery deploys into your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster including an EU-owned provider or on-prem, so changing level stays a procurement decision instead of a rewrite.

Sovereign cloud gets sold as a product. It works more like a ladder with four rungs, and most vendors sell rung one or two using rung four's vocabulary.

I have interviewed more than 200 CTOs over the years, and in the last two years "sovereignty" has gone from a public-sector curiosity to a line item in ordinary enterprise deals. When I ask what the buyer actually means by it, I rarely get the same answer twice. This is the explainer I wish I could have sent the last CTO who asked me "do we need a sovereign cloud?".

What is sovereign cloud, really?

Sovereign cloud means cloud infrastructure where the data, the people who operate it, and the legal entity that controls both sit under a jurisdiction you choose, normally the EU. No single EU law defines it and no single certification makes a cloud sovereign, which is why one word sells four very different products.

The shortest way I can put it: data residency is a location; sovereignty is a jurisdiction, plus an operator, plus an exit you have tested.

Every sovereignty claim mixes three dimensions:

• Data sovereignty: where the data sits and whose law applies to it.
• Operational sovereignty: who can touch the systems, from which country, and under what approval process.
• Technical sovereignty: whether you can audit it, hold your own encryption keys, and leave.

The term took off for legal reasons. In July 2020 the Court of Justice of the EU invalidated the EU-US Privacy Shield in Schrems II while keeping Standard Contractual Clauses alive, subject to case-by-case assessment (CJEU press release 91/20). Add the 2018 CLOUD Act, FISA Section 702, and steadily rising national procurement pressure, and buyers started asking whose law governs their cloud, not only where it runs. A Gartner survey published in November 2025 of 241 Western European CIOs and IT leaders found 61% expect geopolitics to increase their reliance on local or regional cloud providers.

The frameworks with teeth today are national: France's SecNumCloud, Germany's BSI C5, Spain's ENS and the Dutch government baseline BIO. The EU-wide EUCS scheme is still a candidate (ENISA).

Gaia-X confuses people constantly, so here are two sentences on it. Gaia-X is a Brussels-based association that publishes specifications, rules and a compliance framework with label levels (Gaia-X). You cannot deploy anything to Gaia-X; you can only check whether a provider's offer meets one of its labels.

What are the four levels of EU cloud sovereignty, and what does each one actually guarantee?

The four levels are EU data residency, EU operational controls on a US hyperscaler, a locally operated sovereign cloud run by an EU entity under licence, and a fully EU-owned and EU-operated provider. Each level guarantees strictly more than the one below it, and each costs more in money, service breadth or engineering effort.

Level 1, EU data residency. You pick an EU region on any cloud and your data at rest stays there. That guarantees physical location, and that is all. Support staff, telemetry, metadata and the legal reach of the parent company can all sit elsewhere.

Level 2, EU operational controls on a US hyperscaler. This covers the AWS European Sovereign Cloud, Microsoft's EU Data Boundary and Sovereign Cloud offerings, and Google Cloud's sovereign controls. These are serious engineering efforts. AWS launched its European Sovereign Cloud in Brandenburg on 15 January 2026, backed by a planned investment of more than €7.8 billion, run by German subsidiaries led by EU citizens and "operated exclusively by EU residents" (Amazon). Microsoft committed on 30 April 2025 to "challenge any government demand for EU public sector or enterprise customer data where we have a legal basis" (Microsoft). What none of them changes is the nationality of the ultimate parent.

Level 3, locally operated sovereign cloud. Hyperscaler technology, operated by an EU-controlled company. Delos Cloud is an SAP subsidiary delivering Microsoft technology to the German public sector, with Arvato Systems. S3NS is the Thales-majority joint venture running Google Cloud technology in France, and its PREMI3NS offer is SecNumCloud qualified (Thales). Bleu is owned by Orange and Capgemini and runs Microsoft technology. T-Systems operates a sovereign cloud powered by Google Cloud in Germany. You get an EU operator; the software supply chain and the roadmap stay with the US vendor.

Level 4, EU-owned and EU-operated. OVHcloud, Scaleway, IONOS, StackIT, Hetzner, Exoscale, Elastx and UpCloud. No non-EU parent means no CLOUD Act exposure through ownership. The trade-off is real: narrower managed-service catalogues, fewer regions, a much smaller GPU footprint and a smaller ecosystem. AWS lists 39 geographic regions (AWS), while OVHcloud lists 46 data centres across 4 continents (OVHcloud) and most level-4 providers run a handful of regions concentrated in Europe. The market reflects the gap: AWS, Microsoft and Google hold about 70% of European cloud spend, European providers about 15% (Synergy Research Group, July 2025).

Whatever level a vendor claims, put these five questions to them in writing:

1. Who can reach the control plane, and from which countries?
2. Where are support staff located, and can a non-EU engineer escalate into my tenant?
3. Who holds the root key of the key management service?
4. Which metadata, logs and telemetry leave the EU?
5. What is the documented exit procedure, and what does it cost?

The ladder applies per workload, not per company. Running customer data at level 3 or 4 and CI at level 1 is normal, defensible, and what I see most often.

Does storing data in an EU region make it sovereign? (the CLOUD Act question)

No. The CLOUD Act reaches data in a provider's "possession, custody, or control" regardless of where it is stored, so an EU region run by a US-headquartered company does not by itself remove extraterritorial exposure (18 U.S.C. 2713). Residency is a storage fact; sovereignty is a jurisdiction fact.

In plain English: a US court can order a US provider to hand over customer data it controls, wherever the disk sits. The provider has a statutory right to move to quash or modify the order when the customer is not a US person and disclosure would risk breaching foreign law (18 U.S.C. 2703(h)). That is a legal fight the provider may choose to have, not a guarantee.

FISA Section 702 mattered more in Schrems II than the CLOUD Act. It authorises surveillance targeting non-US persons abroad with compelled help from US providers (50 U.S.C. 1881a), and the CJEU found it lacked proportionality and effective redress. Section 702 lapsed at midnight on 12 June 2026 when Congress failed to reauthorise it (EFF), and the fight over its return is ongoing. I go deeper on this in what FISA 702 means for US cloud providers in Europe.

The EU-US Data Privacy Framework is live but contested. The Commission adopted its adequacy decision on 10 July 2023 (European Commission). On 3 September 2025 the General Court dismissed Philippe Latombe's challenge in Case T-553/23, ruling on the law as it stood in 2023 and stressing the Commission must keep monitoring US law (IAPP). The judgment was open to appeal to the Court of Justice and NOYB said it was reviewing its own challenge. As of November 2026, treat the DPF as valid and check the case file on curia before you build a contract on it.

Below level 4, several controls genuinely cut risk. Each has limits worth knowing:

I want to be fair here. For most private-sector companies, a level-2 setup with customer-held keys and a documented Transfer Impact Assessment, following the EDPB Recommendations 01/2020 on supplementary measures, is a defensible, auditable posture that passes enterprise security review.

CISOs rightly push back the other way too. EU-owned does not automatically mean better security, better uptime or better incident response, and concentration risk on a single provider exists at every level.

Which certifications and regulations give a sovereignty claim teeth: SecNumCloud, BSI C5, EUCS, NIS2, DORA and the EU Data Act?

Only a few frameworks make a sovereignty claim auditable. France's SecNumCloud 3.2 is the strictest because it tests ownership and immunity from non-EU law, Germany's BSI C5 is a strong control framework that is deliberately jurisdiction-neutral, and the EU-wide EUCS remains unfinished precisely because member states cannot agree on sovereignty requirements.

SecNumCloud 3.2. Chapter 19.6 requires the provider's registered office and main establishment to be in the EU, and caps the capital and voting rights held by non-EU entities at 24% individually and 39% collectively (ANSSI, SecNumCloud 3.2). ANSSI keeps the official list of qualified providers; check it rather than a vendor slide. I compared how one platform handles both regimes in SecNumCloud vs BSI C5.

BSI C5, ENS and BIO. Strong control catalogues covering security organisation, operations, cryptography and supplier management. None of them tests who owns the provider, which is why a US hyperscaler can hold C5 and still sit at level 1 or 2.

EUCS. The candidate scheme under the Cybersecurity Act stalled over whether to include immunity-from-non-EU-law requirements at the highest assurance level. ENISA still publishes it as a candidate (ENISA), and as of November 2026 I have not seen an adopted implementing act. Gaia-X Label Level 3 fills part of the gap on paper: it requires EU headquarters, no non-EU control, and all customer data processed and stored in the EU/EEA (Gaia-X compliance criteria).

NIS2, DORA and the Data Act are not sovereignty laws, but they force sovereignty questions. NIS2 makes essential and important entities answer for supply-chain and subcontractor risk; on 7 May 2025 the Commission sent reasoned opinions to 19 member states for failing to notify full transposition (European Commission). DORA requires financial entities to keep a register of ICT third-party arrangements and documented exit strategies (EUR-Lex). The Data Act requires cloud providers to support switching, and from 12 January 2027 they can no longer charge switching fees, including data egress for the move (EUR-Lex, Article 29). That last one changes the exit-cost maths: staying at level 1 gets less risky when leaving gets cheaper.

A quick by-sector read: public sector in France usually means SecNumCloud; health in France adds HDS certification; finance means DORA registers and exit plans first; defence means national schemes and usually level 4; B2B SaaS means GDPR transfer documentation plus whatever your largest customer writes into the contract.

Which sovereignty level does my company actually need?

Most companies do not need level 4 everywhere. Public-sector, defence, health and critical-infrastructure workloads often do; a B2B SaaS selling to EU enterprises typically needs level 1 or 2 plus customer-held keys, a documented Transfer Impact Assessment and a tested exit.

Run each workload through five questions:

1. Is the data classified, or special-category under GDPR Article 9?
2. Does your buyer impose SecNumCloud or an equivalent national scheme?
3. Are you an essential or important entity under NIS2, or a financial entity under DORA?
4. Are you training models on EU personal data?
5. Does a single EU public tender represent material revenue?

One "yes" pushes that workload up the ladder. Five "no" answers usually mean level 1 or 2 is enough.

Jumping to level 4 too early has a cost: fewer managed services, limited GPU availability, more platform work in-house and a smaller hiring pool. Staying at level 1 too long has one too: blocked procurement, lost public-sector deals, and re-architecting under a contractual deadline.

Before choosing anything, answer this: how long would it take to run production in a different provider's region today, and have you ever tested it? If the answer is "months" and "no", portability is your real sovereignty problem, and it survives a change of law, a change of vendor and a change of CTO.

How do I stay portable so sovereignty stays a procurement decision, not a rewrite?

Portability is the only sovereignty hedge that does not depend on a vendor's promise: run workloads as containers on Kubernetes, describe infrastructure in Terraform or OpenTofu, prefer data services with an open-protocol equivalent, and keep the deployment workflow independent of the cloud underneath.

Four rules I give every team:

1. Containers over proprietary runtimes. A container image runs on every level of the ladder.
2. Open-protocol data services. PostgreSQL, Redis, Kafka and S3-compatible object storage exist at every major provider.
3. Terraform or OpenTofu for infrastructure. Your environment becomes a file you can re-apply elsewhere.
4. A rehearsed exit test with a date on the calendar. An untested exit plan is a hope.

Lock-in bites hardest in serverless function runtimes, proprietary queues and streams, IAM-coupled identity, data gravity plus egress, and managed-service features you cannot reproduce. Kubernetes itself adds a running cost: the project maintains the three most recent minor releases and gives each roughly a year of patch support (Kubernetes), so self-managed clusters need upgrading every few months.

This is where Qovery fits, and I will be direct about how. Qovery is an internal developer platform that deploys into your own cloud account: AWS, GCP, Azure, Scaleway, or your existing Kubernetes cluster, including one at an EU-owned provider or on-prem. The cloud contract, the data and the bill stay in your name, and your Savings Plans or committed-spend discounts stay yours.

In sovereignty terms, you choose the jurisdiction, the provider and the region. Qovery gives developers git-push deployments, preview environments per pull request, auto-stop for non-production environments, managed cluster upgrades and per-environment RBAC on top. You get Kubernetes without a dedicated DevOps engineer babysitting it.

The honest limitation: an IDP control plane is itself a third party. Ask any IDP vendor what its control plane stores, where it runs, and what happens to your clusters if you stop paying. Ask Qovery the same questions, and hold us to the answers.

The pattern I see working: one developer workflow, production in an EU-owned cloud or a self-managed EU Kubernetes cluster, and non-sensitive environments wherever is cheapest. Here is what it looks like to run the same workloads on an EU cloud and AWS.

How do I deploy to the cloud I chose from Claude Code or Cursor?

Install the Qovery Agent Skills once, then ask your coding agent in plain language to deploy into the cloud account or Kubernetes cluster that matches your sovereignty level. The agent handles setup and asks you to approve each step.

Install the skills for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI). The script asks you to approve the install path:

curl -fsSL https://skill.qovery.com/install.sh | bash

For a project-scoped install instead of a global one:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the Qovery MCP Server to Claude Code. It uses OAuth, opens a browser for approval, and is read-only by default:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you explicitly want it. This also requires enabling write access in the Qovery Console:

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) set things up and deploy. The MCP Server operates what already exists. Then ask in plain language: "deploy this app to my Scaleway account with Qovery" or "deploy this to my existing EU Kubernetes cluster".

Full setup is in the AI agent quickstart and the Claude Code integration page.