GDPR Right to Erasure: How to Handle Deletion Requests (and When You Can Refuse)

Most deletion requests are straightforward. Someone closes an account, asks you to remove their data, and you do. The complexity arrives when the data can’t be deleted, or legally shouldn’t be.

The GDPR right to erasure, enshrined in Article 17, is one of the regulation’s most misunderstood provisions. Controllers routinely either over-comply (deleting data they were entitled to keep) or under-comply (citing exemptions that don’t actually apply to their situation). Both errors carry risk: one operational, one regulatory.

What makes this right genuinely difficult is the layered judgment it demands. Erasure isn’t a binary yes or no. It depends on the legal basis you relied on to process the data in the first place, the nature of the request, and whether any of six specific exemptions apply — each with its own conditions.

This article works through each of those layers, including the exemptions controllers most commonly misapply.

What GDPR Article 17 Actually Says

The GDPR right to erasure is frequently described as the “right to be forgotten” — a phrase that has done more to confuse compliance teams than clarify them. The label implies a broad, unconditional entitlement. Article 17 creates something considerably more specific.

The provision establishes a right to request deletion, not an automatic right to receive it. Whether that request must be honoured depends entirely on which of six grounds the individual is invoking, and whether any countervailing exemption applies.

The six grounds for erasure under Article 17(1)

Article 17(1)(a-f) sets out the conditions under which a data subject may request erasure:

Ground	Summary
Article 17(1)(a)	The data is no longer necessary for the purpose for which it was collected
Article 17(1)(b)	The individual withdraws the consent on which processing was based, and no other legal basis applies
Article 17(1)(c)	The individual objects under Article 21(1) and the controller has no overriding legitimate grounds, or objects under Article 21(2) to direct marketing
Article 17(1)(d)	The data has been processed unlawfully
Article 17(1)(e)	Erasure is required to comply with a legal obligation under EU or member state law
Article 17(1)(f)	The data was collected in connection with information society services offered to a child under Article 8

Each ground is independent. A request citing one does not automatically succeed because another might theoretically apply. Controllers should identify precisely which ground the individual is relying on, because the appropriate response, and the relevant exemptions, differ accordingly.

The context Recital 65 provides

Recital 65 explains what the legislature was actually trying to solve: the internet’s tendency to retain data indefinitely, well beyond any purpose that justified its original collection. The right to erasure was designed as a corrective to that structural problem, not as a general power of deletion.

A request under Article 17(1)(a) is strongest when data has genuinely outlived its purpose. The controller’s first question should be whether the data still serves the function for which it was collected. If the honest answer is no, then deletion should happen without undue delay, and only the exemptions in Article 17(3) become the only defensible basis for refusal.

What “without undue delay” means in practice

Controllers sometimes treat this phrase as giving them meaningful discretion over timing. The regulation in Article 12(3), however, removes that ambiguity. The operative deadline is one calendar month from receipt of the request.

That month runs from the date of receipt, not from the date the controller decides the request is valid. Organisations that only start the clock after an internal triage process routinely miss the deadline without realising it.

For complex cases, or where a large volume of requests arrives simultaneously, the law permits a two-month extension. The controller must notify the individual within the first month that an extension is being taken, explain why, and confirm the revised deadline. That notification is itself subject to the one-month window.

The EDPB’s Guidelines 01/2022 on data subject rights requests also address how controllers should handle requests that are unclear, incomplete, or submitted through unofficial channels. The guidance confirms that controllers cannot routinely demand identity verification beyond what is reasonably necessary, and that directing individuals to a formal request form does not pause the clock while they comply.

The misreading that causes most compliance failures

The persistent assumption that the right to erasure is absolute leads controllers in two directions:

• Some delete data they were entitled, or required, to keep;

• Others refuse requests by citing exemptions that don’t apply to their actual situation.

Both errors stem from treating Article 17 as either a blanket obligation or a blanket discretion, when it is neither. The provision creates a conditional right, triggered by specific grounds, subject to specific exemptions.

Lawful Grounds to Refuse an Erasure Request

Refusing an erasure request is legally defensible only when a specific exemption under Article 17(3) applies. Controllers that refuse requests by citing vague operational needs, general business interests, or the possibility of future utility are not invoking an exemption — they’re simply declining to comply.

The regulation sets out grounds on which a controller may legitimately decline or limit erasure. Four of them account for the vast majority of real-world refusals.

1. When a Legal Obligation Requires Retention

Article 17(3)(b) is the most commonly invoked exemption, and the most reliably defensible when applied correctly. It permits refusal where processing is necessary for compliance with a legal obligation under EU or Member State law.

