When someone asks you to erase their data, delete it from live systems promptly and let backups age out on a short, documented schedule, while making sure a restore cannot bring the person back. Be ready to explain this plainly. Rewriting every backup on demand is usually impractical, so design around it.
What the law says and does not say
Article 17 requires erasure without undue delay when a ground applies, and Article 12(3) sets a one month response window, extendable by two months for complex requests. The article does not list backups as a special case. Regulators have generally accepted a pragmatic approach where backup copies are put beyond use and overwritten on a defined cycle, but confirm your supervisory authority's position and ask counsel, because it is a legal judgement.
Design for it from the start
The easiest fix is a short backup retention period. If full backups expire after a month, any erased record disappears from every backup within that month without manual work. Then your answer to the person is simple and true: "your data is deleted from our systems now and from backups by this date."
Choose that period for operational reasons, and write it into the retention schedule so you can state it.
Keep an erasure ledger
Store a minimal record of each erasure: a pseudonymous subject ID or token, the date, and the systems cleared. Do not store the original details.
The ledger serves two purposes. It proves you acted, and it drives restores. After any restore, replay the ledger against the restored database before reopening it to users, so deleted people do not reappear.
Make restores safe
- Restore into an isolated environment.
- Run the erasure replay job.
- Validate row counts and spot checks.
- Only then switch traffic.
Test this in a drill. Many teams discover the gap only during a real incident.
Other places copies hide
Backups are the famous case, but similar copies sit in:
- Search indexes and caches.
- Data warehouse snapshots and exports.
- Logs with personal data.
- Vendor systems that received the data. Article 19 expects you to tell recipients about erasure unless that proves impossible or involves disproportionate effort.
- Developer laptops and test databases built from production extracts.
Your data map tells you which of these exist.
Cryptographic erasure
If you encrypt each person's data with its own key, destroying the key makes every copy, including those in backups, unreadable. It is elegant but demands per person key management and careful design, since one mistake leaves plaintext copies behind.
Say it honestly
Tell the requester when backups will clear. Do not claim instant deletion if backups persist. Accurate wording protects you better than a promise you cannot show.
Quick check
Must I delete from backups immediately?
The text does not carve out backups, but a short documented expiry combined with safe restore handling is the common approach. Check with counsel.
What if I must keep some data by law?
Article 17 has exceptions for legal obligations and claims. Keep only what the law needs and delete the rest.
Sources
Last reviewed: 19 October 2026.
