What the EDPB’s Right-to-Erasure Report Reveals About Where Organizations Still Struggle

_{Updated: 4 June 2026 by Jetico Technical Support}

SUMMARY: The EDPB's February 2026 coordinated enforcement report examined how 764 controllers across 32 supervisory authorities handle the Right to Erasure in practice. The findings show that most organizations don't fail because they're unfamiliar with Article 17. Instead, they fail because the operational side of erasure is fragmented across teams, systems and procedures. This blog breaks down the 7 recurring problem areas the report identified, then explains the gap between standard deletion and verified data removal and outlines what organizations can do to build a more reliable erasure workflow using BCWipe and Search.

Most organizations that operate in the European Economic Area (EEA) have heard of GDPR’s Article 17. The Right to Erasure isn’t new or obscure. So why are supervisory authorities still finding the same problems? 

In February 2026, the European Data Protection Board (EDPB) published the results of its Coordinated Enforcement Framework (CEF) that focused on how controllers handle erasure in practice.

The pattern is consistent: procedures are unclear, retention policies are inconsistent, backups complicate deletion and teams struggle to decide when erasure applies. 

In this blog, you can find out what the EDPB’s Coordinated Enforcement Framework involved, where the 7 recurring problem areas sit, what the report doesn’t address about the technical side of erasure, and what organizations can do to close the gap between policy and practice.

What Did the EDPB Do?

The CEF is an annual initiative where supervisory authorities across the EEA investigate a shared topic. In 2024, the focus was the GDPR’s Right of Access (Article 15). In 2025, they turned to erasure. 

Key facts about the report:  

• 32 supervisory authorities participated 
• 9 launched formal investigations; 23 ran fact-finding exercises 
• 764 controllers surveyed, from micro-enterprises to large companies 
• Sectors covered: public administration, healthcare, finance, retail, education and more 
• All used a common questionnaire, though each authority chose its own targets

The EDPB was clear about the purpose of the report: to understand how controllers comply with the right to erasure in practice, identify good practices and understand the most important challenges for further guidance.  

The 7 Problems: Where Does It Break Down? 

The report identified 7 recurring problems. None of them are about whether organizations have heard of Article 17. Instead, they all relate to what happens when someone actually has to carry out an erasure request. 

#1. Do Organizations Have a Documented Erasure Process? 

Often, no. 17 supervisory authorities flagged this. Without a documented procedure, requests get handled subjectively. The report found controllers:

• Making inconsistent decisions on the same type of request depending on which staff member handled it 
• Not referencing their records of processing activities (ROPA) when assessing which data falls in scope 
• Confusing closing a user account with fulfilling an erasure request 

#2. Can Staff Recognize an Erasure Request When It Arrives? 

Many can’t. General annual training doesn’t prepare staff to identify an erasure request in unfamiliar wording, or to know what to do with it. The result: missed deadlines, requests forwarded to the wrong person and legal exceptions identified too late. 

#3. Are Data Subjects Told Enough About the Right? 

13 supervisory authorities said no. Some controllers mention the Right to Erasure in their privacy notice but don’t explain how to exercise it, what conditions apply or what happens after a request is submitted. The EDPB’s next coordinated enforcement action, launched in March 2026, focuses on transparency obligations. That’s not a coincidence.  

#4. Are Exceptions Being Applied Correctly? 

Some controllers treated Article 17(3) exceptions as automatically applicable rather than assessing each case individually. High rejection rates suggested that many organizations relied too much on exemptions without documented reasoning. 

#5. Do Retention Periods Hold up Under Scrutiny? 

Not always. One controller applied the longest retention period from one processing activity to all of its activities. Another applied a default period across the board without assessing each processing purpose. If a controller hasn’t defined when data stops being necessary, it can’t assess whether the core grounds for erasure under Article 17(1)(a) apply. 

#6. What Happens When Erasure Meets Backups? 

Half the supervisory authorities raised concerns. Some controllers have no specific procedures, while others wait for automatic overwrites and treat that as compliance. Others rely on general retention periods that vary widely. 

