You do not extract the record. Regulators accept that surgically removing one person from an immutable backup is neither practical nor safe, so the accepted approach is different: delete from live systems immediately, put the backup copy beyond use, let your normal retention cycle overwrite it, and tell the requester exactly that. Which means your backup retention period is not an infrastructure setting. It is the thing that determines how long you are still holding data somebody asked you to erase.
This article covers what "beyond use" actually requires, why your retention window is the real control, the restore problem that quietly undoes erasure, what to say to the person who asked, and when you can decline entirely.
Why This Is Hard, And What Regulators Accept
Article 17 gives people the right to erasure in defined circumstances, and it says nothing about backups. Neither do the recitals. That silence is the whole problem, because backups are built to be immutable and are frequently stored as opaque images that cannot be searched for a single record without a full restore.
The ICO's guidance on the right to erasure sets out the accepted position. Where an erasure request can be fulfilled immediately in live systems but the data will remain in the backup environment until it is overwritten, the key issue is to put the backup data beyond use, even if it cannot be immediately overwritten. Concretely, that means you must ensure you do not use the data within the backup for any other purpose — the backup is simply held on your systems until it is replaced in line with an established schedule.
The ICO also expects you to be absolutely clear with the individual about what will happen to their data, including in respect of backup systems.
The CNIL frames the same problem as a choice, and its wording is worth having in front of you: provide for erasure in backups, or provide an alternative solution that does not restore erased data relating to that person. That second limb is the suppression list described below — a regulator naming it as an acceptable substitute for deleting from the backup itself, and the part most teams skip.
Note what that bargain requires of you. "Beyond use" is not a label you apply. It is a set of commitments: no operational use of that backup, an established schedule that will overwrite it, and honest disclosure. An organisation with no retention schedule has nothing to point at, and the concession does not apply.
Your Retention Window Is The Real Control
If overwriting is how the data eventually goes, then how long you keep backups is how long erased data survives. A thirty-day cycle means a month. A seven-year archive means seven years, and an "erasure" that leaves the record intact for seven years is one you should be uncomfortable describing as erasure.
Article 5(1)(e) applies to backups like everything else — personal data kept no longer than necessary. The necessity here is recovery, and recovery necessity has a shape: you need enough history to restore from a recent failure and to catch corruption that went unnoticed for a while. It does not usually justify keeping every daily snapshot indefinitely.
So the useful exercise is to write down, per backup tier, what it is for and how far back that purpose reaches. Daily snapshots for operational recovery. A shorter set of weeklies. Anything longer needs a stated reason — a legal retention obligation, a contractual commitment — rather than inertia.
Article 32(1)(c) pulls the other way and should be respected: you must be able to restore availability and access to personal data in a timely manner after an incident. Nobody is asking you to stop taking backups, and a policy that deletes backups so aggressively that you cannot recover from ransomware has traded one compliance failure for a worse one.
Worth knowing what your own vendors do here, since their windows become yours. Our piece on Supabase records one published example of a post-termination retention period and a default backup cadence, which is the sort of clause that decides how long your data outlives your account.
The Restore Problem
This is the failure that turns a compliant process into a false statement, and it is almost never designed for.
You delete someone from production. Six weeks later a database incident forces a restore from a backup taken before the deletion. The restore succeeds, the incident closes, and the person you erased is now back in your live systems — searchable, emailable, and included in the next export. Nobody notices, because a successful restore looks like a success.
The fix is a suppression list: a durable record of erased identifiers, held outside the data being restored, that any restore procedure checks and re-applies before the system returns to service. It has to survive the restore itself, which means it cannot live only in the database being replaced.
Two details. The suppression record should be minimal — the point is data minimisation, so a hashed identifier and a date is better than a copy of everything you deleted. And re-deletion needs to be a documented step in the runbook, not something an engineer remembers at 3am. A restore procedure that does not mention erasure suppression will not perform it.
The same logic reaches every other copy of the data you keep, which is more places than people expect. Application logs hold the same records and need the same treatment, and non-production copies are the other common blind spot — dealt with in our guide to using production data in test environments.
What To Tell The Requester, And When You Can Say No
Transparency is doing real work in this arrangement, and vagueness costs you the concession.
A good response confirms deletion from live systems, states plainly that copies remain in backups, gives the date or period by which those backups will be overwritten, confirms the data will not be used for any purpose in the meantime, and confirms that a restore will not reintroduce the record. That is five sentences and it is defensible. "Your data has been deleted," when it has not been deleted from three backup generations, is a misstatement you have put in writing.
When You Can Decline
The right is not absolute. Article 17(3) sets out exemptions, and the ones that come up in practice are compliance with a legal obligation requiring retention, and the establishment, exercise or defence of legal claims. If a legal hold applies, say so and explain the basis rather than quietly keeping the data. Where the request is refused in whole or part, Article 12(4) requires you to tell the person why and inform them of their right to complain to a supervisory authority.
One boundary worth naming: this article is about backups. Setting retention periods across your live systems, classifying data and automating cleanup is a wider programme, and our SaaS data retention guide covers that.
Common Mistakes With Backups And Erasure
Telling someone their data is deleted when it is in three backup generations. The concession regulators offer depends on disclosure. Claiming complete deletion forfeits it and creates a written inaccuracy.
Having no suppression list. Without one, the next restore silently resurrects everyone you erased, and nothing in the process will flag it.
Backup retention that nobody chose. If snapshots accumulate until storage costs prompt a cleanup, your erasure timeline is set by your finance team. Set the window deliberately and document why.
Trying to surgically edit backups. Restoring, deleting a row and re-imaging risks integrity, risks other people's data, and is not what is being asked of you.
Forgetting the other copies. Logs, analytics warehouses, staging databases and exported reports all hold the same records, and an erasure process scoped to the production database misses most of them.
FAQ
Do we have to delete personal data from backups?
Eventually, yes, but not immediately and not surgically. Delete from live systems straight away, put the backup copies beyond use so they are not used for any other purpose, and let your established retention schedule overwrite them. Regulators accept that approach provided you have a real schedule and you tell the person what is happening.
How long can we keep backups under GDPR?
There is no fixed period. Article 5(1)(e) requires you to keep personal data no longer than necessary, and for backups the necessity is recovery. Set a window per backup tier that reflects how far back you would realistically restore from, document the reasoning, and treat anything longer as needing its own justification.
What exactly should we tell someone who asks for erasure?
That live systems are done, that backup copies remain, when those will be overwritten, that nothing will be used from them in the meantime, and that a restore will not bring the record back. Being specific about the date is what turns a vague reassurance into a defensible position.
What if we restore a backup after deleting someone?
Then the record returns unless you prevent it, which is why the suppression list matters. Keep erased identifiers outside the restored dataset and make re-deletion an explicit step in the restore runbook. A restore that silently reintroduces erased people undoes every request you have processed.
Closing Thought
The interesting thing about backups is that they are the one place where good engineering and data protection pull genuinely in opposite directions. Everywhere else the advice converges — minimise, encrypt, restrict access, and both disciplines nod along. Here, the property that makes a backup trustworthy is precisely the property that makes erasure hard, and no amount of policy writing dissolves that.
Which is why the honest answer is a process rather than a technical fix, and why the part that most often fails is not the deletion. It is the sentence you send afterwards.
ComplyDog handles the request side: a self-serve intake form for erasure and other data subject requests on a portal hosted on your own domain, with records of processing that document your retention periods — including the backup ones you will need to quote when somebody asks. You can try it free for 14 days, no credit card required.
