Engineering, production, governance, cost, communication · insight-1285
Treat hashed customer ids as pseudonymous personal data and keep the key apart
- Evidence type
- documented fact
- Difficulty
- medium
- Roles
- ML engineer, Data scientist, Data analyst
- Industries
- cross-industry, e-commerce, banking
Summary: situation, action, reason, boundary
Situation
Emails in a training table are replaced by plain hashes, and the table is called anonymous and sent to a vendor (hypothetical).
Action
Label the table pseudonymised, not anonymous. Use a keyed hash or a token vault whose key and mapping sit in separate, tighter-access storage, and give analysts a controlled join service rather than the mapping.
Reason
GDPR defines pseudonymisation by the separately kept additional information, and its recital treats pseudonymised data attributable with that information as personal data.
Boundary
Training snapshots, analytics warehouses and vendor exchanges holding customer identifiers.
Symptom or risk
Anyone with extra information, or a dictionary of likely emails, can link rows back, so retention, access, deletion and transfer duties still apply to a table described as out of scope.
Exceptions
Data nobody can identify by all means reasonably likely to be used may be anonymous, a legal judgement to take to the privacy owner.
Trade-offs
Separate key storage makes ad-hoc joins slower and needs an owner.
Pitfalls
An unkeyed hash of a guessable value, which a dictionary attack reverses.
Lessons and concepts
Claims and their sources
GDPR Article 4(5) defines pseudonymisation as processing so personal data cannot be attributed to a person without additional information kept separately and protected.
Recital 26 states that pseudonymised data attributable to a person using additional information should be considered information on an identifiable person, judged by means reasonably likely to be used.