The obligation must be specific and identifiable:

• Tax and financial records: HMRC requires retention of business records for six years from the end of the relevant accounting period. Most EU member states impose comparable obligations — Germany’s Handelsgesetzbuch mandates ten years for commercial correspondence and accounting documents.
• Employment records: payroll data, contracts, and statutory sick pay records are subject to retention requirements under national employment law, typically ranging from three to six years post-employment depending on jurisdiction.
• Financial transaction logs: firms regulated under MiFID II must retain records of orders and transactions for five years; certain categories extend to seven years.
• Clinical records: NHS guidelines recommend retention for a minimum of eight years after the last treatment episode for adult patients; longer for children’s records.

What controllers cannot do is point to a general category of legal risk and call it a legal obligation. Reasons such as retention for possible future audits simply don’t cut it under the law. A specific statutory provision requiring retention of specific data for a specific period is.

2. When Freedom of Expression or Information Is at Stake

Article 17(3)(a) exempts processing that is necessary for exercising the right of freedom of expression and information. In practice, this exemption is most relevant to news publishers, digital archives, and public interest journalists.

The legal tension here is real and unresolved. The GDPR explicitly acknowledges in Recital 153 that the right to data protection must be balanced against freedom of expression, and that member states have discretion to provide exemptions for journalistic, academic, and literary purposes. That discretion has produced significant variation across the EU.

A newspaper maintaining an archive of accurately reported historical court cases can generally invoke this exemption against an erasure request from a convicted individual who has since served their sentence. The calculation shifts if the coverage was inaccurate, disproportionate, or no longer serves a genuine public interest. Several live cases across EU member states are currently testing precisely where that line sits.

For most commercial organisations, this exemption will not apply. Its relevance is genuinely confined to publishers, broadcasters, and organisations whose core function involves communicating information to the public.

3. When Public Interest or Research Justifies Retention

Articles 17(3)(c) and (d) permit refusal where processing is necessary for the performance of a public interest task, or for scientific, historical, or statistical research purposes, subject to the conditions in Article 89(1).

Article 89(1) of the regulation imposes a substantive requirement. Controllers relying on these exemptions must implement appropriate technical and organisational safeguards, including pseudonymisation where the research purpose can be achieved without direct identification.

The practical scope here covers universities conducting longitudinal health studies, government bodies maintaining population registers, and public health researchers working with patient data. Germany has developed relatively detailed national frameworks for research exemptions under Article 9(2)(j); the UK post-Brexit position relies on the UK GDPR alongside the DPA 2018’s Schedule 2 exemptions, which follow a broadly similar structure but are interpreted independently by the ICO.

Controllers in this space should document not only that a research purpose exists, but that erasure would genuinely impair it. A vague claim of ongoing analysis is insufficient.

4. When Legal Claims Are Active or Anticipated

In Article 17(3)(e), the regulation permits retention where processing is necessary for the establishment, exercise, or defence of legal claims. This exemption is frequently overlooked by SMEs, partly because it requires a degree of forward-looking legal judgment that smaller organisations rarely apply systematically.

The exemption applies in three scenarios:

1. Active litigation: a claim has been filed, and data may be required as evidence.
2. Reasonably anticipated litigation: circumstances exist that make legal proceedings objectively foreseeable, even if no claim has yet been issued.
3. Regulatory investigations: proceedings before a supervisory authority or regulatory body that may require documentary evidence.

The practical implication for data governance is significant. Automated deletion workflows — including those triggered by account closure, retention period expiry, or a data subject’s erasure request — should be pausable via a legal hold mechanism. Deleting data that a legal team has identified as potentially relevant to anticipated proceedings can constitute spoliation, with serious consequences in litigation.

Controllers should establish a clear internal protocol for placing data under legal hold, including a mechanism for the legal or compliance function to notify data governance teams before automated deletion runs.

A Note on Member State Variation

The exemptions in Article 17(3) operate within a framework that member states have implemented unevenly. Germany’s Bundesdatenschutzgesetz (BDSG) includes specific provisions for research and archival purposes that go beyond the baseline GDPR text. France’s CNIL has published guidance that interprets the legal obligation exemption narrowly, requiring controllers to identify the specific legal source. The ICO’s post-Brexit guidance broadly aligns with the EDPB’s approach but is interpreted under UK law.

Controllers operating across multiple jurisdictions cannot assume that an exemption valid in one member state applies identically in another. Where refusal decisions have cross-border implications, legal advice specific to the relevant jurisdiction is warranted.

