Data retention implementation
Deleting the customer row does not delete every copy
Retention needs a map of data destinations, an approved policy and evidence from each removal path. Backups and derived indexes require explicit treatment.
In this article
Start with the purpose and the policy owner
A support platform stores a customer's request in a database, attachments in object storage, searchable text in an index and diagnostic details in logs. Deleting the database row can leave useful identifying information in all three other places.
Define retention by data category and purpose before implementing a timer. The applicable period and exceptions depend on the organisation and record. Engineers should implement an approved schedule rather than assume that one period applies to every business dataset.
For organisations covered by the Australian Privacy Principles, OAIC guidance explains the requirement to take reasonable steps to destroy or de-identify personal information no longer needed for permitted purposes, subject to exceptions including applicable retention requirements and Commonwealth records. The responsible privacy or records owner should determine how that guidance applies to the specific system.
Inventory the copies the application creates
Trace primary records, attachments, replicas, caches, search documents, analytics exports and provider-held copies. Record the owner and deletion mechanism for each destination.
Separate derived data that can identify a person from genuinely de-identified output. Removing a name field does not automatically make a dataset anonymous when other attributes or linked identifiers can reconnect it to a person.
- Policy decisionCategory, trigger, retention rule and authorised exceptions
- Eligibility checkConfirm current state and any hold before action
- Destination workRemove or transform primary and derived copies
- VerificationRecord outcomes, failures and backup treatment
Make deletion a recoverable workflow
A multi-system retention job can fail halfway through. Give the action an identity and track destination outcomes so retries continue unfinished work without recreating removed data.
An illustrative run removes a ticket and its search entry but fails to delete one attachment because the storage service is unavailable. The job should remain incomplete with a retryable attachment task. A success count based only on the database deletion would be misleading.
Recheck eligibility and holds at the action boundary. A record selected yesterday may have acquired an authorised hold before the worker executes today. Define how that race is resolved under the approved policy.
Describe backup behaviour honestly
Backups may be immutable or managed through a lifecycle that does not permit selective immediate deletion. Document the actual treatment and obtain the appropriate policy decision rather than promising instant erasure from every copy.
A restoration procedure should reapply relevant retention decisions before restored data returns to ordinary use. Otherwise a record deleted last week can reappear after recovery from an older snapshot.
Object-storage versioning and retention locks also affect what removal means. Review the selected service's current rules for versions, delete markers and protected objects instead of equating a successful delete request with physical removal of every version.
Keep evidence without rebuilding the deleted dataset
Record action identity, policy version, destination outcomes and necessary timestamps. Minimise the personal content retained merely to prove that a deletion occurred.
The design is complete when an operator can explain which copies were handled, which remain under an approved lifecycle and what happens after restoration. That explanation is more useful than a Delete button whose effect stops at the main table.
Primary sources
OAIC: APP 11 guidanceAWS: object lifecycle managementAWS: Object LockReferences checked 11 September 2026.