Data masking vs anonymization vs pseudonymization — what is the difference?
7 min read
Data masking is a technique for hiding sensitive values; anonymization and pseudonymization are legal outcomes defined by the GDPR. The same masking tool can produce either result — the deciding factor is whether the original values can still be recovered. Static, irreversible masking usually gives you anonymization; dynamic or deterministic masking that can be reversed is, at best, pseudonymization.
TL;DR
- Data masking — an umbrella technique that replaces real values with realistic or placeholder stand-ins. Not a GDPR term. Comes in two flavours: static (permanently alters a copy) and dynamic (obscures on the fly at query time).
- Anonymization — a GDPR outcome: identification is irreversibly impossible, so the data leaves the scope of the regulation (Recital 26).
- Pseudonymization — a GDPR outcome: identifiers are replaced but can be reversed with separately held additional information; the data remains personal data (Article 4(5)).
- The bridge: masking is how you do it; anonymization and pseudonymization describe what you legally end up with.
This post extends our deeper 2-way treatment, anonymization vs pseudonymization, to the third term people constantly confuse with them.
Is data masking the same as anonymization?
No. Data masking is a method; anonymization is a legal status of the resulting data. Masking is one way to reach anonymization — but only if it is irreversible and no key or lookup table survives anywhere.
Masking replaces sensitive values with fictitious-but-realistic or placeholder values so that data can be used safely in a context where the real values are not needed — testing, analytics, sharing, or pasting into an external AI tool. Whether the masked output is anonymous or merely pseudonymous depends entirely on reversibility:
- If there is no way back to the original values → the outcome can be anonymization.
- If a key, mapping, or algorithm can restore the originals → the outcome is pseudonymization, and the data stays personal data under the GDPR.
What are static and dynamic data masking?
Data masking is usually split into two operating models:
- Static data masking (SDM). A masked copy of the dataset is created, and sensitive values in the copy are permanently replaced. The original production data is untouched; downstream users only ever see the masked copy. Common for populating test, development, training, and analytics environments. Because the transformation is permanent and (if done right) unrecoverable, static masking is the model most often used to anonymize.
- Dynamic data masking (DDM). The original data stays intact in the source system, and masking rules are applied in real time when the data is queried — different users or roles see different levels of detail. Since the underlying real data still exists and can be revealed to authorised users, dynamic masking is inherently reversible, which maps it onto pseudonymization, not anonymization.
There is also deterministic masking: the same input always maps to the same masked output (Lynne → Denise everywhere). This preserves referential integrity across tables, but because the mapping is consistent and repeatable, it is a form of pseudonymization — a consistent pseudonym is still a pseudonym.
Comparison: data masking vs anonymization vs pseudonymization
| Criterion | Data masking | Anonymization | Pseudonymization |
|---|---|---|---|
| What it is | A technique | A legal outcome | A legal outcome |
| Reversibility | Depends (static ≈ irreversible; dynamic/deterministic ≈ reversible) | Irreversible | Reversible (with separately held key) |
| Data status | Depends on how it is applied | No longer personal data | Still personal data |
| Does GDPR apply? | Depends on the result | No (Recital 26) | Yes, in full |
| Basis in GDPR | Not a GDPR term (a means; cf. Art. 32 security measures) | Recital 26 | Art. 4(5), Art. 25, Art. 32 |
| Typical use | Test/dev data, analytics, role-based access, sharing | Publishing, statistics, AI training, open datasets | Internal analytics, testing with re-linkage, risk reduction |
| Example | Jan Kowalski → [PERSON] or → Denise Ford | Jan Kowalski → [PERSON], no way back | Jan Kowalski → ID-8241 + separate mapping table |
The single row that matters most: data masking is the only “technique” in the table. The other two describe the legal state of the data after you apply a technique — which is why a vendor claiming a tool “anonymizes” is really claiming its masking is irreversible in practice.
Where does data masking fit under the GDPR?
The GDPR itself does not use the phrase “data masking.” Its two operative terms are:
Anonymization — addressed in Recital 26: the data protection principles do not apply to anonymous information, i.e. information that does not relate to an identified or identifiable person. Identifiability must be judged against all means reasonably likely to be used, considering cost, time, and available technology.
Pseudonymization — 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 by technical and organisational measures.
So masking is best understood as an implementation detail — a technical measure (the kind Article 32 calls for) that, depending on how it is configured, lands you at one of GDPR’s two defined outcomes. Static, keyless, irreversible masking → anonymization. Dynamic or deterministic masking with recoverable originals → pseudonymization.
A crucial caveat carries over from the 2-way post: masking one field does not anonymize the record. A postcode, a date of birth, and a job title can single out one person even when the name is gone. Real anonymization has to be assessed against the whole record and realistic re-identification attempts — see re-identification risk.
Before / after: what masking looks like on real identifiers
Using placeholder-style masking (the approach that aims for anonymization):
Jan Kowalski→[PERSON]85010212345→[PESEL][email protected]→[EMAIL]NIP 521-30-51-000→[NIP]
Using deterministic / reversible masking (pseudonymization — a key or mapping exists):
Jan Kowalski→ID-8241(with a separate lookup table)85010212345→CUSTOMER-0042(recoverable from a secured mapping)
Same starting data, two very different legal outcomes.
Which one do you actually need?
- You need the data to leave the GDPR regime (publishing, open datasets, keeping data past its retention period, pasting into an external AI tool without a data processing agreement) → aim for anonymization via irreversible, keyless masking.
- You need to re-link later (support, billing, longitudinal research, populating a test environment that mirrors production) → pseudonymization via reversible or deterministic masking is the right fit, but remember the data is still personal data and still fully under the GDPR.
- You need role-based visibility in a live system → dynamic masking — but treat the result as pseudonymized, not anonymous.
For the deeper legal walk-through of the two GDPR outcomes — obligations, common mistakes, and when each is required — read anonymization vs pseudonymization.
FAQ
Is data masking a GDPR term? No. The GDPR defines anonymization (Recital 26) and pseudonymization (Article 4(5)). “Data masking” is a technical method that can achieve either outcome; it is best classed among the technical measures referenced in Article 32.
Does static data masking anonymize data? It can, if the transformation is permanent, no mapping key is retained, and the remaining fields cannot re-identify the person. If any of those fail, it is pseudonymization at best.
Is deterministic masking anonymization? No. A consistent, repeatable substitution is a pseudonym. Because the same input always yields the same output, patterns and mappings can be reconstructed — so it stays within GDPR scope.
Is dynamic data masking reversible? Yes, in effect. The real data still exists in the source system and is revealed to authorised users, so dynamic masking maps onto pseudonymization rather than anonymization.
Can I paste masked data into ChatGPT, Claude, or Gemini? Only if the masking is genuinely irreversible for that output (i.e. anonymized) and the remaining context cannot re-identify anyone. If a key or mapping still exists, you are sending pseudonymized personal data — which needs a legal basis. See anonymize data before ChatGPT, Claude, and Gemini.
Do this locally, before data ever leaves your device
If your goal is to strip personal data out of a document before it reaches an external AI tool, the cleanest path is placeholder-style masking that runs on your own machine. Amaze detects and masks personal data — including Polish identifiers like PESEL, NIP, REGON, and KRS, plus Polish names across grammatical cases — locally, on-device, before any text reaches ChatGPT, Claude, or Gemini. When you do need to re-link results, you can restore the originals locally with your own private mapping file — a deliberate, controlled pseudonymization step rather than an accidental one.
Part of our complete guide to data anonymization.