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.
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"
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...
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.
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?
