GDPR erasure requests: delete across purposes, retain only what the law requires
A practical GDPR guide to deciding what to erase, what to retain under a narrow exception, how to propagate the decision across systems and recipients, and what evidence makes the response defensible.
A former customer asks for deletion. The customer record sits in the live account system, but the same person also appears in support tickets, invoices, analytics exports, a vendor platform, and backups.
The practical question is larger than whether the main profile has a delete button. A defensible response must answer four questions for each processing activity:
- Does an Article 17 ground require erasure?
- Does an Article 17(3) exception require some data to remain?
- Which systems, processors, recipients, and public copies need an action?
- What evidence shows that the organisation made and carried out the right decision?
Article 17 creates a conditional erasure duty
Article 17(1) gives a data subject the right to obtain erasure of personal data without undue delay. It also places an obligation on the controller to erase the data when one of six grounds applies. The grounds cover data that is no longer necessary for its original purpose, withdrawn consent with no other legal basis, a successful objection, unlawful processing, a legal obligation to erase, and certain information-society services offered to a child. 1
Article 17(3) preserves processing that is necessary for freedom of expression and information, a legal obligation or public task, public health, specified archiving, research or statistics, and the establishment, exercise or defence of legal claims. The exception applies only to processing necessary for the protected purpose. The remaining data stays subject to the Article 17 analysis. 1
The response also has a time boundary. The controller must tell the requester what action it has taken without undue delay and within one month of receiving the request. A further two months may be available when the request is complex or numerous, but the controller must explain the extension within the first month. When the controller declines to act, the controller must give the reasons and explain the right to complain to a supervisory authority and seek a judicial remedy. 1
That combination produces a useful working rule: erasure is a purpose-level decision, followed by a system-level execution plan.
Start with the processing purpose before the first database
A request usually arrives through one channel. The personal data usually lives in several places.
Take a customer-support operation. The organisation may hold a profile for account administration, a ticket history for service delivery, an invoice for tax or accounting obligations, a fraud-monitoring record for security, and a metrics export for product analysis. A processor may hold a support copy. A backup may contain an older version. Each location can require a different answer because the purpose, legal basis, recipient, and retention need differ.
Use this decision screen before anyone reports that the request is complete:
- Record the request and identify the person proportionately. An erasure request can arrive verbally or in writing. Staff should recognise it even when the requester uses ordinary language rather than the words "right to erasure" or "Article 17", record when it arrived, and confirm its scope where the wording is unclear. Identity checks should be necessary and proportionate to the data held. The ICO's operational guidance is UK GDPR guidance, but these handling points illustrate the type of intake control a controller needs; EU GDPR teams should apply the relevant EU supervisory authority's guidance. 2
- List each purpose and legal basis. Write "account administration," "customer support," "billing," and "security monitoring" as separate processing activities when they have different reasons for holding the data. "The customer record" is too broad to support a precise decision.
- Map the locations and flows. Search live applications, filing systems, exports, reports, collaboration spaces, processors, subprocessors, and public pages. The map should identify the owner of each location and the route for sending an instruction or confirmation.
- Test an Article 17 ground for each activity. Ask whether the data is still necessary for the stated purpose, whether consent was withdrawn, whether an objection succeeds, whether the processing was unlawful, or whether a legal obligation requires erasure.
- Test a specific exception. If data must remain, name the Article 17(3) purpose and the exact fields or records it covers. A general statement such as "legal reasons" leaves the decision too wide to review.
- Choose the action for each location. The action may be erasure, rectification, restriction, retention under a specific exception, or a request for clarification. The action should include an owner, a completion date, and evidence.
The purpose split prevents a common error. A billing record may need a limited retention period because a legal obligation applies, while a product-marketing profile has no matching retention reason after a person withdraws consent. The controller can retain the billing record for its necessary purpose and erase the marketing profile. The two outcomes belong in one response, and each outcome needs its own branch rather than one "keep" or "delete" label.
The EDPB's coordinated enforcement report published on 18 February 2026 identifies inconsistent internal procedures, difficulties defining retention periods, difficulties deleting from backups, inefficient anonymisation used instead of erasure, and insufficient information given to individuals. The report records findings from coordinated work involving 764 controllers and recommends procedures for receiving, assessing, implementing, and documenting erasure requests. 3
Separate erasure from restriction and rectification
Three requests can sound similar while producing different controls.
| The person needs | The relevant control | What the team must decide |
|---|---|---|
| Removal of personal data because an Article 17 ground applies | Erasure under Article 17 | Which data must be deleted, which exception applies to any retained data, and which recipients need an update? 1 |
| A pause while a dispute is resolved or a legal-claim record is preserved | Restriction under Article 18 | Which processing must stop, what limited processing remains permitted, and when can the restriction be lifted? 1 |
| Correction of inaccurate or incomplete information | Rectification under Article 16 | Which fields are wrong, what is the corrected value, and which recipients need the correction? 1 |
Restriction can be the right response when the person contests accuracy, opposes unlawful processing and chooses restriction over erasure, needs the data for legal claims after the controller's operational need has ended, or objects while the controller tests its overriding grounds. Restricted data should remain separated from ordinary operational use and should be released only for the purposes the law permits. 1
The decision record should therefore state why a record was erased, restricted, rectified, or retained. A team that records only "request denied" loses the distinction that makes the response legally and operationally reviewable.
The hard part is propagating the decision
Erasure remains incomplete when the controller removes a record from the primary application and an operational copy remains with a processor or recipient.
Article 19 requires the controller to communicate a rectification, erasure, or restriction to each recipient to whom the personal data was disclosed, unless communication is impossible or involves disproportionate effort. If the data subject asks, the controller must also provide information about those recipients. 1
When the controller made the personal data public, Article 17(2) adds a separate reasonable-steps duty. The controller must take account of available technology and implementation cost while informing other controllers that the person has requested erasure of links, copies, or replications. 1
A useful handoff record contains more detail than a message saying "please delete." For every processor or recipient, record:
- the processing activity and data fields concerned;
- the Article 17 ground or exception;
- the required action and deadline;
- the secure channel used for the instruction;
- the recipient's confirmation or explanation of any residual copy; and
- the evidence that the controller reviewed the response.
The ICO guidance describes "recipient" broadly and advises contacting recipients unless doing so is impossible or would involve disproportionate effort. It also says that the individual should be told clearly what will happen to data in backup systems. This is UK GDPR guidance, so the applicable EU authority and local law remain the governing reference for EU GDPR work. 2
A controller can delegate an execution task and still needs a complete view of the decision and its propagation. A processor's "done" message confirms one handoff; the controller also needs evidence that every relevant processing activity has been resolved.
Backups and anonymisation need an implementation test
Backups create a different question from active-system deletion: what happens when an old copy has to remain until the backup cycle replaces it?
The ICO says that a valid request with no applicable exemption requires steps to erase data from live and backup systems. Where backup data awaits scheduled overwrite, the organisation should put it "beyond use": reserve it for backup recovery, exclude it from every other purpose, and keep it only until the established backup schedule replaces it. The organisation should explain this handling to the requester. 2
The EDPB's 2026 report confirms that backup deletion is a recurring implementation difficulty. The report recommends that controllers address backup systems in their erasure procedures and leaves the technical timing to the controller's backup architecture. 3
A workable backup control should answer four separate questions:
- Has the data been removed from active systems and ordinary operational copies?
- How will the team stop a backup from returning to ordinary use until the same erasure decision is applied?
- When will the backup expire or be overwritten under the established schedule?
- If a restoration occurs before expiry, will the erasure workflow run again before the restored data is used?
The same implementation discipline applies to anonymisation. Anonymisation can be an appropriate outcome where a dataset is genuinely anonymous for the relevant assessment. An inefficient transformation that leaves the person identifiable remains personal data and fails as a substitute for erasure. The EDPB specifically identifies reliance on inefficient anonymisation instead of deletion as a problem found in its coordinated action. 3
Common shortcuts that fail
| Shortcut | Unresolved question | Repair |
|---|---|---|
| Delete the main customer profile and close the ticket | Where do support, billing, analytics, vendor, export, and backup copies sit? | Search by processing purpose and location, then record an action for every relevant copy. |
| Treat Article 17 as an automatic wipe of the entire file | Which processing is necessary for an Article 17(3) exception? | Name the exact exception, retain only what it requires, and keep the retained material separated and access-controlled. 1 |
| Call pseudonymisation or a weak masking step deletion | Can the person still be identified using the organisation's data or reasonably available information? | If the person remains identifiable, treat the result as personal data and apply the erasure decision. |
| Assume the processor will discover every copy | Did the controller send a purpose-scoped instruction, and did the processor identify subprocessors or residual backups? | Use a defined handoff, confirmation fields, escalation route, and evidence review. |
| Say "legal reasons" and retain the whole record | Which law, purpose, fields, and period make retention necessary? | Record the exact Article 17(3) branch and limit access and scope to that necessity. |
| Miss the deadline while waiting for perfect search results | Can the controller explain action, an extension, or a refusal within one month? | Start the clock at receipt, communicate within one month, and use the permitted extension only with a timely explanation. 1 |
| Send a bare refusal | Can the person understand what happened and how to challenge the decision? | Explain the reasons and the right to complain and seek a judicial remedy. 1 |
The reviewer record
A reviewer should be able to reconstruct the response from one record. Keep these fields:
- Request: date, channel, requester, proportionate identity check, wording, and scope.
- Purpose map: each processing purpose, legal basis, data category, system, owner, processor, subprocessor, and recipient.
- Legal branch: Article 17(1) ground for erasure, Article 17(3) exception for retained data, or the reason another right such as restriction or rectification applies.
- Execution: action taken in each live system, export, processor environment, public location, and backup path.
- Propagation: recipients contacted, instructions sent, confirmations received, and any reason communication was impossible or disproportionate.
- Communication: response date, outcome, retained data, backup treatment, extension explanation if used, and complaint or judicial-remedy information when the controller declined to act.
- Evidence: deletion logs, system confirmations, access-control changes, backup policy reference, approval owner, and follow-up trigger.
The record must cover every personal-data breach under Article 33(5) in the breach context; the erasure workflow has a different legal anchor, but the same accountability principle is useful here: the organisation should preserve the facts, action, and reasoning that explain the outcome. Article 12 requires the controller to communicate the result or refusal within the defined period, while Article 19 and Article 17(2) extend the work to recipients and other controllers where the data has moved. 1
The practical test is simple to state and demanding to execute: can the record show what the person asked for, where the data was found, which legal branch applied to each purpose, what was erased or retained, who received an instruction, how backups are handled, and when the person received the answer?
If the answer is yes, the organisation has turned a deletion request into a controlled decision. A record that says only "the profile was deleted" stops at the first database.
References
- 1Regulation (EU) 2016/679 (GDPR), Articles 12 and 17
data.europa.eu
- 2Right to erasure | ICO
ico.org.uk
- 3
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.