A user requests erasure. The application deletes the row. Then someone asks: what about the backup?
The answer should not be “backups are exempt.” It should be a documented architecture for active data, backups, retention and restoration.
Separate active data from backups
Think in layers:
Active DB
↓
Replica
↓
Snapshot
↓
Backup
↓
Archive
These systems have different purposes and different technical capabilities.
The restore problem
If a deleted user exists in an older backup, a restore can reintroduce the record. A mature deletion process therefore needs a restore reconciliation step.
Restore
↓
Reconcile deletion ledger
↓
Reapply required deletions
↓
Validate
↓
Return to production
Build a deletion ledger
Track request ID, systems affected, deletion status, retention exception, verification and timestamps. Do not turn the ledger into another copy of the user's profile.
Retention matters
Section 12 provides a right to erasure subject to the statutory conditions, and Section 8(7) addresses erasure after withdrawal or when the specified purpose is no longer being served, subject to legal retention. Other laws may require specific records to remain. A retention policy should make those exceptions explicit.
The engineering question is therefore:
Which copy must remain, why, for how long, and how do we prevent unrelated reuse?
Immutable backups
If backups cannot be edited, document the reason, retention period, access restrictions, restore controls and deletion reconciliation. Do not claim immediate physical deletion if the architecture cannot provide it.
Test the workflow
Create a test user, put their data into production-like systems, create a backup, execute erasure, restore the backup in isolation and verify whether deleted data reappears. Then test the reconciliation process.
This tells you more than a policy review.
Where Privra fits
Privra connects deletion requests to the systems and processors that actually hold the data, while preserving the evidence needed to show what was deleted, what was retained and why.