Data Residency vs Data Sovereignty vs Data Localisation
Data residency is where data is physically stored. Data localisation is a legal requirement that data remain within a country's borders. Data sovereignty is which jurisdiction's laws govern the data and who can compel access to it. Residency is a choice, localisation is a mandate, and sovereignty is the consequence of both plus the operator's own jurisdiction.
Confusing them is expensive. An organisation can satisfy residency, satisfy localisation, and still fail sovereignty — which is the position a great many European analytics stacks are in right now.
The three terms compared
| Data residency | Data localisation | Data sovereignty | |
|---|---|---|---|
| Definition | The physical or geographic location where data is stored | A legal requirement that data stay within a specified territory | The legal jurisdiction that governs the data and can compel access |
| Type | An architectural choice | A statutory mandate | A legal consequence |
| Determined by | Where you put the servers | The applicable law | Storage location + operator jurisdiction + data subject jurisdiction |
| How it's satisfied | Select a region | Store only in-country | Store and operate under a single jurisdiction |
| Evidence | Provider region configuration | Storage records, no cross-border replication | Corporate structure of every operator in the chain |
| Common failure | Backups or CDN land elsewhere | Treating region selection as compliance | Assuming residency implies sovereignty |
The one-line distinction: residency tells you where the data sleeps, localisation tells you it may not travel, sovereignty tells you who can wake it up.
Why residency does not deliver sovereignty
Because jurisdiction attaches to the operator as well as to the hardware.
The US CLOUD Act permits US authorities to compel US-based providers to produce data in their possession, custody, or control, regardless of where it is stored. A US hyperscaler's Frankfurt region satisfies EU residency and remains within reach of US legal process.
The same logic runs in other directions. Any provider is subject to the legal orders of the country in which it is incorporated, and to those of countries where it has significant operations. Sovereignty analysis therefore has to trace the corporate structure of every operator in the chain, not just the map pin.
Where this specifically bites analytics stacks
This is the part generic explainers omit, and it is where most of the real exposure sits.
Behavioural data is personal data by default. Event streams describe what identifiable individuals did. They fall under GDPR, DPDP, CCPA and sectoral rules from the moment of collection — unlike much of the aggregated data sitting in a warehouse, which teams instinctively treat as the regulated asset.
The destination list is longer than the diagram. Behavioural data typically reaches the analytics platform, the warehouse, backups, error and crash reporting, session recording, support tooling, and marketing or ad platforms. Each is a separate residency and sovereignty question. Organisations routinely establish residency for the analytics platform and overlook five other destinations receiving the same events.
Sub-processors move. An analytics vendor's own sub-processor list changes on notice. A stack that was compliant at procurement can drift without anything in your architecture changing.
Support access is a transfer. A vendor support engineer in another jurisdiction viewing your data in a debugging session is a transfer, whatever the storage region says. Ask specifically about support-tier access geography — it is rarely in the residency documentation.
Which do you actually need?
| Your situation | Requirement | What satisfies it |
|---|---|---|
| GDPR applies, standard processing | Residency helps; transfer safeguards required | EU region plus a valid transfer mechanism |
| National law mandates in-country storage | Localisation | In-country storage, no cross-border replication or backup |
| DORA, or regulator concerned with third-party ICT risk | Sovereignty plus exit strategy | Operator under domestic jurisdiction, documented and tested exit |
| Air-gapped or classified environment | Absolute sovereignty | On-premises, no external operator |
| Enterprise customer contract imposes it | Read the contract wording | Frequently sovereignty, described as residency |
That last row is worth pausing on. Procurement documents routinely say "data residency" when the underlying requirement — no foreign government access — is sovereignty. Establish which one the clause actually means before designing to it.
Frequently asked questions
What is the difference between data residency and data sovereignty? Residency is the physical location where data is stored. Sovereignty is which jurisdiction's law governs it and who can legally compel access, determined by storage location, the operator's jurisdiction, and the data subject's jurisdiction together.
Is data localisation the same as data residency? No. Residency is a choice about where you store data. Localisation is a legal mandate that data must not leave a territory. You can have residency without a localisation requirement; where localisation applies, residency in that territory is compulsory.
Does choosing an EU cloud region make you GDPR compliant? No. It addresses Chapter V transfer restrictions but not lawful basis, minimisation, retention, or subject rights — and it does not remove exposure where the provider is subject to a foreign legal regime.
Can you have data sovereignty in a public cloud? Yes, with a provider incorporated and operated in the relevant jurisdiction. With a foreign-headquartered provider it depends on the specific legal and operational structure of its sovereign offering, which varies considerably and is actively contested.
Which regulations mandate data localisation? Requirements vary by country and sector, and are most common in finance, health, telecommunications and the public sector. Several jurisdictions impose them for specific data categories rather than universally. Check the sectoral rule that applies to you rather than the general data protection law.
Do backups need to meet the same residency requirements? Yes, and this is one of the most common gaps. Backups, disaster-recovery replicas, and archive tiers frequently sit in different regions from primary storage. Verify each independently.
Countly is a first-party product analytics and customer engagement platform that runs self-hosted, on-premises, or in a private cloud.
Posts that our readers love
to grow your product
is here.