GDPR Article 17 — Right to Erasure (Right to be Forgotten)
The GDPR right requiring controllers to delete personal data without undue delay upon request, subject to specific grounds and exceptions — with significant engineering implementation complexity.
Article 17 of the GDPR grants data subjects the right to obtain erasure of their personal data without undue delay where one of six grounds applies: the data is no longer necessary for the purpose it was collected; the subject withdraws consent and there is no other legal basis; the subject objects under Article 21 and there are no overriding legitimate grounds; the data has been unlawfully processed; erasure is required by EU or Member State law; or the data was collected in relation to the offer of information society services to a child (Article 8). Controllers must respond to erasure requests within one month (extendable to three months for complex requests with notice to the data subject). Article 17(2) creates a propagation obligation: where the controller has made personal data public, it must take reasonable steps to inform other controllers that erasure is requested.
Engineering erasure at scale is architecturally challenging. In a typical microservices application, a single user's data may be distributed across: a user profile service (PostgreSQL), an event log (Kafka/S3), an analytics warehouse (Snowflake/BigQuery), a search index (Elasticsearch), a recommendation engine (Redis/graph database), email marketing (Mailchimp/Braze), CDN caches, backup tapes, audit logs, and archived data lakes. Each data store requires a different erasure mechanism: SQL DELETE and vacuum, Kafka consumer group offset management and log compaction, Snowflake GDPR compliance features, Elasticsearch delete-by-query with segment merging, cache invalidation, and tape overwriting. Pseudonymization of the linking identifier (user ID to ephemeral UUID) is an accepted technical approach where true deletion is disproportionately burdensome — but requires careful analysis that re-identification is not possible.
Article 17 contains important exceptions that controllers frequently misapply. Article 17(3) disapplies the right to erasure where processing is necessary for: exercising the right of freedom of expression; compliance with a legal obligation; public interest tasks or official authority; archiving in the public interest, scientific or historical research, or statistical purposes (Article 89); or establishment, exercise, or defense of legal claims. "Legal obligation" is the most commonly invoked exception: financial transaction records may need to be retained for 6–10 years under AML/KYC regulations, employment records for statutory periods, and tax records under jurisdiction-specific retention laws. The exception is narrow — it applies to the legal obligation to retain specific data, not to a general preference to retain all data. Controllers must demonstrate the specific law requiring retention of the specific data element, not merely assert a general retention policy.
We architect erasure pipelines that maintain a unified data subject index mapping user identities to all data stores holding personal data, automate erasure propagation across all data stores using choreographed event-driven workflows, and implement pseudonymization strategies for analytics environments where hard deletion would destroy referential integrity. We also build legal hold management systems that correctly apply Article 17(3) exceptions to specific data elements rather than applying blanket retention overrides.
Compliance-Native Architecture Guide
Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.