Deleting someone’s personal data when they ask sounds simple until the request arrives and nobody knows where that person’s data actually lives. For website owners, DPOs and support teams, the right to erasure under Article 17 of the GDPR is a hard legal deadline. It is also a test of how well you know your own data flows. This article covers when erasure applies, when it doesn’t, how to run a deletion request from intake to confirmation, and the mistakes that cause trouble with regulators.
What the Right to Erasure Actually Requires
Article 17 gives individuals the right to have their personal data erased “without undue delay” when one of several grounds applies. The data may no longer be needed for its original purpose, the person may have withdrawn consent, they may have objected to processing based on legitimate interests, or the data may have been processed unlawfully in the first place.
The deadline comes from Article 12(3). You have one month from receipt to act and respond. For complex or numerous requests you can extend by two more months, but you must tell the requester about the extension within that first month and explain why.
Article 19 adds an obligation that often gets overlooked. You must notify every recipient you disclosed the data to, such as processors, partners and integrated platforms, unless that proves impossible or involves disproportionate effort. For US-facing sites, the CCPA right to delete runs on a different clock: 45 days, extendable by another 45 with notice.
Myth: Erasure Is an Absolute Right
Many website owners think a deletion request means everything goes, immediately. It doesn’t. Article 17(3) lists exemptions, and the most common in practice is compliance with a legal obligation.
Invoices and accounting records are the classic example. German commercial and tax law (HGB §257, AO §147) requires many business records to be kept for up to 10 years. Finland’s Accounting Act sets six years for many supporting documents. A customer who bought from your webshop in 2024 can have their marketing profile, account and browsing data erased, but the invoice stays.
Other exemptions cover freedom of expression, public health, archiving in the public interest, and the establishment or defence of legal claims. The legal-claims exemption needs a specific and realistic dispute behind it, not a general “we might get sued someday”.
The reverse also holds: unsubscribing is not erasure. A contact who has opted out of emails but still sits in Mailchimp as “unsubscribed” has not been erased. In Mailchimp, archiving keeps the record, and only the “permanently delete” option removes it.
How to Process a Deletion Request Step by Step
An experienced DPO treats every erasure request as a small project with a clear audit trail. The workflow that holds up best looks like this:
1. Log and verify. Record the date received, since the one-month clock starts then. Verify identity in proportion to the risk. If the request comes from the email address already on file, asking for a passport scan is excessive and collects new personal data you then have to protect.
2. Map the data. Search every system where the person may appear: CMS user tables, CRM (HubSpot, Salesforce), email platform, helpdesk (Zendesk, Freshdesk), analytics, payment processor, and server logs. Your records of processing activities should tell you where to look. If they don’t, that is a gap worth fixing first.
3. Apply exemptions record by record. Decide what must be retained and why. Keep the invoice, delete the wishlist, the support chat history and the newsletter profile.
4. Delete and propagate. Remove the data in each system, then notify processors and recipients. Google Analytics 4 has a User Deletion API, and HubSpot has a dedicated GDPR delete function that goes further than a standard contact delete.
5. Confirm in writing. Tell the requester what was deleted, what was retained, the legal basis for keeping it, and how long it will be kept.
A realistic timeline for a mid-sized webshop is day one for intake and verification, days two to five for mapping and deletion across six to ten systems, and a written confirmation well within 30 days. If you regularly need the full month, your data map is probably incomplete.
A Typical Scenario: The Customer Who Came Back
A familiar pattern goes like this. A customer asks for deletion in March. Support deletes the account in WooCommerce and removes the contact from the CRM. In June, the same person gets a promotional email.
The cause is almost always a sync. The contact still existed in a Zapier workflow or a lead-enrichment tool, which pushed the record back into the CRM a few weeks later. The complaint to the data protection authority then concerns not only the email but a failed erasure, which is the more serious violation.
The fix sounds counterintuitive: keep a suppression list. Store a minimal identifier, ideally a hashed email address, whose only purpose is to block re-import. Regulators including the UK ICO accept this as compatible with erasure, because the alternative is worse.
Common Mistakes That Draw Regulator Attention
The first mistake is forgetting processors and third parties. Deleting data from your own database while it stays in a marketing platform, an embedded form provider or an ad audience does not meet Article 17. Tracking pixels are a particular blind spot: custom audiences built from hashed emails in Meta or Google Ads keep that person in circulation. This connects directly to broader vendor risk management, because your erasure is only as complete as your least cooperative vendor.
The second mistake is mishandling backups. Few companies can surgically remove one person from an encrypted nightly backup, and regulators generally don’t expect it. The accepted approach is to put the data “beyond use”: document that backups rotate out on a fixed cycle, for example 35 days, and that restored data will be checked against the suppression list before going back into production.
The third mistake is treating erasure as a support ticket rather than a compliance process. Without a written log of what was deleted, when and where, you cannot prove compliance. The EDPB made the right to erasure the topic of its 2025 Coordinated Enforcement Framework, with more than 30 authorities examining how organizations handle these requests. Documentation was one of the recurring weak points.
Where Your Website Fits Into Erasure Compliance
Your website is often where a deletion request starts and where the promises about it are published. Your privacy policy must explain the right to erasure and how to exercise it. If that page breaks after a CMS update or the contact form for data requests stops submitting, requests go missing and the one-month clock keeps running without anyone knowing.
That is why deletion workflows belong alongside continuous checks of legal pages and forms. Erasure also sits next to the other data subject rights, and teams that already handle data subject access requests efficiently can usually reuse the same intake, verification and logging process.
FAQ
Do I have to delete data from backups when someone requests erasure?
Usually not immediately. Put the backup data beyond use: don’t access it for other purposes, let it expire on a documented rotation schedule, and re-apply the deletion if a backup is ever restored.
Can I refuse an erasure request?
Yes, if an Article 17(3) exemption applies, such as a statutory retention period for accounting records. You can also refuse requests that are manifestly unfounded or excessive. In either case, explain the reason in writing within one month and tell the person they can complain to a supervisory authority.
Does the right to erasure apply to B2B contacts?
Yes. GDPR protects natural persons, so a named contact at a client company, such as anna.virtanen@company.com, has the same rights as a consumer. Generic addresses like info@ fall outside personal data only when no identifiable individual is behind them.
The most useful thing to do this week is a test run. Submit a deletion request for a test account through your own website, follow it through every system, and see where the data survives. That exercise usually shows more gaps than any policy review.