I was wondering about this because, when you delete data, that space on disk is just marked as "free", but unless it is overwritten, can technically still be accessed.
Are you obligated to zero out customer data when they exercise their "right to be forgotten"?
For real legal advice, consult a lawyer, people in this thread can not e held accountable for the consequences of decisions you make after reading this.
Top comments (7)
Theoretically you probably would have to erase the data completely from the disk. Deleting in legal terms means gone. However in no real world example will be checked if you zeroed out the data or just deleted the pointers to it.
However things are different if you trash the HDD. Then you have to be sure that nothing is accessible anymore.
This is a great example of the single biggest problem with the GDPR. It’s so vague on so many points that it’s impossible to actually comply with it. It’s lazy law making that makes some politicians look good, but then puts the onus of clarifying these details onto the judicial branch, where things will remains ambiguous for many years to come.
I’ll not mention the gross over reach in jurisdiction. Oops; just did.
This is by design. If the GDPR had stated "you must zero out the data on your hard disk", then you couldn't apply it to cloud storage. But the point of this law is your customer's personal data, which can be stored anywhere. So it should be applicable no matter what persistency layer you're using. The GDPR should even work in future with technology that has not been invented yet!
That's why it's so vague. It's a feature, not a bug.
My interpretation is that even if you store data locally you don't need to zero out your hard disk as long as it's not common for you or your company to recover data from your hard disk. However you must make sure to remove customer data in backups, because data recovery from backup is a common way to recover data.
In my world of work, where we process personal data as our main way of providing value, we always try to start with an appropriate assessment of risk: both a privacy impact assessment (en.wikipedia.org/wiki/Privacy_Impa...) that focusses on personal data (aka GDPR compliance) and usually a more generic Threat Model (owasp.org/index.php/Category:Threa...) to cover our business and compliance risk in other areas (such as SoX, PCI-DSS, etc.)
This usually results in a number of concrete controls / mitigations we wish to apply, one of which could be using a tool like shred (en.wikipedia.org/wiki/Shred_%28Uni...) to securely erase data, or more likely to securely erase the encryption keys used to protect data in storage. This works well for 3rd party managed storage like S3, once the keys are gone, it's very expensive to get the plain text back :)
The way I see it, the simplest thing to do is to encrypt all user data with a key that is unique for every user. If the user asks to delete its data, just trash the key and you're done, it's automatically erased from any storage layer or backup you have.
It's just that there is no tools or guides on how to do this (yet ?), but I look forward to databases implementing such things.
I don't know about zeroing the actual disk sectors, I don't think the law is technical like that.
Also most of the data now is on cloud storage or databases which abstract you by design from its physical location.
As I understand it, it is deleted as soon as you can no longer access it.
If it is no longer pratical or reasonable to recover it, you will have done a good enough job.
More of a problem is that the data in question might still exist in backups.
How do you prevent data that has been deleted through a "right to be forgotten" request to reappear when an older backup is restored?