Data retention implementation
Restore a backup containing a record you already deleted
Retention testing must include partial failures and recovery. A record disappearing from the live screen is only the first observation.
In this article
Create a traceable synthetic record
Use a test record with an attachment, search entry and permitted analytics copy. Capture the identifiers needed to locate each representation without using real personal data.
Apply the approved test retention rule and verify each destination independently. Check direct retrieval as well as the normal interface, since hidden content may remain accessible by identifier.
Keep the action's evidence record separate from the original content so verification does not create another full copy.
Interrupt one destination
Make attachment deletion fail while primary and search removal succeed. The overall action should remain incomplete, with the failed stage visible and retryable.
Resume the worker and confirm that it finishes the missing stage without recreating deleted data or failing permanently because earlier destinations are already absent.
Run the ingestion process again. It should not repopulate the search index from an old export or replica that the retention design forgot to address.
Add a hold at the execution boundary
Select a candidate, then apply an authorised test hold before the destructive stage. Verify the documented race-handling behaviour and the audit evidence for the decision.
Release the hold through the approved test workflow and confirm that the record is reconsidered under the current policy. A held item should not disappear from the system's retention inventory indefinitely.
Test protected object versions separately. A successful removal of the current visible object may not establish removal of older versions under the storage service's semantics.
Rehearse restoration before reopening access
Restore a backup that predates the deletion into an isolated environment. Apply the retention reconciliation step before enabling ordinary reads or reindexing.
Search for the synthetic record, fetch its attachment and inspect derived copies. Confirm the outcome required by the approved backup policy and record any remaining protected copies accurately.
The test passes when restoration preserves the retention decision, not simply when the database boots. Record the procedure and its dependencies so disaster recovery does not rely on someone remembering an informal cleanup step.
Primary sources
AWS: object lifecycle managementAWS: Object LockReferences checked 11 September 2026.