GDPR Engineering in .NET Systems & Azure

GDPR is an engineering specification dressed up as a legal text. The articles people quote in compliance meetings — lawful basis, data subject rights, retention limits, accountability — only become real when somebody writes the code that enforces them. Most of the “GDPR programme” work happening in organisations is policy theatre: cookie banners, privacy notices, a quarterly training video. The technical surface where regulators actually look — deletion endpoints, consent ledgers, retention jobs, log scrubbing — gets postponed indefinitely.

The collection here treats GDPR as something you build, not something you sign off on. Data Subject Access Request handling means an endpoint that exports every shred of personal data the user touched, across the operational database, analytics warehouse, message queue, cache, and that legacy system everyone forgot. The right to erasure is the same problem inverted: a coordinated, auditable deletion that reaches every store and proves it. Both fall apart the moment your User entity is a 30-column god object with foreign keys spread across half the schema.

Consent is the article that exposes most implementations as fiction. GDPR Article 7 wants granular, withdrawable, evidence-backed consent with a timestamp and a version. A boolean column called IsConsented is not that. ASP.NET Core Identity with a properly modelled consent ledger, middleware that checks current consent on every request, and an audit trail that survives a database restore is closer to what the regulator expects to see.

Retention is where automation pays back the engineering effort. Azure Storage lifecycle rules, Cosmos DB TTL, scheduled cleanup Functions with immutable run logs — none of these are exotic. They are simply the difference between a policy document and provable deletion. The articles here are about building that difference, not documenting around its absence.