Agnes with a checklist and an eraser, focused expression, documents with items being ticked off

Right to Erasure: The 7 Mistakes Most Companies Still Make

GDPR, Compliance

In February 2026, the European Data Protection Board (EDPB) published the results of its Coordinated Enforcement Framework on the right to erasure. 32 national supervisory authorities reviewed hundreds of organisations together. The conclusion was no shock, but it was sobering: nearly everyone makes the same mistakes.

Not exotic mistakes. No legal hair-splitting. Basic things that have been in the regulation since 2018.

For SMBs this matters because supervisory authorities across the EU have signalled that enforcement will step up in the second half of 2026. The number of erasure-related fines doubled last year. Right now is the moment to put your own procedure under the microscope.

The seven mistakes below come straight from the EDPB report. For each one you get a short explanation of what goes wrong and what to do about it. At the end of the article there is a self-assessment you can run through in ten minutes.

Mistake 1: No internal procedure for handling requests

The most common problem. Reception gets an email, forwards it to someone who is on holiday, and that is where it stops. Nobody knows who owns this kind of request, so everybody assumes someone else is on it.

The GDPR requires you to handle requests within one month. That month starts ticking the moment the request arrives, not when the right person finally sees it.

Fix this now: assign one owner (often the DPO or the privacy lead), set up one central email address (privacy@), and make sure reception, sales and support know where requests need to go. Put the procedure on a single page. No more.

Mistake 2: Pseudonymising and calling it anonymisation

This one is technical. Many companies "delete" by replacing the name with an ID. Or by hashing email addresses. That is not anonymisation. It is pseudonymisation, and the GDPR still applies in full.

True anonymisation means the data can no longer be traced back to a person, not by you, not via other sources you have access to. If you keep a hash table that lets you reverse the mapping, you are not done.

Fix this now: decide per dataset whether you genuinely anonymise or simply delete. For analytics, aggregation is often enough. For customer data, deletion is usually the only option that holds up legally. Read more on how to handle data subject rights in practice.

Mistake 3: Forgetting the backups

The biggest blind spot in almost every organisation. You delete properly from the CRM, the marketing platform, the billing system. Meanwhile the data still lives in six nightly backups on an external drive.

The EDPB is strict on this: personal data in backups also falls within scope of the request. But there is practical room. You may wait until the backup is overwritten in normal rotation, as long as you do not restore that data for production use.

Fix this now: document your backup rotation. Add erasure requests to a do-not-restore list. Agree with your IT provider how long the oldest backup is kept. Without this policy, you cannot demonstrate compliance during an audit.

Mistake 4: Inconsistent application across departments

Sales removes the customer from the CRM. Marketing keeps them in the newsletter database because that is a different system. Finance retains the invoices for the statutory seven years (correctly), but never tells the customer.

Result: the customer thinks they were deleted, gets a newsletter three weeks later, files a complaint with the supervisory authority. Fine.

Fix this now: make a deletion checklist with every system that may hold personal data. Including Slack, Notion, shared drives, old Excel files on the network share. Walk through the entire list for every request. Tedious, but essential.

Mistake 5: No confirmation to the requester

Deleting is not enough. The GDPR also requires you to actively confirm that it happened. Many companies delete properly but never send a reply. The requester hears nothing, assumes nothing has happened, and files a complaint.

The EDPB report found that in 41% of reviewed requests, no confirmation had been sent. That is a direct breach of article 12 GDPR.

Fix this now: add the confirmation email as a mandatory final step in your procedure. Keep it short: "On [date] we received your request. On [date] we deleted your data from [systems]. We are retaining the following on the basis of [legal obligation]: [list]." Done.

Mistake 6: No documented exceptions

Sometimes you may refuse to delete. A statutory retention period, ongoing litigation, a legal claim. Fine. But you have to be able to explain which exception applies to which data.

"We keep this because we have to" is not an acceptable answer. You must name the legal basis, state the retention period, and make clear what does get deleted once that period ends.

Fix this now: link your erasure procedure to your processing register. For every type of data, the register should state the legal basis for retention and the duration. Then you can refer straight to the register when a request comes in.

Mistake 7: No timeline tracking

One month. That is the deadline. Who keeps track of when the request came in, when identity was verified, when the confirmation went out? At most SMBs: nobody does, systematically.

Result: a request sits for three weeks, almost misses the deadline, gets handled in panic on day 28. Or worse: it does miss the deadline and nobody notices until the complaint arrives.

Fix this now: a simple register is enough. Date received, date identity verified, date deleted, date confirmed. Excel is fine, a compliance tool is better. But you must be able to demonstrate it.

Self-assessment: ten minutes, honest answers

Run through this checklist. One "no" is a warning. Two or more means you need to start work today.

  • [ ] One person is ultimately responsible for handling erasure requests
  • [ ] There is a central email address or form where requests arrive
  • [ ] Reception, sales and support know where to send a request
  • [ ] We understand the difference between anonymisation and pseudonymisation, and act on it
  • [ ] We have a policy for handling personal data in backups
  • [ ] We have a complete list of every system that may hold personal data
  • [ ] We send a written confirmation for every completed request
  • [ ] Our exceptions are linked to a legal basis in the processing register
  • [ ] We log the date received, date completed and date confirmed for every request
  • [ ] We keep the file for each request for at least three years

What to do next

If the checklist showed gaps in your procedure: good. That is true for most SMBs. The difference between a fine and a clean outcome is not whether you are perfect today, but whether you start acting today.

During an audit, supervisory authorities mostly look at two things: whether you know what you are doing, and whether you can prove you do it. A documented procedure plus a file of handled requests is enough, in about 90% of cases, to close an investigation with a warning instead of a fine.

With ComplianceHive GDPR software you handle erasure requests from arrival to confirmation in one tool. Procedure, logging, evidence: all in one place. Try it free for two weeks and get your data subject rights in order before enforcement steps up.

Frequently asked questions

How long can you delay responding to an erasure request?

You have one month from the moment the request arrives. For complex requests you may extend this by two months, but you must inform the requester in writing within that first month that you are extending and why. Saying nothing counts as a violation, even if you later delete the data properly.

Do I need to delete data from backups too?

Yes, but you do not have to tear apart your entire backup system immediately. Most supervisory authorities accept that personal data may remain in backups until the backup is overwritten in normal rotation, provided you do not restore that data for active use. Document the policy and add the data to a do-not-restore list, so it cannot accidentally end up back in production.

When can I refuse an erasure request?

When you have a statutory retention obligation (such as tax records, typically seven years), when there is ongoing litigation, or when the data is needed for the performance of a current contract. You may also refuse if the request is manifestly unfounded or excessive. In all cases you must explain the refusal in writing within one month.

How do I document handling an erasure request?

At minimum: date received, how you verified identity, which systems you searched, what you deleted or anonymised, what you retained and on what legal basis, and the date you confirmed completion to the requester. Keep this file for at least three years. During an audit, this is the first thing the supervisory authority asks for.

This article is general information and not legal advice. For specific situations, consult a specialised privacy lawyer or your national supervisory authority.

Start gaining control over your vendors and software today

Let ComplianceHive help you with ISO 27001, GDPR, vendor management, and more. No hassle, no spreadsheets, just clarity. Start now with a free 1-month trial. No credit card required, no hidden fees. Discover the Busy Hive plan and manage up to 25 tools and vendors in one overview.

Try 1 month for free