From a Deletion Request to a Defensible Forgetting Claim

The subject here is the working handoff between a GDPR erasure request and the evidence used to describe its outcome. The focus is how a controller or model operator can match the strength of a claim to the scope, action, propagation path, recovery test, and uncertainty actually covered. This is not a universal checklist or a new legal standard. It is a disciplined way to avoid saying “forgotten” when the available evidence supports only “one record was removed” or “one output path was suppressed.”

The earlier chapters separated legal decisions from technical interventions and showed why both ordinary systems and learned models have persistence paths. The practical challenge is to connect those insights without collapsing them. A controller may need to decide whether Article 17 requires erasure, whether an exception or retention duty applies, and what must be communicated. An engineering team may need to remove or alter data in live systems, manage copies and restoration, and test a model if the data influenced one. The resulting statement should make clear which work belongs to which question.

Start by naming the object and its boundaries

Before any command is run, identify the object of the request. That means more than finding a person’s name in one database. The controller should connect the data subject to the processing purpose, data categories, legal basis, storage locations, recipients, retention period, and relevant processors. The EDPB’s observations about weak procedures and incomplete mapping show why this is the first control: if the organisation cannot state where the request applies, it cannot tell whether a later action was complete for that scope.

The purpose of processing is especially important. A person may have a profile, a marketing preference, a support conversation, and an invoice in the same service. A request may lead to erasure for one purpose, continued retention for another where a legal obligation applies, or restriction while an accuracy dispute is examined. A map that treats all records associated with the person as one object encourages both under-deletion and over-deletion. A map organised by purpose and data category makes the legal ground, exception, and action visible.

The map should also record where the data travelled. Article 17(2) addresses reasonable steps to inform other controllers when public personal data must be erased, including links, copies, or replications. Article 19 addresses communication of an erasure carried out under Article 17(1) to recipients to whom the data were disclosed, unless that is impossible or disproportionate. These provisions do not create a ready-made rule for every derivative system, but they make recipients and copies relevant facts rather than optional background.

Processors belong in the same picture. A processor may operate a service, analytics environment, storage system, or other processing function on behalf of the controller. Under the GDPR, the processor must assist with data-subject rights through appropriate measures, and the service arrangement must address the deletion or return of personal data and existing copies at the end of the service unless law requires storage.