GDPR compliance is a data problem, not a routing problem

When a team gets asked to make a platform GDPR-compliant, the instinct is almost always to solve it at the edge — route EU traffic to an EU region and call it done. That’s the easy 20% of the problem, and it’s not the part that actually satisfies the regulation.

Routing is not compliance

Routing determines where a request goes. GDPR cares about where information lives. A request could be misrouted and still be technically compliant if it never touches EU customer data. Conversely, if EU customer data leaks into a non-EU database or backup, clean routing doesn’t save you.

The distinction matters because it changes where engineering effort should go. Most teams over-invest in the routing layer and under-invest in the data layer, because routing is the more familiar problem.

Where the routing decision should happen

Push the decision as early as possible — at the edge, before any request reaches an origin server. Cloudflare Workers can inspect a residency claim in a signed token and route accordingly, before the request lands on any backend at all.

User request
     │
     ▼
Cloudflare edge Worker
reads residency claim, routes before origin
     │
     ├── EU claim ──────► EU region (eu-west-1)
     └── non-EU claim ──► APAC region (ap-southeast-1)

That’s necessary. It is not sufficient.

The part that actually satisfies the regulation

Each region needs to be a fully self-contained boundary — not just serving EU traffic, but never allowing EU data to leave the boundary at rest, in backups, in event streams, or in logs.

Primary database — no cross-region read replicas. A common disaster-recovery pattern is a cross-region replica for resilience, and it’s exactly the wrong pattern for GDPR-scoped data. DR for EU data has to be multi-AZ within the EU, not cross-region.

Backups — automated backup tooling often defaults to cross-region copies for durability. That default needs to be explicitly disabled for any compliance-scoped backup vault, or you’ve quietly replicated regulated data outside the boundary through the back door.

Event streams — a shared Kafka backbone with cross-region MirrorMaker replication for durability will replicate EU customer events out of the EU as a side effect. Compliance-scoped topics need their own regional cluster, full stop.

Secrets — IAM-enforced, not just organizationally separated:

finn/eu/production/db-password       ← EU role can read this
finn/sg/production/db-password       ← EU role CANNOT read this

The APAC secrets role has no read access to the EU path and vice versa. This is the technical control that makes the separation provably true rather than a policy statement nobody enforces.

The org-level guardrail

Per-resource configuration relies on someone remembering to configure it correctly every time. An AWS SCP that denies specific actions — creating a cross-region read replica, enabling S3 cross-region replication, starting a DMS job — for any account tagged as EU-scoped closes that gap. Even a misconfiguration attempt gets blocked before it executes, and the denial itself becomes an audit log entry.

The part everyone forgets: erasure, not just isolation

GDPR isn’t only about keeping data in-region. It’s about being able to delete it within 30 days on request. That means a real DSAR (data subject access request) workflow — a process that cascades a delete across the primary database, backup retention, Kafka tombstone records, and log redaction, with the whole operation logged as evidence.

What to say when someone asks if you’re compliant

“We route correctly” is not the same claim as “we’re compliant,” and conflating them is where most GDPR programs fail their first real audit. The honest answer has two parts: where does the request go, and where does the data actually live once it’s there. Only the second one is what an auditor is going to ask you to prove with CloudTrail logs, not a network diagram.