Pseudonymization
Pseudonymization makes records less directly attributable to a person without separate information, such as a protected mapping table. Under the EU GDPR definition, that additional information must be kept separately with safeguards. The process preserves a link that distinguishes it from a claim of anonymization.
How it works
A workflow might replace customer IDs with randomly assigned tokens and protect the mapping in a separate system. Stable tokens can preserve sequences over time without putting names in the working dataset. Access to the mapping, token generation, and cross-dataset reuse all affect the protection.
Simply hashing predictable identifiers can leave records vulnerable to guessing or matching. Other attributes in the dataset can also identify a person even when the main ID has been replaced.
Why it matters for licensing
Pseudonymization may help a recipient analyze relationships or workflows with reduced exposure to direct identifiers. It does not automatically authorize licensing or remove applicable privacy obligations. The sharing arrangement needs to address the mapping, linkage, downstream access, and remaining identifying attributes.
Example
Fictional example: A support team substitutes random customer tokens in a process-analysis dataset and stores the mapping separately. It also reviews narrative fields because a customer’s name may still appear inside a support note.
Limitations and misconceptions
Pseudonymized data is not automatically anonymous. Removing the mapping does not guarantee anonymity if other details support identification. The appropriate controls depend on the recipient context, intended task, and applicable legal standard.
Questions to ask
- Who can access the mapping or recreate the link?
- Do stable tokens or other attributes enable cross-dataset matching?
- Which remaining privacy obligations and controls apply?
Sources
- EU GDPR — Articles 4–6 and Recital 26 · Accessed
- NIST SP 800-188 — De-Identifying Government Datasets · Accessed