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.
What is data sovereignty, and how does it differ from residency?
Three distinct concepts hide behind the phrase “keeping data in country.”
Data residency
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
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
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.
How is the regulatory landscape evolving?
No single law defines sovereignty, but several overlapping frameworks shape what organizations must demonstrate:
- The GDPR established that personal data of European residents carries protections that travel with it, and that transfers to countries without equivalent safeguards need additional legal mechanisms.
- The EU Data Act extends the conversation to industrial and machine-generated data and sets expectations around switching between cloud providers, including the friction and cost of leaving.
- NIS2 broadens the set of organizations classed as essential or important and raises the bar for securing their infrastructure and supply chain, including cloud and storage dependencies.
- DORA applies similar logic to the financial sector, with emphasis on operational resilience and third-party ICT risk.
- National sovereign cloud programs in several European countries define certification schemes that go beyond residency, typically requiring that the operator, its ownership and its staff be insulated from non-European jurisdiction.
- The US CLOUD Act gives US authorities a legal route to request data held by US-based providers regardless of where it is physically stored.
The direction is consistent: regulators ask not only “where is the data?” but “who can be ordered to produce it, and under whose law?”
Why is residency alone not sovereignty?
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:
- Administrative reach: global providers run shared control planes, and support engineers and automated systems in other countries often have privileged access paths into every region.
- Key custody: if the provider generates and holds the encryption keys, encryption protects against outsiders but not against the provider or anyone who can legally compel it.
- Metadata and logs: even where object contents are protected, access logs, object names and billing records may be replicated outside the region and are often the first target of a legal request.
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.
What does sovereignty mean for storage architecture?
Framed as a control problem rather than a location problem, sovereignty maps onto familiar storage design choices.
Where the storage runs
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.
Who holds the keys
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.
Proving what happened
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.
Separating roles
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.
Being able to leave
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.
Placement within a jurisdiction
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.
How do the main deployment models compare?
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.
What questions should an organization ask before choosing?
A short checklist surfaces most gaps between a residency promise and genuine sovereignty:
- Under which country’s law is the operating entity, and its parent, incorporated?
- Can anyone outside the jurisdiction obtain privileged access to the storage or its metadata?
- Who holds the encryption keys, and can the operator read data without the organization’s involvement?
- Are access and administrative logs immutable, and where are they stored?
- Does the platform expose a standard S3 API, and what would it cost to move all data out within a defined period?
- Can the platform replicate across several sites inside the jurisdiction without ever placing a copy outside it?
An answer of “we are not sure” to any of these is itself useful.
How Scality RING and ADI support sovereign control
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.
