GDPR Infrastructure Requirements for SaaS Teams

GDPR is mostly a legal framework, but a specific slice of it lands squarely on your infrastructure: where EU personal data physically lives, how it’s encrypted, whether you can actually delete a user when they ask, which vendors touch the data, and what ends up in your logs. If you sell to European customers, their security reviews will probe all five. This post covers the engineering subset — it’s engineering guidance, not legal advice, and you should have a lawyer or DPO review your actual obligations.

Does GDPR require hosting data in the EU?

No — GDPR restricts transfers out of the EU, it doesn’t mandate EU hosting. But in practice, running EU customer data in an EU region is the cheapest way to sidestep the transfer question entirely, and it’s what we recommend for new deployments. AWS, GCP, and Azure all offer multiple EU regions (Frankfurt, Ireland, Paris, and others), and for most SaaS workloads the region choice is a one-line Terraform variable — if you set it on day one.

The alternative is relying on a transfer mechanism, and that ground keeps shifting. The EU-US Data Privacy Framework’s adequacy decision (adopted in 2023) is still formally in place, but its oversight bodies have been weakened by US political developments, and privacy groups have signaled fresh legal challenges — the same pattern that killed Privacy Shield. Standard Contractual Clauses remain the fallback, but they carry assessment overhead. Pinning EU data to EU regions removes a dependency on litigation you can’t control.

Watch the second-order services: your database may sit in Frankfurt while your error tracker, analytics, and LLM API calls ship personal data to US endpoints. Data residency is a property of the whole data flow, not just the primary database. This is the same data-flow mapping exercise a SOC 2 infrastructure review forces, which is why teams that did SOC 2 first find GDPR engineering work mostly incremental.

What encryption does GDPR actually require?

Article 32 is deliberately vague — it requires measures “appropriate to the risk” and names pseudonymisation and encryption explicitly as examples, along with resilience, restorable backups, and regular testing of your controls. It never says “AES-256” or “TLS 1.2+”. In practice, the defensible baseline is the same one every other framework expects:

• Encryption at rest on every datastore holding personal data — KMS-backed volume and database encryption on AWS, GCP, and Azure is a checkbox, so there’s no excuse to skip it
• TLS on every hop, including service-to-service traffic inside your VPC where practical
• Key management through the cloud KMS with rotation enabled, not keys in config files — and keep credentials out of AI tooling too (how we handle that)

Article 32 also explicitly requires “the ability to restore the availability and access to personal data in a timely manner” — meaning tested backups are a GDPR requirement, not just good hygiene. An untested restore procedure fails both your auditor and the regulation.

How do you handle the right to erasure across backups?

Article 17 requires erasure “without undue delay,” and Article 12(3) puts a one-month clock on responding to the request (extendable by two months for complex cases). The hard engineering problem is backups: nobody sanely rewrites immutable snapshots to remove one user’s rows. The widely used pattern is: delete from all live systems immediately, let backups expire on their normal rotation, and ensure a restore doesn’t resurrect deleted users.

That last clause is the part teams miss. If you restore a 20-day-old snapshot, the erased user comes back. Your restore runbook needs a step that replays the erasure log against restored data. Concretely, a well-built pipeline looks like:

Stage	What happens	Typical target
Request intake	Ticket or API call, identity verified	Day 0
Data map lookup	Enumerate every store holding that user’s PII	Automated
Primary deletion	DBs, caches, search indexes, object storage	Days, not weeks
Subprocessor notification	Trigger deletion at vendors holding the data	Within the month
Backup expiry	Snapshots age out on documented rotation	Your retention window

Keep backup retention as short as your recovery needs allow — a 35-day rotation is far easier to defend than “we keep everything forever.” Document the policy; a documented, bounded expiry is the position you want to be in when a regulator or enterprise customer asks.

What about DPAs and subprocessors?

Article 28 requires a written contract — a Data Processing Agreement — with every processor touching personal data on your behalf, and it makes you responsible for your processors’ subprocessors. The engineering task is producing the list: every SaaS vendor, cloud provider, monitoring tool, and AI API that receives personal data. AWS, GCP, Azure, and most serious B2B vendors publish standard DPAs you accept online; the work is knowing which vendors need one. Your infrastructure-as-code and billing exports are the honest inventory — Terraform state doesn’t forget a vendor the way a spreadsheet does. Publish the subprocessor list on your site; enterprise buyers ask for it in every security review.

How do you keep PII out of logs?

Logs are the leak nobody plans for. Request bodies, email addresses in URLs, tokens in headers — once PII is in your log pipeline, it’s replicated into a system with its own retention, its own vendors, and no per-user deletion. The fixes are boring and effective: scrub at the emitter (structured logging with an allowlist of fields beats regex redaction), set log retention deliberately (14-90 days covers most debugging needs), and treat your log vendor as a subprocessor with a DPA.

Where does GDPR fit in your compliance sequence?

For most US-selling startups, SOC 2 comes first and GDPR engineering rides along — encryption, access control, vendor management, and logging discipline overlap heavily (see our compliance roadmap and the ISO 27001 vs SOC 2 comparison). If you’re selling into Europe now, do the erasure pipeline and residency work in the same push. Our SOC 2 infrastructure package covers the shared foundation — the GDPR-specific delta on top is usually days of work, not months, when the foundation is sound.