Designing for GDPR and Privacy Compliance

Privacy isn’t a checkbox feature you bolt on at launch—it’s a fundamental architectural constraint that shapes how you store, process, and delete data. When Marriott got hit with a $23.8 million GDPR fine for a breach affecting 339 million guests, the issue wasn’t just the breach itself but their inability to quickly identify what data was compromised and who needed notification. Your system’s privacy architecture determines whether a compliance request takes 30 seconds or 30 days.

The Data Subject Rights Challenge

GDPR grants users seven fundamental rights, but two create the most architectural complexity: the right to erasure (”right to be forgotten”) and the right to data portability. Most systems treat deletion as a simple DELETE FROM users WHERE id = ?, but GDPR requires you to purge data from backups, logs, analytics pipelines, cached CDN assets, and third-party processors. Stripe handles this by maintaining a “deletion queue” that propagates erasure requests across 47 different subsystems with cryptographic verification that each completed.

The non-obvious insight: soft deletes don’t satisfy GDPR. Marking records as deleted=true while keeping the data accessible violates the regulation. You need true data destruction with audit trails proving completion.