Data residency and sovereignty.
Three words get used together and mean different things. Take a single customer record in a CRM, a name, a price, a note from a call. Where it physically sits, whose laws govern it, and whether it is allowed to leave are three separate questions.
This is a plain-language guide to the field. We walk it the way it is built: what residency, sovereignty, and localization are, why they are hard, how region selection, transfer instruments, and key control work, what they make possible, and where the field is heading. The laws, the landmark ruling, and the standards behind each idea are linked, so you can read them yourself. It is educational. It makes no claim about how any one product is built.
Where it sits, whose laws apply, and whether it can leave.
Three nested ideas, best kept distinct. Residency is a component of sovereignty. Localization is one way sovereignty gets enforced.
Data residency is about where data physically sits: which country, which region, which datacenter. It is the most concrete of the three, and the most directly chosen.
Data sovereignty is about whose laws apply to that data. A record can sit on a server in one country and still answer to the laws of another. Sovereignty is the broader question, and residency is one input to it.
Data localization is the strict version: a rule that certain data is not allowed to leave a jurisdiction at all. It is one enforcement mechanism, not the whole topic.
One distinction is worth stating plainly, because it is often blurred. Sovereignty is not the same as privacy. Privacy law, for example the GDPR, sets rules for how personal data is protected. Sovereignty determines which legal regime applies in the first place. They interact, but they are different questions. Most of the pressure comes from personal data about identifiable people: customers, contacts, employees. That is the category regulators care about most, and the category a CRM is full of.
- Residency
- Where is each copy stored?
- Sovereignty
- Which legal regimes apply?
- Localization
- Which movements are restricted?
Data does not respect borders, but law does.
Cloud infrastructure replicates and load-balances across regions by default. Legal authority is tied to territory and nationality. The friction between the two is the whole problem.
The infrastructure crosses lines the law draws.
Cloud systems replicate, cache, and fail over across regions to stay fast and available. Law is bound to place and nationality. A technical fabric that ignores borders, governed by an authority that depends on them, is the core tension.
More than one legal order can claim one record.
A record can be physically in country A, operated by a company headquartered in country B, about a person in country C. The US CLOUD Act is the canonical example of extraterritorial reach: it can compel a US-connected provider to produce data it holds even when that data is stored abroad.
Moving personal data across a border is not free.
Under the GDPR, personal data may leave the EU only through specific gates: an adequacy decision, appropriate safeguards such as standard contractual clauses or binding corporate rules, or narrow derogations. This is Chapter V, Articles 44 to 50.
A single ruling can change what compliant means.
The Schrems II judgment in 2020 invalidated the Privacy Shield framework and tightened, but did not abolish, the standard contractual clauses route, requiring a case-by-case look at the destination's surveillance laws. This is a live area.
Hard rules fragment systems.
Strict localization carries measurable economic cost. The ECIPE study quantifies GDP and investment effects across several jurisdictions. Stated here as a documented trade-off, presented neutrally, not as advocacy for or against.
Isolating one customer from another is its own problem.
Keeping one customer's data logically and physically separated from another's, inside shared cloud infrastructure, is a distinct engineering challenge from where the region sits. This is where residency meets tenancy.
Pick the region, control the flow, hold the keys, write it down.
Residency is a set of levers, not a checkbox. Where data sits, where it is allowed to move, who can decrypt it, and what the contract promises all carry part of the load.
1Region selection and data-flow control
Choose where it lives, then keep it there.
The first lever is choosing where data is stored and processed: a provider region in a specific country or economic area. That is residency in its most direct form. Beyond picking the region, systems constrain where data can replicate, fail over, and be cached, so it does not silently leave the chosen jurisdiction.
This is configuration and architecture, not a single setting. The technical survey in Applied Sciences (MDPI, 2024) catalogs how these controls are actually built: trusted infrastructure, regional isolation, and policy enforcement that keeps data flows inside the boundary that was promised.
Residency
- Question
- Where are the data and its copies stored or processed?
Sovereignty
- Question
- Which jurisdictions and legal authorities may apply?
Include primary storage, replicas, backups, and access arrangements.
2Legal transfer instruments
When data must cross, it crosses through a gate.
When personal data has to leave a jurisdiction, the legal route is one of the GDPR Chapter V gates: an adequacy decision, where the destination is judged to offer essentially equivalent protection; appropriate safeguards such as standard contractual clauses or binding corporate rules; or a narrow derogation. The primary text is Regulation (EU) 2016/679, Articles 44 to 50.
After Schrems II (2020), the contractual route increasingly has to be paired with a case-by-case assessment of the destination's laws and with technical measures such as encryption and pseudonymization. State it precisely: the ruling tightened the conditions, it did not make transfers illegal.
- Identify the transfer
Determine the parties, destination, and personal data involved.
- Check the applicable mechanism
Examples include adequacy, safeguards such as SCCs or BCRs, or a narrow derogation.
- Assess the conditions
Check the requirements and any additional measures for the actual transfer.
3Key residency and encryption control
Who holds the keys, and where, is half the question.
Where the ciphertext sits is one part. Who can decrypt it is the other. If the encryption keys are held under a different jurisdiction's control, access can follow the keys rather than the bytes. That is why customer-managed keys and in-region key management have become common patterns, and why the conversation is moving from where data is stored toward who can technically and legally compel access.
The MDPI survey (2024) treats key control as a core building block of sovereignty, alongside trusted infrastructure and confidential processing, rather than an afterthought to storage location.
Data location
- Stored objects
- Primary copy and backups in the selected regions.
Key control
- Decryption authority
- Who can use the keys, under which access rules.
Data location and control over keys answer different questions.
4Operational, contractual, and tenancy controls
Architecture alone does not carry the assurance.
Standards give cloud processors a written code of practice. ISO/IEC 27018 sets out how a cloud provider acting as a processor should handle personal data: transparency about where processing happens, limits on use, and support for the customer's own compliance. Described here as a subject of the field, what the standard is, not as a claim that any particular product is certified.
Then there is tenancy. Logical separation, such as row-level scoping or per-tenant keys, keeps one client's data apart inside shared infrastructure. Physical separation, dedicated infrastructure per client, goes further. The stricter the isolation guarantee a buyer needs, the further toward physical separation a design tends to move.
| Control | Question it answers |
|---|---|
| Region policy | Where may this tenant’s data be stored? |
| Tenant isolation | Which tenant may this request access? |
| User permissions | Which records may this person use? |
Clear residency and sovereignty answers turn a worry into a position.
At the field level: selling into regulated markets, a defensible compliance story, client isolation as a product property, and trust that survives a change in the law.
Picture a sales team in one region running deals through a CRM. Inside those records are customer names, contact details, pricing, and notes on what was said on calls. A security or procurement team evaluating any enterprise software asks the same questions: where will our data live, whose law governs it, who could compel access, and can one client's data be kept isolated from another's. A sales voice co-pilot built on that data is no different. The same discipline that enforces residency is what supports answering only from data the person asking is permitted to see, and keeping one company's way of selling, and its data, separate from the next. That is the field's payoff, and an example for enterprise software. It is not a claim about how any one product is built.
Selling into regulated markets.
Clear answers are often a precondition for public sector, healthcare, financial services, and EU enterprise buyers to adopt a system at all.
A defensible compliance story.
Being able to say where data lives, whose law governs it, and which transfer instrument is in force turns a vague concern into an auditable position.
Client isolation as a property.
The machinery that enforces residency also supports keeping one client's data separated from another's. Stated as the field's payoff, illustrated for enterprise software.
Trust that survives the law moving.
Designs that keep data in-region and keys under the customer's control are more resilient when a transfer framework is challenged or struck down.
For AI REV Voice's data protection and access controls, see Security & privacy. This explainer covers the underlying research.
The direction the field is heading.
We describe the direction, not a roadmap of our own.
Regionally bounded environments.
Providers increasingly offer regionally bounded environments with local operations and local control planes, aimed squarely at sovereignty requirements.
From where it sits to who can compel access.
Momentum is moving from where data is stored toward who can technically and legally compel access, which centers key control and confidential processing.
Comparable claims across clouds.
Common standards, including the ISO 27000 family, and evolving transfer frameworks aim to make sovereignty claims comparable across providers and clouds.
Beyond named-person records.
Sovereignty conversations are extending to operational, government, and AI-training data, not only personal data about identifiable people.
The legal surface keeps moving.
Transfer frameworks are periodically litigated and renegotiated. The direction is clear, more control, closer to the data and the keys, but statements about what is compliant are best kept time-bounded.
The laws, rulings, and standards behind this page.
- European Union (2016). Regulation (EU) 2016/679 (GDPR), Chapter V: Transfers of personal data to third countries, Articles 44 to 50. EUR-Lex, official consolidated text.
- Chander, A. and Lê, U. P. (2015). Data Nationalism. Emory Law Journal, 64(3).
- Court of Justice of the European Union (2020). Judgment in Case C-311/18 (Schrems II), Data Protection Commissioner v Facebook Ireland and Maximillian Schrems. 16 July 2020.
- Bauer, M., Lee-Makiyama, H., van der Marel, E. and Verschelde, B. (2014). The Costs of Data Localisation: Friendly Fire on Economic Recovery. ECIPE Occasional Paper No. 3/2014.
- ISO/IEC. ISO/IEC 27018, Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors.
- (2024). Modeling Data Sovereignty in Public Cloud: A Comparison of Existing Solutions. Applied Sciences, 14(23), Article 10803 (MDPI).
- Supporting reference: Ahmed, S. S. Jurisdictional Challenges in Cloud Computing: Data Sovereignty and International Agreements. SSRN. Covers the US CLOUD Act, data-residency orders, and mutual legal-assistance treaties.
Keep reading.
Sibling explainers in the Research section.
Talk. Done.
Knowing where data lives and whose law governs it is part of trusting a system with your calls. See it on a real one.
No app required. Just your phone number.