Right to Be Forgotten: How to Implement It Without Pain
The right to be forgotten (formally 'right to erasure' under GDPR Article 17) gives individuals the right to request deletion of their personal data when it is no longer necessary for the purpose it was collected, when consent is withdrawn, or when the data was processed unlawfully. Implementing this right requires identifying all locations where a user's personal data is stored (database records, backups, logs, analytics, third-party services), deleting or anonymizing the data in each location, and maintaining an audit trail of the deletion request itself without retaining the deleted personal data.
Written by Yashveer Singh, founder of Yashveer Labs.
What you need to know
- Right to erasure does not require deleting all records that reference a user. It requires removing personal data (identifiers) from those records, which can often be achieved by anonymization.
- Maintain an audit log that a deletion request was made and completed, without retaining the personal data that was deleted.
- Backups are a documented exception: personal data in backups can persist until the backup expires, provided the backup is not used as a data source.
- Third-party services (analytics, CRM, email marketing) hold copies of the user's data and must be included in the deletion workflow.
- Implement deletion as a specific data access layer operation, not as ad-hoc database queries. The deletion operation should be auditable and repeatable.
The core argument
Right to erasure implementations fail for one of two reasons: they are too narrow (only deleting the primary user record while leaving personal data in analytics, logs, email marketing, and CRM) or too aggressive (deleting records that should be retained for accounting, legal, or referential integrity reasons). Both failures are avoidable with a data map.
A data map is a complete inventory of every location where personal data is stored, organized by data type and retention requirement. Before writing any deletion code, answer: where is the user's name stored? Where is their email address stored? Where is their IP address logged? For each location, identify whether the data should be deleted or anonymized, and whether any legal basis requires retention (accounting records, legal hold). The data map is the specification for the deletion implementation.
The implementation pattern that works: a deletion request triggers a coordinated workflow that calls a deletion function for each data store in the data map. The primary database deletion anonymizes the user record and cascades to related personal data fields. Separate calls handle the analytics data, email marketing suppression, CRM removal, and log scrubbing. Each step logs completion. The workflow is idempotent: running it twice produces the same result as running it once. The audit record shows that the workflow was triggered and completed, without retaining any of the deleted personal data.
Common mistakes
- Only deleting the user account record without searching for personal data in other tables. A user table deletion that leaves the user's email in the orders table, their IP in the access logs table, and their phone in the support tickets table does not satisfy the right to erasure. Build a complete data map and delete or anonymize personal data in every location.
- Deleting data that has a legitimate legal basis for retention. Order records, invoices, and financial transactions often have legal retention requirements (accounting regulations require 5-7 years in many jurisdictions). Deleting these records to comply with an erasure request violates other legal obligations. Anonymize instead: replace personal identifiers with anonymous values while retaining the transaction records.
- Not including third-party services in the deletion workflow. Personal data shared with Google Analytics, Mixpanel, HubSpot, Mailchimp, Intercom, and other third-party services must also be deleted on an erasure request. Each service has an API for user data deletion. Build the deletion workflow to call these APIs as part of the standard erasure process.
- Not sending confirmation to the requestor. GDPR requires a response to an erasure request within one month. Not acknowledging the request or confirming its completion is a compliance failure. Automate the acknowledgment (immediate confirmation of receipt) and the completion notification (confirmation that deletion is complete) as part of the workflow.
- Using production deletion code in the wrong environment. Deletion functions that operate on real user data should never run in development or staging environments connected to production data. Validate the deletion workflow in a staging environment with synthetic data before running it against production, and add environment checks to the deletion functions that prevent accidental execution outside production.
Where to start
- Build a personal data map. For every database table, log store, analytics system, and third-party service, document: what personal data fields are stored, the purpose of storage, the retention period, and whether deletion or anonymization is appropriate. This document takes a day to produce and is the foundation for everything else.
- Implement a user anonymization function in the database layer. Write a function (or stored procedure) that sets all personal data fields on the user record to NULL or anonymous placeholder values, updates related tables to remove or anonymize references, and marks the user record as anonymized with a timestamp. Test it against a staging database with test accounts.
- Build the deletion workflow as an auditable process. Create a deletions log table (with columns: request_id, requestor_user_id, requested_at, completed_at, status) and a deletion workflow function that records the request, runs all deletion steps, and updates the log. The log entry itself does not store personal data, only the fact that a deletion request was processed.
Related reading
Frequently asked
Why I am built for this project type
I have worked on five production systems before turning eighteen. That is not a flex. That is a statement of capability. Yashveer Singh, founder of Yashveer Labs. The work in this article is the work I do on a weekly basis. If you are facing the problem I just described, I do not need to be sold on solving it. I need to be told the constraints.
Posts that line up with this one.
- Security, Auth, and Compliance
The Threat Model: How to Build One in Two Hours
A threat model does not have to be a hundred-page document. A useful one fits on a whiteboard, takes two hours to build, and changes how the team makes security decisions for months. Here is the format I use.
- Security, Auth, and Compliance
How to Sell to Enterprise Without a Full Compliance Stack
You do not need SOC 2 Type II and HIPAA certification before your first enterprise conversation. Here is what you actually need and how to close the deals while you build toward the rest.
- Security, Auth, and Compliance
Incident Response for Startups: A Playbook
A startup does not need an enterprise incident response program. It needs a simple, documented process that prevents the chaos that happens when something breaks at 2am and nobody knows who does what.
- Security, Auth, and Compliance
Insecure Direct Object References: The Bug Founders Underestimate
IDOR vulnerabilities let attackers access other users' data by changing an ID in a URL or API request. They are simple to introduce and expensive to miss. Here is how to find and prevent them.