The Right to Erasure: How to Handle "Delete My Data" Requests

Article 17 of the GDPR gives individuals the right to ask any organisation to delete their personal data. The request can arrive by email, through a web form, over the phone, or even verbally to a member of staff who has nothing to do with data protection. It does not need to mention "Article 17", "right to erasure", or even the GDPR. If someone says "please delete everything you have on me", that counts.

The European Data Protection Board made the right to erasure its enforcement priority for 2025, with 32 data protection authorities across Europe investigating how controllers handle deletion requests. The resulting report, adopted in February 2026, reviewed responses from 764 controllers and identified seven recurring compliance failures. The message from regulators is clear: this right is not optional, and how you process these requests is under active scrutiny.

What the Law Actually Says

Article 17(1) GDPR states that a data subject has the right to obtain erasure of their personal data "without undue delay" when specific grounds apply. Those grounds include situations where the data is no longer necessary for its original purpose, where the individual withdraws the consent on which processing was based (under Article 6(1)(a) or Article 9(2)(a)), where the individual objects to processing and no overriding legitimate grounds exist, where the data has been unlawfully processed, or where erasure is required to comply with a legal obligation under EU or Member State law.

There is also a heightened expectation when the data was collected from a child in connection with information society services, such as app sign-ups or social media accounts. Even if that child is now an adult, the fact that consent was given as a minor strengthens the case for erasure.

Article 12(3) GDPR sets the clock: you have one calendar month from receiving the request to respond. If the request is complex or you are dealing with a high volume of requests, you can extend that deadline by up to two additional months, but you must notify the individual before the initial month expires, explaining the reason for the delay.

When You Can Refuse

The right to erasure is not absolute. Article 17(3) lists five categories of exception where processing remains necessary despite a valid erasure request:

The burden of proof sits with you, the controller. If you refuse a request, you must demonstrate that the exception applies. A vague reference to "legal obligations" is not enough. The ICO guidance is explicit on this point: you must inform the individual of the reasons for refusal, their right to complain to a supervisory authority, and their ability to seek a judicial remedy.

The EDPB's 2026 CEF report flagged that many controllers struggle with applying these exceptions correctly, particularly when it comes to balancing the right to erasure against other rights and freedoms. Some organisations applied exceptions too broadly, rejecting requests without adequate justification.

A Step-by-Step Process for Handling Requests

A deletion request can come from anywhere. A customer emails your support team. Someone fills in your privacy request form. A visitor phones your office. The GDPR does not prescribe a specific format, which means every employee who interacts with the public could potentially receive a valid request. Training matters.

Step 1: Acknowledge and log the request

Record the date you received the request, the channel it arrived through, and the identity details provided. Your one-month response clock starts from the date of receipt, not from when you assign it internally. Send an acknowledgement confirming you have received the request and stating your expected response timeline.

Step 2: Verify identity

You need reasonable confidence that the person making the request is who they claim to be. If they are contacting you from the same email address they used to create their account, that may be sufficient. For more sensitive data, you might ask for additional verification. The key word is "reasonable" - the EDPB's CEF report found that some controllers imposed excessive authentication requirements that effectively discouraged people from exercising their rights.

Step 3: Assess the request against Article 17

Check whether any of the six grounds in Article 17(1) apply. Then check whether any exception under Article 17(3) applies. Document your reasoning either way. If the request is unclear - say, someone asks you to "delete my account" but you process several categories of their data across different legal bases - you can ask them to clarify exactly what they want deleted. This does not stop the clock, but it does show good faith.

Step 4: Locate all the data

This is where many organisations stumble. The CEF report noted that controllers frequently lack the ability to map all personal data associated with an individual across their systems. Think beyond your primary database. Personal data might live in your CRM, email marketing platform, analytics tools, customer support tickets, server logs, backups, and any third-party processors you use. A cookie like _ga ties to a client ID that might be stored alongside form submissions. An email address might appear in your newsletter tool, your invoicing system, and your helpdesk.

Step 5: Delete and notify

Erase the data from your active systems. Under Article 19 GDPR, you must also notify any recipients you have disclosed the data to about the erasure, unless this proves impossible or involves disproportionate effort. If you shared customer data with a marketing automation provider, an analytics service, or a payment processor, those third parties need to be informed.

Article 17(2) adds a further obligation: if you made the data public (for example, by publishing a user review or forum post), you must take reasonable steps to inform other controllers processing that data that the individual has requested erasure of any links to, or copies of, it.

Step 6: Respond to the individual

Confirm what action you have taken. If you have partially refused the request (for example, deleting marketing data but retaining invoicing records under a legal obligation), explain which data was deleted, which was retained, and the specific legal basis for retention.

The Backup Problem

Backups are one of the most persistent headaches in erasure compliance. The EDPB's 2026 report found a wide spectrum of practices: some controllers had no backup deletion procedures at all and relied on automatic overwrite cycles, while others had structured processes that extracted personal data from all systems and permanently deleted it after a defined retention window.

The practical reality is that selectively deleting one individual's data from a compressed, encrypted backup tape is often technically impractical. Most supervisory authorities accept that backup deletion can happen on a deferred schedule, provided certain conditions are met. The data must not be restored and used in the meantime. If a backup is restored for disaster recovery, any previously deleted data must be re-deleted promptly. You should have a documented retention schedule for backups, and that schedule should be as short as operationally feasible.

What regulators will not accept is an indefinite backup retention policy used as a reason to never truly delete anything.

Anonymisation Is Not a Shortcut

