What regulators actually check when you say 'we deleted it'
The EDPB's 2026 report on right-to-erasure enforcement surveyed 764 controllers across 32 DPAs and found most can't prove erasure happened. What auditors check.
By Gabriel Lara, Developer Relations, Norbelys
Founder-reviewed ·How we research and correct articles
On February 18, 2026, the European Data Protection Board published its report on the 2025 Coordinated Enforcement Action on the right to erasure — the fourth in its coordinated-enforcement series, and the first to focus on Article 17 specifically. Thirty-two data protection authorities across the EEA reviewed how 764 controllers, from SMEs to multinationals, actually handle erasure requests in practice. Nine DPAs opened or continued formal investigations as a direct result, with proceedings still running in Ireland, France, Portugal, Slovenia, and Germany. The report is worth reading closely for one reason: it’s the clearest public evidence yet of what “prove you erased it” means to a regulator, as distinct from “did you erase it.”
This post isn’t about the legal definition of the right to erasure — that’s covered in the erasure decision guide — or about the mechanics of an erasure API call, covered in the erase-vs-delete breakdown. It’s about what an auditor actually pulls on when they check whether a company’s erasure claims hold up.
Finding #1: most controllers have no documented procedure at all
The headline finding wasn’t a technical failure, it was a process one: a substantial share of surveyed controllers had no specific, written procedure for handling an erasure request — just ad hoc handling by whoever picked up the ticket. A regulator checking compliance doesn’t start by testing whether a specific record vanished from a database. It starts by asking to see the procedure: who receives the request, how the relevant record is located, who confirms the deletion, and how that confirmation is retained. “We deleted it when someone asked” without a repeatable, documented process behind it isn’t verifiable — from the outside, it’s indistinguishable from “we deleted it this one time, maybe, and got lucky.”
Finding #2: anonymization gets used as a substitute for deletion — and it usually isn’t
The report specifically flagged the use of “ineffective anonymisation techniques” as a stand-in for actual erasure. This is a subtle failure mode: a controller believes it has satisfied a request by stripping obvious identifiers from a record, while enough residual detail remains — a device ID, a precise timestamp combined with a small population, a still-linkable customer number — to re-identify the person with modest effort. Anonymization is a real, legitimate way to retain aggregate value from data without retaining personal data, but it’s a technical bar with a specific meaning, not a synonym for “we changed the name field.” Regulators checking this now ask controllers to demonstrate why their anonymization is irreversible, not just assert that it is.
Finding #3: backups are where erasure claims quietly fall apart
This is the finding most relevant to anyone running production systems. Roughly half of the responding DPAs raised specific concerns about erasure in backup contexts — many controllers had no procedure for it at all, and some had no process to prevent previously erased data from being silently restored the next time a backup got reinstated. A company can execute a clean, correct deletion in its live database and still fail an erasure audit, because the same record is sitting untouched in a six-month-old backup with no mechanism stopping it from resurfacing.
What “proof” actually requires
Put together, the report describes what a defensible erasure claim needs, as distinct from the legal question of whether erasure was owed in the first place:
- A written, repeatable procedure, not case-by-case improvisation.
- A defined retention period the request can be checked against — “we don’t really have a policy on how long we keep things” is itself a finding, separate from any specific erasure failure.
- A real technical standard for what counts as anonymized, not a rename.
- An explicit answer for backups — either they’re purged too, or there’s a documented control preventing restored backups from reintroducing erased data.
- A timestamped, retained record that the request was received and actioned — the audit trail, not just the outcome.
None of that is new as a concept. What’s new is that a body representing every major EU regulator just published, in specific and citable terms, that most controllers surveyed don’t have it.
The practical takeaway
If your own erasure handling — anywhere you hold personal data, not just cold outreach — amounts to “someone asks, someone deletes the row,” the EDPB’s own sample suggests you’re in the majority, and also in the group most exposed if a DPA ever asks you to demonstrate the process rather than just the result. The fix isn’t more urgency on individual requests. It’s turning “we can delete this” into “we can show, on demand, exactly when this was erased, under what request, and that it can’t quietly come back.” That’s a different bar than most teams are currently building toward, and per this report, it’s the one regulators are actually checking.
Where Norbelys draws that line explicitly
The EDPB’s three findings map almost one-to-one onto why Norbelys keeps erasure
separate from ordinary deletion instead of treating them as the same button.
DELETE /v1/people/:id archives a contact and stays reversible
— useful for routine list cleanup, but it isn’t erasure and was never meant to
answer an Article 17 request. A separate people:erase action destroys the
PII, is logged with a timestamp as the audited compliance event it is, and adds
a hash of the address to the suppression list so the same person can’t be
silently re-imported and contacted again from a stale CSV or CRM sync later —
the same “erased data quietly comes back” failure mode Finding #3 flags for
backups, addressed here at the re-import path rather than assumed away.
Documented, distinguishable, and repeatable is exactly the standard this
report says most controllers still lack; it’s also just how the erase action
is built to work by default, not a compliance process layered on top of it.
Right-to-erasure enforcement — common questions
Does this CEF report apply outside the EU?
The report itself is EEA-specific, but the underlying gaps it identifies — no documented procedure, weak anonymization, unhandled backups, no audit trail — are the same ones any regulator anywhere is likely to probe, since they're about operational rigor rather than a specific legal text.
Is 'we deleted the row' enough to satisfy an erasure audit?
Based on the EDPB's findings, no. Auditors are checking for a documented procedure, a retained record of when and how the request was actioned, and confirmation the data isn't sitting untouched in a backup — not just the current state of the live database.
What's the single most common gap the report found?
Lack of a specific, written internal procedure for handling erasure requests — many controllers handled them ad hoc rather than through a repeatable, auditable process.
How is this different from just knowing the legal definition of the right to erasure?
The legal right defines what has to happen. This report is about what a regulator actually inspects to verify it happened — procedure, retention policy, anonymization standard, backup handling, and audit trail — which is a distinct, more operational question.