How to Anonymize Data for Privacy Compliance

Key Takeaways:

On 7 July 2026 the European Data Protection Board adopted Guidelines 02/2026 on Anonymisation, providing a practical framework for assessing whether data has been successfully anonymized. Consultation runs until 30 October 2026.

No single technique guarantees complete privacy. Each method covers a specific failure mode and leaves others open, so selection depends on the intended use and the risk profile of the dataset.

k-anonymity protects against identity disclosure but not attribute disclosure; l-diversity and t-closeness close part of that gap; differential privacy provides a formal, composable guarantee.

A 2025 paper showed that k-anonymity combined with epsilon-differential privacy can yield stochastic t-closeness, which supports hybrid privacy models rather than a single-method approach.

Pseudonymized data remains personal data under GDPR, so tokenization and hashing reduce risk without removing obligations.

Understanding Data Privacy Goals and Regulatory Requirements

GDPR and CCPA both focus on the distinction between data that relates to an identifiable person, which is personal data and remains regulated, and data that no longer relates to an identifiable person, which falls outside the regulation. GDPR Recital 26 sets a high standard, exempting only information that “does not relate to identified or identifiable natural person or to personal data rendered anonymous in such manner that the data subject is not or no longer identifiable.” The standard is “no longer identifiable,” not “unlikely to be re-identified,” and the practical test is whether any party with access to reasonably available means could re-identify the subject.

Pseudonymization lies on the other side of that line. GDPR Article 4(5) defines it as processing that makes personal data un-attributable to a data subject without additional information, provided that information is kept separately under technical and organizational measures. The EDPB’s January 2025 guidelines on pseudonymization confirm that pseudonymized data remains personal data, because it can be linked back to an individual by the controller or someone else. Pseudonymization reduces risk and can support a legitimate-interests basis under Article 6(1)(f), but it does not remove obligations.

Guidelines 02/2026 evaluate anonymity from the perspective of each entity for whom the data is intended to be anonymous. The framework tests data against three criteria: no record isolation (no record can be singled out), no linkage (records cannot be connected to other datasets in a way that enables identification), and no inference (attribute values cannot be derived probabilistically, including by AI systems). All three must be met. The guidelines provide a contextual approach that accounts for differences in attacker capability and a simplified approach that ignores those differences for greater compliance certainty.

Key Techniques and Their Practical Applications

The three main anonymization techniques protect against different types of attacks, and their differences determine where each one falls short.

k-anonymity ensures every record is indistinguishable from at least k-1 others on quasi-identifiers such as age, ZIP code, and gender. It is achieved through generalization (exact age to age band, full ZIP to the first three digits) and suppression of rare combinations. If k=5, every combination of quasi-identifiers appears at least five times. k-anonymity prevents singling out, but it does not prevent attribute disclosure: if every member of a k-group shares the same sensitive value, the attacker learns that value even without an identifier. This is the homogeneity attack.

l-diversity extends k-anonymity by requiring each equivalence class to contain at least l distinct values of the sensitive attribute. If a k-group of five patients all share the same rare diagnosis, l-diversity forces the group to carry multiple diagnoses so the sensitive value cannot be inferred from group membership. The trade-off is utility: higher l requires heavier generalization, which reduces the analytical value of the data.

Differential privacy takes a different approach. It adds carefully calibrated noise to a query result or dataset so that the presence or absence of any single individual’s data cannot be reliably detected. Privacy loss is limited by a parameter, epsilon, which allows teams to measure the trade-off between accuracy and disclosure instead of debating it qualitatively. Because differential privacy composes across queries and is immune to post-processing, it holds up in settings where k-anonymity does not.

These techniques are often combined. A paper on evaluating re-identification risk proposes an approach based on k-anonymity and differential privacy together, using generalization and suppression to prevent the dataset from being re-identified through linking attacks more effectively than either method alone.

Tools and Frameworks for Implementation

Implementation usually involves three layers: a data platform that applies the transformation, a governance layer that controls access to the result, and a scripting environment for custom risk analysis.

Odaseva’s Full Sandbox Anonymization application anonymizes personal data in Salesforce sandbox environments, allowing teams to test and develop against realistic data without exposing production records. Immuta for Databricks is a native integration that applies anonymization techniques within the Databricks platform, aimed at teams that need to secure data collaboration across large datasets. Both are used in GDPR-relevant programs, though effectiveness depends on how the transformation is configured and how access to any retained mapping is controlled.

For custom work, the R ecosystem supports k-anonymity, l-diversity, and differential privacy directly, which suits data scientists who need to tune parameters against a specific dataset rather than rely on a platform default. The right choice depends on where the data resides: a sandbox tool solves the testing-environment problem, a platform integration solves the collaboration problem, and a scripting environment solves the custom-analysis problem. Most mature programs use more than one.

Evaluating Re-Identification Risks

Re-identification risk assessment converts the regulatory criteria into repeatable measurements. The evaluation of re-identification risk work cited above frames the goal as preventing the dataset from being re-identified through linking attacks, using generalization and suppression to break the links. A thorough assessment should include:

Which quasi-identifiers are present and how unique their combinations are in the population.
Whether the chosen k or uniqueness metric meets an agreed threshold, and which equivalence classes fall below it.
What auxiliary datasets exist (voter rolls, social media, data-broker records) and whether linkage is feasible.
Whether a machine-learning attacker can infer sensitive attributes from the remaining fields.
Reassessment triggers: new auxiliary data, a new model release, or a change in who can access the data.