Some organisations respond to erasure requests by anonymising data rather than deleting it. In principle, this can be acceptable - if the data is truly anonymised, it falls outside the GDPR's scope entirely under Recital 26. The problem, as the EDPB's report highlighted, is that many controllers claim to anonymise data when they are actually only pseudonymising it or applying partial masking.

The Greek DPA, participating in the 2025 CEF action, found controllers replacing deletion with anonymisation techniques that lacked sufficient guarantees of irreversibility. The distinction matters enormously. Pseudonymised data, where a key still exists that could re-link records to an individual, remains personal data under the GDPR. Simply removing a name field while leaving a unique user ID, IP address, and behavioural profile intact does not constitute anonymisation.

If you choose anonymisation over deletion, you need to demonstrate that no reasonably available means could re-identify the individual. The EDPB is developing further guidance on anonymisation standards following the CJEU's September 2025 ruling in Case C-413/23P (EDPS v. SRB).

Beyond the GDPR: Erasure Rights in Other Jurisdictions

If your website serves visitors from multiple countries, you are likely dealing with overlapping deletion obligations. The requirements differ in detail, but the underlying principle is consistent: people can ask you to delete their data, and you need a process to handle that.

The California Consumer Privacy Act (CCPA), as amended by the CPRA, deserves particular attention. Under CCPA, businesses must respond to deletion requests within 45 days and must also instruct their service providers and contractors to delete the consumer's information. The CPRA further strengthened this by extending deletion requirements to third-party vendors. Penalties for non-compliance now reach $7,988 per intentional violation, enforced by the California Privacy Protection Agency (CPPA).

What the 2025 EDPB Enforcement Action Revealed

The EDPB's Coordinated Enforcement Framework report, published in February 2026, is the most comprehensive regulatory assessment of erasure compliance to date. Thirty-two DPAs participated. Of the 764 controllers surveyed, the overall compliance level was assessed as "average" - not reassuring language from the body that coordinates European enforcement.

Seven recurring challenges emerged from the investigation:

Controllers frequently lacked documented internal procedures for handling erasure requests. Staff did not know where to route requests, how to verify identity, or what timelines applied. Many organisations processed requests entirely manually, increasing the risk of missed deadlines and inconsistent outcomes.

Retention policies were often vague or missing entirely. Without a clear schedule for how long different categories of data are kept, controllers struggled to assess whether data should have already been deleted before a request even arrived.

Controllers had difficulty locating all personal data subject to a request. Fragmented systems, lack of data mapping, and poor documentation meant that deletion was often incomplete.

Anonymisation was used improperly as a substitute for deletion, with inadequate technical measures to ensure irreversibility.

Backup deletion practices were inconsistent. Some controllers had no policy at all for purging personal data from backups.

Information provided to individuals about how to exercise the right was insufficient or hard to find.

Exceptions under Article 17(3) were misapplied - sometimes too broadly (rejecting valid requests without proper justification), sometimes too narrowly (deleting data that should have been retained for legal compliance).

France's CNIL issued two formal notices as part of its CEF participation in 2025, which may result in penalties. The CNIL noted that an organisation's size and sector significantly influence compliance levels, with larger organisations generally having more formalised procedures but not necessarily better technical implementation.

Cookies and the Right to Erasure

If you run a website, deletion requests will often touch on cookie data. When a visitor asks you to delete their personal data, that includes any personally identifiable information collected through cookies and tracking technologies.

Analytics cookies like _ga and _ga_[container-id] generate a client ID that, when combined with other data points (IP address, browsing history, form submissions), can constitute personal data. Advertising cookies such as _fbp (Meta Pixel) or _gcl_au (Google Ads) link website behaviour to identifiable advertising profiles.

Deleting cookie data on your end is only part of the obligation. Under Article 17(2), if you have transmitted that data to third-party processors - Google Analytics, Meta, advertising networks - you must take reasonable steps to inform them that erasure has been requested. In practice, most major platforms provide data deletion APIs or tools. Google Analytics 4, for instance, offers a User Deletion API that removes data tied to a specific user identifier.

A cookie consent platform like Kukie.io helps you maintain a clear record of which cookies are active on your site and which third parties receive data. That audit trail makes it significantly easier to identify who needs to be notified when a deletion request arrives. You can start a free scan to see exactly what cookies your site sets and where the data goes.

Building an Erasure-Ready Website

Compliance is easier when the groundwork is already in place. A few structural decisions made early can save hours of scrambling when requests start arriving.

Data mapping

Document every category of personal data you collect, where it is stored, who has access to it, and which third parties receive it. Include cookies and tracking technologies in this map. If you do not know what cookies your site sets, you cannot respond to a deletion request completely. Kukie.io's scanner detects first-party and third-party cookies and categorises them, giving you a starting point for your data inventory.

Retention schedules

Define how long you keep each category of data and why. Tax records might need to stay for seven years. Marketing consent records might be kept for the duration of a subscription plus a short buffer. Analytics data older than 14 months may serve no useful purpose. A clear retention policy means much of your data gets deleted automatically before anyone needs to ask.

A visible request channel

Make it easy for people to submit a request. A dedicated email address (like privacy@yourdomain.com) or a web form linked from your privacy policy works well. Do not hide the process behind multiple clicks or require people to log in to an account they may want deleted.

Internal procedures

Write down who handles requests, what the verification steps are, where data needs to be checked, who contacts third-party processors, and who sends the final response. The EDPB's report was unambiguous: controllers without documented procedures are the ones making the most mistakes.

Frequently Asked Questions