An organization can store every byte of its data in a data center inside its own national borders and still not control that data. If the company operating the facility answers to a foreign government, a legal request issued abroad can reach data that never physically left the country. That gap, between where data sits and who ultimately governs it, is the reason data sovereignty has moved from a legal footnote to an architecture requirement.
Regulators in Europe and elsewhere have tightened the rules on how personal, financial and critical-infrastructure data is handled and who may access it, while most enterprise data now lives on infrastructure that someone else operates. This article separates three terms that are often used interchangeably, sketches the regulatory landscape, explains why location alone does not settle the question, and translates the discussion into storage architecture decisions.
Three distinct concepts hide behind the phrase “keeping data in country.”
Data residency is the narrowest of the three: the physical location where data is stored and processed. A residency requirement is satisfied when the storage media sit in a specified country or region. It says nothing about who operates the equipment or which courts have authority over them.
Data sovereignty is the principle that data is subject to the laws of the jurisdiction in which it is located and, in practice, of the jurisdictions with authority over the entities handling it. It is a legal question: which regulators can inspect the data, which courts can order its disclosure, and which privacy protections apply.
Operational sovereignty asks who can actually touch the data: who holds administrative credentials, who manages the encryption keys, who can be compelled to hand over data or metadata, and which legal system that person or company answers to. This includes the home jurisdiction of the service provider itself, not just the location of its regional facilities.
The naive answer to a sovereignty requirement is to pick a local region from a global cloud provider. That satisfies residency, only partially addresses legal sovereignty, and may leave operational sovereignty unresolved.
No single law defines sovereignty, but several overlapping frameworks shape what organizations must demonstrate:
The direction is consistent: regulators ask not only “where is the data?” but “who can be ordered to produce it, and under whose law?”
Consider a hyperscale provider headquartered outside Europe that operates a region inside a European country. The data is resident, and the regional entity may even be a locally incorporated subsidiary. But the parent company remains subject to the laws of its home country, which may compel it to produce data it controls, wherever that data lives. Three mechanisms make this more than a theoretical concern:
Residency is necessary but not sufficient. Sovereignty requires that the operator, the key holder and the administrative staff all sit inside the intended jurisdiction, or that the organization itself retains those roles.
Framed as a control problem rather than a location problem, sovereignty maps onto familiar storage design choices.
On-premises or sovereign-hosted object storage keeps the operator and the hardware under a single, known legal umbrella. Software-defined storage on commodity servers, in the organization’s own facilities or a certified sovereign provider’s, gives the organization direct say over who administers the platform.
Customer-held encryption keys, managed in a key management system the organization controls, mean that even a party with physical or administrative access to the storage cannot read the data. Key control is arguably the most decisive sovereignty lever.
Immutable audit logs, written to write-once storage and protected from deletion by administrators, let an organization show a regulator exactly who accessed what and when. Logs the operator can edit have limited evidentiary value.
Role separation ensures that no single administrator can read data, alter policy and erase the trail at once. Storage administrators, security officers and key custodians should be distinct roles held by different people.
Exit and portability are sovereignty questions too. Data that cannot be moved without prohibitive cost or an application rewrite is not fully controlled. Two factors dominate: whether the platform exposes a standard interface such as the S3 API, so applications can be repointed rather than rewritten, and whether moving data out incurs egress fees that make exit impractical.
Sovereignty does not require a single site. Multi-site placement within one jurisdiction provides resilience against fire, flood or regional outage without crossing a legal boundary, provided storage policies can express “replicate across three sites in this country” as a rule.
The table below summarizes four common approaches against the dimensions discussed so far. Assessments are general; individual deployments differ.
| Model | Residency | Jurisdiction exposure | Key control | Exit cost | Operational burden |
|---|---|---|---|---|---|
| Hyperscale public cloud region | Selectable per region | High: operator subject to home-country law and global control plane | Provider-managed by default; external key options vary | High: egress charges and proprietary service dependencies | Low |
| Sovereign cloud provider | In-country by design | Low: operator, ownership and staff within jurisdiction | Often customer-held or locally managed | Moderate: depends on API standards and contract terms | Low to moderate |
| On-premises private cloud | Fully controlled | Lowest: organization is the operator | Fully customer-held | Low: data already on owned infrastructure | High |
| Hybrid model | Controlled per data class | Varies: sensitive data kept sovereign, other data placed by cost | Customer-held for sovereign tier | Moderate: standard S3 API reduces lock-in across tiers | Moderate |
Many organizations land on the hybrid row, placing each data class where sovereignty and economics both fit. The precondition is a consistent interface across tiers, which in practice means S3-compatible object storage everywhere.
A short checklist surfaces most gaps between a residency promise and genuine sovereignty:
An answer of “we are not sure” to any of these is itself useful.
Scality is a European-founded company, and sovereignty has long been a design consideration in its platforms. Scality RING is software-defined object and file storage that runs on the organization’s own servers or in a sovereign provider’s facilities, at petabyte to exabyte scale, with a standard S3 API. Because the organization or its local operator runs the software, operator, administrators and hardware remain within the intended jurisdiction, and placement policies can keep every replica inside one country.
Scality ADI, the Autonomous Data Infrastructure platform, brings these capabilities together with AI and cyber resilience under one architecture. Sovereign control is one of its three stated outcomes alongside AI and cyber resilience, so the control dimensions discussed here (where the platform runs, who administers it, how data is protected and how access is recorded) are addressed by the platform rather than by policy documents alone.
Organizations building or consuming national or regional cloud services can read more on the sovereign cloud platforms use case page.
The practical starting point: for each class of data, write down who can access it, who holds its keys and under which law they answer, and treat any blank as the first architecture problem to solve.