Data retention implementation
Measure eligible data left behind after the retention run
A job-success counter can hide failed destinations and overdue records. Track complete outcomes, authorised holds and unresolved copies separately.
In this article
Define completion across the required scope
List the destinations included in each policy action and what evidence establishes their outcome. Completion may mean deletion, approved transformation or another explicitly authorised treatment.
Do not use a database row count as the sole measure when attachments and indexes are in scope. The main record can be gone while a public file URL still works.
Keep backup treatment visible as its own policy-controlled lifecycle rather than silently counting every backup copy as immediately removed.
Track age and partial failure
Measure the oldest eligible unresolved record, the time from eligibility to completion and failures by destination. These show whether a recurring job is keeping up with the approved schedule.
An illustrative run selects 1,000 records. Nine hundred and eighty complete, ten are under authorised holds and ten have failed attachment removal. Reporting 990 successful database changes obscures both the holds and the unresolved files.
Use categories that lead to action: permission failure, protected object, provider outage or missing destination mapping. Each needs a different owner or correction.
Verify that removed data stays unavailable
Run controlled checks for reappearance after reindexing, export refresh and backup restoration. These tests establish properties that a normal daily deletion count cannot show.
Sample destination evidence under an appropriate access process. Avoid restoring or exporting large amounts of personal data merely to produce a metric when synthetic fixtures can prove the mechanism.
Track new data destinations without a retention mapping as coverage gaps. A newly added analytics pipeline can invalidate an otherwise complete design.
Keep policy exceptions accountable
Measure holds and other exceptions with owners, reasons and review conditions. An exception with no lifecycle can become permanent retention by accident.
Do not optimise the dashboard by deleting evidence needed to explain the action or by labelling unresolved copies out of scope without approval. Scope changes belong to the responsible policy owner.
Acceptance should show that eligible data receives the approved treatment and that every unresolved destination remains visible. A green scheduler status only proves that the scheduler finished its own code path.
Primary sources
AWS: object lifecycle managementReferences checked 11 September 2026.