A sovereign cloud is a cloud service designed so that data, operations and control stay under the laws and authorities of a particular country or region, and so that foreign governments and companies have limited ability to access or interfere with them. It goes beyond keeping data in a local region: depending on the offering, it may also restrict who can operate the service and from where, which legal entity runs it, who holds encryption keys and whether the service can keep running if cut off from a foreign parent company. This entry is an overview for buyers, not legal advice.
At a glance
- A sovereign cloud is an offering that addresses data sovereignty: whose laws and authorities can reach data, not only where it is stored.
- Common features include in-country data storage, local operating entities, staff access restricted to vetted local personnel and customer-controlled encryption keys.
- Offered by local and regional cloud providers, by telecom and IT services firms, and by large hyperscalers through partnerships or separate entities.
- There is no single universal definition; national schemes and buyer requirements differ.
- Often costs more and may offer fewer services than the provider’s standard cloud.
What problem it solves
Many organizations assumed that choosing a cloud region in their own country settled questions about foreign access to their data. For some it does not. A provider headquartered in another country can be subject to that country’s laws, such as the US CLOUD Act, which can require it to disclose data it controls even when stored abroad. Governments, public bodies and regulated industries increasingly want assurance that their data and critical services cannot be reached or switched off by foreign authorities.
A sovereign cloud is meant to give that assurance through technical, operational and legal measures together. It lets public-sector bodies, defense suppliers, healthcare and financial organizations, and companies selling to them use cloud services while meeting sovereignty requirements set by law, regulators, contracts or their own risk policies.
How it works
Location. Data, backups, logs and metadata are stored and processed within the chosen country or region. This is the data residency layer, and it is necessary but not sufficient.
Legal control. The service may be operated by a locally incorporated entity, sometimes majority-owned by local investors, so that foreign parent companies have limited legal or practical control. How much this reduces foreign legal reach depends on the structure and the laws involved.
Operational control. Administration, support and security operations are performed by staff in the country, often with background checks, and foreign staff access is blocked or tightly controlled. Some designs can operate disconnected from the global provider for a period.
Technical control. Encryption with keys held by the customer or a local third party, sometimes in hardware the provider cannot access, limits what the provider could disclose even if compelled. Under the shared responsibility model, key management and data classification often remain the customer’s job.
Assurance. Providers may certify against national schemes such as France’s SecNumCloud, or align with proposed EU frameworks such as EUCS and the sovereignty levels in the proposed Cloud and AI Development Act (CADA). Requirements differ by jurisdiction; confirm what applies with counsel.
Our private cloud and public cloud pages cover how buyers compare deployment models, including sovereign options.
When it matters for buyers
- Selling to government or regulated customers. Contracts may specify sovereignty requirements or a national certification.
- Expanding into new countries. Local rules and customer expectations differ, especially in Europe; GDPR and national laws shape what is required.
- Handling highly sensitive data. Defense, health, critical infrastructure and some financial data may call for stronger controls than a standard region.
- Choosing between local providers and hyperscaler offerings. Weigh legal structure and access controls against service breadth, cost and lock-in.
- Responding to regulatory change. Proposed and new rules can change what counts as sovereign; build review points into contracts.
Questions to ask vendors
- Which legal entity operates the service, where is it incorporated, and who owns and controls it?
- Where are data, backups, logs, telemetry and support records stored and processed?
- Who can access our data or the systems that hold it, from which countries, and how is that enforced and audited?
- Can we hold our own encryption keys outside your control, and what could you disclose if ordered?
- Which national schemes or certifications does this specific service hold, and what is in scope?
- Which services are available in the sovereign offering compared with your standard cloud, and how do prices compare?
- Can the service keep operating if the connection to a foreign parent or global control plane is lost?
How it differs from data sovereignty
Data sovereignty is the question: which countries’ laws and authorities can govern and compel access to your data? A sovereign cloud is one answer to it: a product designed to limit that reach to a chosen jurisdiction. Data residency, in turn, covers only where data is stored. A local region from a foreign-headquartered provider may meet a residency requirement without meeting a sovereignty one, while a sovereign cloud aims to address both. Whether a given offering is sovereign enough depends on the requirement it is meant to meet, so buyers verify the legal, operational and technical controls rather than relying on the label.