It's not clear how to implement 'right to be forgotten' inside backed-up data, too.
We can already achieve that result by removing records from the live DB and ignoring the whole backup situation.
So what has this separate encryption process achieved?
Even if your business does have the understanding and technical ability to do it, it adds a whole extra layer of complexity and unreliability to what used to be simple, plain text logs -- exactly the kind of information you probably need to access quickly and reliably if you're in the middle of fixing a major fault, for example.
But do you need to keep them forever? If you delete logs after 30 days you are unlikely to be impacted anyways.
We also have backups going back on a staged basis, more frequent backups from the recent past, less frequent going back further. This has been useful more than once for retrieving older information that someone had accidentally modified or deleted and not noticed immediately, so is also demonstrably useful for legitimate business purposes.
Both of these appear to be at risk of conflict with the right to erasure under GDPR, in that for example old backups of emails will inevitably contain customer correspondence that can't readily be isolated.
The trouble is that the definition of PII could be interpreted so broadly as to include almost anything useful ever logged on a server, because if a log record references any data that could be associated with a specific individual, including in combination with other data, then it counts. Given what we already know about de-anonymisation of supposedly anonymous data sets, even just based on quite simple patterns and correlations in the data, any approach based on pseudonymisation is likely to be simplistic and open to challenge.
In any case, what is reasonable for a business to want to do with that sort of data? Can we analyse which content has been most popular on a web site over the past week/month/year/decade? Can we analyse which content a particular paying customer has been accessing, in order to promote a new plan as they approach a limit or suggest a more cost-effective one if they aren't using what they're paying for right now? Can we analyse access patterns for an account over a period of time to detect shared use of an account contrary to our terms? There are plenty of legitimate business purposes for which you might want to know the entire history of access for a particular account and which do not violate the privacy of the user in any unjustified or unfairly exploitative way, but again, any method based on log pseudonymisation will immediately fail to satisfy those requirements.
Nothing about this discussion is even remotely as clear and straightforward as some in this discussion are suggesting.
Most businesses with personal data also have invoices. Since you don’t have to destroy those, simply note their request there.
Other kinds of personal data like marketing leads and medical data should be much easier to see how to forget.
If someone sends you something in the post telling you to delete their data, it should not be difficult to simply keep that record available when you need to restore an unrelated machines backup, unless you have incompetent IT.
This is part of the reason many GDPR consultants suggest applying an IT standard like ISO so that it’s clear you already know what backups are for and how to use it.
A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible.
And to then restore to a point in time before the software or hardware bugs occurred, no?
> A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible.
Um what? There are ton of good reasons to stick to a single DB, it’s not unreasonable at all. The main one being that it massively simplifies ensuring data integrity compared to a distributed system. Also it’s just easier for a small team to manage.
For example:
If someone sends you an email asking to be deleted, why would you store that email in the DB and nowhere else? Your team would read the email then update the database.
After a crash, if you then restored a backup, why wouldn't you be able to review your last days email (since the last backup) for any updates? Of course you would. Even small teams could.
"Who's IT?" -- Small and micro-businesses across Europe
This is part of the reason many GDPR consultants suggest applying an IT standard like ISO so that it’s clear you already know what backups are for and how to use it.
"We can't even afford a GDPR consultant. And who's IT?" -- Small and micro-businesses across Europe
A single machine/database with all your business data on it mixed with personal data and the only record of requests from subjects is criminally irresponsible.
Again, this is simply detached from the reality of many, many small and microbusinesses, community organisations, non-profits, etc.
It's absurd to think that every organisation that has reasonable need to handle personal data has a dedicated IT team, the people and budget to drop a few thousand on professional advice, the budget to buy extra equipment that isn't otherwise needed, etc.
It's also absurd to think that without those things, an organisation can't take reasonable precautions to protect that data or prevent its exploitation for illegitimate purposes.
Unfortunately the GDPR (as often happens with EU legislation) makes little allowance for any of this and thus imposes absurdly disproportionate overheads on smaller organisations.
But the photographer that hosts her website and help forms on wix[1] isn't going to have any problems. The local restaurant using viewtouch PoS and a facebook page isn't going to have any problems[2].
[1]: https://support.wix.com/en/article/general-data-protection-r...
[2]: https://www.facebook.com/business/news/facebooks-commitment-...
Very few real people will have any problems, because the GDPR is fundamentally about tradeoffs: If you have a lot of personal data, you need to protect it and inform the subject what you do with it. If you can't afford to protect it and think that the subject wouldn't want you doing what you're doing with their data, then you probably shouldn't have that personal data.
And process bugs/defects. And human error. Human error such as, for example, 'delete all of Mr. Smith's records.'