Data sovereignty vs data residency vs data localization: three phrases that get used interchangeably, and three questions that aren’t actually the same question. Residency asks where data sits. Localization asks what the law requires. Sovereignty asks who’s really in control. Mixing them up is how an organization passes a compliance checklist while still failing their desired goal for great digital sovereignty.
Quick Answer
Data residency is where data is physically stored. Data localization is a legal requirement that certain data stay within a country’s borders. Data sovereignty is broader still, covering legal jurisdiction, encryption key ownership, and who has operational access, not just location. You can meet the first two and still lack the third. We’ll explain this later on in the blog.
This article breaks down what each term means, where they overlap, and why the distinction matters more once infrastructure spans more sites, more jurisdictions, and more third-party vendors.
Definitions
Data Residency
Data residency is a location question. Is the data physically stored where a contract, policy, or regulation says it should be.
Data Localization
Data localization is a legal requirement. A law that mandates certain categories of data be stored, and sometimes processed, within a specific country’s borders, regardless of what a vendor contract says.
Data Sovereignty
Data sovereignty is a control question. It includes location, but goes further to cover legal jurisdiction, encryption key ownership, and operational access. You can satisfy a residency or localization rule on paper and still lack sovereignty, if a provider keeps the keys, keeps the administrative access, or is itself answerable to a foreign government.
What is Data Residency?
Data residency is the narrowest of the three terms. It’s satisfied the moment data sits in the geographic location a contract or internal policy specifies, usually a cloud region within a particular country or bloc.
Data residency is normally a choice, not a legal mandate. A customer can typically pick a region from a provider’s menu, the same way they’d pick a currency. That flexibility is also the catch: a residency setting can often be changed by the provider, or it might apply only to primary storage while backups, logs, or support access sit somewhere else.
Meeting a residency requirement says nothing about who can access that data, who holds the encryption keys, or which country’s courts can compel the provider to hand it over. A vendor can satisfy a residency clause completely and still leave you with little real say over how that data gets managed behind the scenes.
What is Data Localization?
Data localization is where the location question stops being optional. It’s a legal requirement, not a setting you toggle, that certain categories of data be stored, and sometimes processed, exclusively inside a country’s borders.
Localization rules generally fall into two categories.
Hard localization prohibits certain data from leaving the country at all. No transfers abroad for backup, processing, or anything else, no matter what safeguards are in place. Russia’s personal data law works this way, requiring that the initial collection, storage, and recording of Russian citizens’ personal data happen on servers physically located inside Russia before any copy can move elsewhere.
Soft, or conditional, localization allows cross-border transfer once specific conditions are met, such as a government security assessment, regulatory approval, or a mirrored local copy. China takes this approach under its Personal Information Protection Law (PIPL), requiring operators of critical information infrastructure, and organizations handling large volumes of personal data, to store that data locally, with transfers abroad gated behind a mandatory security assessment.
The EU’s GDPR is usually held up as the model for conditional rather than hard localization. It doesn’t require data to physically stay inside the EU, but it does restrict transfers outside the bloc unless a recognized mechanism, like an adequacy decision or standard contractual clauses, is in place.
The practical effect for anyone running distributed infrastructure: localization requirements don’t apply evenly. An architecture built for a conditional transfer market can fail outright in a hard localization one, which is why many organizations end up running genuinely separate infrastructure for specific countries instead of one global platform.
Data Sovereignty Defined
Data sovereignty is the broadest term, and the hardest one to satisfy with a checklist. It includes location, but adds legal jurisdiction, encryption key ownership, and administrative access to the systems holding the data.
You can meet a residency requirement and a localization law at the same time, with data stored in exactly the right country, and still lack sovereignty over it if a provider keeps the encryption keys, offers remote support from another jurisdiction, or is itself legally answerable to a foreign government no matter where its servers sit.
In some cases, some jurisdictions can assert legal authority over a company’s data based on where the company is headquartered, not where the data physically lives. For example, the CLOUD Act allows U.S. authorities to access data stored in the EU. Residency and localization can both check out while sovereignty doesn’t. Some businesses argue about what this access means, for example, Amazon disputes the CLOUD Act’s ability to for full exposure. Meanwhile, data protection experts state that the only architectural solution eliminating CLOUD Act exposure is genuine data sovereignty, claiming potential solutions like customer-managed encryption keys making compelled disclosure yield only unintelligible ciphertext, and sovereign deployment eliminating US provider jurisdiction entirely.
Forrester analyst Dario Maisto has pointed to exactly this gap. Buyers need to look past where data sits, to who manages the encryption keys, who has operational access, where systems actually run, and which laws apply to all of it.
That gap between meeting a requirement and actually holding control is a board-level question, not just a procurement one. As Susan Odle, CEO of StorMagic, puts it in the executive briefing Edge Infrastructure in an Unpredictable World: “Outsourcing operations doesn’t outsource accountability.” A residency clause or a localization law can be fully satisfied and the organization can still be the one left holding the risk when a regulator, or an incident, asks who was really in control.
Data Sovereignty vs Data Residency vs Data Localization Comparison Table
| Data Residency | Data Localization | Data Sovereignty | |
| What It Answers | Is data stored where it should be | Does the law require it to stay in country | Who has legal and operational control |
| Where The Requirement Comes From | Contract or internal policy | Government legislation | Governance, contracts, and law combined |
| Can You Choose It? | Often, through a provider’s region setting | No, it’s mandatory where it applies | Partly, through architecture and vendor choice |
| What It Misses | Access, jurisdiction, key ownership | Access or key ownership beyond storage | Designed to cover all of the above |
Why Do These Distinctions Matter for Vendor Evaluation?
Confusing these three terms tends to surface at the worst possible time, during an audit, an incident review, or a vendor’s change of ownership, rather than during vendor selection.
A few consequences worth knowing before you sign anything:
Data Residency isn’t Data Sovereignty
Choosing the right region satisfies a residency clause, but says nothing about who can access the data or under what legal compulsion.
Localization Compliance Doesn’t Cover Everything
Meeting a hard localization rule for primary storage doesn’t automatically extend to backups, logs, monitoring data, or third-party support tools, all of which can fall outside the same protections if you don’t design for it.
Sovereignty is Established Per Workload, Not Company-wide
Sovereignty has to be assessed per workload, not once for the whole company. You can be fully compliant with a localization law in one country while having no real sovereignty over a workload in another, because the requirements, and the risk, aren’t the same everywhere.
Susan Odle makes a similar point in Edge Infrastructure in an Unpredictable World, arguing that sovereignty isn’t about eliminating every external dependency: “The stronger position to be in is intentional rather than absolute.” Residency and localization are two boxes that can look like they’re being managed correctly, while that broader, more intentional question of what you can accept and what you need to control goes unanswered.
This is also why data sovereignty works best as one of four connected pillars of digital sovereignty, alongside operational, technical, and legal and regulatory sovereignty, rather than a single location checkbox. Residency and localization only address part of that picture. For the full framework, see our guide, Digital Sovereignty and Edge Infrastructure: A Guide to the Sovereign Edge.
How to Manage Data Sovereignty vs. Data Residency vs Localization
Instead of asking “is our data in the right country,” separate the three questions out.
Question 1: Residency
Where is the data physically stored right now, including backups, replicas, and logs, not just the primary copy?
Question 2: Localization
Does a law require this specific data category to stay in country, and if so, is it hard or conditional?
Question 3: Sovereignty
Who controls the encryption keys, who has administrative or support access, and which jurisdiction governs the entity providing the service, not just the data itself? Read more about this in What is Data Sovereignty?
Answer all three, for each workload and each site, and you’ve got an assessment that holds up under audit, not just a region setting that looked right in the sales deck.
These three questions are a starting point, not the full picture. Susan Odle’s executive briefing, Edge Infrastructure in an Unpredictable World, sets out a longer list of questions every executive team should be able to answer before committing edge infrastructure to an external provider, covering continuity, control, cost, and exit, worth reading in full if you’re taking this beyond a single vendor decision.
To get a better understanding of digital sovereignty as whole, and the four key pillars you can control, read Digital Sovereignty and Edge Infrastructure: A Guide to Sovereign Edge.
