> Most early-stage startup use the best practice of “delete=1”
Honestly that's a bad best practice if the data your collecting is sensitive, which PII is.
Honestly that's a bad best practice if the data your collecting is sensitive, which PII is.
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.
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.
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.
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"
And what if the PII is stored in a blockchain? Then what?
No clue. But I can't wait for that to be tested, because I'm very curious what the solution will turn out to be.
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...
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.
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"
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.
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.
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.
You don't need to actually delete the row, just overwrite the information which you no longer have consent to store...
This is obvious isn't it?