Where Erasure Breaks in the Real World
Once a controller has made the legal decision about an erasure request, the practical subject becomes the organisation’s ability to carry that decision through its systems. This chapter follows that implementation problem: how a controller identifies the scope, assigns the work, handles exceptions and retention, reaches backups and recipients, and demonstrates the result. The point is not to imagine that every system can be rewritten instantly, but to see why an account disappearing or a record being masked is not enough evidence by itself.
The European Data Protection Board’s 2025 coordinated action is a useful case because it examines this gap across real controllers rather than describing an ideal workflow. Its findings also have limits: the authorities used different methods and target groups, and the report is a state of play rather than a final judgment on every participating organisation. Those qualifications matter. The evidence is strongest as a map of recurring failure surfaces, not as a universal compliance score.
The first failure is often knowing what the request reaches
Thirty-two supervisory authorities across the European Economic Area investigated how controllers implemented the right to erasure, and 764 controllers responded. The action included fact-finding, formal investigations, and follow-up work; nine authorities had initiated or continued formal investigations. Most participating authorities assessed compliance among respondents as “average,” with differences associated with organisation size, sector, number of requests, type of data, and number of affected people. The report does not turn those observations into a percentage for all controllers. It does something more useful for diagnosis: it shows that a right can be widely recognised while its execution remains uneven.
The most basic operational question is deceptively difficult: where is the personal data covered by this request? The EDPB says that seventeen authorities found controllers without a documented or current internal procedure. Some controllers did not use their records of processing activities to support the assessment. Others had difficulty identifying the relevant data or locating every place to search. One reported pattern was to treat email data as automatically out of scope; another was to exclude backups by default without a justification. These are not merely filing mistakes. If the scope is wrong at the beginning, a technically flawless deletion applied to that scope still produces an incomplete result.
A procedure supplies the handoffs that memory and goodwill cannot. Someone must recognise that an incoming message is an exercise of a data-subject right, route it to the responsible people, identify the processing purpose and legal basis, and decide which systems and processors hold relevant data. Staff need enough training to recognise the request and apply the procedure consistently. The controller also needs a record of what was assessed and what action followed. The EDPB reports that some organisations used software that automatically generated deletion records and tracked indicators such as the proportion of requests answered within the relevant time. Such records do not prove that every copy was removed, but they make the organisation’s decision and its remaining questions inspectable.
The distinction between account closure and erasure exposes the difference between interface state and system state. Closing an account may disable login, remove a profile page, or stop a service from displaying a person’s information. It may not remove the personal data retained for billing, fraud prevention, customer support, legal claims, analytics, or vendor operations. Whether those records should also be erased depends on the processing purpose, the applicable ground, and any exception or retention duty. The EDPB specifically warns that treating account or application deletion as compliance with an erasure request can undermine the right’s effectiveness.
Transparency is part of this first stage. The EDPB found that some controllers did not clearly explain the existence, scope, conditions, or process for exercising the right. Articles 13 and 14 require information about purposes, legal bases, retention periods or the criteria used to determine them, and the existence of the right to erasure. If a person cannot tell what a controller does with their data or whom to contact, they may submit a vague request and receive an equally vague answer. Clear information is not a substitute for system mapping, but it makes both the request and the eventual decision more intelligible.
The action’s recurring issues form a connected chain rather than seven independent checklist items. Missing procedures make training harder; weak training makes it less likely that a request will be recognised and routed; poor mapping makes deletion incomplete; unclear retention rules make exceptions inconsistent; and weak records make the final answer difficult to defend. The operational failure is therefore often upstream of the deletion command. The command can be correct for the wrong scope.
A worked example shows how the chain develops. A person may send a request to a general support address because that is the contact point they can find. If the support worker does not recognise the message as an exercise of a data-subject right, the request can sit in an ordinary queue or be forwarded to the wrong team. If it is recognised but the controller has no current map, the employee may search the customer database and miss an email archive, a service desk, a payment processor, or an older application. If the account interface reports success after the customer table is changed, the person has received a signal of completion before the organisation has determined whether other processing purposes justify retaining particular data.
The opposite failure is possible as well: an organisation may find a large amount of data but treat the whole collection as one undifferentiated object. That can encourage blanket deletion where a legal obligation requires a limited record to be retained, or blanket retention where only a narrow category is necessary. A purpose-based map is more informative than a list of system names because it connects a data category to why it is processed, who receives it, how long it is needed, and what action the decision permits. The EDPB’s recommendation to map personal data and storage locations is therefore a control on both omission and overreach.
The numbers in the coordinated action should be read in that context. The participation of 32 authorities and 764 responding controllers demonstrates the breadth of the exercise, while the different national strategies and response conditions limit direct comparisons. Some authorities contacted hundreds or thousands of controllers for fact-finding; others examined a smaller group or formal investigations. The report also notes that compliance varied with factors such as organisation size, sector, request volume, data type, and the number of affected people. A large organisation may receive more requests and have a more formal process, yet also have more systems and recipients to coordinate. A small organisation may have fewer layers but no documented procedure. “Average” is consequently a signal that implementation needs attention, not a score that predicts the result of an individual request.
The most reliable process makes its uncertainty visible. If the team has not established whether an old system or processor holds a copy, the record should not imply that the search was complete. If an exception is being assessed, the person should not be left to infer that silence means refusal. If the backup policy means a request will be honoured on restoration rather than through immediate mutation, that policy and its safeguards should be part of the explanation. The EDPB’s examples of deletion records and timing indicators matter because they support this visibility, even though neither one substitutes for a scope-aware verification.
Persistence does not end when the live record changes
After scope has been established, the next problem is that different data locations have different transition rules. A live database may support a targeted delete. A historical system may be difficult to edit. A recipient may have its own processing environment. A backup may be preserved as an intact recovery unit. A data set that has been masked may still be linkable if the additional information needed for attribution remains available. “Erase” describes the legal outcome sought; it does not make every storage layer behave identically.
Retention is one source of legitimate difference. The GDPR’s storage-limitation principle says that personal data should remain identifiable no longer than necessary for the purposes of processing, while Article 17 recognises legal obligations and other exceptions that can limit erasure. The EDPB reports that some controllers used the longest retention period applicable to one activity as a default for all activities, or applied a regulated-sector period without checking whether it fit each processing purpose. A better retention schedule connects the data category to the purpose, legal basis, and period. A deletion matrix can make those relationships explicit, but it is useful only if it reflects the actual systems and is kept current.
This is also why a refusal must not be treated as the end of responsibility. If an exception under Article 17(3) allows processing to continue, the controller still has duties under the other data-protection principles. The EDPB notes that minimisation, storage limitation, integrity, and confidentiality should continue to shape the retained data. Where the final decision is uncertain, restriction can limit future use while the controller verifies accuracy or balances competing grounds. Where a lawful erasure has been decided but technical work needs time, the EDPB mentions anonymisation as a possible safeguard in some circumstances. That is not permission to replace deletion with a convenient mask; the legal and technical requirements still have to be met.
Backups make restoration the decisive transition. The EDPB describes backups as important for protecting integrity after incidents such as ransomware and cautions that changing or deleting parts of a backup may not always be advisable. A controller may therefore keep a backup intact for a period, provided there is an appropriate way to track the erasure request and honour it if that backup is restored. Other reported practices included automatic overwrite, scheduled backup deletion, manual handling, replacing personal data with random characters, or extracting a subject’s data to a separate system inaccessible to employees before later deletion or anonymisation.
None of these approaches is a universal answer. Automatic overwrite may fit a defined retention schedule but fail to address a restore that happens earlier. Manual handling may provide human oversight but require more effort and create inconsistency. Editing an intact backup may undermine its recovery purpose. A long, incremental deletion procedure can also make it difficult to determine whether the action occurred without undue delay. The EDPB therefore recommends secure, structured erasure and the ability to verify and demonstrate it, rather than naming one mandatory backup architecture.
The lifecycle has branches because erasure is not always a single destructive transition. A request may end in a documented exception or temporary restriction. If erasure is granted, the controller may need separate actions for live systems, recipients, and backup restoration. The final state is not “the button was pressed”; it is an outcome that has been checked against the scope and recorded with its qualifications.
Anonymisation creates a related but distinct boundary. The EDPB found that controllers sometimes relied on anonymisation to retain data for analytical or statistical purposes, yet several authorities saw uncertainty about what legally and technically counts as anonymisation. Basic pseudonymisation or partial masking may leave a route to an identifiable person. Under the GDPR definition, pseudonymised data can no longer be attributed to a specific data subject without additional information, but that additional information is precisely why pseudonymisation is not the same as making the data anonymous. A string of random characters, a removed name, or an inaccessible table may reduce exposure without proving that identification is no longer reasonably possible.
The requirement to verify is what joins these cases. Verification should ask whether the action covered the intended data and locations, whether an exception or retention period was documented, whether recipients and copies were handled where required, and whether a restoration path can bring the data back into use. It should also preserve the difference between evidence of an action and evidence of an outcome. A deletion log can show that a command ran. It does not, without a relationship to the data map and the surrounding systems, show that the command reached every relevant copy.
That distinction sets up the technical problem. Ordinary records are already difficult because they can be copied, retained, restored, or masked. A learned model adds a form of derived state that is not normally visible as a copy of the original row. The EDPB report does not decide how such state should be treated, and this chapter cannot turn its backup findings into a rule about model checkpoints. But its operational lesson carries forward: before claiming completion, identify the scope, the paths that persist, the transition that was actually performed, and the evidence that supports the final state.