Data anonymization: the complete guide (GDPR, methods, tools)
10 min read
Data anonymization is the process of transforming personal data so that a specific person can no longer be identified — directly or indirectly — by any means reasonably likely to be used. Once data is genuinely anonymized, it stops being personal data, and under the GDPR the rules of data protection no longer apply to it.
This is the hub guide for the topic. It covers the whole landscape at a skimmable depth and links down to detailed posts wherever you need to go deeper.
TL;DR
- Anonymization irreversibly breaks the link between data and a person. The result is no longer personal data (GDPR Recital 26).
- Pseudonymization replaces identifiers reversibly (with a key). The result is still personal data (GDPR Art. 4(5)).
- The legal test is identifiability: could someone re-identify the person using all means reasonably likely to be used — cost, time, available technology included?
- Core techniques: masking, generalization, suppression, k-anonymity, pseudonymization, and synthetic data. Most real workflows combine several.
- Anonymizing one field does not anonymize a record. A postcode + birth date + job title can single out one person.
- For pasting text into AI tools, the simplest compliant path is to remove personal data locally, before it leaves your device — which is exactly what Amaze does.
What is data anonymization?
Anonymization turns identifiable information into information that no longer relates to an identified or identifiable person. The practical effect at the token level looks like this:
Jan Kowalski → [PERSON]
85010212345 → [PESEL]
[email protected] → [EMAIL]
+48 601 234 567 → [PHONE]
The crucial word is irreversibly. If a key, mapping table, or method exists anywhere to reverse the transformation, you have not anonymized the data — you have pseudonymized it. That distinction is the single most consequential idea in this whole topic, and it decides whether the GDPR still applies.
Anonymization vs pseudonymization vs masking
These three terms are used loosely and often interchangeably, but under the GDPR they are not the same thing.
| Term | Reversible? | Still personal data? | GDPR basis |
|---|---|---|---|
| Anonymization | No | No — GDPR no longer applies | Recital 26 |
| Pseudonymization | Yes (with a separate key) | Yes — fully subject to GDPR | Art. 4(5), Art. 25, Art. 32 |
| Data masking | Depends on the method | Depends on whether it’s reversible | A technique, not a legal status |
Masking is a technique (replacing or obscuring values), not a legal category. Depending on how you mask, the result can be anonymous or merely pseudonymous. That nuance trips up a lot of teams.
Go deeper:
- Anonymization vs pseudonymization — the differences under GDPR
- Data masking vs anonymization vs pseudonymization
What does the GDPR actually say?
The GDPR never defines “anonymization” in its articles. It addresses anonymous data in Recital 26, which states that the principles of data protection do not apply to anonymous information — information that does not relate to an identified or identifiable person, or personal data “rendered anonymous in such a manner that the data subject is not or no longer identifiable.”
The test for identifiability, also from Recital 26:
To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person… account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments.
Pseudonymization, by contrast, is defined — in Article 4(5): processing personal data so that it can no longer be attributed to a specific person “without the use of additional information,” provided that additional information is kept separately and protected. Article 25 (data protection by design) and Article 32 (security) both list pseudonymization as a recommended safeguard.
The upshot: anonymous data escapes the GDPR entirely; pseudonymous data does not. Getting this wrong is expensive.
What counts as personal data (PII)?
Before you can anonymize, you have to know what to look for. Personal data — often called PII (Personally Identifiable Information) — is any information relating to an identified or identifiable person. It splits into two useful buckets:
- Direct identifiers — pinpoint a person on their own: full name, national ID (PESEL), email, phone number, passport number.
- Quasi-identifiers — harmless-looking on their own but identifying in combination: postcode, date of birth, sex, job title, employer.
Amaze detects 13 categories out of the box — people, companies, locations, dates, email, phone, PESEL, NIP, REGON, KRS, IBAN, logins, and passwords — including Polish names across grammatical cases.
For a full breakdown, see What is PII (personally identifiable information)?.
What are the main anonymization techniques?
There is no single “anonymize” button in privacy engineering — there’s a toolbox. Most real projects combine several of these.
| Technique | What it does | Example |
|---|---|---|
| Masking / redaction | Replaces a value with a placeholder or token | Jan Kowalski → [PERSON] |
| Generalization | Replaces a precise value with a broader one | age 54 → 50–60; 31-032 → 31-*** |
| Suppression | Removes a value or an entire record | drop a rare, identifying outlier row |
| k-anonymity | Ensures each record is indistinguishable from at least k−1 others | every combination of quasi-identifiers appears ≥ k times |
| Pseudonymization | Reversible replacement of identifiers with a key | 85010212345 → CUSTOMER-0042 + separate table |
| Synthetic data | Generates artificial records that mimic real statistics | a fake dataset with the same distributions |
A few notes worth carrying with you:
- Masking is the workhorse for documents and free text — swap
Jan Kowalskifor[PERSON]and85010212345for[PESEL]. - Generalization and suppression are the two operations that power k-anonymity, the classic dataset model introduced by Latanya Sweeney: a release satisfies k-anonymity if every record shares its quasi-identifier values with at least k−1 others, so no one can be singled out. Sweeney famously showed that 87% of Americans could be uniquely identified from just birth date, sex, and ZIP code — the canonical illustration of why quasi-identifiers matter.
- Synthetic data and pseudonymization sit at opposite ends: one fabricates data that relates to no one; the other keeps a reversible link to real people.
Why anonymizing one field is not enough (re-identification risk)
Removing the name is not the finish line. The combination of quasi-identifiers can re-identify a person even when every direct identifier is gone — this is re-identification risk, and it’s the reason anonymization is judged at the level of the whole record (and the whole release), not field by field.
Before: Jan Kowalski, 31-032, born 1985-01-02, cardiologist, Kraków
After: [PERSON], 31-032, born 1985-01-02, cardiologist, Kraków ← still identifiable
A single rare combination — a specific postcode, a birth date, and an uncommon job title — can point to exactly one person. That’s why k-anonymity, generalization, and suppression exist.
Go deeper: Re-identification risk: why removing the name isn’t enough.
How do you anonymize different kinds of data?
Documents and free text (Word, PDF, email). The dominant technique is masking/redaction: detect names, IDs, emails, and phone numbers and replace them with tokens. The trap is metadata — comments, headers, tracked changes, and file properties often leak what the visible text hid. Find-and-replace is not enough.
Structured datasets (CSV, database tables). Here you reach for generalization, suppression, and k-anonymity across quasi-identifier columns, plus pseudonymization for any identifier you need to retain internally.
National identifiers (PESEL, NIP, REGON, KRS). These are high-signal: a PESEL uniquely identifies a person and reveals birth date and sex. They must be masked to [PESEL], [NIP], and so on — and hashing them is not anonymization, because the number space is small enough to brute-force.
Go deeper: Anonymizing PESEL, NIP, REGON and KRS.
How do you choose an anonymization tool: local vs cloud?
The biggest architectural decision is where the data is processed.
- Cloud tools send your data to servers you don’t control. For anonymization specifically, that’s a paradox: you’d be transmitting raw personal data in order to protect it. It also usually requires a data processing agreement.
- Local / on-device tools process everything on your own machine. The raw data never leaves, so there’s no transfer to account for — the cleanest route to compliance.
This matters most when the destination is a public AI tool. Pasting client data into ChatGPT, Claude, or Gemini sends it to a third party; the safest fix is to strip personal data locally before you paste.
Go deeper: How to anonymize data before ChatGPT, Claude, and Gemini.
Where Amaze fits. Amaze detects and masks PII entirely on your own machine or infrastructure — no data leaves your device, it works fully offline (air-gap ready), and the masking is reversible with a private key you control. It’s the ready-made local app for the “anonymize before you paste” workflow.
Where to go deeper (the full cluster)
This pillar is the map; these posts are the territory.
- Anonymization vs pseudonymization under GDPR — the legal line, reversibility, and when each is required.
- Data masking vs anonymization vs pseudonymization — how the technique maps to the legal status.
- Re-identification risk — why quasi-identifiers defeat naive redaction.
- Anonymizing PESEL, NIP, REGON and KRS — handling Polish national identifiers correctly.
- What is PII? — the full taxonomy of personal data.
- Does GDPR apply to anonymized data? — scope, erasure and retention under Recital 26.
- Reversible anonymization — masking with a private key, and when a two-way workflow is right.
- DPIA checklist — when Art. 35 requires an impact assessment, and how anonymization lowers the risk.
- Anonymization under RODO: UODO requirements — Polish regulator framing and PESEL/NIP/REGON/KRS.
- HIPAA Safe Harbor: the 18 identifiers — the US health-data de-identification checklist.
- Synthetic data vs anonymization — which actually protects privacy, and how each fails.
- Anonymize data before ChatGPT, Claude, Gemini — the practical AI-tool workflow.
FAQ
Is anonymized data covered by the GDPR? No. Under Recital 26, data protection principles do not apply to anonymous information that does not relate to an identified or identifiable person.
What’s the difference between anonymization and pseudonymization? Anonymization is irreversible and takes the data outside the GDPR. Pseudonymization is reversible with a separate key, and the data remains personal data fully subject to the GDPR (Art. 4(5)).
Is data masking the same as anonymization? Not necessarily. Masking is a technique; whether the result is anonymous or merely pseudonymous depends on whether it can be reversed. See data masking vs anonymization vs pseudonymization.
Is hashing a national ID number anonymization? No. Hashing is deterministic and the space of ID numbers is small enough to brute-force, so at best it’s pseudonymization.
Do I have to anonymize data before using ChatGPT or Claude? If you have no data processing agreement covering that use, removing personal data first — ideally locally, before it leaves your device — is the simplest route to compliance. See the AI-tool guide.
Is anonymizing a single field enough? No. A record can still be identifiable from the combination of quasi-identifiers even after every direct identifier is removed. See re-identification risk.
Amaze detects and masks personal data — including Polish identifiers like PESEL, NIP, REGON, and KRS, and Polish names across grammatical cases — entirely on your own machine, before any text reaches an AI model. See how it works.