I’ve seen organizations use backups as a reason not to set up proper erasure at all. They treat it as an unsolvable problem, when in reality the approach is more straightforward than it appears. The EDPB has called for more guidance on what “without undue delay” means in this context. 

#7. Does Anonymization Count as Erasure? 

Only when done properly. Several supervisory authorities found controllers using basic pseudonymization or partial masking and treating it as erasure. These techniques don’t prevent re-identification. True anonymization puts data outside the scope of GDPR, but many controllers believe they’ve achieved it when they’ve only pseudonymized. 

What Doesn’t the Report Cover?

The report focuses on procedural and legal compliance. But underneath several of the 7 issues is a technical problem, which is organizations can’t erase what they can’t find. 

Some controllers couldn’t identify all personal data within the scope of an erasure request. Some excluded entire categories by default, such as emails. One controller didn’t consider personal data in emails to be in scope at all. 

When we talk about data protection, the conversation tends to focus on what I’d call the finality of the action: the erasure, the encryption and the access control. But before any of that can happen, someone needs to know where the data is. Controllers who can’t locate all the data in scope aren’t necessarily failing at erasure. Instead, they’re failing at discovery. 

This also explains why organizations reach for familiar but inadequate methods. Pseudonymization is already in the toolkit for other GDPR processes. Standard OS deletion makes data disappear from view. Both create the same illusion: you can’t see the data, so you assume it’s gone. 

GDPR itself doesn’t help. The regulation uses “erasure” and “deletion” almost interchangeably, making it harder to understand that standard deletion doesn’t meet the requirement. 

The report also says little about verification. The accountability principle under GDPR (Articles 5(2) and 24) requires organizations to demonstrate compliance. For erasure, that means showing an auditor that data was located, removed beyond recovery and documented. 

What Should Organizations Do Next?

The EDPB found the same structural gaps here that it found in the 2024 right-of-access report, including no documented process, unclear data mapping and insufficient documentation. That repetition suggests legal guidance alone won’t fix these problems. 

Here’s the full chain of what has to happen when an erasure request arrives: 

1. Receive and recognize: Identify the incoming request as an erasure request
2. Assess legality: Determine whether the request is valid and if exceptions apply
3. Route internally: Notify the responsible people within the organization
4. Inventory the data: Where does the data subject’s personal data live?
5. Verify against systems: Is that inventory accurate?
6. Erase with verification: Erase data using a method that prevents recovery
7. Generate documentation: Produce a report for compliance records and the data subject
8. Confirm back: Communicate the result to the requester

The report’s 7 findings map on to different stops in this chain: 

The chain has many moving parts spread across different teams and systems, meaning fragmentation is the default. Fixing one part doesn’t fix the whole thing. 

For backup erasure, which is the area with the widest variation, the approach is simpler than most organizations assume. Organizations can record the date of each erasure and flag any backup created before that date. If a flagged backup is ever used for restoration, erasure is applied immediately. Otherwise, managed retention cycles replace older backups over time. Organizations that already maintain good backup hygiene, including immutable backups, are closer to compliance than they might think. 

The common thread across all 7 findings points to 3 foundational capabilities: 

• Discovery: Identifying where personal data lives across endpoints and storage systems 
• Verified erasure: Erasing data using methods that prevent recovery 
• Audit-ready documentation: Generating evidence that proves erasure happened 

For a step-by-step walkthrough that puts these capabilities into practice, see our complete guide to handling GDPR Right to Erasure requests.

How Can BCWipe & Search Help with Erasure? 

BCWipe Search scans endpoints to locate sensitive and hidden data, including inside archives, compressed files and backup locations. It identifies duplicate files using hash functionality. When an erasure request arrives, BCWipe Search provides the visibility needed to determine what’s in scope. 

BCWipe permanently erases data using recognized wiping standards and generates Certificates of Erasure. These certificates document what was erased, how it was performed and whether the process was successful. 

Together, they cover the sequence the report shows organizations consistently failing at: find the data, erase it beyond recovery and prove it happened. 

To get started, contact our Data Protection Specialist to learn more or request a free trial of BCWipe. 

Frequently Asked Questions (FAQs)