Data Protection · 4 March 2026 · 10 min read

Retention, Erasure and the Limits of the Right to Be Forgotten

Erasure requests collide with regulatory retention more often than they resolve cleanly. DC-Services maps where the right ends and the obligation begins.

Erasure requests are sometimes treated as if they overrode everything else, and sometimes refused on a reflex. Neither approach is quite right. UK GDPR provides a real right to erasure with real limits, and the limits matter most precisely where regulatory retention applies. DC-Services maps each request against the relevant retention obligations, identifies what can be erased, identifies what must be kept, and explains the difference to the requester in writing.

The Right As Written, Not As Imagined

Article 17 gives data subjects a right to erasure in defined circumstances — for example, where the data is no longer necessary for its original purpose, consent has been withdrawn, or the data was unlawfully processed. The right is not absolute, and the exceptions are part of the right rather than awkward exceptions to it.

The file records what the requester actually asked for, the basis on which the right is being exercised, and the data categories implicated. Vague requests are clarified before they are evaluated, because a vague request is hard to comply with and easy to mishandle.

Where Retention Obligations Stop The Right

Records held under a legal obligation — anti-money-laundering retention, tax record requirements, regulatory audit material — cannot be erased on request while the obligation runs. The exemption is specific: it covers the data that the obligation actually requires, not the entire customer file by default.

The response identifies the specific records held under retention, the obligation that requires them, and the date on which the obligation expires. Other data outside that scope is reviewed against the right on its own merits, rather than swept into the same refusal.

Partial Erasure And Selective Retention

Most requests do not divide cleanly into erase-everything or keep-everything. A working response usually involves erasing the data that can be erased, retaining the data that must be retained, and recording both decisions in a way the requester can understand without having to ask twice.

The file produces a written response that itemises what has been erased and what has been retained, with the reason for each. A requester who is told what was kept and why is more likely to accept the response than one who receives a generic refusal.

Erasure From Backups And Derivative Systems

Erasure from the primary system is not the whole job. Backups, log files, archived exports and downstream systems may still hold the data, and a meaningful erasure has to address them — or document why it cannot address them yet.

The response sets out which systems hold the data, which have been processed for erasure, and which retain the data subject to the next backup cycle or system review. The point is honesty about scope, not a claim that the data has vanished everywhere instantly.

Documenting The Decision Trail

An erasure decision that is not documented is, for accountability purposes, an erasure decision that did not happen. The decision trail matters as much as the action, because the regulator's question is rarely what was done but how the choice was reached.

Each request is recorded with the date received, the data categories considered, the obligations checked, the decisions reached and the response sent. The trail allows the decision to be defended later without reconstruction.

Erasure Request Handling Checklist

Clarify the scope of the request in writing before evaluation.
Identify the specific data categories the request implicates.
Map each category against active retention obligations.
Erase data outside retention obligations where the right applies.
Retain data within retention obligations and record the basis.
Address backups and downstream systems explicitly in the response.
Document the full decision trail with dates and reasoning.

Frequently asked questions

Does the right to erasure override anti-money-laundering retention?

No. Records held under a specific legal obligation are exempt from erasure while the obligation runs. The response identifies which records fall under retention and the date on which the obligation expires.

Can part of a request be granted and part refused?

Yes, and it is often the right answer. Data outside retention can be erased; data inside retention is kept; the response sets out which is which and why, so the requester can see the reasoning rather than receiving a blanket outcome.

How are backups handled?

The response identifies the systems that hold the data, the action taken on each, and any data that remains pending the next backup cycle or system review. The aim is accurate disclosure, not a claim of instantaneous erasure everywhere.

What if the request is too vague to act on?

It is clarified in writing before evaluation. A vague request is hard to comply with and easy to mishandle, and the clock for response runs from the point at which the request is sufficient to act on.

Does DC-Services advise on whether to grant erasure?

The work documents the obligations, maps the decision and produces the response. Substantive advice on contested or complex erasure questions remains a matter for the data protection officer or regulated adviser, depending on the structure in place.

Erasure works as a real right when it is treated as one — with limits, with reasons, and with a written trail. Reflex refusals and reflex compliance both fail the same standard.