Data Residency
Date: 2026-08-17
Where data physically sits, and where it travels on the way. It’s usually a contractual requirement rather than a legal one — UK GDPR restricts transfers, not storage location — and the distinction matters because “our data stays in the UK” is a promise most stacks quietly break at three or four points.
Data residency is the physical, geographic location where data is stored and processed.
Three separate things, routinely conflated
RESIDENCY where the bytes are stored at rest
→ mostly a contractual commitment
SOVEREIGNTY whose laws can compel access to it
→ can differ from residency: a US-owned provider
storing data in London may still face US legal
process — this is the harder question
TRANSFER data moving to another country
→ what UK GDPR actually regulates
UK GDPR does not require UK storage. It requires that transfers outside the UK have an appropriate safeguard. Plenty of organisations promise UK-only storage in contracts anyway, and then have to deliver it — which is where the engineering work comes from.
Where it leaks
The commitment is made at the top and broken in the details. The points to check, in the order they’re usually missed:
✓ primary database eu-west-2 (London) ← the bit everyone checks
? backups replicated cross-region? ← check
? CDN edge caching HTML cached at 300 PoPs? ← CDN Caching
? analytics vendor processes in the US?
? error tracking stack traces + user context ← Error Tracking
? session replay full DOM captures
? email provider addresses and open data
? support desk tickets contain everything
? logs and observability often the largest leak ← Observability
? AI/ML features prompts sent to a model API
? the vendor's SUB-processors — their support team,
their monitoring vendor, their own backups
Three of those rows deserve naming, because they’re the ones nobody audits: edge caches distribute whatever’s in the HTML across every point of presence — CDN Caching; stack traces carry user context to wherever the vendor stores them — Error Tracking; and verbose logs are usually the single largest volume of personal data leaving the country — Observability.
Support desks and logs are the two most commonly forgotten, and both routinely contain more personal data than the primary database — a support ticket carries the customer’s name, order, address and complaint in free text, and gets stored wherever the helpdesk vendor stores things.
Sub-processors are the other one. A vendor guaranteeing UK storage may use a US monitoring service, and the sub-processor list is where you find out. It’s contractually required to be published and it changes — put a diary note to re-read it.
When it’s genuinely required
- Contractual commitments to enterprise customers. By far the most common driver. A B2B customer’s procurement asked, someone said yes, and it’s now binding
- Public sector. UK government and NHS contracts frequently specify it
- Financial services and health, where sector regulators add expectations beyond general data protection law
- Specific national regimes — some countries do mandate local storage for particular data types, which matters if you sell there
It’s rarely required by UK GDPR itself, and being clear about that saves a lot of unnecessary architecture. The transfer mechanism — an adequacy decision, or the standard contractual clauses with a transfer risk assessment — is often the proportionate answer rather than relocating infrastructure. [CHECK: adequacy findings and the approved transfer mechanisms change; confirm the current position for the specific countries involved before relying on one.]
The architectural cost
Delivering per-region residency is the same problem as per-tenant isolation, and it’s expensive for the same reasons.
| Single region | Multi-region residency | |
|---|---|---|
| Databases | One | One per region |
| Migrations | Once | A fleet operation — Database Migrations |
| Analytics | One warehouse, one query | Per-region warehouses; cross-region aggregation is the hard bit |
| Deployment | One pipeline | Regional pipelines, possibly at different versions |
| Cost | Baseline | Substantially higher, plus operational complexity |
Cross-region reporting is the problem people hit last and worst. If UK and EU data can’t be combined, then “total revenue” requires aggregating figures that can’t be joined at row level — so the analytics layer has to be designed for federated aggregation from the start, or someone will “temporarily” copy everything to one warehouse and undo the whole arrangement — Event Streams vs Aggregates, Multi-Tenancy.
Anonymous aggregates move freely. Genuinely anonymised counts aren’t personal data, so cross-region reporting on aggregates is unconstrained — which is usually the practical answer to the problem above — Pseudonymisation and Anonymisation.
What to do
- Write down where every category of data lives, per vendor, including sub-processors. This is part of the record of processing you need anyway
- Read the vendor’s residency claim precisely. “EU data centres” is not “UK”, “data residency” often excludes backups and support access, and “processing” may differ from “storage”
- Check the CDN. Caching HTML at the edge distributes whatever’s in that HTML globally, and personalised HTML contains personal data
- Check what your logs contain before worrying about the database. Verbose logging in a US-hosted observability tool is a transfer nobody assessed
- Don’t promise it in a contract without an architecture that delivers it. This is the failure mode: the commitment is made by sales and discovered by engineering a year later
Where it interacts
- Data Retention — the other axis of the same governance question: how long, and where
- UK GDPR and PECR for Analytics — the regime that governs transfers, and what it actually requires
- Multi-Tenancy — per-region residency forces the same isolation decisions as per-tenant isolation
- Edge Computing — running logic at the edge means running it in whichever country the edge node is in