Agree, this is pointless. For one thing how many companies have the technical ability to remove specific records from all their database backups and logs? None that I’ve worked at
I’m not expecting my data get deleted from old backups or log files. I can see where that would be an issue.
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.
The problem is - imagine microservices - that data does not exist in one spot. And chances are no one actaually knows 100% where the data lives. It probably lives in a prod db, an ETL data lake type platform (or two/three - and god knows if that has any kind of identifier to actually delete it) and chances are if you are big enough some 3rd party systems. So even if you delete it from prod, it still exists somewhere.
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.
I don't understand. If they want the ability to ever update the data how do they expect to have it propagate if these information systems aren't connected? And if they are connected, why would 'delete entry' be harder than 'update entry'?
You’re assuming the data is actually handled with care, and lives in a system designed for this sort of thing, but it’s probably not.
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.
Not being able to delete every possible record that may have been used during testing doesn’t mean they shouldn’t delete the data they do know about in the main system. If I can change my username, password, or email address… and those functions work. A delete should also work.
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.
The big scary fine is a absolutely an incentive, unless you are huge company with an army of lawyers on standby. Some customers I've worked with submit GDPR requests on behalf of their users to all of their software vendors; there're even SaaS products for doing exactly that. They also get you to sign documentation to that extent if you want to keep them as a customer.
Not that anyone is disagreeing, but it bears repeating: This is a lack of any real pressure from regulators, not a technical challenge. Or rather, there may be technical challenges but they absolutely can be overcome, and aren’t being tackled right now very simply because the business doesn’t care. As is so often the case, the business must be made to care.
> This is a lack of any real pressure from regulators, not a technical challenge.
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.
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.
In general I don't particularly care what other people say on this topic and rely on the legal guidance I received during my work from UK ICO and Slovenian office, but even some of your links don't collaborate you. The second one linking to Verasafe's page on which it clearly says that yes, you should delete it.
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.
> In general I don't particularly care what other people say on this topic
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.
On the other hand very few organizations I have worked at could definitely restore backups (at least it was not tested regularly) and logs will eventually roll off.
