Right to Erasure vs Backups: What UK GDPR Actually Requires

Someone submits an erasure request. You delete their row from the production database, feel briefly virtuous, and then remember that the same row exists in last night's full backup, the weekly archive, and possibly a disaster recovery replica sitting in a different region. Are you now in breach? Do you owe them a restore-scrub-reseal operation on every tape in the safe?

No, and the reason why is more interesting than "GDPR has a backup exemption", because it doesn't. Article 17 of UK GDPR does not mention backups at all. What exists instead is a practical accommodation the ICO has worked out between the letter of the right to erasure and the reality of how storage systems actually work, and it's worth understanding properly rather than just assuming you're covered.

What Article 17 actually says

Article 17 UK GDPR gives a data subject the right to obtain erasure of their personal data "without undue delay" where one of several conditions applies: the data is no longer necessary for the purpose it was collected for, consent is withdrawn and there's no other lawful basis, the subject objects and there's no overriding legitimate ground, the processing was unlawful, or erasure is required by law.

Nothing in the article distinguishes between "your primary datastore" and "everywhere else a copy of this data might live". Strictly read, a backup containing personal data about someone who has exercised their right to erasure is still processing their data, and the controller is still obliged to erase it. The regulation simply wasn't drafted with immutable, append-only backup architecture in mind, and enforcing it literally would make backups themselves nearly impossible to run.

The ICO's actual position

The ICO addresses this directly in its guidance on the right to erasure, in a section specifically about backup data. The core idea is that where erasing personal data from live systems is technically straightforward but doing the same to backup systems would be disproportionate or technically very difficult, the ICO accepts a staged approach: the data can be put "beyond use" on the backup, and permanently erased when that backup naturally cycles out of retention or is overwritten.

"Beyond use" is doing real work in that sentence. The ICO's guidance sets out what it means in practice. Data on a backup that hasn't been erased yet must not be used for any active processing purpose, must not be restored into a live system in a form that would let anyone access it, must be given appropriate technical and organisational security, and the organisation must commit to permanently deleting it once possible, i.e. when the backup rotates out.

Crucially, this is a concession, not a loophole. It exists because the ICO recognises that most backup systems are designed around retention windows and immutability, not selective per-record deletion, and forcing organisations to break that design would either be pointlessly expensive or actively harmful (an append-only or WORM backup that can be selectively edited is a much weaker defence against ransomware and insider tampering). It is not a licence to keep backups indefinitely and call the data "beyond use" forever. If your backup retention is 30 days, you're fine. If it's 7 years because nobody ever revisited the retention policy, that's a much harder position to defend, and the ICO has been clear in enforcement action that "we never delete anything from backups" is not, on its own, an acceptable answer.

What this means for the systems you actually run

If you're the one designing the storage and backup architecture, the practical requirements fall out of the guidance fairly directly:

• Your backup retention period needs to be a deliberate, documented, and defensible number, not "whatever the default was when we set up the job in 2019".
• You need a way to answer, for any given backup, "when does this get destroyed or overwritten", and that answer needs to be short enough that "beyond use until then" is a credible claim rather than a fig leaf.
• Restoring a backup for disaster recovery is fine. Restoring a backup and then serving that data back out through your application, including data that was subject to an erasure request before the backup was taken, is not. If your DR runbook doesn't account for this, that's a gap.
• Access to backups themselves should already be tightly restricted as a security matter, which happens to also satisfy the "appropriate technical and organisational measures" part of being beyond use.

The practical pattern most systems land on is a tombstone: mark the record as erased in the live system immediately, keep a minimal record of the erasure itself (who, when, on what legal basis) separately from the personal data it applied to, and let the backup rotation handle the rest. Something like:

-- live table: the actual erasure
UPDATE users
SET email = NULL, name = NULL, phone = NULL, erased_at = now()
WHERE id = $1;

-- separate audit trail, no personal data, survives independently
INSERT INTO erasure_log (subject_id, requested_at, completed_at, basis)
VALUES ($1, $2, now(), 'article_17_1_a');

The erasure_log row is the thing you can point to later if someone (the subject, or the ICO) asks whether the request was actioned and when. The personal data itself is gone from anything you actively query or serve, and the backup copies fall out of scope for erasure on their own schedule, provided that schedule is short and genuinely enforced, not just declared in a policy document nobody checks.

Where organisations get this wrong

The failure mode isn't usually the backup policy itself, it's letting "beyond use" quietly become "we just don't think about it". A few patterns that turn a legitimate exemption into a liability:

Backups with no defined expiry, kept because storage is cheap and nobody wants to be the person who deletes something that might matter later. Restore procedures that get tested against production traffic without anyone checking whether the restored data includes records that should have been erased. Replicated environments (staging copies seeded from production dumps, analytics warehouses fed by full exports) that quietly become a second live copy of data the backup exemption was never meant to cover, because they're not really "backups" in the sense the ICO's guidance is talking about, they're active processing.

That last one is the one worth checking your own systems for. A nightly production-to-staging database copy that engineers query against is not a backup for the purposes of this exemption, however it's labelled in your infrastructure diagrams. If personal data in it hasn't been erased and someone can query it, you're processing it, full stop, and the erasure request applies there just as it does in production.