What if the hardest part of building a sovereign cloud had nothing to do with where the servers sit? That question unsettles a lot of boardroom assumptions. A government or regulated bank can insist that its data stays inside national borders and still end up with a platform that is expensive, slow to change, and legally exposed. The location of a data center is the simplest box to tick. Everything that makes sovereignty real, from who holds encryption keys to who can answer a support ticket, is harder.
This article looks at the practical obstacles organizations hit when they move toward sovereign cloud arrangements, why those obstacles exist, and what tends to work when teams stop treating sovereignty as a checkbox.
What “Sovereign Cloud” Actually Means in Practice
There is no single agreed definition of a sovereign cloud. In broad terms, it describes cloud infrastructure and services where the customer’s data, operations, and legal control sit within a specific jurisdiction, with restrictions on foreign government access. Vendors and regulators use the phrase differently, which is itself a problem: two providers can both advertise “sovereign” offerings that mean very different things.
A useful way to think about it is as a stack of layers, each of which can be more or less sovereign. Data residency is the bottom layer. Above it sit operational control, personnel access, encryption key ownership, legal jurisdiction over the provider, and technical independence from foreign platforms. A provider can score well on the bottom layer and poorly on the rest.
That gap is where most of the real challenges live. Teams that inventory only the data residency layer often discover later that support engineers in another country can access their systems, or that the provider’s parent company is subject to laws the customer never considered. Getting the inventory right before committing is the same discipline that underpins any careful migration planning, and it pays off here too. Our guide to what to inventory before a cloud migration covers the asset and dependency mapping that sovereignty reviews depend on.
The Legal Layer: Residency Is Not the Same as GDPR Compliance
A common mistake is assuming that the EU’s data protection rules require data to stay in Europe. They do not. The General Data Protection Regulation governs how personal data is processed and transferred, but it does not by itself impose a localization requirement. Sovereignty demands usually go further than compliance: control over operations, personnel, and encryption keys, with a lawful transfer mechanism as only one part.
The legal landscape shifted sharply with the Court of Justice of the EU’s ruling in Case C-311/18, commonly called Schrems II, in July 2020. The court invalidated the EU–US Privacy Shield over concerns about US surveillance access to European data. A successor mechanism, the EU–US Data Privacy Framework, was adopted in July 2023, but its durability has been questioned by privacy advocates, and organizations watching the space treat legal challenges as a live risk rather than a settled matter.
On top of that sits the US CLOUD Act, enacted in 2018, which allows US authorities to compel US-based providers to produce data they control even when it is stored abroad. That is the central tension for any sovereignty strategy: a provider can host data in Frankfurt and still be subject to US legal process. No amount of local data center construction changes the provider’s jurisdiction of incorporation.
The practical lesson is that legal review has to look beyond the region code in the console to the corporate structure behind the service. Procurement teams that ask “where is the data?” and stop there are asking half a question.
Operational Sovereignty: Keys, People, and the Support Ticket Problem
Ask a security architect what actually determines sovereignty and the answer usually starts with keys. If a provider holds the encryption keys, or can be compelled to hand them over, then residency is a comfort rather than a control. Customer-managed keys and, increasingly, hold-your-own-key arrangements are where sovereignty claims get tested.
The second test is people. Who can access the systems operationally? A platform may store data locally while routing support requests to staff in another jurisdiction. Some sovereign offerings address this by promising that only nationals of the relevant country can access systems, which sounds reassuring until you ask how that promise is audited and what happens during a major incident at 3 a.m.
A third test is the shared responsibility model. Sovereignty is often marketed at the infrastructure layer, but customers configure identity, networking, and logging themselves. A misconfigured storage bucket in a sovereign region is still a breach. This is why governance discipline matters as much as provider choice, and why splitting sensitive workloads across separate accounts with tighter controls is a common pattern. Our piece on when to split workloads across cloud accounts explains how account boundaries can be used to isolate regulated data.
Common Mistakes in Sovereign Cloud Programs
A few patterns show up again and again:
- Treating “region” as “sovereignty.” Choosing a local region without reviewing the provider’s ownership, key management, and support model.
- Skipping the exit plan. Signing a multi-year sovereign deal with no tested path to move data and workloads out.
- Ignoring the operational layer. Assuming the provider’s sovereignty claims cover the customer’s own configuration errors.
- Underestimating cost. Sovereign environments often carry a premium that was never modeled against the business case.
- Forgetting the skills gap. Teams trained on mainstream hyperscaler tooling find sovereign platforms unfamiliar and slower to operate.
The Cost and Capability Trade-Off
Sovereignty has a price, and it shows up in two places: money and features.
Sovereign environments typically lack the economies of scale of global hyperscalers, so unit costs run higher. That premium is easier to justify for a small set of regulated workloads than for an entire estate. Organizations that try to move everything at once often find the business case collapses.
The capability gap is subtler. Advanced services, particularly in AI, tend to arrive on sovereign platforms later, if at all. A team that has built its analytics around a hyperscaler’s managed machine learning stack may find the sovereign equivalent limited or absent. Planning around that gap early is far cheaper than discovering it mid-project.
A workable pattern is to segment workloads by sensitivity rather than moving everything. Highly regulated data goes to a sovereign environment; general workloads stay where the tooling and pricing are strongest. That segmentation requires clear data classification, which is unglamorous but decisive. The broader discipline of cloud infrastructure and architecture is where these segmentation decisions get made, and getting them right early avoids expensive rework.
Public-Sector Frameworks and National Certification Schemes
Governments have responded to the sovereignty question with frameworks and certification schemes, and these shape what vendors can credibly offer.
Gaia-X, launched in 2019, is a European initiative aimed at building a federated data infrastructure with shared sovereignty rules. The European Commission has also developed an EU Cloud Sovereignty Framework, with draft and later versions published in recent years; exact version dates and current status are worth checking directly, since the framework is evolving.
At national level, France’s SecNumCloud certification, run by ANSSI, and Germany’s C5 criteria catalogue from BSI are the two best-known security baselines that shape sovereign offerings. Both impose detailed requirements on providers, and both are used by public-sector buyers as a proxy for trustworthiness.
The challenge with frameworks is fragmentation. A provider certified under one national scheme is not automatically recognized under another. Buyers operating across borders end up mapping requirements manually, which is slow and inconsistent. For readers tracking how policy announcements translate into actual service availability, our guide to how to read a cloud region announcement is a useful filter for separating marketing from substance.
Governance, Cost Visibility, and the Multi-Cloud Reality
Most organizations pursuing sovereignty do not end up with a single sovereign cloud. They end up with a mix: a sovereign environment for regulated data, one or two hyperscalers for everything else, and a legacy estate that refuses to die. That mix creates governance complexity that is easy to underestimate.
Cost visibility is a frequent casualty. Sovereign platforms often have different billing models and less mature cost tooling than mainstream providers, so finance teams lose the granular view they had before. Building a clearer way to track costs, including data transfer charges that sovereign architectures can amplify, becomes essential. Our note on a clearer way to track cloud data transfer costs covers where those charges hide.
The same applies to cost reviews. A sovereignty program that adds a premium without a feedback loop to engineering teams tends to drift into resentment and workarounds. Making cost reviews useful to engineers, rather than treating them as a finance ritual, is what keeps a segmented architecture honest. There is practical guidance on making cloud cost reviews useful to engineers for teams setting this up.
Security governance deserves equal attention. A sovereign environment does not remove the need for identity controls, logging, and incident response; it changes who you coordinate with when something goes wrong. Enterprise security practice in this space is covered in more depth in our enterprise AI and cloud security resources.
What Actually Works
Organizations that navigate sovereignty well tend to share a few habits.
They define sovereignty in writing before they shop, layer by layer, and use that definition to score providers. They insist on contractual clarity about key custody, personnel access, and legal jurisdiction, and they get it reviewed by lawyers who understand the provider’s home jurisdiction. They run a pilot on a genuinely sensitive workload rather than a toy application, because the gaps only show up under real operational pressure. And they keep an exit plan tested, not merely documented.
They also accept that sovereignty is a spectrum, not a badge. The question is rarely “is this sovereign?” but “sovereign enough for this data, under this law, at this cost?” That framing turns an impossible procurement exercise into a series of tractable decisions.
For teams building the broader intelligence layer around these choices, enterprise AI and cloud intelligence offers a wider view of how platform decisions connect to data strategy.
Conclusion
The challenges of sovereign cloud are real, but they are rarely about data centers. They are about legal jurisdiction that follows a provider home, encryption keys that determine who really controls data, support staff who can see systems, certification schemes that do not talk to each other, and a cost premium that has to be justified workload by workload. None of these problems is unsolvable. All of them punish organizations that treat sovereignty as a checkbox on a procurement form.
The teams that succeed start with a written definition, segment their estate by sensitivity, test the operational layer before signing, and keep an exit route open. That is less exciting than a sovereignty badge on a slide, but it is what holds up when a regulator, an auditor, or a court asks the difficult question.
FAQ
Is data residency the same as data sovereignty?
No. Data residency means data is stored in a particular location. Data sovereignty is broader: it covers who controls the data, who can access it operationally, who holds encryption keys, and which laws the provider is subject to. A provider can store data locally while remaining subject to another country’s legal process.
Does GDPR require data to stay in the EU?
No. GDPR governs how personal data is processed and transferred, but it does not by itself impose a localization requirement. Organizations often add residency and operational control requirements on top of GDPR compliance for sovereignty reasons, but the two are distinct.
What was Schrems II and why does it matter?
Schrems II was a July 2020 ruling by the Court of Justice of the EU that invalidated the EU–US Privacy Shield over concerns about US surveillance access to European data. It matters because it showed that transfer mechanisms can be struck down, which pushed many organizations to look harder at where data sits and who can reach it.
What is the US CLOUD Act and how does it affect sovereign cloud?
The CLOUD Act, enacted in 2018, allows US authorities to compel US-based providers to produce data they control, even if it is stored abroad. It affects sovereign cloud because a provider can host data in Europe and still face US legal obligations, which is why corporate structure matters as much as region choice.
What are SecNumCloud and C5?
SecNumCloud is a French security certification run by ANSSI. C5 is a criteria catalogue published by Germany’s BSI. Both are national baselines used by public-sector buyers to assess provider security, and they are not automatically interchangeable across borders.
Why does sovereign cloud often cost more?
Sovereign environments usually lack the economies of scale of global hyperscalers, so unit costs run higher. They may also offer fewer advanced services, particularly in AI, which can mean building functionality that would otherwise be bought. Segmenting workloads by sensitivity rather than moving everything helps keep the premium proportionate.
