Sovereign cloud is the cloud industry’s fastest-growing promise and its most frequently broken one. A sovereign cloud is a cloud environment designed so the data and workloads inside it stay fully subject to the laws and control of a single jurisdiction, and beyond the legal reach of any foreign government. That is the sovereign cloud definition on the label. The reality is that most offerings deliver data residency, keeping data on local soil, while leaving untouched the one thing that actually determines sovereignty: which government can compel the provider to hand the data over. Worldwide sovereign cloud spending is forecast to reach 80 billion dollars in 2026 (Gartner), and a large share of it buys a map pin, not immunity.
TL;DR
- A sovereign cloud keeps data and workloads under the exclusive legal and operational control of one jurisdiction, beyond the reach of any foreign government.
- Most “sovereign cloud” offerings deliver data residency, not sovereignty. Where the data sits is not what matters; who can be legally compelled to produce it is.
- The US CLOUD Act makes data access follow corporate control, not data location. A US-operated cloud is reachable by US authorities even when the servers are in Frankfurt or Paris.
- Structural fixes like locally controlled subsidiaries reduce the risk but do not fully answer it. The only way to make a foreign demand unenforceable is to make the provider technically unable to comply.
- Privacy-enhancing technologies deliver that: they keep data encrypted even during processing, so the operator holds ciphertext it cannot read, regardless of which court comes asking.
What Is Sovereign Cloud?
Sovereign cloud is a cloud model in which data, the infrastructure that processes it, and the people and entities that operate it all remain under the jurisdiction and control of a specified country or region. The sovereign cloud meaning that matters is not “hosted locally”; it is “controllable only locally.” When people ask what is sovereign cloud, they are usually reaching for one of three distinct guarantees, and conflating them is where the confusion starts.
The first is data residency: the physical data stays within a defined border. The second is operational sovereignty: the systems are administered by vetted local personnel, with no foreign operator holding privileged access. The third, and the one almost everyone skips, is legal and technical sovereignty: no foreign law can compel disclosure, because the operator is either outside foreign jurisdiction or technically incapable of producing readable data. Residency is easy to sell and easy to verify. Legal sovereignty is the hard part, and it is the part that determines whether a cloud is genuinely sovereign or merely local. This is the same distinction at the heart of data sovereignty as a discipline: control, not coordinates.
What Is the Difference Between Public Cloud and Sovereign Cloud?
The difference between public cloud and sovereign cloud is control and jurisdiction, not technology. A public cloud optimizes for global scale, elasticity, and a single operational model spanning many countries. A sovereign cloud deliberately constrains that model so a specific jurisdiction retains exclusive authority over the data and who can access it. The same underlying compute can run in both; what changes is the legal and operational envelope around it.
| Dimension | Public cloud | Sovereign cloud |
| Data location | Anywhere in the provider’s global regions | Confined to a defined jurisdiction |
| Jurisdiction over operator | Provider’s home country (often the US) | The customer’s jurisdiction |
| Who can compel access | Any government with authority over the operator | Only the local jurisdiction, by design |
| Operational control | Global staff and shared tooling | Vetted local personnel, restricted access |
| Primary goal | Scale, cost, and feature velocity | Legal control and non-reachability |
| What it protects against | Outages and general breaches | Foreign legal compulsion and surveillance |
The rows that matter are jurisdiction and compulsion, not location. Two clouds can store identical data in the identical city and still differ completely in sovereignty, because sovereignty is decided by who can lawfully reach the operator. Baseline data compliance frameworks increasingly recognize this, which is why a growing number of regulated buyers now write jurisdictional control, not data residency, into their requirements.
Why Do Most Sovereign Cloud Offerings Fall Short?
Most sovereign cloud offerings fall short because they solve for data residency and stop, leaving the operator subject to foreign law. The single most important reason is the US CLOUD Act. Passed in 2018, it established that data access follows corporate control rather than data location, letting US authorities compel any US-based provider to produce data it holds anywhere in the world (Congress.gov). A dataset sitting in a German data center, operated by a US company, is reachable by a US warrant. The map pin is irrelevant.
European law has been colliding with this for years. In 2020 the Court of Justice of the European Union invalidated the EU-US Privacy Shield in the Schrems II ruling, finding that US surveillance law gave the government disproportionate access to Europeans’ data with insufficient redress (European Parliament). The concrete consequences are not hypothetical. France’s Health Data Hub, which centralizes national health data, was built on Microsoft Azure and immediately challenged; Microsoft’s French subsidiary acknowledged it could not guarantee refusal of a US authority’s request under the CLOUD Act, and France has since moved to relocate the platform to a domestic provider (actu IA). A sovereign cloud that cannot say no to a foreign subpoena is offering reassurance, not sovereignty.
The Core Distinction:
Data residency answers “where does my data live?” Sovereignty answers “who can force it out of my control?” These are different questions with different answers. A provider can guarantee the first perfectly and still fail the second completely, because the location of a server has no bearing on the jurisdiction of the company that runs it.
Can US Cloud Providers Deliver True Data Sovereignty?
US cloud providers can deliver meaningful sovereignty controls, but delivering true, unconditional data sovereignty is structurally harder for them, and the honest answer is “not fully, not yet.” The major providers have recognized the problem and are building serious answers. AWS launched its European Sovereign Cloud in January 2026, with its first region in Brandenburg, Germany. It is physically and logically separate from other AWS Regions, operated through dedicated European legal entities under German law, and designed for EU-based operational control (Amazon). Microsoft and Google have pursued a related path through local joint ventures, such as Bleu in France and S3NS with Thales, designed to place operations under European control.
These are genuine structural attempts, not marketing, and they raise the bar considerably. The unresolved question is whether corporate separation fully severs the parent’s exposure to home-country law, a point regulators and courts are still testing. That uncertainty is the crux: sovereignty built on legal structure is only as strong as the next ruling that interprets it. It is a probabilistic guarantee, contingent on how a foreign court reads a corporate boundary. For workloads where the cost of being wrong is a national-security or patient-safety failure, “probably out of reach” is a different product from “provably out of reach.” The distinction pushes the most sensitive workloads toward a stronger form of assurance than any operating model alone can provide.
Why Would an Organization Build Its Own Sovereign Cloud?
Organizations build their own sovereign cloud when no commercial offering can satisfy their jurisdictional or classification requirements, and when the sensitivity of the workload justifies the cost. The clearest cases are national governments, defense and intelligence agencies, and critical infrastructure operators, where foreign reachability is not a compliance risk but a security one. France’s SecNumCloud qualification and similar national schemes exist precisely to certify providers that meet this bar, and some states prefer to build rather than trust any external certification at all.
The tradeoff is real and rarely acknowledged in vendor pitches. Building a sovereign cloud means forgoing the scale, feature velocity, and operational maturity of hyperscalers, and absorbing the cost and talent burden of running modern infrastructure alone. For most enterprises that is the wrong trade; the smarter move is to keep using scalable infrastructure while removing the provider’s ability to read the data, which sidesteps the build-versus-buy dilemma entirely. Building your own makes sense when sovereignty is existential; for everyone else, the question is not who operates the cloud but whether anyone operating it can see inside. That reframing is what makes secure data sharing strategies and sovereignty-preserving architectures more practical than a private data center for most regulated organizations.
What Does True Cloud Sovereignty Actually Require?
True cloud sovereignty requires satisfying three layers at once, and most offerings stop after the first two. The foundation layer is data residency: data confined to the right jurisdiction. The middle layer is operational sovereignty: local, vetted personnel with no foreign privileged access to systems. Both are necessary, both are now widely available, and neither is sufficient, because both leave intact the possibility that the operating entity can be legally compelled from abroad.
The decisive layer is technical sovereignty: the provider is cryptographically unable to produce readable data, no matter who demands it. When the customer holds the only keys and the data is protected even while it is being processed, a foreign subpoena served on the operator yields ciphertext, not records. This is the layer that converts sovereignty from a legal argument into a mathematical fact, and it is the one that does not depend on how a court someday interprets a corporate structure. Sovereign AI follows the same logic: running models on national or regulated data only counts as sovereign AI if the infrastructure cannot quietly exfiltrate or be compelled to expose the underlying data. For a jurisdiction-by-jurisdiction view of what the rules actually demand, Duality maintains a data sovereignty country guide that maps the requirements to real obligations.
What Most Buyers Miss:
Legal and operational sovereignty are contingent guarantees; they hold until a law changes or a court rules otherwise. Technical sovereignty is an unconditional one. If the operator physically cannot read your data, it does not matter which government has authority over it. The strongest sovereign cloud is the one whose provider could hand over everything it holds and still reveal nothing.
How Do Privacy-Enhancing Technologies Support Sovereign Cloud?
Privacy-enhancing technologies support sovereign cloud by closing the gap that residency and operational controls leave open: they keep data protected even during processing, so the provider holds only ciphertext it cannot decrypt. Privacy-enhancing technologies shift sovereignty from a promise about jurisdiction to a property of the data itself. A demand served on an operator that never possesses usable keys cannot produce usable data, which is the strongest possible answer to the CLOUD Act problem.
Three techniques carry most of the weight. Confidential computing isolates processing inside hardware enclaves the cloud operator cannot inspect. Fully Homomorphic Encryption lets applications compute directly on encrypted data, so records are never decrypted, even in memory, even by the party running the workload. Secure multi-party computation lets multiple parties or agencies compute joint results without any of them exposing raw inputs, the basis for cross-border and government data collaboration that respects each jurisdiction’s boundaries. Paired with customer-held keys, these technologies underpin secure AI collaboration and treat AI data security as inseparable from sovereignty.
This is where Duality Technologies is architecturally different from a conventional sovereign cloud offering. A locally controlled subsidiary, like the AWS European Sovereign Cloud or the Bleu and S3NS joint ventures, answers the sovereignty question with corporate structure and local staffing, a legal argument that a foreign court could still test. Duality answers it with cryptography: data stays encrypted through computation itself, so the entity operating the infrastructure is technically incapable of producing plaintext, regardless of which jurisdiction claims authority over it. Sovereignty stops being a contingent legal position and becomes a guarantee the mathematics enforces.
The Real Test:
A cloud is only truly sovereign if its provider could be handed a foreign court order and still be unable to comply in any meaningful way. Residency and local operations are worth having, but they are the easy 80 percent. The last 20 percent, making the data mathematically unreadable to the operator, is the part that actually decides sovereignty, and it is the part the market is only beginning to demand.
How Should You Evaluate a Sovereign Cloud Provider?
Before accepting a sovereign-cloud label, ask five questions that test whether the controls extend beyond data residency:
- Which jurisdictions can reach the provider? Look beyond the data center location to the operating entity, parent company, subcontractors, and any laws that can compel them.
- Who can access plaintext data? Ask whether the provider, administrators, support staff, or infrastructure operator can ever see sensitive data during storage, processing, backup, or troubleshooting.
- Who controls the encryption keys? Determine whether the customer has exclusive control of the keys and whether the provider can recover, escrow, substitute, or otherwise obtain them.
- Can the environment operate independently? Verify where administration, identity systems, logging, support, backups, control planes, and critical dependencies are located, and what happens if services outside the jurisdiction become unavailable.
- What can the provider prove? Ask for independent certifications, audit evidence, documented legal structure, access controls, key-management architecture, and a clear answer to what the provider could actually hand over if served with a foreign court order.
If a vendor can answer only where the servers are located, it is describing residency. A credible sovereignty architecture should also explain who controls operations, which laws can reach the service, and whether the provider is technically capable of exposing the data.
