Data retention implementation
Investigate a record that reappears after recovery
Find the source that recreated the data before deleting it again. Otherwise the next reindex or restore can repeat the same failure.
In this article
Limit exposure and identify the record's origin
Follow the approved incident and data-handling process for the affected system. Locate the retention action, policy version and last confirmed destination outcomes.
Determine whether the visible record came from a restored database, stale index, old export or provider synchronisation. Compare creation and restoration metadata rather than assuming it is a new customer submission.
Use restricted identifiers and evidence links in the working record. Avoid copying the full personal record into a broadly shared incident ticket.
Stop the recreation path
Pause or constrain the specific ingestion or restoration stage through the authorised operating procedure if it is continuing to republish affected data.
For a synthetic example, an older database snapshot feeds a search rebuild before the retention ledger is reapplied. Deleting the search entry alone will not work while that source remains eligible for ingestion.
Confirm the current hold and policy state before repeating destructive action. The original decision may have changed, and the operator should not infer authority solely from an old deletion timestamp.
Reapply the approved treatment
Run the supported retention or reconciliation workflow against the affected destinations. Preserve action identity and outcome evidence so retries remain explainable.
Verify direct retrieval and the ordinary user path after completion. Check attachment versions and caches according to the destination's actual behaviour.
If a protected backup or object cannot be selectively removed, escalate through the documented policy path and describe the remaining copy accurately. Do not claim full erasure because the live application no longer exposes it.
Repair the recovery procedure
Add the missing retention reconciliation step before restored data can serve traffic or populate derived systems. Rehearse the corrected sequence with synthetic records.
Review the scope of other records affected by the same restoration or export. A single reported reappearance may reveal a broader pipeline gap.
Close the incident with verified outcomes, remaining approved exceptions and a named owner for any further work. The durable fix prevents recreation, while another isolated delete only treats the visible symptom.
Primary sources
AWS: object lifecycle managementAWS: Object LockReferences checked 11 September 2026.