Category: Data Subject Rights

Right to be Forgotten

Also known as: RTBF, Right to Erasure

Simply put

The right to be forgotten is the ability of an individual to ask an organization to delete personal data held about them, or to have information about them removed from internet search results, in certain circumstances. It is not an absolute right, meaning a request can be refused where the organization has valid grounds to keep the data. It originated in the European Union and is closely related to what the EU GDPR calls the right to erasure.

Formal definition

The right to be forgotten (RTBF) is commonly used to describe two related but distinct concepts. First, it refers to the right to erasure codified in the EU GDPR (and mirrored in the UK GDPR), under which a data subject may request that a data controller erase personal data concerning them without undue delay in defined circumstances; the controller, not the processor, bears the obligation to act on and evaluate such a request against the applicable grounds and exemptions. Second, in common usage the phrase also references the de-indexing or delisting of personal data from search engine results, a concept associated with EU jurisprudence rather than being co-extensive with the statutory right to erasure. The right is qualified rather than absolute, and controllers may lawfully refuse or limit erasure where recognized grounds apply. This entry does not enumerate the specific conditions, exemptions, associated notification obligations to other recipients, time limits, or how the right is treated outside the EU/UK regimes, and treatment under other frameworks such as the CCPA/CPRA differs and is out of scope here. Any specific article numbers, dates, or procedural detail should be confirmed against the applicable legal text.

Why it matters

The right to be forgotten sits at the intersection of individual autonomy and organizational data practices, and it carries direct operational and legal consequences for data controllers. Because the right is qualified rather than absolute, organizations cannot simply automate deletion on request; they must be able to evaluate each request against recognized grounds and any applicable exemptions, and to document the reasoning where a request is refused or limited. This demands demonstrable accountability rather than stated intent, since an organization that cannot show how it assessed and actioned a request is exposed to challenge from both data subjects and supervisory authorities.

The term also matters because it is frequently conflated with two distinct ideas. In the EU GDPR (and mirrored in the UK GDPR), the phrase maps to the statutory right to erasure, which is an obligation borne by the data controller, not the processor. In common usage, however, the phrase also describes the de-indexing or delisting of personal data from search engine results, a concept associated with EU jurisprudence and first established in the European Union in May 2014 through a ruling of the European Court of Justice. Treating these as one and the same leads to misaligned processes, because a delisting request directed at a search engine and an erasure request directed at a controller involve different parties and different assessments.

For practitioners, the practical stakes are that erasure obligations must be operationalized across systems, backups, and any onward recipients, while recognizing that the right can be lawfully refused where valid grounds to retain data apply. This entry does not enumerate those specific grounds, exemptions, notification obligations, or time limits, nor does it address how equivalent or divergent rights are treated under frameworks such as the CCPA/CPRA, which fall outside its scope.

Who it's relevant to

Data Protection Officers and Privacy Leads

DPOs and privacy teams are responsible for ensuring the organization can receive, assess, and respond to erasure requests in line with the EU GDPR or UK GDPR, and for maintaining demonstrable evidence of how each request was evaluated. They must distinguish statutory erasure obligations, which fall on the controller, from search engine delisting, which involves a different party and assessment.

Data Controllers

As the party bearing the obligation to act on erasure requests, controllers must be able to locate relevant personal data across systems and evaluate requests against applicable grounds and exemptions. They must also be prepared to refuse or limit erasure where valid retention grounds apply, and to document that reasoning.

Privacy Engineers and Data Governance Teams

These teams operationalize erasure by mapping where personal data resides and building processes to action deletion across primary stores, backups, and onward recipients. Their governance work on data lineage, cataloging, and ownership underpins a controller's ability to respond, though the legal determination on any given request remains a controller responsibility.

Legal and Compliance Professionals

Legal and compliance staff advise on whether recognized grounds or exemptions permit refusal, and confirm that request handling aligns with the applicable legal text. They should note that the right is qualified rather than absolute, that treatment under frameworks such as the CCPA/CPRA differs, and that specific procedural detail must be checked against the governing instrument.

Inside RTBF

Right to Erasure (Article 17, EU GDPR)

The formal name under the EU GDPR for what is colloquially called the 'right to be forgotten.' It gives a data subject the ability to request that a controller delete personal data relating to them in certain circumstances. A materially similar right exists under the UK GDPR. This entry does not cover the specific article-by-article procedural detail, which practitioners should verify against the current text.

Conditional, not absolute

The right applies only where specified grounds are met, such as where the data is no longer necessary for the purpose it was collected, where consent is withdrawn and no other lawful basis applies, or where the data subject objects and there are no overriding legitimate grounds. It is not a blanket entitlement to have all data deleted on demand.

Recognised exemptions

Erasure may be refused or limited where processing is necessary for reasons such as exercising the right of freedom of expression and information, compliance with a legal obligation, or the establishment, exercise, or defence of legal claims. The availability and interpretation of exemptions is jurisdiction- and context-dependent.

