Sovereign cloud
In shortSovereign cloud is not a protected term. Ask which of the four layers the provider actually means.
At a glance
- Legal protection of the term
- None — there is no binding definition and no mandatory certification
- Four layers
- Ownership and legal form, operations and staff access, technology, data-centre location
- Most common market reading
- The bottom layer only: a data centre in the EU, everything else unchanged
- Strictest reading
- European owner, European operations staff, open or own technology, customer-held keys
- Middle form
- European operator on licensed US technology — sovereign by contract, dependent in the supply chain
- Verified through
- Company register, sub-processor list, access matrix, description of key management
"Sovereign cloud" is not a protected term. There is no definition a provider must observe and no body checking how it is used. Two offerings carrying the same label can therefore mean entirely different things.
The term only becomes usable once you break it into four layers and ask, per layer, what is actually promised.
The four layers
Ownership and legal form. Which law does the parent company answer to? This layer decides the reach of the US CLOUD Act and is the only one that can exclude a disclosure order completely. It is also the only one that can change overnight — through an acquisition.
Operations and staff. Who holds administrative access to production systems, from which countries, in which cases, logged how? This layer decides everyday reality. A European provider with support from a third country has a gap here that the contract often mentions only in an annex.
Technology. Own development, open building blocks, or licensed third-party technology? This layer is rarely discussed and matters for sanctions, loss of licence and long-term maintainability.
Location. Where do the data centres stand? Easiest to verify, most advertised, least meaningful. What location claims deliver and what they do not is set out under Data residency.
The middle case worth knowing
There are offerings operated by a European company, exclusively with European staff, for European customers — and running technically on licensed technology from an American corporation.
That can be an entirely correct decision. Such arrangements hold up against access requests, because the operator has control. They do not hold up against loss of licence, sanctions or discontinuation of the product. The distinction is not pedantry; it decides which scenario you have covered.
How to assess an offering
Four questions that together cost half an hour:
Who owns the operating company, and when did that last change? Company registers and investment announcements are public.
Who can access production data during an incident, and from which country? The answer belongs in the contract as an access matrix.
Who manages the keys? The three tiers are set out under Key control.
What does the technology run on, and what happens if the licence goes?
Anyone who gets solid answers to all four no longer needs the word "sovereign" — they have something better: four verifiable commitments.
Common questions
- Is a sovereign cloud automatically GDPR-compliant?
- No. The terms overlap only partly. A provider can satisfy all four layers and still have a poor processing agreement — and conversely a US provider can present formally clean contracts while remaining subject to the CLOUD Act.
- What to make of offerings running on licensed US technology?
- They can be the right choice. Sovereignty there comes from the contract and the operating model, not from independent technology. That holds against access requests but not against loss of licence or sanctions. Know which kind of safety you bought.
- Which question exposes marketing fastest?
- "Who can access production data during an incident, from which country, and how is it logged?" Providers who only talk about locations become evasive at exactly this point.
- Do small companies need this?
- Rarely as a complete package. It is more useful to assess the layers separately for your own data categories: for bookkeeping a European provider often suffices, while design data may call for key control.