Updated: 4 June 2026 by Jetico Technical Support
SUMMARY: The EDPB's February 2026 coordinated enforcement report on the Right to Erasure found 7 recurring compliance gaps across 764 controllers, from undocumented procedures to backup erasure confusion. Most organizations don't fail because they're unfamiliar with Article 17. Instead, they fail because erasure is operationally fragmented across teams, systems and procedures. This blog breaks down each problem area, explains the technical gaps the report doesn't fully address and outlines how tools like BCWipe and BCWipe Search can help organizations close the gap between policy and practice.
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). The EDPB CEF 2025 Right to Erasure action turned to how controllers handle Article 17 in practice.
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 EDPB described the report’s purpose as understanding “how controllers comply with the right to erasure in practice“. Not testing whether organizations know the right exists, but whether they can act on it.
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. For example, one controller did not 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.
| Method | Is Data Still Recoverable? | Does It Satisfy GDPR Erasure? |
| Standard OS deletion (e.g., Shift+Delete) | Yes: recoverable with basic tools | No |
| Pseudonymization / masking | Yes: reversible with the key or reference data | No |
| Anonymization (if properly implemented) | No: but execution often falls short | Yes: if re-identification is truly impossible |
| Secure erasure (overwriting / wiping) | No: data is irrecoverable | Yes |
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 EDPB recommends that controllers “verify that erasure has been carried out” and be able to demonstrate it, but doesn’t address how. 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:
- Receive and recognize: Identify the incoming request as an erasure request
- Assess legality: Determine whether the request is valid and if exceptions apply
- Route internally: Notify the responsible people within the organization
- Inventory the data: Where does the data subject’s personal data live? Tools like BCWipe Search can scan endpoints, archives and compressed files to establish scope
- Verify against systems: Is that inventory accurate?
- Erase with verification: Remove data beyond recovery using overwrite-based secure erasure (such as BCWipe)
- Generate documentation: Produce a Certificate of Erasure for compliance records and the data subject
- Confirm back: Communicate the result to the requester
The report’s 7 findings map on to different stops in this chain:
| Finding | Where It Breaks the Chain |
| No documented procedure | Steps 1-3: receiving, assessing and routing requests |
| Inadequate staff training | Steps 1-2: recognizing requests and knowing what to do |
| Insufficient information to data subjects | Before step 1: data subjects don’t exercise the right |
| Exceptions applied as blanket refusals | Step 2: legal assessment skipped or done incorrectly |
| Inconsistent retention periods | Step 2: can’t determine if erasure grounds apply |
| No backup erasure process | Steps 4-6: data persists in systems outside the workflow |
| Anonymization mistaken for erasure | Step 6: the method used doesn’t erase data |
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)
The European Data Protection Board’s February 2026 Coordinated Enforcement Framework report identified 7 recurring compliance gaps across 764 controllers in 32 EEA supervisory authorities. The most common failures were undocumented erasure procedures, inadequate staff training, inconsistent data retention periods, undefined approaches to backup erasure and the use of pseudonymization or masking that doesn’t satisfy GDPR’s erasure obligation under Article 17. Nine supervisory authorities launched formal investigations; 23 ran fact-finding exercises.
GDPR erasure under Article 17 is an operational problem, not a knowledge problem. Receiving a request, assessing its validity, locating all in-scope data across endpoints and storage systems, removing it beyond recovery and documenting the outcome — each step involves different teams and tools. Any one of them can break the chain. The EDPB’s 2026 coordinated enforcement findings show that most controllers haven’t connected the legal process to the technical workflow. Jetico’s BCWipe Search and BCWipe address the two steps organizations most consistently fail at: finding all personal data before erasure begins and generating a Certificate of Erasure as documented proof afterward.
No. Standard operating system deletion — including Shift+Delete on Windows — removes a file from view but leaves the underlying data on the drive, where it’s fully recoverable with basic forensic tools. GDPR’s Article 17 requires that personal data be removed beyond recovery. Overwrite-based secure erasure tools, such as Jetico’s BCWipe, meet this requirement by writing over the data and generating a Certificate of Erasure as documented proof that the process was completed.
The EDPB’s 2026 Right to Erasure report identified backup erasure as the area with the widest variation in practice — half the supervisory authorities raised concerns. A workable approach: record the date of each GDPR erasure request and flag any backup created before that date. If a flagged backup is restored, erasure is applied immediately to the restored system. Where a backup isn’t restored, managed retention cycles will eventually replace it with a version that no longer contains the erased data. Organizations that already maintain immutable backups are closer to compliance than they might think. For the discovery step — identifying which backups contain the relevant personal data — Jetico’s BCWipe Search can scan across endpoints, archives and compressed files to establish what’s actually in scope before erasure begins.
Pseudonymization replaces identifying information with a reference key, but the process is reversible — the original data can be reconstructed. It does not satisfy GDPR’s Article 17 erasure obligation. True anonymization, where re-identification is genuinely impossible, can count as erasure, but the EDPB’s 2026 enforcement report found that many controllers apply only basic masking and treat it as compliant when it isn’t. Secure erasure — overwriting data so it cannot be recovered — is the reliable method. Jetico’s BCWipe uses recognized wiping standards and produces a Certificate of Erasure to document that the process was completed correctly.