Data Anonymization: Techniques and GDPR Rules - Blog

Data anonymization is the process of transforming personal data so that the people it describes can no longer be identified, by you or anyone else, using the means reasonably likely to be used. Under GDPR, truly anonymous data falls outside the regulation (Recital 26), while data that can still be linked back to a person with additional information is pseudonymized and remains personal data. Most datasets described as "anonymized" in test and analytics environments are in fact pseudonymized, and the difference has legal consequences.

What data anonymization means

Anonymization is an outcome, not a single technique. A dataset is anonymous when the chance of identifying someone from it is sufficiently remote, taking into account who can access it, what other data they hold, and the cost and effort of linking records. The UK ICO describes identifiability as a spectrum and frames the test around a "motivated intruder": a competent person with ordinary resources who wants to identify someone.

Regulators judge whether anonymization has worked against three risks:

Singling out: can you isolate one person's records, even without knowing their name?
Linkability: can you connect records about the same person, within a dataset or across datasets?
Inference: can you deduce a new fact about someone with reasonable confidence?

Removing names is rarely enough. Latanya Sweeney's analysis of 1990 US Census data estimated that 87% of the US population was likely unique on just three attributes: 5-digit ZIP code, gender and date of birth. Those quasi-identifiers sit in almost every customer, patient and employee table.

Data anonymization techniques

Most anonymization programs combine several of the techniques below. Each reduces identifiability; none guarantees anonymity on its own.

Generalization

Reduce precision. Exact ages become 10-year bands, dates of birth become years, full postal codes become districts. Generalization lowers uniqueness, but it also removes analytical detail and can break application rules that expect a complete value.

Suppression

Remove values, columns or whole records that are too identifying: the only 104-year-old customer in a region, a rare job title, a free-text comment field. Suppression is blunt, but it is the most reliable fix for rare combinations.

k-anonymity

A dataset is k-anonymous when every record shares its quasi-identifier values with at least k-1 other records, so each person hides in a group of at least k. It gives you a measurable target, usually reached through generalization and suppression. It does not prevent inference when everyone in a group shares the same sensitive value, which is why extensions such as l-diversity exist.

Noise and perturbation

Add random noise to numbers and dates, or swap values between records, so individual values are no longer accurate while totals and averages stay close. Differential privacy formalizes this: it measures how much any one person's data can change an output and calibrates the noise to a defined privacy budget.

Synthetic data

Generate new records that follow the statistical patterns of the original without copying any real row. For testing, synthetic data is often the most useful option because records stay complete and realistic. It is not automatically anonymous: some generation methods are vulnerable to model inversion and membership inference attacks, and rare records are the most exposed, so assess the method before relying on it.

Anonymization vs pseudonymization under GDPR

GDPR Article 4(5) defines pseudonymization as processing personal data so that it can no longer be attributed to a specific person without additional information, provided that information is kept separately and protected by technical and organizational measures. Tokenization, keyed hashing, encryption and consistent masking that keeps a mapping table all fall into this category.

Recital 26 draws the line between the two:

Pseudonymized data is personal data for anyone who can attribute it to a person using additional information. GDPR applies, although pseudonymization is recognized as a privacy-by-design and security measure under Articles 25 and 32.
Anonymous data is outside GDPR, but only if identification is not reasonably likely, considering factors such as cost, time, available technology and technological developments.

Three points are often missed. First, the assessment depends on context. In EDPS v SRB (C-413/23 P, September 2025), the EU Court of Justice held that pseudonymized data should not be regarded as personal data in all cases and for every person; for a recipient with no reasonable means of re-identification, it may not be. For the organization that holds the additional information, it remains personal data. Second, anonymizing personal data is itself processing, so the anonymization step needs a lawful basis. Third, other regimes use different tests: HIPAA treats health information as de-identified only through Safe Harbor (removing 18 types of identifiers) or Expert Determination under 45 CFR 164.514(b), as summarized on our HIPAA test data page.

Re-identification risk: why anonymized data often isn't

Re-identification usually happens through linkage, not by breaking cryptography. We cover real-world cases in how weak anonymization became a privacy illusion. The common failure modes are:

Quasi-identifiers left intact. Names are removed, but date of birth, postal code and gender stay.
Deterministic tokens shared across datasets. The same token for the same customer everywhere is useful for joins, and equally useful for linking.
Unsalted hashes. Hashing an email address or national ID without a secret key can be reversed by hashing a list of candidate values and comparing.
Free text. Notes, comments and ticket descriptions carry names, account numbers and health details that column-level rules never see.
Rare records. Extreme salaries, ages or transaction sizes identify people even after generalization.

Treat anonymization as a risk assessment you repeat when the data, the recipients or the available auxiliary data change, not as a permanent property of a file.

How to anonymize test and analytics data

Test data and analytics data need different trade-offs. Analysts need accurate aggregates. Testers need valid formats, working joins and realistic edge cases. A workable process for both:

Discover. Scan schemas and sample values to find direct identifiers, quasi-identifiers and sensitive fields, including custom tables and free-text columns.
Decide the target. Pseudonymization is often appropriate for internal test environments, where it reduces risk and supports Articles 25 and 32. Aim for anonymization when data leaves your control, for example when it goes to an external vendor or into a published dataset.
Choose techniques per field. Use format-preserving replacement for identifiers that applications validate, generalization for quasi-identifiers in analytics, and synthetic generation where no real record is needed.
Keep relationships consistent. The same original value should map to the same replacement in every table and system, or joins and end-to-end tests break.
Remove or isolate the keys. If no mapping table or secret survives and re-identification is not reasonably likely, the output may qualify as anonymous. If a key survives, treat the output as pseudonymized personal data.
Test and document. Check how many records are unique on quasi-identifier combinations, re-scan the output for residual real values, and record the assessment.

Documents need anonymization too

Personal data in PDFs, scanned forms, emails, chat logs and call transcripts is still personal data. It is harder to anonymize than tables because identifiers appear in context ("her son Tom, who attends the school on Mill Road") and inside images. Effective document anonymization:

runs OCR on scanned pages before detection;
combines pattern matching for values with a known shape, such as card numbers, with context-based detection for names and addresses;
replaces values in the file itself rather than drawing boxes over text that remains underneath;
keeps one replacement per person across every document, email and table in a batch.

Rich text is rarely anonymous after masking alone. Treat masked documents as pseudonymized data with access controls unless a documented assessment shows otherwise.

How Synthesized helps

Synthesized masks, subsets and generates test data for databases and enterprise applications. Data masking replaces personal data with realistic values and gives each original value one replacement, so keys and joins keep working across connected systems. Where you need records with no real person behind them, synthetic generation creates production-like data from your schema. For PDFs, Word files, emails, chats and transcripts, unstructured data masking applies the same policy to documents, runs in your cloud, on-premises or air-gapped, and re-scans output before release. The GDPR test data page maps these steps to Articles 4(5), 25 and 32.

FAQ

Is anonymized data subject to GDPR?

Not if it is truly anonymous. Recital 26 says GDPR does not apply to information that no longer relates to an identifiable person, judged by the means reasonably likely to be used, including cost, time and available technology. If anyone, including you, could reasonably re-identify individuals, for example by holding a key or linking other data, the data is pseudonymized and GDPR still applies.

What is the difference between anonymization and pseudonymization?

Pseudonymization replaces identifiers so data cannot be linked to a person without additional information, such as a token map or key, that is kept separately and protected (GDPR Article 4(5)). It remains personal data. Anonymization removes any reasonably likely means of identification. Pseudonymization is reversible by design for whoever holds the key; anonymization should not be reversible by anyone.

Is data masking the same as data anonymization?

Not necessarily. Masking is a set of techniques; anonymization is an outcome. Consistent masking that keeps a mapping table or uses a secret key is pseudonymization. Masking can contribute to anonymization when no key survives, quasi-identifiers are also treated and re-identification is not reasonably likely, but that has to be assessed and documented rather than assumed.

Can synthetic data be considered anonymous?

Often, but not automatically. Synthetic records generated without copying real rows generally do not relate to real people. Risk returns when a generation model reproduces rare records, or when synthetic rows are seeded from real identifiers. Assess the generation method, check the output for near-copies of real records, and treat it with care until that check is done.

What Is Data Anonymization? Techniques, GDPR Rules and Risks