It’s probably healthy to design systems that are build to let people manage their own data though. I think people will slowly start to expect that of you in the future as more and more solutions start to offer it.
In the public sector of Denmark we give people access to all their health data. When I have blood drawn for analysis (not English and I don’t know what it’s called sorry) I can log in and see the results exactly like the doctor sees them. When I’ve been to a doctors consultant and she’s written stuff in my journal I can log in and read it. People are going to want that stuff once they get used to it.
Chances are, that's not the case.
The only notable exception is ad business because "users" are not customers and do not enter any transactions.
The legal basis is actually quite broad. For example, most companies need to keep records for accounting purposes for several years which would count as a lawful basis. Another example would be keeping client data in case you need to protect yourself against potential future litigation e.g. a gym may need to protect themselves against personal injury claims (otherwise you could injure yourself, ask them to delete the records and then sue them).
A legal requirement is "you shall retain these data for N years or face prison time" not "this might be helpful in a lawsuit"
This is covered here[1]
Basically:
* The right to object is not applicable if your processing is based on contract, legal obligation or protection of vital interest
* The right to erasure is not applicable in case of a legal obligation or public interest
[1]https://github.com/LINCnil/GDPR-Developer-Guide/blob/master/...
Yes, you can ask that your avatar image be removed. But they can easily claim that your name, address, bank account number are needed for tax auditing and Know Your Customer purposes.
Also, remember that data subjects have a right to limit the purposes for which their data is used – systems need to be able to cope with that.
This is where a well thought-out and documented approach to personal information makes everything easier, for internal users of that data too. For legacy systems it can be a nightmare because nobody seemed to care, but with a clean sheet, _why wouldn’t you_ address data protection and privacy from the outset?
Easiest way to do this is probably to duplicate data into another table for tax audit purposes, that your "normal" applications have no permission to read. Then you can delete everything your application can access and still keep legal records.
There are several possible legal bases for processing personal data and legitimate interests is one; if legitimate interests wasn't your reason for processing personal data in the first place, then you couldn't rely on it later.
If legitimate interests were the basis for your processing, and a person requested their data be deleted, you have to be able to demonstrate that your legitimate interest overrides their rights. You should probably also demonstrate there aren't other steps you could reasonably take, eg partially deleting or anonymising the data.
I didn't save the link but at least one country's privacy regulator has said that when processing a deletion request you do not have to go through all your backups and remove the data from them too.
If you ever have to do a restore from those backups you will need to re-apply past deletion requests to the restored data before you start using it.
But honestly this is a very minor point, if that's what is keeping you up at night, you are amongst the most compliant ones !
GDPR is mostly about processing user data, not storing them. So user can execute "right to be forgotten", so the data will not be accessible in any way and you are not allowed to process them, however you have full right to keep those data if you believe that this user might show up five years later and try to sue you for a, say, undelivered order, etc.
In that particular case you need to be able to prove that user wanted to delete the data. Otherwise user might sue you that you've deleted those data without agreement and caused some business losses in that way.
Someone third party might also show up and accuse you that you deleted data as a part of conspiracy with the user (think of angry former wives/husbands).
Storage is considered as processing.
But yes, you're right that the Right to Erasure is not absolute.
If you use it to block the user from using your service or punish them in some other way, that might be very problematic in legal sense.
When you receive a deletion request, you must delete the data and stop using it from anywhere you don't have a legitimate reason to continue processing it under one of the reasons for processing personal data without user consent.
Which is easier said than done, because it's against general development practice of having a single copy of any data that you use everywhere without much checking. Instead, you have to either check a flag before using data (do I have consent? Has it been revoked?), or keep several copies of the same data for distinct use (for example, one copy for your app, one copy for legal reasons). The first approach helps you to be able to prove consent. The second approach helps you when you need to archive data past its retention date.
PII is a US legal term and means precisely nothing in the context of the GDPR.
There are also limits placed on this by other laws. For example tax agencies often require companies keep sales records for multiple years. A request for deletion doesn't remove all invoices from sales records with their name on it. I imagine there are more examples, but I think it gives a good indication that GDPR is not where the buck always stops.
If you are a software architect, you need to ask yourself: can I delete a single user data across all my infra easily? If not, you might be in trouble a couple a year later when you are hit with thousands of deletion request and technically can't honor them.
Another side of tech debt I guess!