The One-Month Clock: Building a Request-Handling Workflow

While the legal framework for erasure requests is well-documented, the operational reality is harder. Organisations that understand Article 17 in principle still miss deadlines, overlook processors, and fail to notify third parties. They don’t do this out of ignorance, but from the absence of a workflow that converts legal obligations into consistent process steps.

The following framework follows the sequence a request actually travels through an organisation, from receipt to documented resolution.

Step 1: Day Zero — What Counts as Receipt

The one-month clock starts when the request is received, not when it’s been reviewed, validated, or assigned to a compliance officer. Controllers should treat any communication that constitutes a recognisable erasure request as triggering the clock, regardless of the channel through which it arrives: a support ticket, an email to a general inbox, a social media message, or a written letter all count.

Identity verification is permitted under Article 12(6) where there is reasonable doubt about the requester’s identity, but it must be proportionate. Controllers cannot demand a copy of a passport as a matter of routine. The bar is whether additional information is necessary to confirm identity, not whether it would be convenient. Requesting unnecessary verification information, or using the verification step to slow the process, is a compliance failure in its own right.

If a request is ambiguous, the law in Article 12(3) permits asking for clarification — but that exchange does not pause the clock. The one-month period continues running.

Step 2: Triage

Once a request is logged, the first substantive question is whether it’s clearly covered by one of the six Article 17(1) grounds, and if so, whether an Article 17(3) exemption obviously applies.

A triage decision should address three questions:

1. Which ground is the individual invoking? If the request doesn’t specify, identify the most plausible ground based on the relationship with the individual and the nature of the data involved.
2. Is there an applicable exemption? Legal obligation, legal claims, and public interest are the most commonly relevant. If an exemption applies, document it now.
3. Is this a partial erasure situation? Some data may be subject to erasure while other categories are retained under a valid exemption. Partial compliance is a legitimate outcome, provided each decision is reasoned and recorded separately.

Requests that span multiple systems, jurisdictions, or data categories should be flagged at triage as complex, triggering the option to extend the response period by two months under Article 12(3). The extension notice must still be sent within the first month.

Step 3: Scope Mapping

Identifying what must be deleted requires a complete picture of where the individual’s data lives. For most organisations, that means looking beyond the primary CRM:

• Operational systems: CRM, HR platform, billing system, customer service tools.
• Marketing and analytics: email marketing platforms, web analytics tools, retargeting lists, advertising platform audiences.
• Communications: email archives, chat logs, recorded calls.
• Backups: scheduled backups often retain deleted records for weeks or months. Controllers need a documented approach to backup erasure, which may involve flagging the data for deletion on the next backup cycle rather than immediate removal.
• Third-party processors: any vendor processing data on the controller’s behalf.

The backup question deserves specific attention. The ICO acknowledges that immediate deletion from backup systems is not always technically feasible, and accepts that data flagged for deletion from live systems, and deleted at the next scheduled backup purge, satisfies the obligation in most cases. Controllers should document this approach explicitly in their retention and erasure policies.

Step 4: The Processor Obligation

Article 28(3)(e) requires that data processing agreements include a provision obligating processors to assist controllers in responding to data subject requests. In practice, this means that when a controller needs to action an erasure across a vendor’s system, the contractual mechanism to require that deletion should already exist.

Controllers that haven’t audited their DPAs for this provision face a structural problem: they may be legally obligated to erase data they cannot compel a processor to delete. That gap is a compliance risk and a potential enforcement issue in its own right.

Practically, the processor notification and deletion process should be initiated as early in the workflow as possible, since vendor response times can be unpredictable and the obligation to complete erasure runs on the controller’s timeline, not the processor’s.

Step 5: The Article 19 Notification Obligation

Article 19 is one of the more consistently overlooked obligations in the erasure process. It requires that where a controller has disclosed personal data to third parties, and subsequently receives a valid erasure request, the controller must notify each recipient of the erasure.

The obligation applies to disclosures, not just processor relationships. If a controller has shared an individual’s data with a partner organisation, a data broker, or another controller under a joint processing arrangement, that recipient must be informed.

Article 19 includes a proportionality qualifier: notification is required unless it proves impossible or involves disproportionate effort. Controllers should not treat this as a general escape hatch. The ICO’s accountability guidance indicates that “difficult” does not equate to “disproportionate,” and that maintaining records of disclosures is itself part of the accountability obligation that makes compliance with Article 19 feasible.

Step 6: Documenting the Decision