Risk changes over time, and a single assessment performed at design time is not enough. Published analyses of event logs have found that potentially all cases in a log could be re-identified through cross-correlation, which is why the EDPB expects controllers to keep anonymization records and reassess after any incident that could enable re-identification.

Choosing the Right Technique: A Decision Guide

The choice depends on one question: do you need to re-identify the data later? If yes, you are doing pseudonymization and the data stays in scope. If no, you are doing anonymization and must clear the three-test bar. The table below maps common objectives to the technique that fits, with the trade-off to manage.

Use Case	Recommended Technique	Why It Fits	Main Trade-off
Operational systems that must later re-identify (fraud, follow-up, audit)	Tokenization with a separately secured vault	Original value is physically separated; breach of the token store alone is low risk	Vault becomes a critical high-risk system and single point of failure
Sharing between teams that must join on a stable key	Keyed hashing with a secret key	Deterministic output lets datasets join without either side exposing raw identifiers	Compromised key re-identifies everything; key rotation forces re-hashing
Publishing aggregate statistics	k-anonymity with l-diversity	Prevents singling out and homogeneity attacks; aligns with regulatory expectations	Generalization reduces granularity; vulnerable to inference in some configurations
Statistical release or model training needing a formal guarantee	Differential privacy with a documented epsilon budget	Composes across queries and resists post-processing; quantifies disclosure risk	Noise reduces accuracy; epsilon tuning is a governance decision
Software testing or model development without real individuals	Synthetic data generation, validated for memorization	No real records in the output if the generator does not overfit	Overfitting can reproduce real records; validation is mandatory

Simple generalization often falls short for high-risk datasets. When the population is small, the quasi-identifiers are numerous, or the sensitive attribute is rare, k-anonymity alone will not pass an inference test, and differential privacy provides a stronger guarantee. The common approach is to layer techniques: tokenize identifiers for operational systems, apply differential privacy to any released statistics, and validate any synthetic training data against the source. Layering addresses the different failure modes each technique leaves open.

Surprising Findings in Privacy Guarantees

The connection between the two dominant privacy models is closer than previously thought. Research on t-closeness and differential privacy finds that the two are strongly related when anonymizing datasets. Specifically, k-anonymity for the quasi-identifiers combined with epsilon-differential privacy for the confidential attributes produces stochastic t-closeness, with t depending on k and epsilon. The reverse also holds under certain assumptions: t-closeness can produce epsilon-differential privacy when t equals exp(epsilon/2) and the assumptions t-closeness makes about the prior and posterior views of the data hold.

This finding is important for practitioners because it shows the choice between the two families is not strictly exclusive. A team that applies k-anonymity to quasi-identifiers and differential privacy to sensitive attributes obtains a stochastic t-closeness guarantee as a byproduct, which is stronger than k-anonymity alone. This supports hybrid privacy models that combine the utility of generalization with the formal guarantee of noise, instead of forcing a choice between them.

Synthetic Data and Tokenization as Supplementary Measures

Synthetic data is created to mimic the statistical properties of a source dataset without reproducing real records, typically using generative adversarial networks or variational autoencoders. It is useful for software testing, model development, and sharing when the source cannot be released. The main risk is memorization: if the generator overfits, its output can reproduce real individuals. Synthetic data must therefore be tested to check whether sampled records match real records too closely, and whether a model trained only on the synthetic data reveals the population statistics too precisely to be considered non-identifying. Treat synthetic output as a hypothesis to test, not an automatic exemption.

Tokenization supports this by replacing a direct identifier with a random token whose mapping to the original value is stored in a separate vault, so the token has no mathematical relationship to the original. Format-preserving tokenization keeps the original format, allowing legacy systems and validation rules to work unchanged. Tokenization is a form of pseudonymization under GDPR, so the tokenized dataset remains in scope, but a breach of the token store without the vault carries significantly lower risk. The vault is a single point of failure and must be treated as a high-risk processing system on its own.

Best Practices and Compliance Checklist

A defensible program follows a consistent sequence. The steps below reflect what regulators and auditors expect to see documented.

Classify every dataset as personal, pseudonymized, or anonymous, and record the basis for the classification. Treating pseudonymized data as anonymous in a data inventory invalidates the legal basis for the processing.
Select the technique by use case, not by convenience. If re-identification is needed, use pseudonymization and keep the data in scope; if not, apply an anonymization technique and test it against the three criteria.
Set and document thresholds. Minimum group size for k-anonymity, distinct values for l-diversity, and the epsilon budget for differential privacy should be explicit decisions, not defaults.
Perform a documented re-identification risk assessment covering quasi-identifiers, auxiliary data, linkage feasibility, and inference. Keep the results.
Protect the key store or vault with separate access controls, because it is the single point that re-identifies the entire dataset if compromised.
Validate synthetic data for memorization before using it in any regulated context.
Schedule reassessment triggered by new auxiliary data, new model releases, or changes in access.

A reasonable preparation timeline is two to four weeks to classify existing “anonymous” datasets against the EDPB tests, one to two weeks to build the re-identification threat model and record the techniques applied, and ongoing reassessment thereafter. Because Guidelines 02/2026 remain in consultation until 30 October 2026, organizations have a window to submit comments, but the underlying legal standard in Recital 26 already applies. The compliance work is not optional pending the final text.

For related work, see our analysis of operationalizing GDPR Article 25 and our overview of anonymization and pseudonymization techniques, which this piece updates against the July 2026 EDPB guidelines. For the encryption and key-management layer that supports tokenization and hashing, see our guide to data encryption best practices.

More in-depth coverage from this blog on closely related topics:

Sources and References

Sources cited while researching and writing this article: