What the Right to Erasure Actually Requires
For the GDPR right to erasure, the critical question is not simply whether a person asks for deletion. It is whether a legal ground requires a controller to erase, whether an exception permits the processing to continue, and how the decision must be carried out and explained. This chapter turns Article 17 and its surrounding duties into a decision path that readers can use to distinguish a completed erasure from an unexamined request or a technical shortcut.
That distinction is the legal foundation for everything that follows. A model may later be asked to unlearn, but neither the word “unlearning” nor the disappearance of an account determines what the GDPR requires. The legal analysis begins with the purpose and context of processing, the data concerned, the controller’s responsibilities, and the reason the request was made.
Article 17 starts with a ground, not a button
Article 17 gives a data subject the right to obtain erasure of personal data concerning them without undue delay, but only where one of the provision’s grounds applies. The first ground is that the data are no longer necessary for the purposes for which they were collected or processed. Others cover withdrawal of consent where no other legal basis remains, a successful objection or an objection to direct marketing, unlawful processing, a legal obligation to erase, and data collected in relation to an information-society service offered to a child under the relevant consent rules.
The wording matters because the same deletion request can lead to different decisions in different processing contexts. Suppose a person withdraws consent for a marketing list. If the controller has no other legal ground for that processing, the withdrawal can activate the erasure ground. But a request concerning information retained to meet a separate legal obligation cannot be decided by looking only at the person’s preference. The controller must identify which processing is at issue and which legal basis governs it. “Please delete my data” is a clear expression of intent; it is not, by itself, the complete legal classification.
The right also has five exceptions. Processing may continue to the extent it is necessary for freedom of expression and information; for compliance with a legal obligation or a public-interest or official-authority task; for public-health reasons; for archiving in the public interest, scientific or historical research, or statistical purposes under the required safeguards when erasure would make the objective impossible or seriously impair it; or for establishing, exercising, or defending legal claims. These are not a general licence to keep everything. They define circumstances in which the controller may have a reason not to erase all or part of the data, and the reason must fit the processing at issue.
That last point is where an apparently simple right becomes a judgment problem. The European Data Protection Board’s 2025 coordinated action found that more than a dozen supervisory authorities saw uncertainty around the exceptions. Some controllers treated an exception as automatically applicable instead of assessing the request case by case. Others did not document the reasoning behind a refusal. A high rejection rate, on its own, therefore says little: it might reflect a legitimate retention duty, or it might signal an unreliable decision process. The evidence needed to tell those cases apart is the reasoning tied to the particular data and purpose.
The law also allows an intermediate response when the final decision is not yet clear. Article 18 provides a right to restriction in circumstances such as a dispute about accuracy, unlawful processing where the person asks to restrict use instead of erase, or a pending assessment of whether the controller’s legitimate grounds override the data subject’s objection. The EDPB points to restriction as a possible safeguard while an erasure decision is being analysed. This is a different state from both ordinary use and permanent erasure: the data may remain stored, but future processing is limited under the conditions that apply.
The practical sequence is therefore more precise than “request in, deletion out.” A controller must identify the personal data and processing concerned, determine whether an Article 17 ground applies, test any relevant Article 17(3) exception, and decide whether erasure, restriction, or another lawful outcome follows. If technical work takes time after an erasure decision, the delay still needs to be managed against the requirement to erase without undue delay. A system that cannot answer which of these states it is in cannot provide a reliable account of what happened.
A single person’s request can contain several such decisions. Imagine that a service holds a public profile, a marketing preference, and an invoice. The profile may be unnecessary for the service’s current purpose, while the marketing record may depend on consent that has been withdrawn. The invoice, however, may be subject to a separate legal retention obligation. The controller cannot use the invoice as a reason to keep the profile indefinitely, nor can the person’s request make the legal retention duty disappear. The correct result may be different actions for different data categories, with an explanation that makes those boundaries visible.
The same logic applies to an objection or a contested record. If the person disputes the accuracy of information, immediate destruction is not the only possible response; a period of restriction can allow the controller to verify the record. If the processing is unlawful and the person asks for restriction rather than erasure, the data may remain stored but cannot continue to circulate as though nothing were wrong. These alternatives protect the person while preserving the distinction between a temporary limit on use and the final state of erasure.
Exceptions also have to be connected to necessity. A controller cannot simply label an entire database “legal,” “research,” or “public interest” and stop examining the request. The relevant question is whether the particular processing is necessary for the particular exception. A record needed for a legal claim does not automatically justify retaining unrelated account data. Research safeguards do not turn every identifiable copy into an unrestricted archive. A refusal or partial refusal should therefore identify the data and purpose that remain, the exception relied on, and any measures that limit continued use.
This is why the legal outcome is not adequately represented by a green checkmark beside a user account. The checkmark may indicate that a request was received or that one application-level record was removed. It does not tell the data subject whether the controller granted the request in full, granted it for some processing, restricted another part, or refused a part under a documented exception. Nor does it reveal whether the stated purpose and retention period were examined. Those distinctions are not procedural ornament: they determine what the controller must do next and what the person can reasonably understand from the answer.
A decision is incomplete until it is explained and propagated
Article 12 makes the right usable by imposing duties around the decision. Information and communications must be concise, transparent, intelligible, and easily accessible, using clear and plain language. A controller must facilitate the exercise of the rights, provide information on action without undue delay and, in any event, within one month, and explain the reasons for not taking action. The period can be extended by up to two further months when necessary because of the complexity or number of requests, but the person must be told about the extension and the reasons within the first month. The response must also mention the possibility of complaining to a supervisory authority and seeking a judicial remedy when the controller does not act.
These communication deadlines should not be treated as a substitute for Article 17’s separate requirement to erase without undue delay. They do mean that the controller must make and communicate a timely decision about the request, including any extension, rather than leaving the person to infer the outcome from a changed interface. A good response distinguishes a request that was granted from one that was refused under an exception, a request that is still being assessed, and a request for which only a particular system or recipient could be reached. Precision in communication is part of the right’s practical effect.
The information duty begins before a request arrives. Articles 13 and 14 require controllers to explain the purposes and legal bases of processing, the period for which data will be stored or the criteria used to determine it, and the existence of rights including erasure and restriction. They also cover recipients and, where relevant, automated decision-making, including meaningful information about its logic and significance. A person who does not know what is being processed, why it is held, or whom it was shared with is less able to make a specific request or understand a specific answer.
Propagation is a separate part of the legal structure. When a controller has made personal data public and is obliged to erase them, Article 17(2) requires reasonable steps—taking available technology and implementation cost into account—to inform other controllers processing the data about the request to erase links, copies, or replications. Article 19 requires communication of an erasure carried out under Article 17(1) to each recipient to whom the personal data were disclosed, unless that is impossible or involves disproportionate effort. If the data subject asks, the controller must tell them about those recipients.
The two provisions do not say that every imaginable downstream artefact must be located by any means, nor do they automatically answer how a trained model should be treated. They do establish a principle that the legal effect of an erasure action cannot be evaluated solely at the place where the controller first stored the data. Recipients and public copies are part of the factual picture. Whether a model, an embedding, or a derivative system falls within a particular duty requires a fact-specific analysis that the sources here do not resolve.
The controller’s ability to perform that analysis depends partly on its relationship with processors. Under Article 4, a controller determines the purposes and means of processing, while a processor acts on the controller’s behalf. Article 28 requires a processor to assist with data-subject rights through appropriate technical and organisational measures. At the end of the service, the processor must, at the controller’s choice, delete or return personal data and delete existing copies unless Union or Member State law requires storage. The controller is not absolved simply because another organisation operates the system where the processing occurs; the contract and the actual allocation of roles must support the rights process.
Records and design requirements turn these duties into a capability rather than an aspiration. Article 5 includes storage limitation and accountability: personal data should not remain identifiable longer than necessary for the purpose, and the controller must be able to demonstrate compliance with the processing principles. Article 24 requires appropriate measures and review. Article 25 extends protection into the design and default settings of the processing, including the amount of data collected, the extent of access, and the storage period. Article 30 says that a controller’s record of processing activities should include, where possible, envisaged time limits for erasure of different categories of data. These provisions do not prescribe a single software design, but they make ignorance of the processing landscape a poor basis for a confident answer.
The sequence shows why “the controller deleted it” is an incomplete sentence. Which data were identified? Was a ground established? Was an exception tested? Did a processor hold copies? Were recipients informed when required? Was the person told what the controller decided and why? The answers do not always lead to total destruction, but they should lead to a legible, reviewable outcome.
This is also the point at which the legal question meets the title’s concern without becoming the same question. A controller’s responsibility is to make a lawful, timely, and demonstrable decision about personal-data processing. In a conventional system, that may require locating records, coordinating vendors, managing retention, and controlling restoration. In a system that uses machine learning, it may raise an additional technical question about information derived from the data. Article 17 does not supply a universal algorithm for answering that question, and a technical method cannot silently supply the missing legal analysis.
The next difficulty is operational. Even when a controller understands the grounds, exceptions, deadline, and communication duties, the answer can fail if the organisation cannot find the data, distinguish account closure from erasure, control backups, or tell anonymisation from masking. The legal decision becomes meaningful only when the systems implementing it can reach the relevant scope and show what they did.