Under Article 5(2), controllers must be able to demonstrate compliance with the GDPR’s principles. For erasure requests, this means the decision — whether to comply, refuse, or partially comply — must be recorded with reasoning.

Documentation should capture:

• The date the request was received and the identity of the requester.
• The ground(s) invoked under Article 17(1).
• Any exemption relied upon, with the specific Article 17(3) basis identified.
• The systems searched and the outcome in each.
• Any processors notified and their responses.
• Any third parties notified under Article 19.
• The date and content of the response sent to the individual.

This record serves two functions. First, it demonstrates accountability to a supervisory authority in the event of a complaint or investigation. Second, it creates an internal audit trail that allows compliance teams to identify patterns — including systemic gaps in scope mapping or processor compliance that may need to be addressed at a policy level.

The ICO’s accountability framework is explicit that documented decision-making is a compliance output in itself. A well-handled erasure request with complete records is a stronger position than a deletion that happened but left no trail.

When You Partially Comply: The Overlooked Middle Ground

Most guidance on erasure requests treats the outcome as binary: you either delete or you refuse. The more accurate picture is that partial compliance is frequently the correct response, and handling it well requires more precision than a straightforward deletion.

The scenario arises constantly. A customer closes their account and requests erasure. The marketing profile, preference data, and browsing history have no legitimate basis for retention once the relationship ends. The transaction records, however, may be subject to a statutory retention obligation. Deleting one and retaining the other becomes the legally correct outcome, provided each decision is grounded in a specific justification.

Separating Data by Legal Basis

The key to handling partial erasure coherently is treating different categories of data independently, according to the legal basis on which each was originally processed.

An e-commerce business receiving an erasure request from a former customer might reasonably:

• Delete: behavioural analytics data, marketing segmentation profiles, email preference records, abandoned basket data, and any other data whose sole purpose was enabling personalised marketing.
• Retain: order history, invoices, and payment records required under tax law for the applicable statutory period (typically six years under UK law, with comparable obligations across EU member states).
• Pseudonymise: aggregated purchase data used for demand forecasting or statistical analysis, where the research purpose can be achieved without individual identification.

Each of these decisions requires its own documented rationale. A single erasure request may generate three separate compliance outcomes across different data categories.

Pseudonymisation as a Legitimate Alternative

In research and statistical contexts, Article 89(1) permits pseudonymisation as an alternative to outright deletion where erasure would seriously impair the research purpose. The condition is that the purpose can genuinely be achieved without identifying the individual.

The pseudonymisation must be real, meaning the re-identification key is held separately with strict access controls, and the pseudonymised dataset is genuinely de-linked from the individual for all operational purposes. Controllers who pseudonymise in name only while retaining easy re-identification capability are not complying with either the spirit or the letter of Article 89.

For qualifying research organisations, pseudonymisation offers a meaningful middle path. It preserves the analytical value of longitudinal datasets while honouring the data subject’s request to the extent the research purpose allows.

Suppression Lists: Deleting the Data, Retaining the Signal

For email marketing, outright deletion creates a specific operational problem: without a record that an individual has unsubscribed, there’s nothing to prevent their data from being re-collected and re-added to a mailing list at a later date.

The ICO explicitly recognises suppression as a legitimate alternative to erasure in this context. Rather than deleting all records of the individual, the controller retains a minimal suppression entry — typically a hashed email address or identifier — whose sole function is to prevent future contact. No marketing processing occurs; the entry exists only to enforce the individual’s objection.

This approach is well-established in email marketing compliance and aligns with both the GDPR’s purpose limitation principle and the practical reality of permission-based marketing. The suppression list should contain only the minimum information necessary to enforce the opt-out, and it should be clearly segregated from active marketing data.

Communicating Partial Compliance Clearly

Partial compliance generates an obligation that’s easy to underestimate: the individual must be told, in plain terms, what was deleted, what was retained, and why.

A response that simply confirms “we have processed your request” is inadequate if some data has been retained. The law requires a substantive response, and where the controller is not acting in full, it must inform the data subject of the reasons without undue delay and within the one-month window.

The communication should:

• Confirm which categories of data have been deleted.
• Identify which categories have been retained.
• Cite the specific legal basis for each retention decision, in plain language.
• Inform the individual of their right to lodge a complaint with the relevant supervisory authority if they are dissatisfied with the outcome.

Vague responses to partial erasure decisions are a common source of supervisory authority complaints. A clear, specific explanation — even one the individual disagrees with — is substantially less likely to escalate than one that leaves them uncertain about what action was taken.

