"Right to be forgotten" is the popular name for GDPR Article 17, and the name oversells what the law actually does. Article 17 doesn't give anyone an unconditional right to vanish from every system that ever touched their data. It gives them a right to have their personal data erased when specific grounds apply, subject to a specific list of exceptions that can override it, and businesses that treat every erasure request as an all-or-nothing wipe either over-delete data they were legally entitled to keep, or under-deliver on data they were required to remove.
Where the phrase actually comes from
The term predates GDPR by several years. It entered EU law through Google Spain SL v. Agencia Espanola de Proteccion de Datos, a 2014 ruling from the Court of Justice of the European Union, which held that a search engine could be required to delist links to lawfully published information about an individual when that information was no longer relevant to the purpose it was originally processed for. That case was about search result delisting specifically, a narrower situation than what most businesses deal with, but it's the origin of the phrase, and GDPR's Article 17 codified a broader, statutory version of the same underlying idea across the EU rather than leaving it to case-by-case court rulings.
When the right to erasure actually applies
Article 17(1) lists six grounds, and at least one has to apply for the right to kick in:
- The personal data is no longer necessary for the purpose it was originally collected or processed for.
- The individual withdraws consent, and there's no other legal basis for the processing.
- The individual objects to the processing under Article 21, and there are no overriding legitimate grounds to continue.
- The personal data has been processed unlawfully.
- Erasure is required to comply with a legal obligation under EU or member state law.
- The data was collected in connection with offering information society services directly to a child.
A request that doesn't fit one of these grounds isn't automatically refused, most erasure requests naturally correspond to "I withdrew consent" or "this is no longer necessary," but it's worth actually checking which ground applies, since the answer affects what else in the file needs to change (a withdrawn consent, for instance, usually means the processing has to stop even before erasure is complete).
The exceptions that override it
Article 17(3) lists five situations where the right to erasure doesn't apply, even when one of the grounds above is met:
- Exercising the right of freedom of expression and information.
- Compliance with a legal obligation requiring processing (tax and accounting retention laws being the most common in practice), or performance of a task in the public interest.
- Public health reasons in the public interest.
- Archiving purposes in the public interest, scientific or historical research, or statistical purposes, where erasure would seriously impair those objectives.
- The establishment, exercise, or defense of legal claims.
That last one covers more ground than it sounds like. A business facing, or reasonably anticipating, a dispute with the individual making the request can retain the specific data relevant to that dispute, rather than erasing everything and losing its own ability to defend a claim later.
What "must be deleted" actually means in practice
What erasure typically covers vs. what can often be retained
| Typically deleted | Often retained | |
|---|---|---|
| Primary account and profile data | ||
| Marketing preference and behavioral profile | ||
| Financial records under statutory retention law | ||
| Data relevant to an active or anticipated legal claim | ||
| Data shared with third parties, once notified | Third party erases independently |
Article 19 adds an obligation that's easy to miss: once you erase data, you generally have to notify each recipient the data was disclosed to, so they can erase it too, unless that proves impossible or involves disproportionate effort. If a customer's data was shared with an email marketing platform, an analytics vendor, or a data processor acting on your behalf, the erasure request isn't complete until those parties are notified, not just your own primary database.
Backups and logs: the part that trips up most technical teams
Backups are the most common source of confusion in an erasure request, because most systems can't selectively delete one person's record from a backup snapshot without restoring, editing, and re-archiving the whole thing, which is often disproportionate for a single request. Regulatory guidance generally accepts a pragmatic approach here: erase the data from live, production systems immediately, and let it age out of backups on their normal rotation schedule (30, 60, or 90 days, whatever the backup retention policy already specifies), as long as the backup data isn't restored into live use in the meantime and isn't accessible for any purpose other than disaster recovery.
Logs raise a similar but distinct issue. Application, security, and access logs often contain personal data (an email address in an error log, an IP address in a web server log) incidentally, not as their main purpose. A short, defined retention period for logs, justified by security and troubleshooting needs, is generally defensible even after an erasure request, but an indefinite retention policy with no stated reason is exactly the kind of gap a request like this can expose. The practical fix isn't erasing logs on demand, which is usually impractical, it's having a genuinely short retention window for logs in the first place, so there's rarely much left to erase by the time a request arrives.
Responding on time and documenting the decision
The same one month deadline that governs access requests under Article 12(3) applies to erasure requests, extendable by two further months for complex or numerous requests, with the requester notified of the extension and its reasons within the first month. If an exception applies and no data is being erased, that decision, and which specific exception it rests on, should be recorded, not just communicated to the requester. A one-line note ("Article 17(3)(e), data retained for an ongoing billing dispute") is what turns a defensible decision into a documented one if it's ever questioned later.
Build erasure rights into the policy your users actually read
A privacy policy that mentions "the right to erasure" without any explanation of what it can and can't reach sets an expectation the actual process won't always meet. Our Privacy Policy Generator builds GDPR's full set of data-subject rights, including erasure, its grounds, and how retention obligations interact with it, into a policy scoped to the jurisdictions you operate in. For the parallel process on the access side of these same rights, see How to Respond to a GDPR Data Subject Access Request, and for how erasure and consent withdrawal interact with CCPA's very different rights model, GDPR vs CCPA Cookie Consent Requirements Explained covers where the two frameworks agree and diverge.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.
