Data Residency

Data residency constrains where data is stored and processed, requiring region-pinned storage, replication controls, and evidence that no copy leaves the allowed geography.

compliance

Definition

Data residency is the requirement that certain data remains within a specified legal or contractual geography. It affects primary storage, backups, replicas, caches, logs, analytics, and third-party processors. Meeting it requires more than choosing a region: every copy and every access path must be inventoried and constrained.

Context and scope

Residency requirements appear in privacy regulation, public-sector contracts, and enterprise security reviews. They are often confused with data sovereignty, which can include legal control as well as location.

Common misconceptions

Selecting a region for the primary database is enough — backups, replicas, logs, and CDNs can leave the region
A multi-region architecture is always allowed — replication itself may violate residency
Residency is only a legal concern — engineering must prove where every copy lives and who can access it

Anti-patterns

Replicating all data to a global analytics warehouse
Sending logs containing personal data to a vendor outside the allowed region
Backing up a regional database to a default global bucket

Related concepts

Authoritative source

https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

The primary region is only the beginning

A database in Frankfurt does not make the system compliant if nightly backups go to a global bucket, logs are shipped to a US analytics service, or a read replica is created in another region for latency. Residency is an inventory problem: find every copy of the data and every processor that can access it.

Data class: customer PII
Allowed region: EU
Primary: eu-central-1
Backups: eu-central-1, encrypted, no cross-region replication
Logs: EU-only bucket, PII redacted
Vendors: EU data-processing addendum, subprocessor list reviewed

Design for pinning

Pin storage, backups, and processing to the allowed region. Disable cross-region replication for the constrained data, or replicate only an aggregated, non-personal dataset. Configure CDNs and edge functions so they do not persist request bodies or logs outside the region. Review vendor subprocessors and data-processing terms; a vendor’s global status page is not evidence of regional storage.

Prove it continuously

Maintain a data map with owners, classes, and locations. Audit cloud storage policies, backup jobs, log pipelines, and analytics exports for cross-region destinations. Include residency in architecture reviews and incident response: a failover to another region may be technically possible but legally prohibited. Test the controls by attempting a disallowed copy and confirming it is blocked.

When to use it

Use explicit residency controls when law or contract restricts where data may live. The advantage is demonstrable compliance; the drawback is reduced availability options, higher cost, and more complex failover. Compared to a global multi-region design, residency often accepts a regional failure domain in exchange for legal certainty.