Responding to a Refusal: What You Must Tell the Data Subject

A refusal is not the end of the process. Under Article 12(4), when a controller decides not to act on an erasure request, they must inform the individual without undue delay and within one month of receipt. That communication is itself a compliance obligation, with specific content requirements that many organisations fail to meet.

The most common failure is not refusing — it’s refusing badly.

What the Response Must Contain

The GDPR sets out three non-negotiable elements for any refusal communication:

1. The reasons for not taking action. Not a category or a label, but a substantive explanation of why the specific exemption applies to this specific individual’s data.
2. The right to lodge a complaint with a supervisory authority. This must be signposted explicitly, including the relevant authority for the individual’s jurisdiction.
3. The right to seek a judicial remedy. Individuals may pursue their rights through the courts independently of any supervisory authority complaint, and they must be told this.

Omitting any of these elements is a standalone compliance failure, regardless of whether the underlying refusal was legally sound. Controllers have faced regulatory scrutiny not because their refusal was wrong in substance, but because the communication left out required information.

What “Explaining the Reasons” Actually Means

Article 12(1) requires that communications with data subjects be concise, transparent, intelligible, and in plain language. That requirement applies to refusal responses as much as to privacy notices.

A response stating “we are retaining your data pursuant to our legal obligations under applicable law” does not meet the standard. The individual is entitled to know which legal obligation, which data it applies to, and for how long retention is required. A legally adequate explanation might read: “We are required to retain your transaction records for six years from the date of the transaction under HMRC’s record-keeping requirements. We have deleted your marketing profile and preference data, which were not subject to this obligation.”

The specificity required is meaningful but not burdensome. Controllers should be able to explain their retention rationale in two or three plain sentences. If they cannot, that difficulty is usually a signal that the underlying exemption analysis needs strengthening.

Responding in dense legal language is a documented compliance risk. The enforcement decisions and published guidance have consistently emphasised that responses that are technically accurate but practically incomprehensible fail the transparency standard. One of the most direct routes to a supervisory authority complaint is leaving an individual unable to understand what was done with their data or why.

Signposting the Complaint Route Is Not Optional

Several published ICO enforcement cases have cited the failure to clearly inform data subjects of their right to complain as an aggravating factor in overall GDPR non-compliance assessments. The right to complain to a supervisory authority and the right to an effective judicial remedy are fundamental rights under Articles 77 and 79 of the GDPR. Treating them as optional additions to a refusal letter is a misreading of the regulation.

In practice, the signposting should name the relevant supervisory authority and, ideally, include a direct link to its complaints process. For UK-based controllers, that means the ICO. For EU-based controllers, it means the lead supervisory authority under the one-stop-shop mechanism, where applicable, though individuals also retain the right to complain to the authority in their own member state.

Elements a Refusal Response Should Include

Without prescribing template language, a compliant refusal response addresses the following:

• Acknowledgement that the request has been received and considered.
• Identification of which data the decision applies to (particularly important in partial refusal scenarios).
• The specific exemption being relied upon, identified by its legal basis rather than a general description.
• A plain-language explanation of why that exemption applies in this case.
• Confirmation of any data that has been deleted, where partial compliance has occurred.
• The individual’s right to complain to the relevant supervisory authority, with the authority named and a reference to where they can do so.
• The individual’s right to seek judicial remedy.
• Contact details for a point of escalation within the organisation, such as the DPO where one is appointed.

The tone matters as much as the content. A refusal that is accurate, specific, and respectfully worded substantially reduces the likelihood of escalation to a supervisory authority. Individuals who feel their request was properly considered and clearly explained are meaningfully less likely to complain than those who receive a form letter that leaves them uncertain whether anyone read their request at all.

Enforcement Patterns: What Regulators Are Actually Penalising

In 2025, all 32 data protection authorities across the European Economic Area spent the entire year scrutinising how organisations handle deletion requests, and the findings, published by the EDPB in February 2026, were not encouraging.

The right to erasure is one of the most frequently exercised data subject rights and has given rise to many complaints across the EEA and a growing number of decisions from supervisory authorities. That volume of complaint activity is precisely why the EDPB selected Article 17 as the focus for its 2025 Coordinated Enforcement Framework (CEF) action — the fourth such initiative since the framework launched in 2020.

What the EDPB’s 2025 Investigation Found

The findings were drawn from responses by 764 controllers, spanning SMEs to multinational corporations across industries and the public sector. Nine DPAs launched formal enforcement investigations. Twenty-three conducted fact-finding exercises.

