Article
Data Masking vs. Tokenization vs. Anonymization: What's the Difference?
On July 7, 2026, the European Data Protection Board adopted its first-ever formal Guidelines on Anonymisation, introducing a three-part technical test — "No Record Isolation," "No Linkage," and "No Inference" — that data has to pass before it can legally be called anonymous under the GDPR (EDPB Guidelines 02/2026 on Anonymisation). The timing wasn't random: less than a year earlier, the EU's top court had ruled that pseudonymized data isn't automatically "personal data" at all — its status depends entirely on whether the specific party holding it could realistically re-identify someone (Skadden, on EDPS v Single Resolution Board, C-413/23 P). Together, these two developments underscore something practitioners have argued for years: masking, tokenization, and anonymization are not interchangeable words for "making data safe." They're distinct techniques with different mechanics, different reversibility guarantees, and — as regulators are now spelling out in detail — different legal consequences.
What data masking actually does
Data masking replaces sensitive values with realistic but fictitious substitutes while preserving the original format and structure, so a masked dataset still "looks" and behaves like the real thing for testing, analytics, or development (AWS). It comes in two main flavors. Static data masking permanently rewrites values in a copy of the data before that copy ever leaves a secure environment — once applied, the original values generally cannot be recovered from the masked copy (Perforce). Dynamic data masking works differently: it leaves the underlying data untouched and instead obscures it on the fly, at query time, based on who's asking and what they're authorized to see (Tonic.ai).
Masking techniques vary by field type — substitution, shuffling, redaction, or number variance — but the goal is consistent: strip out the sensitive value while keeping the dataset structurally and statistically usable (TechTarget). This is why masking is the default choice for non-production environments: QA, staging, and developer sandboxes need data that behaves realistically without exposing anything real.
What tokenization actually does
Tokenization replaces a sensitive value — most commonly a payment card number — with a "token" that has no mathematical or algorithmic relationship to the original value (Internet Security Auditors). The original data is stored separately, usually in a secure token vault, and the mapping between token and original value is what makes tokenization fundamentally different from masking: it's designed to be reversed by authorized systems through a process called detokenization (DataStealth).
Many implementations use format-preserving tokenization, generating a token with the same length and character pattern as the original — a 16-digit card number becomes a different 16-digit, Luhn-valid token — so legacy systems and validation logic keep working without modification (SecurityMetrics). Because systems that only ever touch tokens (never the vault) don't hold real cardholder data, tokenization is the standard way payment processors shrink their PCI DSS compliance scope (Internet Security Auditors).
What anonymization actually does — and why it's legally different
Anonymization aims for something masking and tokenization don't: an outcome where no individual can realistically be re-identified from the data, ever, by anyone. Under the GDPR, that's not a marketing claim — it's a specific legal threshold. The EDPB's new guidelines define anonymous data as information that "does not relate to an identified or identifiable natural person," and lay out a concrete three-part test for getting there: No Record Isolation (no unique combination of attributes singles out one person), No Linkage (the data can't be correlated with other records about the same person), and No Inference (no meaningful conclusion about an individual can be drawn from it) (EDPB Guidelines 02/2026). If all three pass, the data falls outside GDPR scope entirely. If even one fails, further analysis is required before anonymity can be claimed.
Common anonymization techniques include generalization, suppression, adding statistical noise, k-anonymity (ensuring each record is indistinguishable from at least k-1 others), and differential privacy (mathematically bounding how much any single record can influence an output) (University of Padua thesis on anonymization techniques). Crucially, the EDPB also warns that anonymity isn't permanent: "the likelihood of re-identification typically increases over time due to advances in the technology and techniques used for re-identification," meaning data anonymized safely today can lose that status later as re-identification methods improve (EDPB Guidelines 02/2026).
Reversibility is the core distinction — and it decides your legal exposure
Here's the dividing line that matters most: masking and anonymization are designed to be irreversible; tokenization — and its close cousin, pseudonymization — are designed to be reversible by an authorized party (Anonde). That single design choice determines regulatory treatment. Format-preserving encryption, a technique often used for tokenization, is explicitly reversible by design: "the same input data set consistently produces the same output token," and authorized users can decrypt it back to plaintext (Fortanix).
The GDPR treats this distinction as decisive. Pseudonymized data — including tokenized data — remains personal data and stays fully within GDPR scope as long as anyone could plausibly reverse it back to an identifiable person, even if that "anyone" is a third party who received the data downstream (UCL Data Protection Guidance). The September 2025 ECJ ruling in EDPS v Single Resolution Board refined this further: identifiability has to be assessed from the specific recipient's perspective, not automatically from the sender's. If a consulting firm receiving pseudonymized codes has no realistic way — technically, contractually, or legally — to map those codes back to individuals, the data may not be personal data in that firm's hands, even though it clearly still is in the original controller's hands (Skadden). The court was explicit that this is not a "blank cheque" — it requires documented, case-by-case analysis, not an assumption.
Anonymized data, by contrast, is designed to make that reversal analysis moot: done correctly, there's no key, no vault, and no realistic path back to the individual for anyone (Anonde).
How this plays out across other regulatory frameworks
The GDPR isn't the only framework drawing these lines, and the boundaries don't always match up neatly across jurisdictions.
HIPAA takes a more prescriptive, checklist-based approach through its Safe Harbor method: strip 18 specific identifiers — names, geographic detail smaller than a state, dates other than year, and so on — and the data is legally de-identified, regardless of whether a statistician has assessed actual re-identification risk (Censinet). That's a materially lower bar than the GDPR's anonymization standard, which asks whether re-identification is realistically possible for any relevant party, not just whether a fixed list of fields was removed.
PCI DSS 4.0 doesn't ask whether cardholder data is "anonymous" at all — it cares whether raw account numbers exist outside a tightly controlled vault. Tokenization satisfies this by design, since systems holding only tokens fall outside the Cardholder Data Environment and face a reduced compliance burden (Internet Security Auditors).
Genetic and health-adjacent data stress-tests all of these frameworks at once. When 23andMe filed for bankruptcy in March 2025, genetics experts pointed out that DNA data resists true anonymization in a way most other data types don't — "each individual's sequence is distinct, making complete anonymization impossible," according to the National Human Genome Research Institute (CNBC). 23andMe's own privacy approach relied on separating identifying registration details from genetic data and using randomly assigned identifiers — a pseudonymization pattern, not true anonymization — which is precisely why the company's bankruptcy sale of that data drew such scrutiny (CNBC).
A framework for choosing the right technique
Start with the question "does this data need to come back?" If any authorized process ever needs the original value restored, you need tokenization (or reversible pseudonymization) — masking and anonymization are the wrong tools by design, because reversal isn't supposed to be possible.
If the data only needs to look real, not be reversible, mask it. Test, QA, staging, and developer environments almost always fall here — masked data needs to preserve format and statistical realism, not a path back to the original (TechTarget).
If you're handling payment card or similarly regulated transactional data, tokenize it. Format-preserving tokens keep legacy validation logic working while pulling the actual PAN out of scope entirely, which is the core mechanism PCI DSS rewards (SecurityMetrics).
If your goal is to permanently remove data from a privacy regulation's scope, anonymize it — and prove it. Run the data against a real test (the EDPB's No Record Isolation / No Linkage / No Inference framework is a useful starting point even outside the EU) rather than assuming that removing a name or ID column is sufficient (EDPB Guidelines 02/2026).
Match the legal standard to the jurisdiction, not just the technique. HIPAA Safe Harbor, GDPR anonymization, and PCI DSS tokenization scope reduction are three different bars — meeting one doesn't automatically satisfy another (Censinet).
Re-assess anonymized data periodically, not just once. Because re-identification techniques keep improving, data that was safely anonymous at creation can drift back into "personal data" status over time — the EDPB explicitly calls this out as a reason to revisit assessments (EDPB Guidelines 02/2026).
A quick checklist
Does any authorized system or process need to recover the original value, or is one-way protection sufficient?
If you're relying on pseudonymization or tokenization to reduce compliance scope, have you documented — from the recipient's perspective — whether re-identification is realistically possible?
If you're claiming data is "anonymized," has it actually been tested against isolation, linkage, and inference risks, or does it just have obvious identifiers removed?
Does your chosen technique satisfy the specific regulatory framework you're subject to (HIPAA Safe Harbor, GDPR anonymization, PCI DSS scope reduction), rather than a generic idea of "de-identified"?
Have you revisited older anonymization or masking decisions to confirm they still hold up against current re-identification techniques?
The bottom line
Masking, tokenization, and anonymization solve related but distinct problems: masking makes data safe to use without needing it back, tokenization makes data safe to store while keeping a controlled path back to the original, and anonymization aims to remove a person from the data permanently and provably. Regulators are increasingly precise about which is which — the EDPB's 2026 anonymization test and the ECJ's 2025 pseudonymization ruling both show that "we de-identified it" is no longer a sufficient answer on its own.
C² Data Privacy Platform discovers sensitive data across production, test, and analytics systems, and applies the right technique — masking, tokenization, or anonymization — automatically before that data is delivered anywhere it doesn't need to be. Book a demo to see it run against your own schema.
Sources: EDPB — Guidelines 02/2026 on Anonymisation, Skadden — "In a Landmark Decision, EU Court Clarifies When Pseudonymised Data Is Personal Data", AWS — What is Data Masking?, Perforce — Static Data Masking vs. Dynamic Data Masking, Tonic.ai — Static vs Dynamic Data Masking, TechTarget — What is Data Masking?, Internet Security Auditors — Tokenization in Environments with PCI DSS Compliance Requirements, DataStealth — PCI DSS Tokenization Guide for Hybrid Environments, SecurityMetrics — What is Tokenization and How Can I Use It for PCI DSS Compliance?, Fortanix — Format Preserving Encryption (FPE), University of Padua — Examining Anonymization Techniques for Effective AI, Anonde — Data Anonymization: Techniques and Tools, UCL — Anonymisation and Pseudonymisation of Personal Data, Censinet — Top Frameworks for GDPR Data De-Identification, CNBC — With 23andMe Entering Bankruptcy, Here's How to Delete Your Genetic Data, CNBC — 23andMe Bankruptcy: With America's DNA Put on Sale, C² Data Technology.
