> Someone says "delete me and my purchases", so you do, and oops - total book sales are now wrong.
Erase the name and address fields from the user in the database. You don’t have to delete any line, and that person doesn’t have any personal info in your database anymore. Problem solved.
Two days later the customer files a chargeback with their credit card company and the credit card company wants you to provide documentation for the transaction.
Credit card company is not a government. It's helpful for business purposes to have records, but it's not always a legal requirement.
Anyway this stuff is super complicated and there's no rollback for data that was mistakenly deleted and shouldn't have been, so the point is there are layers and layers of complications and scenarios and it's not as simple as everyone likes to make it out to be. It's not impossible, but it's definitely a lot of difficult work.
IF my understanding is correct, you can actually keep a denormalized version of user information (name, shipping info etc) and still be compliant, assuming you do not use that billing information for any purpose other than billing.
The "right to erasure" isn't as strict as the "right to be forgotten" -- You (the end-user) would need to prove that merely having your name and address in billing records violates your right to privacy. And to make that argument you'd have to provide evidence the business is using said information for purposes other than billing.
Personal data can be used lawfully to "fulfill contractual obligations with a data subject" (eg: fulfilling a purchase, and retaining information for warranty/returns/RMA etc purposes) and "To perform tasks at the request of a data subject who is in the process of entering into a contract with the controller.
" and "For the legitimate interests of a data controller or a third party"
"Anonymizing" would be replacing each user's PII with a value that's unique to that user. Instead, you could just blank it out or overwrite with universal "data removed because of GDPR" token.
That highly depends on the DB used. If you're using a log structured database, it's possible the original data could still be there. Immutable databases that never delete or overwrite entries exist.
And what if the PII is stored in a blockchain? Then what?
Someone says "delete me and my purchases", so you do
In many cases, that will be your mistake. The right to erasure is not absolute, and if you need to keep those records for a good reason -- for example, as evidence to support tax returns or defend chargebacks -- then you are entitled to refuse to delete them and to continue processing them for the necessary purposes. Otherwise mortgages would suddenly become a very fast way to send lenders under, since everyone could just demand they delete all identifiable records of who owes them money...
I couldn't agree more. The rules about erasure are full of holes like this. So are the rules about legitimate interests. And those represent, respectively, probably the most significant new subject right and probably the most common lawful basis for processing that isn't strictly necessary for some sort of legal compliance.
No, if you say you need the information for tax purposes (say) then the user will complain to the data protection authorities. These authorities will then accept or reject the complaint, and if accepted will help you to come into compliance.
The trouble is, that's an assumption on your part, and it might not be a valid one. We have no idea yet how 28 different regulatory authorities will handle this sort of situation, or how much of an effort they will expect controllers and processors to make on their own if they are to receive the benefit of the doubt. And even if everything you assume proves to be correct, any formal interaction with authorities is stressful and expensive for a small business with limited time and resources available, and being confident that you aren't doing anything wrong in the first place is obviously preferable.
Not necessarily. The performance of contract basis under the GDPR is for contracts with the data subject. You can't just agree a contract with some arbitrary third party and use that to circumvent any subject rights you don't like.
For data processing purposes like this, you will normally have to rely on the legitimate interests basis. That's the one with the almost entirely non-specific definition, combined with the almost entirely non-specific balancing requirements.
With a case like defending an unjustified chargeback, we might assume that the interest is surely both legitimate and overriding, but even that is only a personal view and not something any regulator has explicitly addressed in guidance, as far as I'm aware. In any case, plenty of other scenarios won't be so black and white.
If a user requests deletion, assign anyYassociated entities (eg purchases, conversations etc) to an anonymous user. Or, keep the original user record and just blank all of the fields. You've had two years to think about these problems.
What about if you need to report any payouts made to an individual as required by a tax authority? How are you also supposed to delete all their information and be in compliance with tax law? You can't say, "I paid <ANONYMOUS> 12,152.00" in 2018.
Edit:
Ok, looks like there is a clause for these scenarios:
"However, the further retention of the personal data
should be lawful where it is necessary, for exercising the right of freedom of expression and information, for
COMPLIANCE WITH A LEGAL OBLIGATION, for the performance of a task carried out in the public interest or in the
exercise of official authority vested in the controller, on the grounds of public interest in the area of public
health, for archiving purposes in the public interest, scientific or historical research purposes or statistical
purposes, or for the establishment, exercise or defence of legal claims."
Then there's:
"It should not
apply where processing is based on a legal ground other than consent or contract. By its very nature, that right
should not be exercised against controllers processing personal data in the exercise of their public duties. It
should therefore not apply where the processing of the personal data is necessary for compliance with a legal
obligation to which the controller is subject or for the performance of a task carried out in the public interest or
in the exercise of an official authority vested in the controller."
And, in terms of technical burden at least it seems like they try to alleviate it somewhat...
"The data subject's right to transmit or receive
personal data concerning him or her should not create an obligation for the controllers to adopt or maintain
processing systems which are technically compatible"
It’s only a strawman if you assume that everybody knows the right way to do everything. There was nobody around when I did my start up to tell me how to do all of this stuff.
The entire point of GDPR is that it creates a set of requirements, and allows you to make decisions in your professional judgement to fill those requirements. This is no different to how management in any software company will present business requirements for the software you are to make, and request that you decide the technical implementation. That's your job if you're a developer.
As long as you're confident enough in your PII solution to be willing to present it in front of other software developers who have been called as expert witnesses and declare that it meets the GDPR requirements, you can pick any "right way" you like to meet those requirements.
If you think it's an unreasonable burden to have to make PII handling solutions that are robust enough that you can honestly defend them in court if challenged, maybe you shouldn't be handling PII. Like, at all.
I’m not confident in anything I’ve written ever to have it picked apart by a team of expert witness programmers. Maybe that means I have no business working at a startup. Maybe we should think about the implications of that.
>I’m not confident in anything I’ve written ever to have it picked apart by a team of expert witness programmers.
Then you shouldn't be handling PII, any more than you should be handling credit card details, genetic information or military intelligence.
>Maybe that means I have no business working at a startup. Maybe we should think about the implications of that.
The EU has, and has decided that having seen the alternative, it would rather just not have the startups. I think that's a reasonable position to take.
> Maybe we should think about the implications of that.
A good thing because it means startups stop playing fast and loose with my data. These are just growing pains. In a few years, enough stuff will be written online about best practices to stay GDPR compliant. The new guys can follow that.
> Part of creating a business is figuring out how to do things that won't get you sued into oblivion.
The harder that gets, the fewer businesses there will be.
If you look at businesses that managed to exist, sure, you'll see stories of how they used their "innovative entrepreneurial spirit" to triumph over every obstacle. Hurrah! What you won't see are the companies that just barely weren't able to exist, the ones that didn't quite make it through every hoop -- and it is this unseen cost that should keep every regulator up at night.
> The harder that gets, the fewer businesses there will be.
And at what point is it more important to have more businesses than it is to have more businesses that treat consumers fairly? Usury laws have eliminated some companies, reigning in student loan companies would probably eliminate a few more. But that's a balance deemed worth it because usury is predatory and harmful. Profiting by being lazy and sloppy with people's personal information where the risks (e.g. identity theft) are huge isn't a particularly well balanced justification for "more businesses above all else".
Someone says "delete me and my purchases", so you do, and oops - total book sales are now wrong.
There's ways around it, obviously. But they are not easy. Much easier to just mark as deleted.
Another example: Threaded conversation - someone deletes their post, and oops all the replies are now orphaned.