Deletion Verification
Proving that a deletion actually removed the data everywhere it existed, which is a harder problem than issuing the delete.
Issuing a deletion is straightforward. Demonstrating that the subject's data is gone from everywhere it propagated is not, and it is the part a regulator asks about.
The places it survives are predictable and are missed in roughly this order. Backups, which hold every prior state and are typically excluded from the deletion job on the reasoning that they will age out — which is a defensible position only if the retention period is stated and the exclusion is documented. Analytical copies, where the record was replicated into a warehouse, a lakehouse snapshot and three derived tables. Search indexes and caches, which hold denormalised copies with their own lifecycles. Logs, which frequently contain the identifier and sometimes the payload. Third parties, where the data was pushed to a CRM or a marketing platform whose deletion API is asynchronous and whose confirmation nobody records.
Verification therefore needs three things: a lineage-derived list of every location the data reaches, a per-location deletion mechanism with a recorded outcome, and a sampled re-query afterwards that asserts absence rather than trusting the job's exit code.
The design consequence is that erasure has to be an architectural requirement from the start. Retrofitting it onto an estate with unmapped downstream copies is how a thirty-day obligation becomes a six-month programme, and the discovery is always the same: nobody knew the data went there.