Sovereign is suddenly everyone's word. How to tell the label from the thing.
Sovereign cloud is having a moment. But when a German chancellor, an American hyperscaler and the European Commission all use the same word to mean slightly different things, buyers need to ask what it actually means.
Until recently, “sovereign cloud” meant roughly the same thing to most European buyers: a European provider, European servers, European law.
That quiet consensus is over.
Three developments have put the word under new pressure.
At the Digital Summit in Berlin, German Chancellor Friedrich Merz defended a plan to run the shared cloud of Germany’s intelligence services on Google infrastructure. His argument: European sovereignty is possible “with an American provider”.
On 24 October, AWS deliberately disconnected its European Sovereign Cloud from two global AWS systems in a live operational exercise, demonstrating that it could continue running without them.
And on 4 November, a revised draft of the EU’s Cloud and AI Development Act surfaced in Brussels, reportedly giving public buyers more flexibility in choosing the sovereignty requirements they demand.
Three different approaches. One increasingly contested word.
That’s good news. Sovereignty deserves serious attention. But as the term becomes more popular, it also becomes more elastic. And an elastic definition is a dangerous thing to put in a procurement contract.
What sovereignty actually means
Sovereignty has never been about disliking foreign providers. It is about control.
There are four questions every buyer should be able to answer:
- Jurisdiction: Who can be compelled to hand over your data, and under which country’s laws?
- Operations: Who controls the people and systems that can access or affect your data?
- Technology: Who controls the software, updates and infrastructure your cloud depends on?
- Exit: What happens to your data and workloads if you decide to leave?
A server in Frankfurt tells you where the bits sleep. The provider’s legal home tells you who might be able to knock on the door. The people maintaining the system determine who has operational control.
These are different dimensions of sovereignty. They should never be confused.
And no marketing budget can make them the same.
Three approaches, one word
To be fair, none of the three developments is simply a story about good guys and bad guys. Each represents a different interpretation of what sovereignty requires.
Germany and Google: sovereignty through operational control
The proposed intelligence cloud would use an air-gapped version of Google Distributed Cloud for Germany’s federal intelligence services.
Merz’s argument is straightforward: the infrastructure is in Germany, the system is isolated from the public internet, and its operation is subject to German security requirements. Why should the nationality of the provider automatically disqualify it?
It’s a reasonable question.
The system is expected to undergo security assessment by Germany’s Federal Office for Information Security (BSI). But there is a dependency that no air gap can entirely eliminate: software maintenance.
Even an isolated cloud needs patches, updates and new versions. Those ultimately depend on the vendor, even if their delivery is tightly controlled and there is no direct remote connection.
That creates a particular kind of trust relationship. Instead of relying exclusively on European ownership or jurisdiction, the buyer relies on technical safeguards, operational arrangements and the provider’s continued cooperation.
That may be a legitimate choice. But it is a choice, not the absence of dependency.
AWS: sovereignty through technical and operational separation
AWS is making a different argument, backed by substantial investment and a more explicit engineering proposition.
Amazon announced plans to invest more than €7.8 billion in its European Sovereign Cloud in Germany. The service, which became generally available in January 2026, is designed to operate as a physically and logically separate cloud environment, with European infrastructure, governance and operational teams.
Its most interesting feature is not the investment figure. It is the attempt to demonstrate operational independence.
On 24 October, AWS conducted a live exercise in which it switched off two systems normally used by the European Sovereign Cloud: the AWS Global Network backbone and a dedicated system for controlled transfers of operational AWS data.
Traffic normally carried over the private AWS backbone was rerouted through European internet connections. The European cloud continued running on its own hardware and software resources, operated by EU-resident staff. AWS reported that workloads continued running and customers retained access to their data.
This matters. It takes a claim about independence and puts it to a practical test.
But the test also has limits.
It demonstrated that the European Sovereign Cloud can operate without those two global AWS systems. It did not demonstrate independence from every element of the wider technology supply chain, nor did it resolve questions about the legal jurisdiction of its American parent company.
For critics who define sovereignty primarily through ownership and jurisdiction, that remains decisive. For those who focus on operational control and technical separation, AWS has provided meaningful evidence.
Both sides are using the same word. They are measuring different things.
Brussels: sovereignty through common standards
The European Commission is trying to give buyers a common vocabulary for making these distinctions.
Its proposed Cloud and AI Development Act (CADA) introduces four assurance levels for cloud and AI sovereignty. They range from data being stored and processed in EU infrastructure to much stronger requirements around independence from third countries, EU ownership and control, and protection against third-country interference.
The idea is important: instead of asking whether a cloud is simply “sovereign”, public buyers should be able to specify the level of sovereignty they require.
A revised draft reported by MLex on 4 November reportedly gives buyers more flexibility in choosing those levels.
That could be progress. Different workloads have different risk profiles. A public website does not need the same protections as an intelligence database or a critical national infrastructure system.
But flexibility without clear criteria simply moves the ambiguity from the provider’s marketing material into the procurement process.
And CADA is still a legislative proposal, not an established procurement regime.
How to tell the label from the thing
The checks are straightforward. They should apply to every provider, including those with the strongest sovereignty credentials.
-
Ask who can be compelled, and get the answer in writing.
Don’t just ask where your data is stored. Ask under which laws the provider can be compelled to disclose it.
A European data centre does not automatically protect you from the laws governing the company that operates it.
If the provider is subject to a jurisdiction outside Europe, understand what that means for your data, even when every server is physically located inside the EU.
-
Ask who controls the people and the updates.
An air-gapped server still needs maintenance, patches and software updates. Someone develops, signs and delivers them.
Find out who has privileged access, where those people are based, who employs them and how software updates are controlled.
Technical separation is valuable. But it does not automatically eliminate external dependencies.
-
Make the word contractual.
“Sovereign” on a presentation slide is marketing.
In a contract, it should mean something specific: defined jurisdictions, operational responsibilities, access restrictions, audit rights and enforceable liabilities.
If a provider cannot translate its sovereignty claims into contractual commitments, you have little to rely on when circumstances change.
-
Run the exit test.
Try exporting your data, configurations and workloads. Find out what it costs, how long it takes and what you lose along the way.
Can you move your applications to another provider? Can you retrieve your data in a usable format? Are there proprietary dependencies that make leaving prohibitively expensive?
A provider that makes leaving difficult is asking you to trust its promises indefinitely.
The ability to leave is not separate from sovereignty. It is one of its conditions.
What to do this month
Start with your current cloud provider. Ask one question in writing:
Under which jurisdictions can this company be compelled to disclose our data?
Then work through the other three checks: operations, technology and exit.
Record what you know, what the provider promises and what you can actually verify.
If the answers give you confidence, stay. Sovereignty includes the freedom to choose a provider and the freedom not to change it.
If they don’t, at least you know where your dependencies are. And the European market has never offered more options for addressing them.
“Sovereign” is having a moment. Use it to ask better questions, not to collect another badge.
Because a cloud can demonstrate that it runs without its parent company’s global network. That is meaningful technical and operational independence. But it does not, by itself, settle the question of legal jurisdiction or strategic dependency.
A label is a claim. Control is the proof.
Sources
- Heise: Merz says Google Cloud is sovereign enough for intelligence agencies (Digital Summit Berlin, November 2026)
- ComputerBase: the German intelligence cloud and the sovereignty debate (November 2026)
- Techzine, interview with Mustafa Isik (AWS Chief Technologist for Sovereignty): AWS proves its European Sovereign Cloud runs fully independently (3 November 2026)
- MLex: Revised EU sovereign cloud bill gives public buyers more flexibility (4 November 2026)
STAY INFORMED
New guides, straight to your inbox.
We publish a new guide regularly. No spam, no sales pressure. Just an email when there is something worth reading.
Email address
Notify me →