Right to Erasure Engineering: Systems, Backups and Logs

Deleting a customer row from the primary database is the easy part of an erasure request; the same person also lives in replicas, event streams, analytics warehouses, search indexes, logs, backups, suppliers and sometimes machine learning training sets. Under the UK GDPR and EU GDPR the right to erasure (Article 17) must be answered without undue delay and at the latest within one month, and the controller must tell recipients of the data unless that is impossible or involves disproportionate effort. Meeting that across a modern architecture is an engineering design problem, not a ticket. This guide covers how to map where personal data propagates, deletion patterns that work at scale (hard delete, tombstones, crypto-shredding), how to handle backups, logs and ML, how to prove deletion, and how to roll it out. It is for privacy engineers, platform architects and data protection officers. Request intake and identity verification are covered in the DSAR Guide: Handling Data Subject Requests.

Status checked 27 October 2026: GDPR Article 17 and the UK GDPR right to erasure are in force; ICO guidance as published on the date checked. This page is engineering guidance, not legal advice.

Key takeaways

You cannot erase what you have not mapped. A per-subject data map that follows identifiers through pipelines, caches and suppliers is the foundation.
Design one deletion event, many consumers. Publish an erasure event once and have every system that holds the data subscribe, act and acknowledge.
Crypto-shredding scales where row deletion does not. Encrypt each subject's data under a per-subject key and destroy the key to make all copies, including backups, unreadable.
Backups need a documented "beyond use" position. The ICO accepts that backups may not be overwritten immediately if the data is put beyond use and expires on the normal schedule.
Evidence matters as much as deletion. Keep a minimal, non-identifying record that a request was completed, by which systems, and when.

What the law asks engineers to deliver

Obligation	Source	Engineering consequence
Erase where a ground applies: data no longer necessary, consent withdrawn, successful objection, unlawful processing, legal obligation to erase, or data collected from a child for online services	GDPR Art. 17(1); ICO right to erasure guidance	Deletion must be possible per subject, not only by retention batch
Respond without undue delay and within one month, extendable by two further months for complex or numerous requests (tell the person within the first month)	GDPR Art. 12(3); ICO guidance	End-to-end deletion SLA well inside one month, with tracking
Tell each recipient of the data about the erasure, unless impossible or disproportionate	GDPR Art. 19; ICO guidance	Supplier and processor deletion APIs or contractual processes, logged
Where data was made public, take reasonable steps to inform other controllers to erase links, copies or replications	GDPR Art. 17(2) and Recital 66	Records of where data was published or syndicated
Exceptions: freedom of expression, legal obligation, public interest, public health, archiving and research, legal claims	GDPR Art. 17(3) and Recital 65; ICO guidance	Per-system retention holds that override deletion, with the legal basis recorded
Storage limitation: keep data no longer than necessary, with time limits for erasure or review	GDPR Art. 5(1)(e) and Recital 39	Retention schedules enforced automatically, which reduces erasure scope

For the security programme view of GDPR see the GDPR Compliance Guide for Security Teams.

Mapping where personal data propagates

Start from the Data Mapping and ROPA Guide and add the detail an erasure needs: which identifier keys the data in each store, and how to find every record for one subject.

Identifier graph: record every key that can identify a subject (customer ID, email, phone, device ID, advertising ID, hashed email) and the joins between them. Systems keyed only by a hashed email or device ID still hold personal data.
Operational stores: primary databases, read replicas, caches (Redis, CDN edge caches), search indexes (Elasticsearch, OpenSearch).
Streams and queues: Kafka topics, event buses and dead letter queues, which retain messages for their configured retention period.
Analytics: data lakes, warehouses, BI extracts, notebooks and CSV exports in shared drives.
Logs and telemetry: application logs, access logs, APM traces and error trackers that capture email addresses, IPs or request bodies.
Suppliers: CRM, marketing, support desk, payment and analytics SaaS. Each is a recipient under Article 19.
ML: feature stores, training datasets, embeddings in vector databases, and fine-tuned models.
Backups and archives: database snapshots, object storage versions, tape and long-term archives.

Deletion patterns and when to use each