The overall level of compliance of the responding controllers was assessed as “average.” The EDPB identified seven recurring issues across participating jurisdictions:

• Absence of a documented internal procedure for handling erasure requests
• Inadequate or absent staff training
• Insufficient information provided to data subjects about their rights
• Misuse of, or legal uncertainty about, the exceptions used to deny requests
• Difficulties defining and implementing data retention periods
• Inability to delete personal data from backup systems
• Reliance on ineffective anonymisation techniques as a substitute for deletion

The main findings include the lack of adequate internal procedures for handling erasure requests, the use of ineffective anonymisation techniques as a substitute for deletion, the absence of clearly defined data retention periods, and technical limitations preventing erasure in backup systems. Controllers often failed to properly balance the right to erasure against other fundamental rights where required.

The backup and anonymisation findings are particularly significant. Both represent cases where organisations believed they were complying while, in the assessment of supervisory authorities, they were not.

The Compounding Effect: Erasure Failures Rarely Arrive Alone

The Spanish DPA has issued more fines than any other EU authority, with a total of 932 recorded actions. Spanish fines tend to be smaller in individual amount but span a far wider range of sectors and organisation sizes, including SMEs. That breadth is instructive: GDPR enforcement, including erasure failures, is not confined to large technology companies. Controllers of all sizes are within scope.

Across the broader enforcement picture, a total of 2,685 fines have been recorded in the CMS Enforcement Tracker database as of 1 March 2026, amounting to a sum of around €6.11 billion since 2018. Individual erasure violations rarely account for headline fines in isolation. The pattern that emerges from published decisions is that Article 17 failures surface alongside related deficiencies such as missing records of processing activities, defective controller-processor agreements, and privacy notices that fail to explain retention periods. Regulators don’t find one problem — they find the cluster.

ICO vs. EU DPAs: Two Different Risk Profiles

The contrast between the ICO’s enforcement model and the approach taken by EU supervisory authorities has sharpened since Brexit, and it carries practical implications for UK and EU-based controllers.

In the 2024/25 financial year, the ICO received 42,315 data protection complaints, an increase from 39,721 in 2023/24. Its enforcement, however, remained conspicuously light. There were only 43 UK GDPR investigations in 2024/25 compared to 285 in 2023/24, not a single UK GDPR enforcement notice was issued, and just two UK GDPR fines were imposed totalling £3.8 million. The ICO’s complaints-led model means that UK controllers’ primary enforcement exposure comes from individual escalations, making request-handling process quality directly relevant to fine risk.

EU supervisory authorities present a different dynamic. Multiple DPAs, including the CNIL, the Portuguese CNPD, and the Swedish IMY, have indicated that CEF findings will inform sector-specific inspections and supervisory planning in 2026. Nine DPAs launched or continued formal investigations as part of the CEF action, with ongoing enforcement proceedings in Ireland, France, Portugal, Slovenia, and Germany. Controllers in those jurisdictions face proactive scrutiny, not just reactive investigation triggered by complaints.

The Technical Infrastructure Problem

The EDPB’s 2025 findings place a specific challenge on record that compliance teams cannot resolve through policy updates alone. Participating supervisory authorities reported specific findings related to the reliance by some controllers on inefficient anonymisation techniques to handle erasure requests as an alternative to deletion. SAs also noted inconsistent practices and the difficulties faced by controllers regarding the determination of retention periods and the deletion of personal data in backups.

These are infrastructure problems. Legacy systems with no deletion capability, backup cycles that retain flagged-for-deletion data for extended periods, and data silos that fall outside the scope of standard erasure workflows are all now documented compliance concerns at the European regulatory level. The EDPB’s report signals that guidance on backup erasure and anonymisation standards is being developed, which means the current period of relative ambiguity is closing.

The growing number of cases and the increasing level of substantial fines in individual proceedings suggest that European DPAs will continue to pursue a strict enforcement approach. For organisations that have deferred investment in deletion infrastructure, the enforcement trajectory is clear

Why Deleting The Data Is Harder Than It Sounds

The legal obligation to erase personal data under GDPR is straightforward in principle. The engineering problem it creates is considerably less so, and the gap between the two is where most erasure failures actually originate.

For every one million consumer identities, manually processing data subject requests costs approximately $800,000. That figure, from DataGrail’s annual privacy trends research, reflects what happens when organisations try to act on deletion requests without the infrastructure to support them efficiently. It also explains why the volume of requests matters: there was a 246% increase in data subject requests between 2021 and 2023. Organisations still handling these manually are absorbing a cost that grows with their customer base.

