Data residency is the requirement that data be physically stored or processed within a defined geographic area — a country, a region, or sometimes a specific data centre. It overlaps with but isn't identical to data sovereignty, which is the legal regime that applies to data based on its location.
Where it comes from
Residency requirements come from several sources:
- Sectoral law. Russian Federal Law 242-FZ requires personal data of Russian citizens to be stored on servers in Russia. China's PIPL has a similar localisation rule for "important data." Australia's eHealth Records Act requires Australian health data to remain in Australia.
- Public-sector procurement rules. Many governments require their contractors' data to remain in-country.
- Customer commitments. Some enterprise customers contractually require their vendor to store their data in a specific region (often the EU).
- GDPR transfer mechanisms. Not technically a residency requirement, but the practical effect of "data must stay in the EEA unless an Article 46 tool is in place" is similar.
Verifying a residency claim
A vendor saying "we store EU customer data in EU regions" is doing one or more of:
- Hosting on AWS, GCP, or Azure regions in Europe.
- Running their own data centres in Europe.
- Using a regional pinning feature in their multi-tenant database.
The claim is verifiable by checking three things:
- Their subprocessor list — does it specify regions, or just entity names?
- Their security or trust page — does it identify the data centre regions used?
- Whether their support, engineering, and operations teams have access — "data stays in the EU" is meaningless if a US-based engineer can SSH into the EU production database.
The third point is where most residency claims weaken. Storage residency is necessary but not sufficient; access residency is what regulators are increasingly looking at.