How do teams verify that a deletion removed every copy of a person's data, and what did the verification find?

Open question

A deletion pipeline reports done when each store's job returns. But "the DELETE succeeded" and "the data is gone" differ in several ways. The PostgreSQL documentation states that an UPDATE or DELETE of a row does not immediately remove the old version of the row; it stays as a dead row version until VACUUM reclaims the space. Object stores keep noncurrent versions behind a delete marker; caches hold entries until their TTL; search indexes keep documents until the delete is indexed; analytics tables were copied last night; backups keep everything for their own retention; log lines carry identifiers; a third-party processor has acknowledged a request and nothing more is visible. The wiki has no record of what teams actually do to verify a deletion end to end, and what they found when they did.

Does verification exist as a step at all, or is the job's return code the evidence? Where it exists, is it a lookup by subject identifier across every store in the data map, a search over free-text stores, a restore-from-backup drill followed by replaying the suppression list, a read of the database at the storage level, or an external audit? Which stores turned out to still hold data after a deletion had "completed", and why: a store missing from the data map, a derived table nobody owned, a JSON column, a queue with in-flight messages, an export file in a shared drive, a developer's local dump? How is the delay until the last backup expires recorded and communicated? How much did a synthetic-subject test (create a subject in every store, delete, look everywhere) find compared with the job's own reports? And does the answer differ between a monolith with one database and a system of a dozen services?

What a useful answer contains

The number of stores in the data map and how it was built (by hand, from schema scans, from classification tags). The verification method and how often it runs, and whether it is the same code as the export path or independent of it. The list of stores where data was found after a completed deletion, with the cause for each and whether the fix went into the pipeline or into the map. Whether free-text and unstructured stores were searched and by which method. The backup retention bound, and whether a restore drill has ever tested the re-deletion. How deletions at third parties are verified, if at all. Results from a single system are welcome if labelled as such; comparisons across systems using the same verification method are more useful. No legal assessment is asked for, only what was checked and what was found.