Pattern	How it works	Best for	Trade-offs
Hard delete	Remove rows and documents by subject key	Primary OLTP stores, search indexes	Foreign keys and denormalised copies must be found; immutable stores cannot do it
Anonymisation in place	Overwrite identifying fields, keep the record for aggregates	Orders and financial records needed for reporting	Must be genuinely irreversible; pseudonymised data is still personal data
Tombstone and compaction	Write a deletion marker; background compaction removes data	Kafka compacted topics, LSM stores, data lake table formats with delete files	Data remains until compaction or vacuum runs; schedule and verify it
Crypto-shredding	Encrypt each subject's data under a per-subject key; delete the key	Event stores, immutable logs, backups, large lakes	Key management at scale; plaintext copies outside the scheme are not covered
Partition drop by retention	Drop whole time partitions when they expire	Logs, telemetry, clickstream	Does not meet one-month deadlines if retention is longer; pair with redaction at ingest
Supplier API deletion	Call the processor's deletion endpoint and record the response	SaaS recipients	Supplier timelines vary; contracts must define them

Crypto-shredding in practice

Key hierarchy: a key-encryption key in a KMS or HSM wraps per-subject data keys held in a key store. Deleting a subject's data key makes every ciphertext copy unreadable, wherever it sits.
Know your KMS behaviour: in AWS KMS, deleting a key requires a waiting period of 7 to 30 days (default 30) and is irreversible once complete; data keys already wrapped by a KMS key are affected when services next need to decrypt them. Per-subject keys are therefore usually managed in an application key store wrapped by a few KMS keys, rather than one KMS key per person.
Back up the key store separately with a shorter retention than data backups, so a restored data backup cannot be decrypted for erased subjects.
Cloud provider precedent: Google Cloud describes cryptographic erasure for Cloud Storage and for backups, noting that data in a backup becomes unrecoverable once its key is destroyed, even before the backup expires.
Media sanitisation: NIST SP 800-88 Rev. 2 (final, September 2025) covers sanitisation methods including cryptographic erase for media; use it for decommissioned storage rather than per-subject deletion.

Backups, logs and immutable stores

Backups: the ICO's position is that the key issue is to put backup data "beyond use", even if it cannot be immediately overwritten; it should not be used for any other purpose and should remain only until replaced under the established schedule. Engineer for that: a restore procedure that replays the erasure ledger before restored data returns to production, and a backup retention you can state to the requester.
Restore replay: keep an erasure ledger of subject keys (or hashed keys) and request dates, retained longer than the longest backup. Every restore runs the ledger against restored data.
Provider timelines as a benchmark: Google Cloud commits to delete customer data within a maximum of about 180 days, with soft deletion up to 30 days, logical deletion from active systems taking about two months and backups expiring within six months. Your own stated period should be similar or shorter, and documented.
Immutable and WORM storage: object lock and immutable backups protect against ransomware but conflict with deletion. Use crypto-shredding for personal data in immutable stores, and keep immutability periods no longer than needed. See the Backup Security and Immutable Backup Guide.
Logs: redact or tokenise identifiers at ingestion (log only a pseudonymous subject ID), keep retention short, and keep security logs needed for legal obligations under an explicit exception. See the Log Management and Retention Guide.
Event sourcing and Kafka: append-only logs cannot delete individual events. Encrypt personal fields per subject, or keep personal data out of events and reference it by key.

Machine learning and AI systems

Training data: the ICO says you still need to consider erasure requests for training data, and that removing one person's data is unlikely to affect your ability to train, so refusal grounds are unlikely.
Models: the ICO says erasing training data does not entail erasing models built on it, unless the models contain the data or can be used to infer it. Some models retain training examples by design, and then retraining or deletion may be needed.
Engineering response: keep training sets versioned and keyed by subject so records can be removed before the next training run; record which model versions used which dataset versions; remove embeddings for the subject from vector stores; filter retrieval-augmented generation sources at query time.

See the AI and GDPR Guide.

Orchestrating and proving deletion

Intake and verification through the DSAR process; decide applicability and exceptions.
Publish one erasure event (subject identifiers, request ID, deadline) to an orchestration service.
Fan out: each registered system, including supplier connectors, receives the event, applies its pattern (delete, anonymise, shred) and returns an acknowledgement with a count of affected records.
Retry and escalate any system that has not acknowledged within its SLA (for example 7 days) so the one-month deadline is never at risk.
Verify: run a lookup across the identifier graph to confirm no live records remain, and schedule a second check after compaction and cache expiry windows.
Close and evidence: keep a completion record with request ID, systems, dates and exceptions applied, not the erased data itself. Tell the requester what was erased, what was retained and why, and the backup expiry period.

