Deletion must cover backups and derived data

What it is

End-to-end data deletion gives deletion semantics to every linkable copy and derivative of a person's record, not only the primary application table. Scope may include caches, search indexes, warehouses, logs, recoverable backups, and labels, scores, or profiles produced from source data. Coverage need not mean instantaneous byte-level disappearance from every medium; each residue needs explicit isolation, expiry, and exclusion from routine processing.

Why it happens

Copying, transformation, and aggregation turn a record into a directed lineage graph. Removing the source does not trigger downstream materialized views, feature stores, or offline files automatically, and backup restoration can resurrect deleted records. A derivative without the source field can still influence decisions about the same person. Reliable deletion is therefore a cross-store state-propagation protocol requiring stable identity, dependency registration, idempotent work, and replay after recovery.

Studying it

Tests can seed synthetic accounts with unique markers, invoke each deletion route, and trace source and derived identifiers across primary stores, caches, indexes, warehouses, logs, and isolated backup restores. Measures include coverage, propagation latency, retry failure, post-restore resurrection, and availability to downstream decisions. Logical inaccessibility, cryptographic erasure, and physical removal should be distinguished; failure to find a plaintext marker does not prove all aggregate or model influence has vanished.

Where it stops holding

Aggregates no longer reasonably linkable to a person may not require recomputation for every request; model retraining depends on identifiable effect, risk, and applicable obligation. Append-only security logs or legally held records may remain temporarily but need isolation, use restrictions, and deletion when the condition ends. Backups can expire on a rotation schedule only if restoration reapplies the deletion ledger before returning data to production.

Applying it

• Maintain lineage from personal identifiers to primary records, replicas, derivatives, logs, and recovery paths.
• Write requests to a durable tombstone or deletion ledger consumed idempotently by each store, with completion status returned.
• Isolate backups that cannot be immediately rewritten, set expiry, and replay the ledger before any restored system becomes active.
• Exercise deletion and disaster recovery with marked synthetic accounts; declare technical completion only when online lookup, derived decisions, and restored copies no longer expose the account.

Related

• Same group: O1.07.2 Deletion scope and timing must be stated · O1.07.3 Disappearance from the interface is not backend deletion · O1.07.4 Erasure is an assertable legal right, not an optional feature · O1.07.5 Deletion requests must propagate to downstream recipients · O1.07.6 Public-interest and retention exceptions can justify refusal · O1.07.7 Completion needs verifiable evidence, not a verbal promise
• Adjacent: O1.02 Data minimization · O1.12 Data portability and export
• Search terms: end-to-end deletion · data lineage · deletion tombstone