1. Structured vs. Unstructured Data

Deleting a database record is a solved problem. The same individual’s data rarely lives in one place.

A typical mid-sized organisation holds personal data across CRM systems, billing platforms, email archives, marketing automation tools, analytics events, chat logs, support tickets, and shared document repositories. Deleting a structured record from a database takes seconds. Finding and removing all references to the same individual across years of unstructured email threads, uploaded documents, and analytics event logs is an entirely different undertaking — one that most organisations have not built systematic processes to address.

The gap here is not small. The EDPB’s 2025 CEF report, drawing on findings from 764 controllers across 32 supervisory authorities, identified the absence of documented internal procedures for handling erasure requests as the single most common compliance failure observed. The underlying cause, in many cases, is that organisations have no reliable picture of where an individual’s data actually resides across their systems.

A maintained Record of Processing Activities (RoPA) under Article 30 is the foundational prerequisite. You cannot delete what you cannot find, and you cannot find what you have never mapped.

2. The Backup Problem

Article 17 applies to backup systems. What the law does not require is immediate physical deletion from every backup layer simultaneously, because in most architectures that is technically impractical.

The GDPR requires organisations to have a documented, reasoned, and proportionate approach to erasure in backup systems, and to also communicate that approach honestly to data subjects.

The accepted pragmatic approach is to flag data for deletion from live systems immediately, ensure the backup is never restored with that individual’s data intact, and document that the deletion will be completed at the next scheduled backup cycle. The key requirement is a written policy that describes this process and a mechanism to enforce it.

Some controllers have no procedures at all for erasure in backups, while others wait for automatic overwrites and treat that as compliance. Neither is adequate. The EDPB has called for further guidance explaining how controllers should practically deal with erasure of personal data stored in backups, and what “without undue delay” means in this context. That guidance is pending — which means the current period of relative ambiguity will close, and organisations without documented backup erasure procedures are accumulating a compliance gap.

3. Sub-Processor Chains

When a controller receives a valid erasure request, the obligation does not stop at the controller’s own systems. Article 28(3)(e) requires data processing agreements to include a provision obligating processors to assist with data subject rights requests, and Article 19 requires notification to third parties to whom data has been disclosed.

In reality, this means a single erasure request may need to travel to a CRM vendor, an email marketing platform, a cloud analytics provider, a customer support tool, and potentially several sub-processors below them in the chain. Each link in that chain requires a contractual hook — an Article 28-compliant DPA that explicitly includes the deletion assistance obligation.

Controllers that haven’t audited their processor agreements for this provision face a structural problem: they may be contractually unable to compel the deletion they’re legally required to take action on. That gap is its own compliance risk, independent of any specific request.

Privacy by Design: The Cheaper Path

Article 25 requires data protection by design and by default. For erasure specifically, that means building deletion capability into systems from the outset rather than retrofitting it after a compliance failure.

The engineering patterns that support scalable erasure are well established:

• Soft delete flags that mark records as deleted without immediate physical removal,
• Data subject ID indexing that allows all data associated with an individual to be located and removed across tables with a single query,
• And separation of personal identifiers from analytical datasets so that pseudonymisation can substitute for deletion where the research purpose genuinely warrants it.

Organisations that automate data subject request workflows, including identity verification, data retrieval, deletion, and secure response, can reduce their cost to fulfil by significant margins compared to manual processing. The economics of building erasure capability into systems at design stage are substantially better than the economics of manual compliance at scale — and the regulatory exposure from architectural non-compliance is now clearly documented in the EDPB’s February 2026 CEF report.

For development and engineering teams, the Article 17 obligation is not an abstract legal requirement. It is a system design constraint with measurable cost implications, and one that regulators are now assessing with increasing technical sophistication.

Special Situations: Children’s Data, Deceased Persons, and Joint Controllers

Three scenarios consistently expose compliance gaps that standard erasure workflows aren’t built to handle: requests involving data collected from children, requests made on behalf of deceased individuals, and requests that implicate more than one controller. Each creates legal complexity that generic guidance doesn’t address — and each is becoming more, not less, common.

Children’s Data: The Most Forward-Facing Application of Article 17

Article 17(1)(f) establishes a specific erasure right for personal data collected from children in connection with information society services — the provision that sits closest to the original policy intent behind the “right to be forgotten.”

The Google Spain ruling in 2014, which established the practical contours of the right, involved an adult seeking removal of historical newspaper content from search results. But Article 17(1)(f), read alongside Article 8 and Recital 38 of the GDPR, points in a different direction: it recognises that children may not fully understand the implications of sharing personal data, and that they are entitled to have that data removed when they reach adulthood or withdraw their engagement with a platform.

