Data residency is where data is stored. Data localisation is a legal rule that data must stay in a country. Data sovereignty is about which country's laws and authorities can reach the data, wherever it sits. They overlap, but a design that satisfies one can still fail another.
These are working definitions for engineering conversations. Vendors and regulators use the words loosely, so always ask what a specific document means.
Residency: where it sits
Residency is a property of your architecture. Which region holds the database, the object store, the backups and the search index? It is the easiest to measure and the easiest to promise. A customer who asks for EU residency usually wants a statement and an architecture that match.
Localisation: where the law says it must sit
Localisation comes from a rule. Some countries and sectors require certain data to be stored or processed inside the country. One source I fetched on UAE law lists sector rules, including for health information and retail payments, that restrict storing or processing data outside the UAE. See UAE data rules for software teams. Localisation is binary: you comply or you do not.
Sovereignty: whose law reaches it
Sovereignty asks who can compel access. A provider established abroad, or with a foreign parent, may be subject to that country's legal demands even when the servers are local. The EDPB's guidelines on transfers note a case where a processor in the EU subject to third country legislation could receive access requests. That is why the EDPB looks at law and practice, not just server location.
Why the three get confused
- Fact or rule? Residency is a fact, localisation is a rule, sovereignty is a legal exposure.
- Who sets it? You set residency, law sets localisation, law and corporate structure set sovereignty.
- How do you check? Architecture review for residency, statute and sector rules for localisation, counsel and contract analysis for sovereignty.
- Fixed by changing region? Yes for residency, sometimes for localisation, not by itself for sovereignty.
What to do
- Ask the customer which of the three they mean.
- Describe your residency precisely: primary storage, replicas, backups, logs, support access. See residency leaks in logs and backups.
- List any localisation rules for your sectors and countries.
- Document who can access data and from where, since that touches sovereignty.
- Avoid promising "data never leaves" unless you can prove it for every system.
An example conversation
A prospect writes: "We need EU data residency." Three different needs can sit behind that sentence. The first is a contract preference for EU storage, which is residency. The second is a sector rule from their regulator, which is localisation. The third is a worry that a foreign parent company could be forced to hand data over, which is sovereignty.
You answer the first with a region. You answer the second by reading the rule. You answer the third with a description of corporate structure, access controls and technical measures such as customer held keys, and you leave the legal side to counsel.
Why the distinction saves time
Teams that treat all three as one problem over build, and then still fail the review. Sorting the request first lets you promise only what you can deliver.
Quick check
Does EU residency satisfy GDPR?
Not by itself. The GDPR regulates transfers and access, and residency is one fact within that. See whether GDPR requires EU only storage.
Sources
This is educational content, not legal advice.
Last reviewed: 19 October 2026.