Controller obligation

The obligation to act on a valid erasure request falls on the data controller, which determines the purposes and means of processing. Where the controller has made the data public or shared it with processors, the controller generally bears responsibility for taking reasonable steps to inform those parties. A data processor typically acts on the controller's instructions rather than adjudicating the request itself.

Regime-specific scope

This right as framed here originates in the EU and UK GDPR context. Other regimes, such as the CCPA and CPRA in California, provide deletion rights that are structured differently in their grounds, exceptions, and definitions. These should not be treated as interchangeable with the GDPR right.

Common questions

Answers to the questions practitioners most commonly ask about RTBF.

Does the right to be forgotten mean an organisation must always delete personal data on request?

No. The right, framed as the right to erasure under the EU GDPR and mirrored in the UK GDPR, is not absolute. It applies in specific circumstances and is subject to exemptions, such as where processing is necessary for exercising freedom of expression, for compliance with a legal obligation, or for the establishment or defence of legal claims. A controller must assess whether a valid ground for erasure applies and whether an exemption overrides it, rather than treating every request as an automatic deletion mandate.

Is the right to be forgotten a universal legal concept that applies the same way everywhere?

No. It originates in EU law and is reflected in the UK GDPR, and its scope and conditions are tied to those instruments. Other regimes, such as the CCPA and CPRA, provide their own deletion or erasure rights with different triggers, exemptions, and definitions. HIPAA does not frame a comparable general erasure right. Treatment therefore differs by jurisdiction, and a request valid under one regime may not carry the same obligations under another.

Who bears the obligation to act on an erasure request when a processor holds the data?

The data controller generally bears accountability for responding to the data subject and determining whether erasure applies. Where a processor holds relevant personal data, the controller typically instructs the processor to delete it under the terms of their processing arrangement. The processor's obligation is generally to act on the controller's documented instructions rather than to independently adjudicate the request. This entry does not detail specific contractual clauses required to give effect to such instructions.

How should an organisation handle erasure when personal data has been disclosed to third parties?

Where a controller has made personal data available to others and receives a valid erasure request, it is generally expected to take reasonable steps to inform those recipients of the request, taking account of available technology and cost. The practical mechanics of tracing recipients, the reasonableness threshold, and the extent of onward notification depend on context and implementation, and are not exhaustively specified in this entry.

What does it mean to demonstrate that an erasure request was handled properly?

Accountability under governance and data protection frameworks generally requires demonstrable evidence rather than stated intent. In practice this typically means retaining records of the request, the assessment of whether erasure or an exemption applied, the decision reached, and the actions taken across systems and processors. This entry does not prescribe specific retention periods for such records or the format of that evidence.

Does encrypting or pseudonymising data satisfy an erasure request instead of deleting it?

Not on its own. Pseudonymisation is reversible and the data generally remains personal data, and encryption does not by itself render data non-personal. Whether a technique such as rendering data inaccessible or destroying keys can be treated as equivalent to erasure depends on the jurisdiction, the specific facts, and how residual re-identification risk is assessed. This entry does not resolve when such techniques may or may not be accepted as an alternative to deletion.

Common misconceptions

The right to be forgotten means an individual can always compel deletion of their data.

The right is conditional and subject to defined grounds and exemptions. A controller may lawfully retain data where, for example, it is needed to comply with a legal obligation or to defend legal claims. Whether erasure applies depends on the specific facts, purpose, and lawful basis for processing.

Withdrawing consent automatically triggers erasure.

Withdrawal of consent supports an erasure request only where consent was the lawful basis and no other lawful basis applies. Consent is one of several lawful bases; if the controller relies on a different basis for the same data, withdrawal of consent alone generally does not require deletion. Consent should not be conflated with other lawful bases.

Anonymizing, encrypting, or tokenizing the data satisfies an erasure request by rendering it non-personal.

Encryption and tokenization are reversible and do not make data non-personal; the underlying data typically remains personal data and within scope. Only genuinely irreversible anonymization removes data from scope. These are security and de-identification measures, not automatic substitutes for erasure.

Best practices

Establish a documented procedure to verify the identity of the requester and to assess each request against the specific grounds and exemptions before acting, rather than treating every request as an automatic deletion.

Determine and record the lawful basis for the relevant processing so you can correctly evaluate whether withdrawal of consent or an objection actually supports erasure.

Map where the personal data resides across systems, backups, and processors so that a valid erasure decision can be executed and evidenced consistently.

Where data has been shared with processors or made public, define and follow reasonable steps to notify those recipients, consistent with the controller's responsibilities.

Retain demonstrable records of how each request was assessed and resolved, since accountability requires evidence rather than stated intent, and document the justification when a request is refused under an exemption.

Confirm which regime applies to a given data subject and dataset, as deletion rights under other frameworks are structured differently and should be handled under their own requirements.