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

21–30 of 86 posts

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

#21

Post by pan69 »

raverbashing wrote: post #12
pan69 wrote: post #7

Earlier quoted context omitted.

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?

Rather than having an expire date, with a creation time you can e.g. delete everything older than 1 day, or what ever. I.e. you don't hard code the expire time in the data itself. If you want to change the timeout to 2 days it's a change in your delete logic, not your data.

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

#22

Post by jakozaur »

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

If you have a lot of data, keeping backups for too long can be costly. But a lot of datasets are small (e.g. few GB) which makes keeping backups for really long time cheap enough.

If you're datastore is small (e.g. SQL table), but supersensitive (E.g. financial data), you may want to keep backups for really long and on medium that doesn't allow easy modifications (e.g. tapes or AWS Glacier).

I know some government (e.g. Poland social security) keep several backups in many locations for many years just as a redundancy.

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

#23

Post by CamperBob2 »

chesimov wrote: post #6

What would be the sort of dispute you envisage?

Government: "You know that data you were required to delete when $(USER) requested to be forgotten? We require you to provide it in connection with our ongoing investigation of $(USER)."

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

#24

Post by Ezku »

> it helps for documentation purpose should the dispute arise over some issue in future.

If you are required to hold on to the data for legal purposes such as dispute settlement, there is no issue. The customer can request you delete such data but you have no obligation to do so. Issues arise when holding on to the data is no longer "necessary". At that point soft deletion is not enough and you must be able to remove personal data regarding that customer from your systems. Source: IP lawyer I talked with last week on this.

From what I can tell, one good way of going about this in case you really do not want to throw away data – such as when you're doing event journaling – would be to have all personal data encrypted. When the data reaches its expiration point or is requested for deletion, throw away the decryption key and all you're left with is is the metadata which you are allowed to hold on to for purposes of running your business.

EDIT: This concept is called 'cryptographic deletion'. Here's one whitepaper on the subject. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.397....

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

#25

Post by moviuro »

tyfon wrote: post #18
ZenoArrow wrote: post #16

Earlier quoted context omitted.

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.

backups and archive are a different matter. Archives are meant to not be altered; ever (WORM disks[0]). Backups are made to be rewritten, ~~lost~~, or used for restoration.

[0] https://en.wikipedia.org/wiki/Write_once_read_many

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

#26

Post by eb0la »

Consult your Data Protection Officer first.

GDPR says you must delete information about the customer; but there are cases where you still might need to have that data available.

If your customer can interact with another one inside your app/platform, he/she can commit a crime, and you might be required by court (and by law) to disclose some information (even conversations! inside the platform).

Setting something to "deleted" might not be the best way to do the actual soft delete.

Sometimes you can "delete" that user moving it to a separate part of an LDAP branch (where nobody except someone with authority can access).

In other cases, you can add the "deleted" flag on the table. If so, MAKE SURE your app access the data from a view of the table where the 'deleted' users are not present. Even better: partition the underlying table based on the "deleted" field to physically separate active and deleted users.

But whatever you do, ask your Data Protection Officer first.

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

#28

Post by andriesvh »

Ezku wrote: post #24

> it helps for documentation purpose should the dispute arise over some issue in future. If you are required to hold on to the data for legal purposes such as dispute settlement, there is no issue. The customer can request you delete such data but you have no obligation to do so. Issues arise when holding on to the data is no longer "necessary". At that point soft deletion is not enough and you must be able to remove…

Are you sure about throwing away encryption keys is sufficient to be GDPR complient? Does this comes from IP lawyer as well?

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

#29

Post by pc86 »

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.

Do you know how you are supposed to handle disputes in the future? If I ask that all my information be deleted and I say n months later I was charged for something I never received, how does the company disprove that?
Post reply on HN