DATA RESIDENCY / RULE REFERENCE

Sovereign partitions

GDPR’s free-flow principle applies inside the EEA; Chapter V mechanisms — adequacy decisions, SCCs, binding corporate rules — govern exits. Since Schrems II, "where does it live" is an architecture question, not a marketing one. Enforcement repeatedly shows "data stays in the EU" claims failing at the support-tool, analytics, and disaster-recovery layers even when the primary database is genuinely European.

The rule

GDPR lets data flow freely inside the EU; moving it elsewhere needs a Chapter V mechanism. For many buyers, "stays in Europe" is a hard procurement gate, not a preference.

What it means for how you build

Bind data to regions at the database layer, not the app layer — a misrouted write is a residency breach regardless of what the marketing page says.

Self-check

Can you enumerate every system touching personal data — support tools, telemetry, error trackers, backups included?
Is residency enforced at the routing and auth layer, or by convention in app code?
Do admin and support access paths get the same treatment as data flows?
Can a write ever land in the wrong region — is there a per-tenant home-partition guarantee?

Common pitfalls

Primary-in-EU, exhaust-everywhere: US-region error tracking and support tooling quietly defeats the residency story.
Failover to "the other region" — a DR plan replicating outside the EEA is a residency breach waiting for a bad day.
Region claims on the marketing page the database layer cannot verify.

How the engine checks it

Dual-node architecture: every tenant’s data lives on exactly one partition — europe-west1 (Belgium) or europe-west2 (London) — routed and refused cross-border by the auth layer.

Sources

Related rules

Last reviewed 2026-11-01.