Handling Data Deletion Requests in Practice
By Mykhailo Boichuk · Co-founder & Vice-President
In short
Honoring a deletion request means removing a person’s data everywhere it lives, which is harder than deleting one database row because copies persist in backups, caches, logs, and third-party services. A practical approach maps where data goes before it is requested, distinguishes hard deletion from anonymization, handles backups with a clear policy, and confirms completion. Knowing your data flows in advance is what makes deletion achievable.
Deletion is a distributed problem
A deletion request asks you to remove a person’s data, but that data rarely lives in one place. It is in the primary store, in derived caches, in search indexes, in application logs, in analytics, in backups, and possibly in third-party services the data was sent to. Deleting the obvious copy while leaving the others is not honoring the request; it is doing the easy part and ignoring the rest. The difficulty is that you cannot delete data you have lost track of.
This is why the foundation of handling deletion is knowing, before any request arrives, where personal data flows and comes to rest. A data map that records every place a person’s information lives turns deletion from a frantic search into a defined procedure.
Hard deletion versus anonymization
Not all data can simply be erased. Some records must be retained for legitimate reasons, such as financial or legal obligations, and some data is entangled with other people’s. The distinction between hard deletion, removing the data entirely, and anonymization, severing the link to the person while keeping non-identifying data, matters here. Anonymization is only valid if the data genuinely cannot be re-associated with the individual.
- Map where personal data flows before a request ever arrives.
- Decide per data type whether to hard-delete or properly anonymize.
- Propagate deletion to caches, indexes, logs, and third parties, not only the primary store.
Backups and third parties
Backups are the hardest case, because the point of a backup is to be immutable and to preserve past state. The common approach is a clear policy: the data is deleted from active systems immediately, and the request is recorded so that if a backup is ever restored, the deletion is reapplied, with backups themselves expiring on a defined schedule. Third-party services that received the data must also be instructed to delete it, which requires knowing which services those are.
Confirm and record
Finally, the person who requested deletion deserves confirmation that it happened, and the organization needs a record that the request was honored. Under privacy regimes such as those overseen by Canada’s privacy commissioner, being able to demonstrate that you fulfilled an obligation matters. A deletion handled well ends with a clear confirmation and an internal record, not with an assumption that the data is probably gone.
Key takeaways
- Personal data lives in many places: stores, caches, indexes, logs, backups, third parties.
- Deleting only the obvious copy does not honor the request.
- Map data flows in advance so deletion is a defined procedure, not a search.
- Distinguish hard deletion from valid anonymization that cannot be reversed.
- Handle backups with a clear policy and confirm completion to the person and yourself.
Frequently asked questions
- Why is honoring a deletion request harder than deleting a row?
- The data lives in many places, including caches, indexes, logs, backups, and third-party services, and deleting only the primary copy leaves the rest behind.
- What is the difference between deletion and anonymization?
- Hard deletion removes the data entirely; anonymization severs the link to the person while keeping non-identifying data, and is only valid if it cannot be reversed.
- How are backups handled in a deletion request?
- Data is deleted from active systems immediately and the request recorded, so a restored backup has the deletion reapplied, while backups expire on a defined schedule.
References
About the author
Mykhailo Boichuk
Co-founder & Vice-President
Mykhailo is an engineer who builds native applications and the systems behind them. He concentrates on macOS and iOS performance, local-first data architecture, and the synchronization problems that come with offline-capable software.