Anonymization vs pseudonymization and key handling
precise grasp of two privacy techniques and key management.
anonymization is irreversible and exits GDPR scope; pseudonymization is reversible via a separated key; secure that key in a KMS with strict access.
WHAT THIS TESTS The interviewer wants a crisp technical and regulatory distinction, then a realistic key-management design, because longitudinal studies require re-linking the same person across sessions while staying compliant.
A GOOD ANSWER COVERS Anonymization irreversibly removes the ability to identify an individual, even by the data holder, through techniques like aggregation, generalization, or k-anonymity guarantees; properly anonymized data falls outside GDPR. Pseudonymization replaces direct identifiers with artificial tokens but keeps re-identification possible for anyone holding the separate key or mapping, so it remains personal data and stays in scope, while reducing risk. For a longitudinal study, you need a stable per-participant pseudonym so repeated sessions join correctly. Generate it via a keyed hash (HMAC) of a real identifier, or a lookup table mapping participant to token. Store the de-linking key or mapping in a separate datastore from the research data, encrypt it at rest using a key held in a managed KMS, grant access to a minimal set of roles, log every access for audit, and define when the key is destroyed to convert the dataset to effectively anonymous.
COMMON WRONG ANSWERS Claiming the two terms are interchangeable. Asserting pseudonymized data is exempt from GDPR. Storing the mapping table in the same database or repo as the data. Using an unsalted hash of an email, which is trivially reversible by guessing.
LIKELY FOLLOW-UPS How do you handle a participant's deletion request when data is pseudonymized. Why is unsalted hashing weak. How does key rotation interact with stable pseudonyms. When can pseudonymized data be treated as anonymized.
ONE CONCRETE EXAMPLE For a six-month diary study, each participant's email is HMAC-hashed with a secret key to produce a stable token like p_8f3a used across all sessions. The HMAC key and any email-to-token table live in a separate, KMS-encrypted vault accessible only to the research lead, with access logged. To honor a deletion request, the lead removes that participant's mapping entry, severing re-identification.
Read the original → ico.org.uk
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.