[sb8244]

I'm not sure. I think this is a very absolutist and probably naive way to look at it, frankly.

For a simple example, let's say you use an immutable data store. What do you do if a customer wants every info about them redacted, but you did something like store their IP, name, or email. All common things. Now you must build mutability into your store and all assumptions that used to be made can be removed.

This is just a very small piece of something that even a small or medium company may be using or doing.

[robin_reala]

You encrypt the data before it’s stored with a unique key, then destroy the key when the user requests it.

Doesn’t help for pre-GDPR data but that’s the way you should be building going forwards.

[reynoldsbd]

"We could have done it this way." doesn't pay the bills (or in this case, doesn't prevent steep fines).

[robin_reala]

Sure, it’s always painful to fix existing systems. In the future it should be no more expensive than business as usual though.

[sb8244]

Will this satisfy GDPR requirements fully? What if that key had somehow been involved in an unknown leak in the past (of just the keys) and then the data is exposed somehow in the future?

Leaks are punished, as they probably should be, under gdpr anyways. But now do we have to account for all of the keys over time and have it be probably gone? What if we take backups of the systems that stores the keys? Do we have to purge those backups as part of the deletion request? What if they're terabytes in size?

Just thinking through edge cases here

[eadmund]

> You encrypt the data before it’s stored with a unique key, then destroy the key when the user requests it.

That makes selects & joins on the data quite a bit more complex. Per-record & per-subject keys are … tricky.

[s73v3r_]

Right, but you had assumptions built into your data store before, namely that you could keep all info about someone for eternity, and that you'd never have to correct it.