GDPR Right to Erasure for SaaS: How to Handle Deletion Requests

Under Article 17 of the GDPR, a person can ask you to delete their personal data, and you generally have one month to do it. For a SaaS business that means a deletion workflow that removes or anonymises the person's data across your primary database, your sub-processors, and — in time — your backups, while keeping an audit record that proves you complied. This guide covers what erasure actually requires, the narrow cases where you can refuse, and how to build the workflow so a request is a routine job rather than a fire drill.

What the right to erasure requires (Article 17)

The "right to be forgotten" lets a data subject request deletion of their personal data in defined circumstances — most commonly when the data is no longer necessary for the purpose you collected it, when they withdraw the consent you relied on, or when they object to processing based on legitimate interests and you have no overriding grounds. When a valid request lands, you must erase without undue delay and, in practice, within one month (extendable by two further months for complex requests, if you tell the person why). You also have to take reasonable steps to inform any processors — and, where the data was made public, other controllers — that the person has asked for erasure.

When you can refuse — and must retain

Erasure is not absolute. You can decline, in whole or in part, where you have a competing legal reason to keep the data. The ones that catch SaaS businesses most often:

The key move is partial erasure: retain only the narrow slice you are legally required to keep, delete or anonymise the rest, and record which exemption covers what remains. A blanket "we keep everything for seven years" is not a lawful answer to an erasure request.

Delete or anonymise? Your audit trail is the trap

Not every record can — or should — be hard-deleted. An audit log, a usage ledger, or an entitlement history often has to survive for security and accountability, yet it names the person you are meant to erase. The resolution is anonymisation: strip or irreversibly hash the identifiers so the record can no longer be linked to an individual, and keep the now-anonymous event. Truly anonymised data falls outside the GDPR, so an anonymised audit log is compliant andpreserves the integrity of your history. Pseudonymisation — where a key could still re-identify the person — does not count; the mapping is still personal data.

The deletion workflow, step by step

Build erasure as a defined pipeline, not an ad-hoc SQL statement:

• Verify the requester. Confirm the person is who they say they are before you delete anything, without collecting excessive new data to do it.
• Scope the request. Identify every store that holds their data — primary database, per-tenant data, caches, search indexes, logs, and each sub-processor.
• Soft-delete with a grace period. Mark the account for deletion and give a short, disclosed window (often 14–30 days) to guard against mistaken or malicious requests and account recovery.
• Hard-delete or anonymise. After the grace period, remove the personal data from live systems and anonymise anything you must retain for audit.
• Propagate to sub-processors. Trigger deletion in the third parties that hold the data on your behalf (email, analytics, error tracking, support tooling).
• Record the outcome. Log that the erasure happened, when, and what exemptions applied — anonymised so the log itself is not a new copy of the person's identity.
• Confirm to the requester. Tell them it is done within the one-month window.

What to do about backups

Backups are where deletion projects stall, and the good news is that regulators are pragmatic here. You do not have to surgically rewind every encrypted backup the moment a request lands. The accepted approach is to delete from live systems immediately, and let the data age out of backups on their normal rotation — provided you can guarantee that a restore will not silently bring the deleted person back into production. Document your backup retention period, and make your restore process re-apply outstanding deletions. Tell the requester their data is gone from live systems and will be purged from backups within your stated retention window.

The licensing and entitlement slice

A licensing system is squarely in scope for erasure: it holds account identifiers, device fingerprints from activations, IP addresses from validation calls, and usage telemetry. When someone is erased, their licenses, activations, and usage records have to go with them — and the audit trail of those events has to be anonymised, not simply dropped.

That is built into ValidonX. Each customer's licensing data lives in an isolated per-tenant database; a deletion request runs a workflow that removes the user's licenses and activations, anonymises the associated audit events, and closes the tenant database after a grace period — while every user can first export their full profile as structured JSON to satisfy the access and portability rights alongside erasure. You inherit the licensing slice of your erasure obligation instead of building the pipeline yourself. (For the isolation that makes clean per-customer deletion possible, see how ValidonX multi-tenancy works.)

This is engineering guidance, not legal advice — scope your own obligations with a DPO or privacy counsel. For the full picture around erasure, see the practical GDPR guide for SaaS and the startup GDPR checklist.

Frequently asked questions

How long do I have to respond to a GDPR deletion request?

You must act without undue delay and, in practice, within one month of receiving the request. You can extend by up to two further months for complex or numerous requests, but you have to tell the person about the extension and why within the first month.

Do I have to delete data from my backups too?

Eventually, yes, but you do not have to surgically edit every backup the moment a request arrives. The accepted approach is to delete from live systems immediately and let the data age out of backups on their normal rotation — provided a restore cannot silently bring the deleted person back into production. Document your backup retention window and make your restore process re-apply outstanding deletions.

Can I refuse a right-to-erasure request?

In part, yes, where you have a competing legal reason to keep specific data — a legal obligation to retain invoices for tax, an active legal claim, or an ongoing contract you cannot deliver without the account data. Retain only the narrow slice the exemption covers, delete or anonymise the rest, and record which exemption applies to what remains.

Should I delete or anonymise audit logs when someone asks to be erased?

Anonymise them. An audit or usage log often has to survive for security and accountability, but it names the person you must erase. Irreversibly stripping or hashing the identifiers so the record can no longer be linked to an individual keeps the log useful while taking it outside GDPR scope. Pseudonymisation — where a key could still re-identify them — does not count.

What is the difference between erasure and anonymisation?

Erasure removes the personal data entirely. Anonymisation keeps the record but irreversibly severs its link to a person, so it is no longer personal data. Use erasure for data you can drop outright, and anonymisation for records you must retain — like audit history — that would otherwise identify the erased individual.

Want deletion and export handled for your licensing data? Start free — issue and validate your first license in minutes, with export and erasure workflows built in, no credit card.