GDPR Art.17: Right to Erasure ('Right to Be Forgotten')
What This Control Requires
The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies: (a) the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed; (b) the data subject withdraws consent on which the processing is based and where there is no other legal ground for the processing; (c) the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2); (d) the personal data have been unlawfully processed; (e) the personal data have to be erased for compliance with a legal obligation; (f) the personal data have been collected in relation to the offer of information society services referred to in Article 8(1).
In Plain Language
The "right to be forgotten" gets the most media attention of any GDPR right, but it is also the most misunderstood. It is not absolute - individuals can only request erasure when one of six specific grounds applies, and there are important exceptions for legal obligations, freedom of expression, public health, archiving in the public interest, and legal claims. The six grounds cover situations where data is no longer needed for its original purpose, consent was withdrawn with no alternative legal basis, the individual successfully objected to processing, the data was processed unlawfully, deletion is required by law, or data was collected from children in relation to online services. Every erasure request needs assessment against these criteria before you act on it or refuse it. If you have made the data public, Article 17(2) adds another layer: you must take reasonable steps to inform other controllers processing that data about the erasure request. This is the "right to be forgotten" in the Google sense - notifying search engines and third parties who may have copied or indexed the data. "Reasonable steps" accounts for available technology and cost, but you need to demonstrate you actually tried.
How to Implement
Build an erasure request handling procedure with a clear decision framework. When a request comes in, staff need to verify identity, assess which Article 17(1) ground applies (if any), check whether an Article 17(3) exception overrides it, and document the decision with reasoning. Create a simple flowchart or checklist so this assessment happens consistently. Map everywhere personal data lives - primary databases, analytics platforms, email systems, file shares, cloud services, data warehouses, CRM, marketing tools, and third-party platforms. For each location, document the technical process for deletion. Some systems need cascade delete rules, others require anonymisation of audit logs, and some third-party tools only support manual deletion through their admin interfaces. Know the limitations before a request arrives. Deal with backups and archives pragmatically. Surgically removing one person's data from a backup tape is often impractical. Workable approaches include flagging records for deletion so they are not restored, relying on backup rotation schedules for eventual overwriting, or encrypting data and destroying keys. Document your chosen approach and make sure backup retention periods are reasonable. For data you have made public, implement Article 17(2) notifications. Track where personal data has been published or shared externally. Use search engine content removal tools and API-based notifications to third-party platforms. Keep records of what you notified and when. Verify that erasure is actually complete. After executing a deletion, spot-check the relevant systems to confirm the data is gone. Maintain an audit trail covering which systems were checked, what was deleted, and any data retained under an applicable exception with documented justification.
Evidence Your Auditor Will Request
- Documented erasure request handling procedure with decision framework
- Erasure request log showing requests, assessments, decisions, and completion dates
- Data mapping identifying all systems where personal data is stored and deletion capabilities
- Evidence of completed erasure actions across all relevant systems
- Records of Article 17(2) notifications to third-party controllers for published data
Common Mistakes
- Treating the right to erasure as absolute and deleting data that should be retained for legal compliance
- Deleting data from primary systems but failing to address backups, archives, and third-party systems
- No formal assessment of whether Article 17(1) grounds are met before processing or refusing the request
- Inability to locate all instances of personal data across the organisation due to poor data mapping
- Failing to notify third parties who received the data about the erasure request
Related Controls Across Frameworks
| Framework | Control ID | Relationship |
|---|---|---|
| ISO 27001 | A.8.10 | Related |
Frequently Asked Questions
Can we refuse an erasure request?
What about data in backups?
Does erasure mean anonymisation or actual deletion?
Track GDPR compliance in one place
AuditFront helps you manage every GDPR control, collect evidence, and stay audit-ready.
Start Free Assessment