EDPB study on the right to erasure: why article 17 GDPR often becomes a practical challenge

A Well-Known Right – and the EDPB’s Current Stocktaking

A recent coordinated enforcement action by the European Data Protection Board (EDPB) on the right to erasure shows how organizations are actually implementing Article 17 GDPR in practice. To this end, 32 data protection supervisory authorities across Europe examined in 2025 how controllers implement Article 17 GDPR in practice. The report consolidates the findings from 764 responses submitted by organizations of different sizes and from various sectors.

This is precisely what makes the assessment so interesting: it does not show in abstract terms how the right to erasure functions doctrinally, but where companies and public authorities actually fail in practice. The key finding is clear: the problem usually does not lie in a lack of awareness, but in implementation. Many organizations have addressed the topic, but still operate with incomplete procedures, unclear responsibilities, or technically difficult system landscapes.

This is delicate because the right to erasure is far more than simply “removing data.” Controllers must assess whether there is a valid right to erasure in the first place, which data is affected, whether exceptions apply, which systems need to be included, and how the decision is to be documented in a traceable manner.

When a right to erasure exists and when it does not

Article 17 GDPR does not grant a blanket right to immediate deletion. A right to erasure exists only where there is a statutory ground for deletion – for example, because the data is no longer necessary for the original purpose, consent has been withdrawn, a valid objection applies, the processing was unlawful, or a legal obligation to erase the data exists.

The other side is just as important: the right to erasure is not absolute. In individual cases, erasure may be excluded, for example because of statutory retention obligations or because the data is still needed for the establishment, exercise, or defense of legal claims.

In practice, this means that controllers must assess not only whether data must be erased, but also why, to what extent, and whether there are exceptional reasons why immediate erasure may not be required. In addition, the requirements of Article 12 GDPR apply, particularly with regard to deadlines, communication, and the obligation to provide reasons.

Where organizations most frequently fail in practice

The enforcement action reveals recurring patterns. Not every issue is new – but many organizations still have not resolved them properly.

1. Unclear processes and responsibilities

The most common weakness lies in the procedure itself. Where there are no clear internal workflows, erasure requests are handled differently depending on the department or the person responsible. Sometimes a request is forwarded immediately, sometimes it remains pending for too long, and sometimes it is answered incompletely.

This is risky for a sensitive data subject right. Anyone who wants to handle erasure requests in a legally compliant manner needs a practical day-to-day process with clearly defined roles across the business function, data protection, IT, and, where applicable, Legal or Compliance.

2. Organizations often do not have a complete overview of their data holdings

Many problems do not begin with the legal assessment, but already with identifying the relevant data. In complex organizations, personal data is rarely stored in just one place. It can be found in specialist systems, emails, archives, user accounts, logs, or backup systems.

If an organization does not have a proper understanding of this data landscape, it can hardly fulfill erasure requests consistently. This is precisely why a robust data inventory and a well-maintained record of processing activities are so valuable in practice.

3. Retention periods are often handled too broadly

Another perennial issue is retention periods. In practice, there is often no sufficiently differentiated approach based on which data is processed for which purpose and how long it may or must actually be stored.

Instead, organizations often use blanket retention periods – or, as a precaution, apply the longest conceivable period. This may be convenient internally, but it is risky from a data protection perspective. After all, the obligation to erase depends directly on whether the data is still necessary or whether legal obligations require further storage.

4. Backups remain a particularly sensitive area

Backups are important for the integrity and recoverability of systems. For that very reason, they cannot always be modified easily. However, this does not relieve controllers of their obligation to take erasure requests seriously in this context as well.

The issue becomes particularly problematic where backup data is excluded across the board. What is needed instead are traceable rules: How are erasure requests documented? What happens in the event of a restore? And how is it ensured that data is not processed for longer than necessary?

5. Account deletion does not automatically mean data deletion

Especially in the context of digital services, platforms, and apps, one point is often underestimated: a deleted or deactivated account does not necessarily mean that all personal data has actually been erased.

If logs, communication data, backups, or other datasets continue to exist in the background, the right to erasure is not automatically fulfilled. In other words, the visible user interface says nothing definitive about what is actually happening within the system.

What good erasure practice looks like

The good news is that the enforcement action does not only highlight deficits, but also shows what matters in practice. Particularly important are:

• clear responsibilities for intake, assessment, and technical implementation,

• understandable processes for employees,

• a robust overview of data holdings and storage locations,

• differentiated retention and deletion concepts,

• traceable rules for backups,

• transparent communication with data subjects.

Care is especially crucial where a request is refused. Anyone relying on an exception should carefully assess the individual case, document the decision, and explain it in a way that is understandable. In difficult cases, it may also be sensible to temporarily restrict processing rather than erase data prematurely or reject the request as a matter of course.

What companies should review now in concrete terms

Anyone who wants to put this topic on a sound footing should ask in particular:

• Is there a documented process for erasure requests?

• Are roles and responsibilities clearly defined?

• Is it known in which systems the relevant data is stored?

• Are retention periods defined in a traceable and differentiated way?

• Is there a robust approach for backups and restore scenarios?

Even this short check often shows whether the right to erasure is truly under control within the organization – or whether it still depends largely on the individual case and the commitment of specific people.

Conclusion

The main problem with the right to erasure is usually not the legal text itself, but its implementation within the organization. Weaknesses are particularly evident in processes, data visibility, retention periods, and backups.

The most important takeaway is therefore this: anyone who wants to comply with Article 17 GDPR in a legally sound manner needs not only legal expertise, but also robust procedures, clear responsibilities, and technically viable deletion concepts.

The practical recommendation is clear: companies should review their deletion processes now, not in isolation, but together with data protection, IT, the relevant business functions, and, where applicable, Legal or Compliance. That is precisely where it will be decided whether the right to erasure works in practice