Pseudonymization

The core mechanism of pseudonymization is the separation of direct identifiers (name, email, social security number) from quasi-identifiers (age, zip code, occupation).

• Direct identifiers are replaced with a pseudonym or token
• Quasi-identifiers remain in their original form to preserve analytical utility
• The mapping table linking pseudonyms to real identities is stored separately with strict access controls

This separation reduces linkability but does not eliminate re-identification risk when quasi-identifiers are combined with auxiliary data.

Pseudonyms can be generated using various cryptographic primitives, each offering different security properties:

• Hash-based pseudonyms: One-way SHA-256 or BLAKE3 hashes of the original identifier, optionally with a secret salt to prevent rainbow table attacks
• Tokenization: Randomly generated tokens stored in a secure vault, providing no mathematical relationship to the original value
• Format-preserving encryption (FPE): Encrypts identifiers while maintaining the original data format and length, useful for legacy system compatibility
• Deterministic vs. probabilistic: Deterministic methods always produce the same pseudonym for a given input, enabling consistent record linkage across datasets

Pseudonymized data remains personal data under GDPR because re-identification is possible. Key risk factors include:

• Quasi-identifier uniqueness: Combinations of attributes like date of birth, gender, and postal code can uniquely identify 87% of the U.S. population when linked to public records
• Auxiliary data availability: Attackers may possess external datasets that enable record linkage
• Pseudonym persistence: Using the same pseudonym across multiple datasets creates cross-context linkability
• Inference attacks: Machine learning models trained on pseudonymized data can still infer sensitive attributes through correlation patterns

Effective pseudonymization requires ongoing risk assessment rather than a one-time transformation.

These two techniques are fundamentally different in both mechanism and legal status:

• Pseudonymization is reversible under controlled conditions; the data remains personal data subject to GDPR
• Anonymization is intended to be irreversible; successfully anonymized data falls outside GDPR scope
• True anonymization is extremely difficult to achieve in practice due to the mosaic effect, where combining multiple anonymized datasets can reconstruct identities
• Pseudonymization is explicitly encouraged by GDPR as a technical safeguard that can reduce breach notification obligations and demonstrate compliance

Regulators increasingly view robust pseudonymization as a practical middle ground between full identifiability and the elusive goal of perfect anonymization.

In AI/ML workflows, pseudonymization enables privacy-preserving model training while maintaining data utility:

• Training data preparation: Direct identifiers are stripped and replaced before data enters the training pipeline
• Feature engineering: Quasi-identifiers can still be used as model features, but pseudonymization prevents the model from memorizing specific identities
• Federated learning integration: Pseudonymization complements federated approaches by adding an additional layer of protection before local data contributes to global model updates
• Limitations: Pseudonymization alone does not prevent model inversion attacks or membership inference; it must be combined with differential privacy or other techniques for robust protection

This technique is particularly relevant for healthcare and financial ML applications where complete anonymization would destroy essential signal.

Effective pseudonymization requires more than just technical transformation—it demands a comprehensive governance framework:

• Access control: The pseudonymization mapping table must be stored in a separate, hardened system with role-based access and audit logging
• Key management: Cryptographic keys or salts used in pseudonym generation require secure rotation policies and hardware security module (HSM) protection
• Data lifecycle management: Pseudonyms should be rotated or deleted when data retention periods expire
• Re-identification protocols: Documented, approved procedures for when and how re-identification is permitted, typically limited to specific legal or clinical justifications
• Continuous monitoring: Regular re-identification risk assessments as new auxiliary datasets become publicly available

A privacy property ensuring each released record is indistinguishable from at least k-1 other records with respect to quasi-identifiers (attributes like ZIP code, age, gender).

• Prevents re-identification by grouping similar records
• Common implementations: generalization (replacing specific values with ranges) and suppression (removing outlier records)
• Limitation: Does not protect against homogeneity attacks where all k records share the same sensitive value
• Example: A dataset where every combination of ZIP code, age, and gender appears at least 5 times achieves k=5 anonymity

A de-anonymization technique that links pseudonymized or anonymized records back to specific individuals by correlating quasi-identifiers with auxiliary external data sources.

• Attackers cross-reference attributes like birth date, gender, and postal code against public records
• The famous Netflix Prize dataset was re-identified using IMDb reviews as auxiliary data
• Demonstrates why pseudonymization alone is insufficient when quasi-identifiers remain intact
• Mitigation requires combining pseudonymization with k-anonymity or differential privacy

A mathematical framework providing provable privacy guarantees by adding calibrated noise to data or model outputs. Unlike pseudonymization, DP ensures the removal or addition of a single record does not statistically change observable results.

• Parameterized by epsilon (ε) — lower values indicate stronger privacy
• Implementations include Laplace mechanism for numeric queries and exponential mechanism for categorical outputs
• Provides a formal privacy budget that quantifies cumulative information leakage
• Used by the US Census Bureau and tech companies for public data releases

A core privacy principle under GDPR Article 5(1)(c) dictating that data collection and processing must be limited to what is strictly necessary for a specified purpose.

• Reduces the attack surface for model inversion and re-identification
• Complements pseudonymization by eliminating unnecessary quasi-identifiers before they enter the system
• Requires purpose specification before collection begins
• Example: An e-commerce site collecting only shipping address and payment info, not browsing history, for order fulfillment

The process of creating artificial data using generative models (GANs, diffusion models, VAEs) that retains the statistical properties of a real dataset without containing actual individual records.

• Goes beyond pseudonymization by removing all one-to-one mappings to real individuals
• Enables safe sharing of data for model training and testing
• Risk: May still leak training data characteristics if the generative model overfits
• Used in healthcare and finance where direct identifiers cannot be exposed under any circumstances

The fundamental balancing act between the strength of a privacy-preserving mechanism and the resulting accuracy or usefulness of the data or model output.

• Pseudonymization preserves high utility but offers weaker privacy than DP
• Differential privacy provides strong guarantees but degrades query accuracy as epsilon decreases
• K-anonymity protects against re-identification but may lose granularity through generalization
• Engineering decision: Choose the technique matching your threat model and data utility requirements