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.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
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 :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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 :)