The Right to Erasure: What "Delete My Data" Actually Requires

What the Right to Erasure Actually Covers

When someone exercises their right to erasure, you must delete all personal data you hold about them — not just their account record. Personal data means any information that can identify them: name, email address, IP address logs, device identifiers, usage events tied to their account, support tickets, billing records (with caveats), and any data you've synced to third-party tools.

That last part is where most implementations fall short. Deleting the database row is one step. But if you've sent that user's data to Intercom, Mailchimp, Amplitude, and a data warehouse, you need to delete it from all of those too.

What You Can Legitimately Keep

The right to erasure isn't absolute. Article 17(3) lists exceptions. The most relevant for most businesses:

• →Legal obligations. If you're legally required to keep financial records (typically 6–7 years for tax purposes), you can retain the minimum necessary billing data. Delete everything else, keep the invoice. For practical guidance on how long to keep data, your retention policy should document the basis for each category.
• →Establishment, exercise, or defence of legal claims. If there's ongoing litigation or a dispute, you can retain relevant data.
• →Public health and research. Unlikely to apply to most web products.

When you're retaining data under a legal obligation exemption, tell the user. Your response to their deletion request should explain which data you're keeping, why, and for how long. This information should also appear in your privacy policy.

The 30-Day Window

You have one month from receiving a deletion request to complete it. This clock starts when you receive the request — not when you start processing it. For most small products, deletion should happen within days, not weeks.

You can extend by a further two months for complex or numerous requests, but you must inform the person within the first month that you're extending, and explain why.

Soft Delete vs Hard Delete

Many applications implement "soft delete" — the account is flagged as deleted but the data stays in the database for recovery purposes, or to prevent ID conflicts. This does not satisfy the right to erasure. Soft deletion is an operational convenience, not a privacy measure.

You need to either hard delete the personal data fields (replacing them with nulls or a hash) or genuinely purge the row. Which approach you take depends on your data model, but "the record still exists" is not compliant. For SaaS products, build this deletion logic before you have users — retrofitting it is painful.

A common pattern: keep the user ID (for referential integrity), delete all personal data fields, and flag the record as `[deleted]`. This lets foreign key relationships survive while removing the identifying information.

Backups: The Part Everyone Ignores

GDPR acknowledges that backups are complicated. The general guidance is that you don't need to immediately restore a backup just to delete a user's data from it — but when a backup is restored, if you've already processed a deletion request, you must delete the data again promptly after restoration.

In practice: document your deletion requests. When your backup is eventually restored (which should be rare), re-run deletions for anyone who requested erasure since the backup was taken.

The guidance doesn't let you hide behind backups indefinitely. If your backup retention is 90 days and you never restore them, that data sits there for 90 days after a deletion request — which is an area of legal grey. Some DPAs are less tolerant of this than others.