GDPR Right to Erasure: How to Handle Article 17 Deletion Requests

Short answer: The GDPR right to erasure, set out in Article 17, lets individuals ask a controller to delete their personal data. You must erase it without undue delay when one of six grounds applies and no exception does, answer within one month, tell recipients of the data, and make sure processors and backups follow through.

Related guides:

• GDPR data subject rights explained
• GDPR right of access and DSAR handling
• How to write a data retention policy

Key takeaways

• Erasure is conditional, not absolute. Article 17(1) lists six grounds that trigger the duty, and Article 17(3) lists exceptions that switch it off.
• The clock is one month. You can extend by two further months for complex or numerous requests, but you must tell the person, with reasons, inside the first month.
• Deletion has to travel. Article 19 requires you to tell each recipient of the data about the erasure, unless that is impossible or involves disproportionate effort.
• Backups count. UK ICO guidance says backup copies that cannot be overwritten immediately must be put beyond use until they are.
• Processors assist, controllers decide. A processor's contract must commit it to help with rights requests and to delete or return data at the end of the service.

What is the GDPR right to erasure?

The right to erasure, also called the right to be forgotten, is the individual's right under Article 17 GDPR to have a controller delete their personal data without undue delay when certain conditions are met.

It is one of the eight GDPR data subject rights, with two features that matter for engineering. It is a right to an outcome: the data must be gone, not hidden in the UI. And it is qualified, so a valid request may still be lawfully refused in part when an exception applies. Your process needs a decision step, not just a delete button.

Recent enforcement shows where teams struggle. In its February 2026 report on the 2025 coordinated enforcement action on the right to erasure, the European Data Protection Board said 32 data protection authorities took part and 764 controllers responded. Challenges it named include missing internal procedures, deletion in backups, retention periods, weak anonymisation and assessing exceptions.

When must you erase data, and when can you refuse?

You must erase when at least one of the six Article 17(1) grounds applies, and you may refuse only to the extent that an Article 17(3) exception covers the processing.

Article 17(1): erase when	Article 17(3): erasure does not apply when processing is necessary
(a) The data is no longer necessary for the purposes it was collected or processed for	(a) For exercising the right of freedom of expression and information
(b) The person withdraws consent under Article 6(1)(a) or 9(2)(a) and there is no other legal ground	(b) To comply with a legal obligation under EU or Member State law, or for a task in the public interest or official authority
(c) The person objects under Article 21(1) and there are no overriding legitimate grounds, or objects to direct marketing under Article 21(2)	(c) For reasons of public interest in the area of public health under Article 9(2)(h) and (i) and Article 9(3)
(d) The data has been unlawfully processed	(d) For archiving in the public interest, scientific or historical research or statistical purposes under Article 89(1), where erasure would make those aims impossible or seriously impair them
(e) Erasure is needed to comply with a legal obligation under EU or Member State law	(e) For the establishment, exercise or defence of legal claims
(f) The data was collected in relation to information society services offered to a child under Article 8(1)

Three practical points follow from the table:

1. Check the lawful basis first. Ground (b) only bites when consent was your basis and nothing else supports the processing. If you rely on contract or legal obligation, map that per data category. Our GDPR data mapping guide shows how to record it.
2. Exceptions are usually partial. A HealthTech platform may need to keep clinical records that a law requires it to hold, while still deleting marketing preferences, analytics profiles and support chat history. Erase what is not covered and explain what you kept and why.
3. Health data has its own exception. Article 17(3)(c) covers public health processing under Article 9(2)(h) and (i). Point (h) covers medical diagnosis and the provision or management of health or social care, and Article 9(3) adds that the data is handled by or under the responsibility of a professional bound by professional secrecy. Point (i) covers public health interests such as the quality and safety of health care, medicinal products and medical devices.

When you refuse, Article 12(4) requires you to tell the person, within one month of receiving the request, why you are not acting and that they can complain to a supervisory authority and seek a judicial remedy.

How long do you have, and how do you verify identity?

You must act without undue delay and at the latest within one month of receiving the request, with a possible extension of two further months.

Article 12(3) allows the extension where requests are complex or numerous, and you must tell the person about it, with reasons, within the first month. Under Article 12(5), action is free of charge, and only manifestly unfounded or excessive requests allow a reasonable fee or a refusal, with the burden on you to show that.

Identity checks must be proportionate. Article 12(6) lets you ask for additional information only when you have reasonable doubts about who is asking. The ICO's right to erasure guidance says you should only request information that is necessary to confirm identity, must tell the person without undue delay and within one month that you need it, and do not need to comply until you receive it.

In our experience, the most reliable SaaS pattern is to verify through a channel the person already uses, such as an authenticated in-app request or a confirmation link sent to the account email.

How should engineering handle a deletion request?

Treat erasure as an eight-step workflow with a named owner, a ticket and an audit trail, so every request ends with evidence that deletion happened.

