Historically, yes.
But don't the GDPR and CCPA et al. create liability around failure-to-delete after receiving a request?
But don't the GDPR and CCPA et al. create liability around failure-to-delete after receiving a request?
update users set deleted=true where uid=123345;
GDPR and CCPA etc made it easy to send a request for deletion that will most probably be a frontend gimmick. How much effort are they really going to put into going back in their backups and deleting all your entries? I'm pretty sure it must be the lowest roadmap priorities.
And it's amazing how financial liability has a way of getting things on a VP's feature radar that common sense doesn't.
The reason it was haphazardly handled prior was that there was no liability. Who cared? (legally speaking)
From working inside a T25 American retail company, I can say that we went top-to-bottom and rearchitected for traceability and hard deletes as a result of the CCPA.
If I ask Google to delete my data (EU citizen), I have trouble believing that they actually go through all of their cold storage backups where it was stored and make sure it's erased. At best I could believe that the process is designed in such a way that my soft-deleted data is unlikely to be recovered (intentionally or not) and maybe unlikely to be possible to link to my account.
Since the key is not used for end to end encryption, and backends still have access to the data (as long as the key lives), it has different requirements on how it needs to be protected. The biggest challenge is backing up the key itself, as losing it means losing access to all the user’s data by design. But backing up and obliterating a single key is much, much easier than doing so for a whole set of loosely associated data across many databases.
There is no end to end encryption involved here, so you don’t need to resort to such voodoo as homomorphic encryption.
Also, is an encrypted piece of data with a lost key truly deleted? What if the encryption gets cracked?
I would say it is more deleted than toggling a `deleted` flag in the db and less deleted than burning the tapes in fire.
I mentioned that: It makes the problem much smaller, as you only have one single, small piece of data to backup and and erase, instead of an ever-changing many-faceted blob of distributed data.
> Also, is an encrypted piece of data with a lost key truly deleted? What if the encryption gets cracked?
Oh boy. If simple symmetric encryption gets “cracked”, then you have much larger problems.
> I would say it is more deleted than toggling a `deleted` flag in the db and less deleted than burning the tapes in fire.
For all practical purposes symmetrically encrypted data that lost its keys is considered “random” data. If you “erase” data on a device before you sell it, most often it will just throw away the key to the disk contents nowadays.
There is generally an expectation that data may be retained in backups for a specified retention period, but will not be used or restored. Beyond that, it is up to the regulator to determine if this is meets the standard, but it's worth noting that there are notions baked into the text and the interpretations of the text of GDPR that account for reasonable costs and efforts.
Auditors can and do test and monitor for this, both using audit processes and demanding evidence, and by performing manual testing and experimentation.
Maybe some mom-and-pop shop would bodge it, but any serious business has legal council and wisely listens to them.
83(5) GDPR, the fine framework can be up to 20 million euros, or in the case of an undertaking, up to 4 % of their total global turnover of the preceding fiscal year, whichever is higher.