What the response must contain. The ICO expects the response to say whether data was erased or the request refused. Build the response template from the orchestration record:

Completed: systems erased, data retained under an exception with the reason, and the date by which backup copies expire.
Extended: where the request is complex, the notice of extension sent within the first month, with reasons.
Refused: the reasons, the right to complain to the ICO (or the relevant EU supervisory authority) and the right to seek a judicial remedy, as the ICO requires for refusals of manifestly unfounded or excessive requests.

Where identity fits: the deletion orchestrator and its connectors are non-human identities with delete rights across every data store and SaaS tenant. Scope each connector to deletion on its own system, store its credentials in a vault, log every call and alert on deletions not linked to a request ID, because the same capability could destroy data at scale if misused.

Implementation plan and decision guidance

Phase 1 (0 to 3 months): build the identifier graph for top systems; manual runbooks per system; erasure ledger and restore replay procedure.
Phase 2 (3 to 9 months): event-driven orchestration for internal systems; supplier deletion API integrations; log redaction at ingest.
Phase 3 (9 to 18 months): per-subject encryption for event stores, lakes and backups; ML dataset lineage.
Testing: use synthetic test subjects seeded into every system in staging and production; run an erasure each release and confirm zero residual records. Roll back a failing connector by disabling it and falling back to its manual runbook, never by skipping the request.

Small versus large organisations: a small business with a handful of SaaS tools can meet the obligation with a documented manual runbook per tool, short backup retention and a tracker. A large organisation with hundreds of services needs the event-driven model and crypto-shredding, because manual deletion across that estate will miss copies.

Metrics: median and 95th percentile time from verified request to completion; percentage of in-scope systems integrated with orchestration; residual record count from post-deletion verification (target zero); supplier acknowledgement rate within SLA; restores performed with ledger replay (target 100%).

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A
Retention and disposal of information	SI-12	PR.DS-01	A.8.10 Information deletion
Authority to process personal data	PT-2	GV.PO-01	A.5.34 Privacy and protection of PII
Key destruction for crypto-shredding	SC-12	PR.DS-01	A.8.24 Use of cryptography
Media sanitisation	MP-6	PR.DS-01	A.7.14 Secure disposal or re-use of equipment
Backups	CP-9	PR.DS-11	A.8.13 Information backup

Common failure patterns

Soft delete treated as erasure: a deleted_at flag hides the record from the UI, but it remains in the table, replicas and exports.
Restores resurrect erased people: a backup restored after an incident brings back subjects because no erasure ledger was replayed.
Logs full of identifiers: request bodies and emails logged for debugging sit in a log platform with a one-year retention.
Suppliers forgotten: the CRM and marketing platform still hold the record because no Article 19 process exists.
Pseudonymised mistaken for anonymous: hashed emails in analytics are still personal data and must be erased or genuinely anonymised.
Compaction never runs: tombstones are written but vacuum or compaction jobs are disabled, so deleted data persists in files.

Practitioner checklist

Build an identifier graph covering stores, streams, analytics, logs, suppliers, ML and backups.
Assign each system a deletion pattern and an owner, with a completion SLA well inside one month.
Implement an erasure event and acknowledgement flow, with retries and escalation.
Maintain an erasure ledger and replay it on every restore.
Document backup retention and the "beyond use" position; state it in responses.
Redact identifiers from logs at ingestion and shorten log retention.
Use per-subject encryption for immutable stores, event logs and backups where volume justifies it.
Integrate supplier deletion APIs or contractual processes and record acknowledgements.
Version ML training data by subject and track which models used which datasets.
Test monthly with synthetic subjects and report residual record counts to the DPO.
Scope, vault and monitor the credentials of every deletion connector.

Standards and references

Related NHI Mgmt Group resources: DSAR Guide: Handling Data Subject Requests · Data Retention and Secure Deletion Guide · Data Mapping and ROPA Guide · AI and GDPR Guide. This guide summarises GDPR and UK GDPR erasure obligations for engineers and is not legal advice.

Right to Erasure Engineering Guide: Deleting Personal Data Across Systems, Backups and Logs