In our system, the biggest piece of PII is email addresses. I did not work on our GDPR solution, but my understanding is we have a system where data flows into our log aggregators and email addresses (or any other PII) are scrubbed and replaced with a hash. In our persisted logs (used for analytics and all that), there is only a hash and no email address. In the event that someone needs access to the pre-hashed value, first a request must be approved, and then access granted to a lookup table. If a user has requested we remove their information, the look up hash returns something to that effect.
If the data is anonymised when collected you can't follow through with the right to erasure as they're should be nothing uniquely identifiable for that user.
Otherwise you have to do it on request, either by email or form submission or link; automated or manually as you will have 24 hours to follow through with the request. I'd keep track of these requests just in case you need to restore a backup where their data still exists, to notify them and delete their data again from the backup.
I love seeing the same lie repeated over and over: You do not have to delete them from backups. Anyone wasting time on "rewriting backups" should be fired from their job.
You just need a process in place so you don't restore those same users if ever restoring backups.
Interesting. I’ve spent a fair bit of my life lately looking at this problem and come to the opinion that anyone trying to systematically prevent deleted users from being restored should be fired.
Different strokes I suppose.
Can we agree at least that you have to account for deletion in your backup strategy?
My understanding is that you can refuse to comply with erasure if it's for a "legitimate business purpose." Every company has a legitimate business purpose for backups that aren't kept indefinitely.
In our system, the biggest piece of PII is email addresses. I did not work on our GDPR solution, but my understanding is we have a system where data flows into our log aggregators and email addresses (or any other PII) are scrubbed and replaced with a hash. In our persisted logs (used for analytics and all that), there is only a hash and no email address. In the event that someone needs access to the pre-hashed value, first a request must be approved, and then access granted to a lookup table. If a user has requested we remove their information, the look up hash returns something to that effect.
If the data is anonymised when collected you can't follow through with the right to erasure as they're should be nothing uniquely identifiable for that user.
Otherwise you have to do it on request, either by email or form submission or link; automated or manually as you will have 24 hours to follow through with the request. I'd keep track of these requests just in case you need to restore a backup where their data still exists, to notify them and delete their data again from the backup.
I'm just taking all my contact info out of my site's footer so lawyers can't reach me.
...but really, no idea. Im likely just going to put a contact form in and handle any requests manually.
You might try changing the contact details to a location that is hard to reach - say the Central African Republic.
I'm quite curious about this myself...
I would like to extend the question by asking the owners of event-sourced systems how they handle it.
In my case, we will have to do manuell, software-assisted deletions
Mostly by email. Hopefully it won’t have to scale :)
It's quite easy for me.
I don't use any piece of shit like Google Analytics, or tracking services, so that's already a plus.
I don't collect anything I don't explictly need on my users, it's easier to manager, more secure and will make it easier to handle those new laws.
That's great, but totally non-responsive to the question.
Right of erasure means you have to delete them on request.
From backups too...
I love seeing the same lie repeated over and over: You do not have to delete them from backups. Anyone wasting time on "rewriting backups" should be fired from their job.
You just need a process in place so you don't restore those same users if ever restoring backups.
Interesting. I’ve spent a fair bit of my life lately looking at this problem and come to the opinion that anyone trying to systematically prevent deleted users from being restored should be fired.
Different strokes I suppose.
Can we agree at least that you have to account for deletion in your backup strategy?
You should account for deletion, but in general this stuff doesn't keep me up at night.
In the rare event you restore deleted users, and even rarer, if they actually notice, just tell them you screwed up.
My understanding is that you can refuse to comply with erasure if it's for a "legitimate business purpose." Every company has a legitimate business purpose for backups that aren't kept indefinitely.