Recital 38 states that children merit specific protection because they may be less aware of the risks, consequences, and safeguards involved in the processing of personal data. The erasure right under the law operationalises that concern: where data was collected under Article 8 (which governs the consent conditions for children’s data), erasure applies on request without the individual needing to invoke any of the other Article 17(1) grounds.

The practical implications for platforms are significant and growing. The EU’s Digital Services Act has sharpened obligations around minors, requiring designated platforms to prohibit targeted advertising based on profiling to children and to assess systemic risks to minors. As regulatory scrutiny of children’s data intensifies under both the GDPR and the DSA framework, the erasure right is increasingly likely to be tested through enforcement. Platforms that have not built dedicated erasure pathways for data collected from child users, including data collected years ago from individuals who were minors at the time, are carrying an exposure that standard adult-data workflows won’t address.

Deceased Persons: A Gap the GDPR Leaves to Member States

The GDPR does not apply to deceased individuals. Recital 27 is unambiguous: the regulation covers only the personal data of living natural persons. A request made after death falls outside the regulation’s scope, though that is not the end of the legal analysis.

Several member states have exercised the discretion implied by Recital 27 to introduce national rules extending data rights to heirs or nominees. France is the most developed example. Under Article 63 of the Loi pour une République numérique (2016), individuals may issue advance directives concerning the retention, deletion, and communication of their personal data after death. In the absence of such directives, heirs may exercise certain rights on behalf of the deceased, including requesting erasure, subject to conditions.

Italy has taken a comparable approach, permitting next-of-kin to exercise erasure rights where the deceased has not issued contrary instructions.

The implication here is that a controller receiving a deletion request from a family member following a customer’s death cannot simply decline on the basis that GDPR doesn’t apply. The correct response requires a two-stage assessment: first, whether the individual was resident in a jurisdiction with applicable national rules; second, whether those rules confer erasure rights on the requester and under what conditions.

Controllers operating across multiple member states should document their position on posthumous data requests explicitly, including the jurisdictions in which national rules apply and the evidence required to establish standing. Treating all post-death requests as automatically outside scope is a legally incorrect shortcut in an increasing number of EU jurisdictions.

Joint Controllers: One Request, Two Obligations

Where two or more controllers jointly determine the purposes and means of processing under Article 26, the GDPR’s erasure obligations apply to both. But the data subject is entitled to exercise their rights against either one, regardless of internal arrangements.

Article 26(3) states that a data subject may exercise their rights in respect of and against each of the controllers. The joint controller arrangement that the controllers have agreed between themselves does not affect the data subject’s ability to contact whichever party they choose. It affects only the internal mechanics of how the obligations are fulfilled.

This creates a practical requirement that joint controller agreements address deletion specifically. Where Controller A receives an erasure request that also requires deletion of data held by Controller B, Controller A cannot simply forward the request and consider its obligation discharged. The agreement must establish:

• Which controller takes primary responsibility for coordinating erasure responses.
• The timeline within which each controller undertakes to act on a deletion instruction from the other.
• How the one-month response deadline is managed where cross-controller coordination is required.
• How the Article 19 notification obligation (informing third parties of erasure) is allocated between the parties.

Joint controller arrangements are common in group company structures, platform-advertiser relationships, and data-sharing partnerships between public bodies. They are also an area where the internal agreement frequently fails to address data subject rights at the required level of specificity. A joint controller agreement that establishes lawful processing but leaves deletion mechanics undefined is legally incomplete, and the compliance risk falls on both parties when a request arrives.

Final Thought

The GDPR right to erasure is not a particularly complex legal provision. Article 17 runs to fewer than 500 words. What makes it difficult is the operational infrastructure it assumes. This includes data maps that are accurate, processor agreements that are complete, systems that can locate and delete data across every layer, and a decision-making trail that survives regulatory scrutiny.

Organisations that handle erasure requests well don’t treat them as isolated compliance events. They treat each request as a test of whether their broader data governance infrastructure is functioning. A request that arrives and flows smoothly through triage, scope mapping, processor notification, and documented response is evidence that the underlying systems work. One that stalls, escalates, or results in a complaint usually reveals something that was already broken.

The EDPB’s 2025 enforcement findings confirm that the gap between legal knowledge and operational capability is where most failures occur. Knowing what Article 17 requires is not the same as being able to deliver it.

Build the infrastructure first. The requests will follow.