Data and reporting
Data retention needs deletion evidence, not just a policy
A retention policy is only useful when the system can show which records were eligible, which were held back, what was deleted and what evidence remains. Deletion needs an operational workflow, not a calendar reminder.
A policy does not delete anything by itself
Many organizations have a sentence that says records should be kept for a certain period. The hard part is turning that sentence into safe system behavior. Which records are in scope? Which copies exist in attachments, exports and backups? Which records are under a hold? Who reviews exceptions?
A useful deletion workflow answers those questions before the scheduled job runs. It treats deletion as a controlled operation with evidence, not as a background cleanup script nobody can explain.
Start with eligibility and exclusions
The first step is a clear eligibility query. It should identify records by source, date basis and business status. “Older than two years” is incomplete if one system uses creation date, another uses closure date and a third keeps a copied export.
Then define exclusions. A customer dispute, open invoice, active contract, regulatory hold or support investigation may prevent deletion. Those holds should be visible as reasons, not hidden in a custom filter. If a record is skipped, the workflow should say why and when it should be reviewed again.
Choose the right removal method
Deletion is not one technique. Some systems remove a row. Others anonymize fields, detach files, revoke search access or sanitize media. NIST SP 800-88 focuses on media sanitization and emphasizes choosing techniques based on information sensitivity and context. In application workflows, that principle translates into choosing a removal method that actually addresses where the data lives and how it can be recovered.
For example, deleting a document record may not remove thumbnails, extracted text, search index entries or exported CSV files. An operational retention plan lists those dependent stores and assigns each one a deletion or refresh step.
Keep evidence without keeping the data
The evidence record should prove the action without preserving the data that was meant to be removed. Store the rule name, run id, actor or job identity, record reference, deletion method, timestamp, counts, exceptions and verification result. Avoid copying deleted content into the evidence log.
Backups need special handling. A backup may retain data until it ages out through the backup lifecycle. The workflow should state that behavior plainly and prevent ordinary restore drills from reintroducing deleted records into active systems without review.
Test deletion like any other workflow
Run the deletion process in preview mode first. Show eligible records, held records, dependent stores and expected evidence. Then test a small authorized batch and verify the active application, search results, reports and exports behave as expected.
The practical takeaway is that retention is a workflow. It needs scope, holds, deletion method, evidence and verification. Without those pieces, a policy can sound responsible while the data remains scattered and unexplained.