1. Intake. Accept requests from any channel. They need not cite Article 17. Log the received date, because the clock starts there.
2. Verify. Confirm identity proportionately, as described above. Record what you asked for and when you received it.
3. Locate. Search every system using stable identifiers such as user ID and email, starting from your data map.
4. Decide. Test each data category against the six grounds and five exceptions. Record the decision and the legal basis for anything you keep.
5. Delete. Run deletion jobs per system. Hard delete where possible. If you anonymise instead, make sure the result can no longer be linked to the person, because the EDPB report found that basic pseudonymisation or partial masking fell short.
6. Propagate. Instruct processors and notify recipients, as covered in the next section.
7. Confirm. Reply to the person: what you erased, what you kept and why, what happens to backups, and their right to complain.
8. Record. Log the request, decision and completion, without keeping the deleted data.

Who else must you tell about the erasure?

You must notify every recipient to whom the data was disclosed, and instruct your processors to delete, so the erasure reaches every copy you are responsible for.

Three provisions drive propagation:

• Article 19, recipients. The controller must communicate any erasure to each recipient of the data, unless that proves impossible or involves disproportionate effort, and must tell the person who those recipients are if they ask.
• Article 17(2), data made public. If you made the data public, you must take reasonable steps, considering available technology and cost, to inform other controllers processing it that the person has asked for erasure of any links, copies or replications.
• Article 28(3)(e), processors. Your contract with each processor must commit it to assist you, through appropriate technical and organisational measures, in responding to data subject rights requests. In practice, that means an API, admin function or documented support route that deletes a specific person's data.

Keep a propagation list per data category, such as hosting, CRM, support desk, analytics and error tracking, and keep confirmations from each.

What about backups, logs and derived data?

Backups, logs and derived datasets are in scope, but you can handle them differently from live systems as long as the data is put beyond use and you are clear with the person.

Backups. The ICO's guidance says that if a valid request has no applicable exemption, you must erase the data from backup systems as well as live systems. It accepts that live data may be erased immediately while backup copies persist until overwritten, provided the backup data is put "beyond use" and you are clear with individuals about what will happen. The EDPB's 2025 coordinated enforcement report notes that modifying backups may not always be advisable because they protect against incidents such as ransomware. It suggests tracking erasure requests so they can be reapplied when a backup is restored, and recommends that controllers verify erasure and be able to demonstrate it.

A workable backup pattern:

• Keep a suppression list of erased identifiers, holding only what is needed to re-run deletion.
• Make re-applying that list a mandatory step in every restore runbook.
• Set backup retention in your data retention policy so copies age out on a known schedule you can explain.

Logs. Logs often contain emails, IP addresses and user IDs. Set short retention, avoid logging personal data you do not need, and include log stores in the locate step. If you keep security audit logs under an exception, record that decision.

Derived data. Analytics profiles, search indexes, caches, data warehouse tables and machine learning features all derive from source records. Delete or rebuild them, or show the output is anonymous. Under Recital 26, pseudonymised data that could be attributed to a person using additional information is still personal data.

What if you are the processor and the request comes to you?

If you process the data on behalf of a customer, the customer is the controller and decides the request, so your job is to route it promptly and assist as your contract requires.

When an end user of a customer writes to you directly:

1. Do not decide on the controller's behalf. Forward the request to the customer through the channel your data processing agreement specifies, and tell the requester you have passed it on.
2. Assist on instruction. Article 28(3)(e) requires you to help the controller respond. Offer self-service deletion in your product or a documented support process.
3. Handle end of contract. Article 28(3)(g) requires you, at the controller's choice, to delete or return all personal data after the services end and delete existing copies, unless EU or Member State law requires storage. Your offboarding runbook should cover production, replicas, sub-processors and backups.

Where you are a controller for your own data, such as account admins, billing contacts and marketing leads, you handle requests yourself with the workflow above.

How SecureSlate helps

SecureSlate helps privacy and engineering teams run GDPR alongside their other frameworks. Built-in GDPR support with multi-framework control mapping to SOC 2, ISO 27001 and HIPAA links your erasure procedure to related controls, and custom controls add steps such as restore-time re-deletion. Vendor risk management tracks processors and their agreements, agentless read-only cloud integrations show where data stores live, and audit management keeps evidence of completed requests together. Risk management records exception decisions, and the trust center and security questionnaire automation help you explain deletion practices to customers.

FAQ

Is the right to be forgotten the same as the right to erasure?

Yes. Article 17 GDPR is titled "Right to erasure ('right to be forgotten')". Both names refer to the same right and the same grounds and exceptions.

Do we have to delete data from backups immediately?

Not necessarily. ICO guidance accepts backup copies persisting until overwritten if they are put beyond use and you tell the person what will happen.

Can we keep data because we might need it for a dispute?

Only where processing is necessary for legal claims under Article 17(3)(e). Keeping data just in case is not enough. Document the specific claim and keep only the data it needs.

Can we charge a fee for an erasure request?

Normally no. Article 12(5) allows a reasonable fee or a refusal only for manifestly unfounded or excessive requests, and you must be able to show that the request meets that standard.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.