My impression from all that I've heard is that you should have a backup retention policy, but otherwise there's no set upper bound on how long that may be. Not that the text of the GDPR breathes a word of it, though, everything's just a rat's nest of exemptions suggested by various authorities and other parties that haven't been tested in court.
There's a lot of complainig around how difficult that can be and the fact that EU legislation in general often does not like to precisely prescribe its requirements like what reasonable means, which can indeed be annoying.
You still need to remove it either directly or your retention policy for backups needs to be short enough that keeping it in backups for a while is judged as reasonable.
Nor do I see why I should particularly listen to what you say on this topic, given that others have similarly claimed authority from their lawyers or from their local jurisdictions.
> The second one linking to Verasafe's page on which it clearly says that yes, you should delete it.
Right before the "But don’t panic! Enforcement authorities know how difficult it is to fulfil this obligation in practice." section, where it elaborates on your ability to claim that stripping data from backups is technically infeasible, in which case you must promise to delete the data on restoration. Just like I've heard from everyone else.
It's always seemed paradoxical to me that the GDPR is branded as this unyielding hammer against companies improperly storing your data, only for it to be riddled with amorphous holes on every axis. "Data is data, period, unless it's not on a live production system, in which case the written vague rules it abides by are swapped out for a new set of totally undefined rules!"
> You still need to remove it either directly or your retention policy for backups needs to be short enough that keeping it in backups for a while is judged as reasonable.
And how might I know a priori what's the longest 'reasonable' retention term that a business might be permitted by its jurisdiction? The whole nature of backups is that they're useless right up until they aren't, so the marginal value of each additional week is difficult to measure in the first place. And when most concrete talk of 'reasonableness' is seemingly done behind closed doors if at all, I have no idea just how far other jurisdictions' ideas of a reasonable term might differ from mine.
Also, I think it's easy to misstep if we start thinking of it as a problem of "better regulators", since some of the blame lies on deeper legal-aspects around (data-)ownership, contracts, and what what happens in bankruptcies.
Even a company with great intentions may have difficulty ensuring the promises they made are kept long-term, especially if a bankruptcy court voids those promises in the name of repaying creditors.
What I do expect is my data is deleted from the production database and thus won’t be in any future backups/logs/etc. I guess to that end, they would need to keep a record of delete requests to re-delete them if they ever need to restore from backup.
If there is a data breach in a year where the company’s user data ends up on the internet, I expect to not be in that user list.
In a perfect world there would be some way to snap your fingers and delete it from every system - but we do not live in a perfect world. There is absolutely no incentive to build systems with this kind of requirement in mind. It's a waste of time and effort. Europeans will say "but hey wait! GDPR!" meanwhile the world keeps spinning and no one gives a shit.
Some data scientist who wasn’t even supposed to be able to view stuff managed to copy data from prod to dev, maybe by accident. Then an engineer who intended to be testing an in place transform pipeline actually wrote a copy elsewhere, maybe once for each test, and didn’t even notice. This stuff happened off and on for like fifteen years while projects and people all changed and no one cares, because sure there’s some vague gestures in the direction of compliance, security, and privacy but it’s just a token effort because anyone who really starts asking questions is let go for not being a team player.
Syncing updates to some “main” copy won’t make it easy to delete dupes.
Why a prod db with sensitive user info is being used in testing is a whole separate issue. Those can be deleted in their entirety.
But don't the GDPR and CCPA et al. create liability around failure-to-delete after receiving a request?
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. update users set deleted=true where uid=123345;
23andme didn't implement strong customer identity and auth mechanisms, for example, and it cost them ~$30M to settle their data breach liability [1]. Take action, keep receipts, and failing good faith actions, step back while regulators and the legal system whack whack whack with a hammer.
[1] https://news.ycombinator.com/item?id=41536494 ("HN: 23andMe settles data breach lawsuit for $30M")
But the not the death of your data. That will be sold onto someone else.