Right to Erasure: The GDPR Right to Be Forgotten, Explained

The right to erasure, set out in Article 17 of the GDPR and widely known as the right to be forgotten, lets a person ask an organization to delete the personal data it holds about them. It is not absolute. It applies on six specific grounds, it can be refused on five, and you have one month to act. This guide is written for the organization that has to answer, not the person making the request.

General information, not legal advice. Erasure decisions turn on facts, so take advice on the borderline ones.

What the right to erasure actually says

Article 17 gives a person the right to obtain erasure of their personal data "without undue delay" where one of six grounds applies. The mirror-image duty sits on you: where a ground applies, you have an obligation to erase, not a discretion. The six grounds are worth knowing by heart, because most requests you receive will fall under the first two.

Two practical consequences follow. First, "no longer necessary" means a request can be valid even when nothing has gone wrong: you simply do not have a reason to keep the data anymore. Second, if consent was your lawful basis and it is withdrawn, you cannot quietly switch to legitimate interests to keep processing. That reads as a workaround and regulators treat it as one.

Right to erasure or right to be forgotten: is there a difference?

No. They are two names for the same right. "Right to be forgotten" is the informal term that came out of the 2014 Google Spain ruling, before the GDPR existed; "right to erasure" is the term the regulation actually uses in Article 17. The heading of Article 17 includes both, which is why they are used interchangeably. If a request arrives citing either phrase, treat it the same way.

The one place the older phrase still carries extra meaning is Article 17(2). Where you have made someone's personal data public and you are obliged to erase it, you must take reasonable steps, allowing for available technology and cost, to tell other controllers processing that data that the person has asked for links to it, and copies of it, to be erased. That is the "forgotten" part in its strongest form, and it is the part that reaches beyond your own database.

When you can refuse

Article 17(3) lists the exceptions. The right does not apply to the extent processing is necessary for:

• Freedom of expression and information. The exception that carries most of the weight in journalism and archives.
• Compliance with a legal obligation, or a public interest task. The everyday commercial exception: tax, accounting, and statutory record-keeping.
• Public interest in public health. Narrow and sector-specific.
• Archiving, research, or statistics in the public interest. Narrow, and it only holds where erasure would seriously impair the work.
• Establishment, exercise, or defence of legal claims. The exception you rely on when a dispute is live or genuinely foreseeable.

Notice what is not on that list. "It would be inconvenient," "we paid for that data," and "we might want it for marketing later" are not exceptions. Neither is a blanket retention policy on its own: a policy only helps you if it implements an actual legal obligation. And the exception has to be necessary for the specific data you are keeping, which is why partial refusals, keeping the invoice while deleting the marketing profile, are far more common than full ones.

How long do you have to respond to an erasure request?

One month from receipt, and you must act without undue delay within it. You can extend by two further months where the request is complex or where a person has made several, but you have to tell them within the first month and give a reason. The clock does not pause while you verify identity, so verification that drags on is time you spend from your own budget.

There is no fee. You can charge or refuse only where a request is manifestly unfounded or excessive, and the burden of showing that sits with you. For most organizations the honest answer is that the fee provision will never be used.

The obligation people forget: telling everyone else

Article 19 requires you to communicate the erasure to each recipient you disclosed the personal data to, unless that proves impossible or involves disproportionate effort. Recipients means processors, vendors, and any third party you passed the data to: your email platform, your analytics vendor, your CRM, the partner you shared a lead list with.

In practice this is the step that quietly fails. A team deletes the record in the CRM, feels finished, and never tells the three downstream systems the record was synced to. Then a marketing email goes out to an erased contact six weeks later, and now you have a complaint with evidence attached. The person is also entitled to be told who those recipients were if they ask, which means you need to know.

Keeping that map current is ordinary discipline, the same kind you apply when you map each control you rely on to the framework that demands it. If you cannot list every system holding a given person's data, you cannot honestly promise you erased it, and that is a personal data discovery problem before it is a legal one.

What about backups?

You are not expected to tear a single record out of an immutable snapshot the day the request lands. The accepted approach is to put the data beyond use: erase it from live systems, exclude it from any restore, and let the backup expire on its normal cycle. Tell the person that is what you have done and roughly how long the cycle takes. The commitment you are making is that the data is not processed and does not come back. If a restore quietly resurrects an erased contact, that promise is broken and the original request was never really fulfilled.

Erasure is harder than access, and here is why

Teams that have handled access requests for years often find their first serious erasure request rougher, and the reason is structural. An access request ends in a document you can review before it leaves. An erasure request ends in an irreversible action inside your own systems.

That last row is the one that catches people. Delete too little and you have not complied. Delete too much and you have destroyed the transaction record you needed for a tax audit, or the evidence you needed for a claim, and no one can give it back. Getting erasure right means being precise about the boundary before anything is destroyed, not after.

A workflow that holds up

Run every erasure request through the same five steps and it stops being frightening:

1. Verify the requester. Deleting the wrong person's data on an unverified request is its own breach.
2. Log the deadline. One month from receipt, on the day it lands.
3. Find every location. Live systems, integrations, exports, spreadsheets, and the tools you forget you connected.
4. Split delete from retain. Name the exception for anything you keep, with an end date. Everything else goes.
5. Erase, notify, record. Delete, tell the recipients under Article 19, and write down what you erased, what you kept, and why.

Step five is what turns a deletion into a defensible deletion. Six months later, nobody remembers which systems were touched, so the record is the only thing that answers a regulator.

This is the loop data deletion request software automates. Obtainer verifies the requester, discovers where the person's data lives across your connected systems, flags the records covered by a statutory exception so you keep what you are required to keep, routes the rest for erasure, and logs what happened. Because deletion is irreversible, nothing is erased on its own: a human approves at the review gate and you stay in control. When you are ready to write the reply, the GDPR right to erasure response template covers the three letters you will actually send, and if the request comes from California instead, the deadline and the exceptions change, so use the CCPA right to delete guide.

Erasure is also the right people reach for when what they actually want is a correction. If the complaint is that your records are wrong rather than that you should not hold them, it is the right to rectification that applies, on the same one-month clock. The data subject rights overview maps all eight GDPR rights against California's six if you need to work out which one a request is really invoking. Where a person wants you to stop using their data rather than delete it, the request falls to the right to restrict processing and the right to object, which pause processing instead of ending it.