The idea: Customer requests account or item deletion, you set it to "deleted" in DB without actually deleting it and it helps for documentation purpose should the dispute arise over some issue in future.
Ask HN: How are you implementing GDPR-compliant soft deletes?
1–10 of 86 posts
Re: Ask HN: How are you implementing GDPR-compliant soft deletes?
#2I don't think "soft deletes" are actually allowed, are they?
https://gdpr-info.eu/art-17-gdpr/
> the controller shall have the obligation to erase personal data without undue delay
Re: Ask HN: How are you implementing GDPR-compliant soft deletes?
#3Another pattern you might consider is setting an expiry date on a database row. You only show values where the expiry date is null. Every night you have a cronjob or some other process that deletes all objects that have expired.
Re: Ask HN: How are you implementing GDPR-compliant soft deletes?
#4[deleted]
Re: Ask HN: How are you implementing GDPR-compliant soft deletes?
#5Deletion of backup-data is also an interesting topic
Re: Ask HN: How are you implementing GDPR-compliant soft deletes?
#6What would be the sort of dispute you envisage?
Re: Ask HN: How are you implementing GDPR-compliant soft deletes?
#7Another pattern you might consider is setting an expiry date on a database row. You only show values where the expiry date is null. Every night you have a cronjob or some other process that deletes all objects that have expired.
You probably already add a "time created" column/field to each row/document (at least, I personally do this to all data I store in a database).
If you want to expire something, you can now easily calculate it and you can even easily change the timeout/lifespan without having to update the data in the database.
Re: Ask HN: How are you implementing GDPR-compliant soft deletes?
#8Deletion of backup-data is also an interesting topic
I believe (not a lawyer, etc.) that you don't have to delete from existing backups as long as you have a process to immediately wipe the customer details again if that backup is restored (and before any other processing can happen.)
[edit to clarify that you wipe the customer details]
Re: Ask HN: How are you implementing GDPR-compliant soft deletes?
#9Another pattern you might consider is setting an expiry date on a database row. You only show values where the expiry date is null. Every night you have a cronjob or some other process that deletes all objects that have expired.
Not sure that would comply with the "without undue delay" requirement unless you always set the expiry date to be today and then you might as well just wipe them immediately.
Re: Ask HN: How are you implementing GDPR-compliant soft deletes?
#10Deletion of backup-data is also an interesting topic
The way I'm handling it (probably non-compliant) is to store a list of the internal keys we use for people in a list as GDPR requests come in.
If I restore a backup it will go via this list and ensure that content in my backups which are keyed to deleted accounts are never restored.
In theory we have the data, but it's never reachable by internal systems. -- Anything else is essentially compromising the integrity of a backup.