Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: How are you implementing GDPR-compliant soft deletes?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 86 posts

Re: Ask HN: How are you implementing GDPR-compliant soft deletes?

#11

Post by snowwolf »

Soft deletes as you describe aren't allowed under GDPR.

But a possible solution may be to disassociate the data from the customer (as long as the data itself isn't considered 'personal data'). For example, if the reason the data falls under GDPR is because it is connected to the customers email address, you could clear the email address. But that wouldn't let you ever re-associate it. But you could maybe (but don't take my word for it) one way hash the email address (bcrpyt, etc.) and if a dispute arises in the future scan the hashes for a match of the person raising the disputes email address in order to re-associate the data.

Re: Ask HN: How are you implementing GDPR-compliant soft deletes?

#12

Post by raverbashing »

pan69 wrote: post #7
gtsteve wrote: post #3

Another 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.

How would that help? Would you set time created to zero?

Re: Ask HN: How are you implementing GDPR-compliant soft deletes?

#13

Post by jakozaur »

jjoergensen wrote: post #5

Deletion of backup-data is also an interesting topic

The law itself was written by someone unaware of that. A lot of interpretations:

1. The most extreme, go back to all of your backups and delete them too.

2. You don't need to do anything, if you do not touch the backups and truly treat them for disaster recovery.

3. Your backups need to have reasonable retention (e.g. two year) and way to apply post requests after recovery.

4. A lot of in between.

5. My personal interpretation is that in first year of GDPR there will be so many companies that are not even trying to be compliant. Any companies showing any reasonable efforts will be just left alone and at worst heard some recommendations. Of course ad-tracking companies might get screwed, but their business model seems to be incompatible with GDPR.

Also right to erasure can be tricky (e.g. what if you keep records for support/warranty purpose). What you should do if someone exercise their right to be forgotten and than ask you for refund.

Re: Ask HN: How are you implementing GDPR-compliant soft deletes?

#14

Post by politelemon »

snowwolf wrote: post #11

Soft deletes as you describe aren't allowed under GDPR. But a possible solution may be to disassociate the data from the customer (as long as the data itself isn't considered 'personal data'). For example, if the reason the data falls under GDPR is because it is connected to the customers email address, you could clear the email address. But that wouldn't let you ever re-associate it. But you could maybe (but don't t…

This is the guidance we have been given as well.

It'll depend on the kind of data you're talking about. If you are obligated to keep that data for legal purposes then there's no working around that. But then make an effort to only keep exactly the data you need.

However in the context you're asking - absolutely do delete where possible. If not possible then pseudo-anonymization is a way of dealing with this.

Re: Ask HN: How are you implementing GDPR-compliant soft deletes?

#15

Post by samsari »

snowwolf wrote: post #11

Soft deletes as you describe aren't allowed under GDPR. But a possible solution may be to disassociate the data from the customer (as long as the data itself isn't considered 'personal data'). For example, if the reason the data falls under GDPR is because it is connected to the customers email address, you could clear the email address. But that wouldn't let you ever re-associate it. But you could maybe (but don't t…

My understanding, as someone implementing the GDPR-compliance for my company right now, is that if you could produce the same one-way hash a second time from the same input email address then the hash is still considered PI.

Re: Ask HN: How are you implementing GDPR-compliant soft deletes?

#16

Post by ZenoArrow »

jakozaur wrote: post #13
jjoergensen wrote: post #5

Deletion of backup-data is also an interesting topic

The law itself was written by someone unaware of that. A lot of interpretations: 1. The most extreme, go back to all of your backups and delete them too. 2. You don't need to do anything, if you do not touch the backups and truly treat them for disaster recovery. 3. Your backups need to have reasonable retention (e.g. two year) and way to apply post requests after recovery. 4. A lot of in between. 5. My personal inte…

In what world is two years worth of backups required for reasonable retention? Either the backups are tiny or the company involved has got more money than sense. I'd see no reason, in any company, for backups to be held for longer than 6 months, and that would be an outside estimate (many companies could get away with only having a couple of months worth of backups).

Re: Ask HN: How are you implementing GDPR-compliant soft deletes?

#17

Post by tyfon »

samsari wrote: post #15
snowwolf wrote: post #11

Soft deletes as you describe aren't allowed under GDPR. But a possible solution may be to disassociate the data from the customer (as long as the data itself isn't considered 'personal data'). For example, if the reason the data falls under GDPR is because it is connected to the customers email address, you could clear the email address. But that wouldn't let you ever re-associate it. But you could maybe (but don't t…

My understanding, as someone implementing the GDPR-compliance for my company right now, is that if you could produce the same one-way hash a second time from the same input email address then the hash is still considered PI.

Yep, we've been through this discussion where I work just a few days ago and one way hashing even with salt is _not_ compliant as you can search for whatever you hashed and get a hit (SSNs, emails etc).

Re: Ask HN: How are you implementing GDPR-compliant soft deletes?

#18

Post by tyfon »

ZenoArrow wrote: post #16
jakozaur wrote: post #13

Earlier quoted context omitted.

The law itself was written by someone unaware of that. A lot of interpretations: 1. The most extreme, go back to all of your backups and delete them too. 2. You don't need to do anything, if you do not touch the backups and truly treat them for disaster recovery. 3. Your backups need to have reasonable retention (e.g. two year) and way to apply post requests after recovery. 4. A lot of in between. 5. My personal inte…

In what world is two years worth of backups required for reasonable retention? Either the backups are tiny or the company involved has got more money than sense. I'd see no reason, in any company, for backups to be held for longer than 6 months, and that would be an outside estimate (many companies could get away with only having a couple of months worth of backups).

In Norway you need to keep accounting data for ten years to be compliant with accounting laws so I you lose eight of them you would be in violation.

Edit: I see you mean retention, I guess if you discover after a year that your backup routine is malfunctioning and you need older backups but that is not that common I'd guess.

Re: Ask HN: How are you implementing GDPR-compliant soft deletes?

#20

Post by snowwolf »

samsari wrote: post #15
snowwolf wrote: post #11

Soft deletes as you describe aren't allowed under GDPR. But a possible solution may be to disassociate the data from the customer (as long as the data itself isn't considered 'personal data'). For example, if the reason the data falls under GDPR is because it is connected to the customers email address, you could clear the email address. But that wouldn't let you ever re-associate it. But you could maybe (but don't t…

My understanding, as someone implementing the GDPR-compliance for my company right now, is that if you could produce the same one-way hash a second time from the same input email address then the hash is still considered PI.

Fair point.

I can see the purpose of "right to be forgotten", but I think in some circumstances it is going to be abused. Any service that "bans" users for fraudulent/abusive activity and stores data about the banned user to prevent them from creating new accounts is going to have a problem. Banned user can just request to be forgotten and then create a new account. Unless there is some exception within GDPR that will support this use case.

Post reply on HN