The Right to Be Forgotten: Handling Erasure Requests in Practice

The phrase "right to be forgotten" came from a 2014 court case, not from the GDPR. In Google Spain SL v AEPD (C-131/12), the Court of Justice of the EU ruled that a Spanish man could force Google to delist search results about a decade-old debt notice. The GDPR later codified the idea in Article 17 and gave it a plainer name: the right to erasure. Two things get lost when people call it a delete button. It is not a single click, and it is not absolute. You can lawfully keep data in several situations, and you have downstream obligations that most teams forget until a regulator asks.

This guide walks the request from receipt to closure: the grounds that trigger it, the exemptions that let you refuse, what to do about backups, the Article 19 notification chain, and how the CCPA right to delete runs alongside it. For the broader request-handling process across all rights, start with DSAR handling for website owners.

The six grounds that trigger erasure

Article 17(1) lists six situations where a person can ask you to delete their data and you generally must comply:

• The data is no longer needed for the purpose you collected it for.
• Consent is withdrawn and you have no other legal basis to keep processing.
• The person objects under Article 21 and you have no overriding legitimate grounds. For direct marketing, the objection is absolute.
• The data was processed unlawfully.
• Erasure is required to comply with a legal obligation.
• The data was collected from a child in connection with online services.

Notice the pattern. Erasure is usually the consequence of something else, a withdrawn consent, a successful objection, an expired purpose. When someone withdraws consent for analytics cookies, for example, the identifiers tied to that consent can fall under this right. That is one reason a clean consent log and cookie inventory make erasure faster: you already know what you hold and why.

When you can lawfully refuse

Article 17(3) sets out the exemptions. You can decline erasure, in whole or in part, where keeping the data is necessary for:

• Exercising the right of freedom of expression and information.
• Complying with a legal obligation (tax records and accounting are the classic example) or performing a task in the public interest.
• Reasons of public interest in public health.
• Archiving in the public interest, scientific or historical research, or statistics, where erasure would seriously impair those aims.
• Establishing, exercising, or defending legal claims. If you are in or reasonably anticipate a dispute, you can retain what you need for it.

The exemption is scoped to the data it actually covers. If you must keep an invoice for seven years under tax law, that does not license you to keep the marketing profile attached to the same person. Erase what you can, keep what the exemption genuinely requires, and document the split. A refusal still needs a response inside the deadline, with your reasons and a note that the person can complain to a supervisory authority.

The backup problem

Almost every erasure request runs into the same wall: the data lives in production systems and in backups. Regulators accept that you cannot always reach into a backup archive the moment a request lands. The UK ICO's guidance is that you should put the backup "beyond use", stop using that data actively, isolate it, and ensure it is overwritten or deleted on the normal backup cycle, rather than restoring it into live systems. Say this plainly in your response: the data is erased from live systems now and will clear from backups on your documented retention cycle. What you cannot do is quietly restore a backup and bring the erased record back to life.

Article 19: you have to tell everyone else

This is the step most teams miss. Article 19 says that when you erase data, you must communicate the erasure to each recipient you disclosed it to, unless doing so is impossible or involves disproportionate effort. If someone asks, you have to tell them who those recipients were.

Article 17(2) goes further for data you made public: you must take reasonable steps, accounting for available technology and cost, to inform other controllers that the person has asked to erase any links to or copies of the data. In practice that means keeping a record of who you send personal data to (processors, ad partners, enrichment vendors) so that an erasure request can propagate down the chain rather than dead-ending in your own database. A record of processing activities is what makes this notification possible.

Search engines and delisting

The original Google Spain right is narrower than a full erasure. It is a right to delist, to have specific results removed from searches against your name, not to have the underlying page deleted. Search engines run their own request forms and weigh your privacy against the public interest in the information. A public figure's professional conduct is far harder to delist than a private individual's spent debt. If your organisation runs a search product or publishes content, expect delisting requests to arrive separately from GDPR erasure requests, and treat the balancing test seriously rather than deleting or refusing reflexively.

The CCPA right to delete runs in parallel

California's version is the right to delete (Civil Code 1798.105), and the mechanics differ from GDPR in ways worth knowing. Under CCPA regulation section 7022, you can satisfy a deletion request three ways: permanently erase the data, deidentify it, or aggregate it. You must also notify your service providers and contractors to delete the data they hold under their contracts, and notify third parties you sold or shared it with, unless that proves impossible or takes disproportionate effort.

The CCPA also carries its own exceptions (completing a transaction, security, legal compliance, internal uses aligned with the consumer's expectations). And it adds a wrinkle GDPR does not: if you deny a deletion request because an exception applies, you still have to delete the data for any other purpose, and you must not use it for anything else. For the wider US picture, see the US state privacy laws guide.

How CookieBeam handles erasure requests

CookieBeam ships an embeddable privacy portal you can attach to a banner. When a visitor opens it, the portal detects their region and shows the request types that actually apply there: an EU visitor sees access, deletion, rectification, portability, and objection, while a California visitor sees access, deletion, do-not-sell, and correction. A deletion request routes into a request register with a status and timestamps, so the one-month clock is visible rather than buried in an inbox. Requests are tied to the requester's email and verified before they are actioned, which is the identity step Article 17 requires. The portal is the intake and tracking layer; the actual deletion across your systems and processors stays a human decision, because only you know which Article 17(3) exemptions apply to a given record.

Authoritative sources

• GDPR Article 17, right to erasure
• GDPR Article 19, notification obligation
• UK ICO: Right to erasure
• Irish DPC: The right to erasure (Articles 17 and 19)
• CJEU judgment in Google Spain SL v AEPD (C-131/12)
• CCPA Regulations section 7022, requests to delete