8.2 De-identification and Privacy Risks: Pseudonymity, Anonymity, and Differential Privacy

Removing names and email addresses only eliminates direct identifiers. Time, location, occupation, device information, and behavioral patterns can still uniquely point to an individual. The more comprehensive external datasets become, the easier it becomes to re-identify individuals.

Pseudonymization Preserves Linkability

person_id 42 → random pseudonym 7f8c...
mapping table stored independently and strictly authorized

Pseudonymization reduces the risk of direct identification during everyday use, enabling identity rotation and role separation. However, as long as an organization or other party can reassociate identities through the mapping table, stable patterns, or auxiliary data, the data remains subject to personal data processing.

Do not use unencrypted hashes for small-space identifiers like email addresses: attackers can enumerate common inputs. If stable tokens are required, use controlled keyed constructions, purpose-bound separation, and rotatable mapping services. Sharing the same stable pseudonym across different datasets increases cross-database linkage risks.

Anonymization Is a Conclusion About Reasonable Re-identification Risk

Anonymization is not a single function name; it's a risk assessment derived from the data itself, the way it's published, the attacker's capabilities, and the potential for future auxiliary information. Common attack vectors include:

• Singling out: Combining fields to uniquely identify a single record;
• Linkability: Associating records across datasets to identify the same individual;
• Inference: Inferring sensitive attributes from non-sensitive fields;
• Membership inference: Determining whether a specific individual is present in the dataset.

Models like k-anonymity can help identify quasi-identifiers, but they cannot alone address issues such as attribute homogeneity, background knowledge, or differential risks across multiple releases. A dataset may appear anonymous in isolation, but when combined with other data, re-identification risks can still emerge.

Risk mitigation strategies include generalization, binning, suppression of rare combinations, sampling, aggregation, and controlled query environments. Data utility and risk must be evaluated through real-world analytical use cases, rather than by counting deleted columns alone.

Differential Privacy Limits Individual Marginal Impact

Intuitively, adding or removing a single record should not significantly alter the probability distribution of the published output. The mechanism uses privacy budget parameters ε (and, in some definitions, δ) to control the upper bound of information leakage.

Differential privacy is not "just add noise." Implementation requires:

1. Defining adjacent datasets and protected units, such as a row, a user, or a household;
2. Limiting how many times a single entity can contribute and the range of values they can provide;
3. Computing the sensitivity of each query;
4. Selecting a provably private mechanism;
5. Combining query results across multiple queries and consuming the privacy budget accordingly;
6. Protecting the privacy budget ledger, original data, and query interface.

If the same statistic is published daily without accounting for compositional loss, an attacker can average out the noise. ε is not a universal "safe threshold" across products, it must be tailored to the use case, population risk, publication frequency, and acceptable utility.

Aggregated Data Can Also Harm Groups

Even when individuals cannot be identified, statistical results may lead to discrimination, exclusion, or price manipulation against certain small groups. Privacy risk assessments should ask:

Which data actions could cause problems for individuals or groups?
What is the likelihood and severity of those impacts?
What value does the organization derive from processing the data?
Can the use, granularity, access, or retention be modified to reduce risk?

This differs from a purely security threat model: an organization executing data processing may have full authorization, yet the harm still stems from the nature of the data handling itself.

Model and Analysis Environments Require Independent Review

Deleting training data does not automatically remove it from trained models. Models may retain rare samples, and embeddings or feature stores might leak sensitive relationships. It's essential to document dataset lineage, training objectives, versions, access patterns, retention policies, and strategies for retraining or retirement. These should be accompanied by testing for membership inference, model inversion, and output-sensitive information disclosure.

A controlled research environment should employ minimal data views, prohibit raw data exports, enable query auditing, and require output disclosure reviews. Downloading anonymized data en masse to all analysts undermines future control and the ability to perform combined or follow-up analyses.

Risk Assessment Evidence

• What are the direct and quasi-identifiers, and what auxiliary data is externally available?
• Are pseudonym mapping and token keys independently protected and rotatable?
• Are unique combinations, rare cohorts, and multi-release scenarios tested before deployment?
• Is differential privacy clearly defined in terms of protection units, contribution bounds, and budget ledger?
• Do data, features, models, and derived statistics maintain lineage?
• Can access patterns shift from raw data downloads to controlled queries?
• When are risk conclusions re-evaluated due to new data or emerging attack capabilities?

The next chapter integrates these design constraints into the delivery pipeline, enabling security and privacy validation to run repeatedly with every change.

References

• NIST, De-Identification of Personal Information
• NIST, Privacy Engineering Program
• NIST, Differential Privacy Guidelines