Executive Summary
The right to erasure enables Data Principals to request deletion of their personal data. Implementing this right requires both technical capability to locate and delete data across all systems and procedural frameworks to handle requests appropriately. This guide addresses the practical aspects of erasure implementation.
Key Takeaways
- 1Map all locations where personal data is stored before designing deletion capabilities
- 2Implement both logical deletion and eventual physical deletion mechanisms
- 3Address backup and archive data in deletion procedures
- 4Document exceptions where retention is legally required
- 5Verify deletion completion across all systems
1Understanding the Erasure Right
Section 12 provides that upon withdrawal of consent, the Data Fiduciary shall erase personal data unless retention is required for compliance with law. This creates both a right for Data Principals and an obligation for organisations to implement deletion capabilities.
2Mapping Data for Deletion
You cannot delete what you cannot find. Comprehensive data mapping underpins effective erasure.
Primary Systems
Identify all databases, applications, and systems that store personal data in structured form.
Unstructured Data
Locate personal data in unstructured repositories including documents, emails, and file shares.
Derived Data
Identify personal data created through processing, such as profiles, scores, and predictions.
Backup Systems
Catalogue backup infrastructure where personal data copies reside.
Archive Systems
Document archived data locations and retention periods.
Third Party Holdings
Identify personal data held by processors and partners on your behalf.
3Designing Deletion Capabilities
Technical systems must support deletion requests. This often requires specific development.
Unique Identifier Propagation
Establish consistent identifiers that allow the same individual to be found across systems. Without this, comprehensive deletion is difficult.
Deletion APIs
Build or configure APIs that can accept deletion requests and execute them across relevant systems.
Cascading Deletion
Where data is linked across systems, implement cascading deletion that follows relationships.
Verification Mechanisms
Build in verification that deletion actually occurred, not just that a deletion command was issued.
Practical Tips
- •Design for deletion from the start of system development; retrofitting is harder
- •Consider soft delete followed by hard delete to allow recovery from errors
4Handling Backup and Archive Data
Backup systems present particular challenges for erasure because they are designed for data preservation.
Assess Backup Architecture
Understand how backups work, retention periods, and whether selective deletion is technically feasible.
Deletion from Active Backups
Where feasible, delete personal data from backup systems. Modern backup solutions increasingly support selective deletion.
Lifecycle Expiry
Where selective deletion is not feasible, document that data will be deleted when backups naturally expire through retention policy.
Restoration Procedures
If a backup containing deleted data is restored, procedures should ensure the previously deleted data is re-deleted.
Important Warnings
- •Backup systems not designed for selective deletion may require architectural changes
- •Claiming inability to delete from backups may not satisfy regulatory expectations
5Processing Erasure Requests
Establish procedures for receiving and actioning erasure requests.
Request Intake
Provide clear channels for submitting erasure requests. Link these from privacy notices and account settings.
Identity Verification
Verify requester identity before deleting data. Deleting the wrong person's data creates its own compliance problem.
Scope Confirmation
Confirm what data the requester wants deleted. Full erasure or specific data? All services or specific products?
Execution and Tracking
Execute deletion across all identified systems and track completion status.
Confirmation
Confirm deletion completion to the requester within prescribed timelines.
6Exceptions to Erasure
Not all data must be deleted upon request. Document and apply exceptions appropriately.
Legal Retention Requirements
Where law requires data retention (tax records, transaction logs, regulatory filings), this overrides erasure requests.
Legitimate Continued Processing
Where processing continues on a basis other than consent (legal obligation, legitimate interest), erasure may not be required.
Document Exceptions
When declining erasure based on an exception, document the specific basis and communicate it to the requester.
Partial Erasure
Where some data is subject to exception but other data is not, delete what can be deleted and retain only what must be retained.
7Third Party Notification
Where data has been shared with third parties, consider obligations to notify them of erasure.
Identify Recipients
Determine which third parties received the data subject to erasure.
Assess Notification Duty
Consider whether you have an obligation to notify recipients of the erasure request.
Execute Notification
Where appropriate, notify recipients and request they delete their copies.
Track Compliance
Follow up to verify third party deletion where feasible.