> If you back up a list of things to delete is that GDPR compliant? Ponder.
There's little to ponder, that's why I mentioned "entities" rather than "user data." Use unique keys to reference the data rather than sensitive identifiers. The nontrivial part is storing your backup of entities to be deleted in a way that doesn't get destroyed at the same time as the event that forces you to revert to a backup. This now requires a separate storage, backup, and retrieval mechanism to maintain compliance.
The GDPR does not use the term "personally identifying information" anywhere in the text. Using that term suggests that you either haven't read the text or haven't understood it.
"Personal data" (the term actually used in GDPR) means any information relating to an identified or identifiable natural person. The GDPR specifically states that the regulations do not apply to anonymous data. A list of unique keys marked "never restore this data from backups" is not personal data. The data associated with those identifiers is not personal data if it cannot be associated with an identifiable natural person.
You italicized the wrong data here: "Personal data" means any information relating to an identified or identifiable natural person"
Here's how to read it: "Personal data" means any information relating to an identified or identifiable natural person"
The "any information relating to" part is exactly the "unique keys" that you seem to think are not covered. The uniqueness and mapping to a person is literally the problem.
And re: PII, seriously? You're upset because I didn't type out "Personal Data"—even though you knew exactly what I was referring to, as did everyone else? Fight bigger battles…
>"any information relating to" are the "unique keys" that you seem to think are not covered. The uniqueness is literally the problem.
The uniqueness is completely irrelevant unless it identifies someone. If there's no way to trace that unique key back to the identity of a natural person, then it isn't an identifier within the meaning of the GDPR and the data associated with that identifier isn't personal data.
>And re: PII, seriously? You're upset because I didn't type out "Personal Data"—even though you knew exactly what I was referring to, as did everyone else? Fight bigger battles…
It's a highly significant difference. Other legislation talks about "personally identifiable information" - in the US, NIST define a finite list of things that constitute PII. The GDPR talks separately about "personal data" (stuff you know about someone) and "identifiers" (the information that ties the data to a natural person). Lots of stuff that isn't PII is personal data. Data can become personal data through association with an identifier or cease to be personal data through anonymisation. Apropos of nothing, PII isn't necessarily personal data. Without that distinction, large parts of the GDPR are incomprehensible.
I couldn't disagree more with your understanding of the legislation.
If I discovered your company was storing my personal data under "unique keys" that considered by themselves didn't personally identify me, I'd report you to my GDPR regulator immediately.
Unique keys with no personally-identifiable data in the key aren't some sort of innovative workaround that will allow you to store my personal data without my consent. It's not even remotely consistent with the spirit of the law, and IMO, with the plain text of the legislation.
If data is stripped of all identifiers that could be used to associate it with a natural person by any reasonable means, then it isn't personal data. If a unique key could in any way be used to identify a natural person, even indirectly, then it constitutes an identifier and any data associated with it is personal data.
A salted hash of your IP address is an identifier, because it can be used to indirectly identify a natural person. If I see the same IP again, I can hash it with the same salt and check for a match. The IP can then be used to identify you through your ISP's DHCP logs. If I associate the hash value with any other data, then that data becomes personal data.
If I delete the salt value, then it's impossible for me to match the hash to an IP, so the hash ceases to be an identifier. Assuming that the data associated with that hash does not contain any other identifiers, or data that when combined in aggregate could identify a natural person, then it ceases to be personal data.
There's little to ponder, that's why I mentioned "entities" rather than "user data." Use unique keys to reference the data rather than sensitive identifiers. The nontrivial part is storing your backup of entities to be deleted in a way that doesn't get destroyed at the same time as the event that forces you to revert to a backup. This now requires a separate storage, backup, and retrieval mechanism to maintain compliance.