Articles / Privacy Law

1069 words

  • uk-law
  • gdpr
  • data-protection
  • backups
  • privacy
  • ico

Do You Have to Erase Someone from Your Backups?

You've deleted someone's row after an erasure request, and the same row is still sitting in last night's full backup. It's also in the weekly archive, and possibly in a disaster recovery replica 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 is more interesting than "GDPR has a backup exemption", because it doesn't have one. 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 how storage systems actually work. It's worth understanding properly rather than just assuming you're covered.

Article 17 doesn't distinguish backups from anything else

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
  • 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 is still processing, and the controller is still obliged to erase the data from it.

The regulation simply wasn't drafted with immutable, append-only backup architecture in mind. Enforcing it literally would make backups themselves nearly impossible to run.

The ICO accepts "beyond use" until the backup rotates out

The ICO addresses this directly in its guidance on the right to erasure, in a section specifically about backup data.

The core idea: erasing from live systems is technically straightforward, but doing the same to backups may be disproportionate or technically very difficult. Where that's so, the ICO accepts a staged approach. The data can be put "beyond use" on the backup, then 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
  • must be permanently deleted once possible, i.e. when the backup rotates out, and the organisation must commit to that

It's a concession, not a loophole

The ICO recognises that most backup systems are designed around retention windows and immutability, not selective per-record deletion. Forcing organisations to break that design would be pointlessly expensive or actively harmful.

Actually, the harm bit is interesting. An append-only or WORM backup that can be selectively edited is a much weaker defence against ransomware and insider tampering. The very property that makes erasure awkward is the one protecting you.

But 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.

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 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 tombstone pattern most systems land on

The practical pattern is a tombstone:

  1. Mark the record as erased in the live system immediately.
  2. Keep a minimal record of the erasure itself (who, when, on what legal basis) separately from the personal data it applied to.
  3. 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 what you 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.

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.

How "beyond use" quietly becomes a liability

The failure mode isn't usually the backup policy itself. It's letting "beyond use" quietly become "we just don't think about it". Three patterns 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. They're not really "backups" in the sense the ICO's guidance is talking about; they're active processing, and the backup exemption was never meant to cover them.

Check your staging copy first

That last one is 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. The erasure request applies there just as it does in production.

← All articles