Retention, Hashing, and De-identification

Companies want to study their own history and show numbers to investors. The raw rows are often personal data. Two techniques get used, and they are not the same thing.

Pseudonymisation swaps a name for a token. “Tunde Bello” becomes “User_XY921,” and a separate key can turn the token back into Tunde. Because the key exists, the curriculum source treats the result as still personal data. Protect it accordingly.

Anonymisation is the irreversible version. If nobody can get back to a person, privacy rules fall away. Teams often claim anonymisation when they have only dropped the name and kept a device identifier. Ask what else is in the row.

Passwords

Hashing is a one-way function. The password the user typed is not stored. A later login hashes the new attempt and compares the results. Staff should not be able to read the password back, because there is nothing to read. If a breach note says “passwords were exposed” and they were properly hashed, the sentence is different from a note about passwords stored in clear. Check which one is true before you draft either sentence.

Purge scripts

The Act’s working idea, as this course uses it, is that personal data is not kept longer than the purpose needs. A notice that says inactive accounts go after three years is a promise about a program. Engineers keep that promise with a purge script: a job that runs on a schedule, finds the rows, and deletes or anonymises them. Your job is to make the number in the notice the number in the job. A notice of three years and a script of never is a false notice.