← All Posts
SecurityComplianceData ArchitectureDatabases

GDPR Is a Database Architecture Problem

Sean Lobjoit··2 min read
// View summary on LinkedInopenLinkedIn();

Most developers treat GDPR as a legal problem.

It's actually a database architecture problem. And if you're building it in after the fact, you're already too late.

Here's what "GDPR-compliant by design" actually looks like at the database level:

Five Database-Level Principles

  1. Encrypt at the column level, not just at rest

    Full-disk encryption doesn't protect you when someone runs SELECT * FROM users. Sensitive PII (name, email, DOB) needs field-level encryption. Your query layer handles decryption and compliance is enforced structurally.

  2. Design for the Right to Erasure from day one

    "Delete the user" sounds simple but if user_id is a foreign key across 40 tables, you have a problem. Pseudonymisation over hard deletes. Replace PII with a token, row gone, but the relationships remain intact and the audit trail is preserved.

  3. Data residency isn't a deployment concern, it's a schema concern

    EU data must stay in EU regions but if your multi-tenant schema doesn't encode residency, your infrastructure team is making compliance decisions blind. Add a region column and enforce it at the ORM layer.

  4. Audit logs are not optional

    Who accessed what, and when? GDPR requires you to answer this. Append-only audit tables with user_id, action, timestamp, and resource_id. Not in your application logs but in your database.

  5. Treat data minimisation as a schema review

    Do you actually need date_of_birth, or just is_over_18? Every column you don't store is a breach you can't have. Make this part of your PR review process, not your legal review.

The 72-Hour Breach Window

GDPR fines aren't the scary part.

The scary part is Article 33. You have 72 hours from awareness of a breach to notify your supervisory authority.

Not 72 hours from your security team's post-mortem. From awareness.

And under Article 34, if the risk to individuals is high, you notify affected users too: no fixed window, as fast as possible.

To notify properly you need:

  • what was breached
  • how many people
  • what categories of data
  • what you're doing about it

Try answering those questions with missing audit logs and a schema you don't fully understand.

Build It In

Build it in. It's cheaper.

I've put together a GDPR-ready database checklist covering all of this.

← Back to all posts