What Is Data Anonymization? Redaction, Masking, and Pseudonymization Explained

A company implements what it believes is anonymization. It strips names and email addresses from its customer dataset, replaces account numbers with random tokens, and stops treating the data as personal data — no DPA requirements, no subject access obligations, no breach notification if something goes wrong.

A supervisory authority investigates. The data was not anonymized. It was pseudonymized. The tokens are reversible. The original identities can be recovered using a mapping table stored elsewhere in the system. The company has been processing personal data without proper legal basis for two years.

This scenario is not hypothetical. Multiple European supervisory authorities issued enforcement actions in 2024 and 2025 against organizations that claimed their data was anonymized when re-identification remained technically possible. The distinction between these terms is not semantic — it determines whether GDPR applies to your data at all.

Why the Terminology Matters

The four terms — anonymization, pseudonymization, redaction, and data masking — are used interchangeably in most organizational contexts. They describe different operations with different legal consequences.

Under GDPR:

Anonymized data falls entirely outside the regulation. It is no longer personal data. You can share it, analyze it, and retain it indefinitely with no GDPR obligations.
Pseudonymized data is still personal data. All GDPR obligations apply: lawful basis, data subject rights, breach notification, transfer restrictions.
Redacted documents may contain anonymized data, pseudonymized data, or something in between, depending on how thoroughly the redaction was done and what remained.
Masked data is a system-level technique that operates on databases and pipelines rather than documents.

Getting these categories wrong creates compliance exposure that most organizations have not formally assessed.

Anonymization: The Only Exit From GDPR

Anonymization is the irreversible removal or alteration of personal data such that no individual can be identified from the resulting information — not directly, not indirectly, not by any means reasonably likely to be applied.

The GDPR’s standard is set in Recital 26: data protection rules do not apply to information that cannot identify a natural person. But Recital 26 also sets the bar: the assessment of identifiability must take into account “all the means reasonably likely to be used” to re-identify the data. This includes combining the dataset with other publicly available data, using inference attacks, or applying modern re-identification techniques.

That last point is increasingly significant. Research from ETH Zurich published in 2026 demonstrated that large language models can re-identify individuals from text that traditional anonymization techniques had classified as clean. The bar for what counts as “reasonably likely” means of re-identification has moved, and it will continue to move as AI capabilities improve.

True anonymization requires more than removing obvious identifiers. It requires ensuring that the combination of remaining attributes — age, location, occupation, behavioral patterns, dates — cannot be used to single out an individual even when combined with external data sources.

In practice, datasets that are genuinely anonymous and still useful for analysis are rare. Most “anonymized” datasets are pseudonymized. The distinction matters enormously for compliance.

Pseudonymization: Still Personal Data

Pseudonymization replaces identifying information with a reversible stand-in — a token, a code, a synthetic identifier — while keeping the mapping between the original value and its replacement stored separately.

GDPR Article 4(5) defines it precisely: processing of personal data such that the data can no longer be attributed to a specific data subject without the use of additional information, provided that additional information is kept separately and is subject to technical and organizational measures.

The GDPR rewards pseudonymization — it is treated as a security measure that reduces risk and can support compliance with data minimization and storage limitation principles. But it does not treat pseudonymization as anonymization. The EDPB Guidelines 01/2025, published in January 2025, were unambiguous on this point: pseudonymized data remains personal data. Organizations cannot use pseudonymization to exit GDPR obligations.

The practical implication: a customer database where names and emails have been replaced with random tokens is still a database of personal data. The people in it still have the right to access their data, to request deletion, and to be notified in the event of a breach — even if the breach involves the pseudonymized version, not the original.

When does pseudonymization make sense? When you need to preserve the ability to link records to individuals for follow-up — clinical research where outcomes need to be connected to patients, fraud detection systems where alerts need to be traced back to accounts, customer analytics where longitudinal tracking requires consistent identifiers. Pseudonymization protects the data in transit and at rest while keeping re-identification available to authorized parties.

Redaction: A Mechanism, Not an Outcome

Redaction is frequently misunderstood as a category alongside anonymization and pseudonymization. It is not — it is a mechanism, and the outcome of redaction can be either anonymized data or pseudonymized data depending on what was removed and what remained.

Redaction permanently removes specific information from a document before disclosure. Replace a client’s name with [REDACTED]: the name is gone, the replacement conveys no information about the original, and that specific identifier has been removed. Whether the resulting document is anonymous depends on whether the remaining content — the dates, the context, the referenced locations and relationships — is sufficient to identify the individual through other means.

A contract with the client’s name redacted but the client’s industry, company size, location, and deal terms still present may still identify that client to anyone familiar with the market. The redaction removed a direct identifier. It did not produce anonymized data.

This distinction matters for document sharing under GDPR. Redacting a document before sharing it with an external party reduces the personal data transferred, but does not necessarily eliminate the personal data transfer. The remaining content may still be personal data. The transfer may still require a lawful basis.

The practical standard: redaction produces anonymized data when the resulting document cannot identify the individual by any means reasonably likely to be applied. It produces pseudonymized data — still personal — when re-identification remains possible through context, combinations, or external data.

Data Masking: The Database-Layer Technique

Data masking operates at the system or database level rather than the document level. It replaces sensitive values in a database, test environment, or data pipeline with realistic but fictitious substitutes — a real-looking name that isn’t real, a valid-format credit card number that isn’t active, an address in the right ZIP code that doesn’t belong to anyone.

The key distinguishing feature: the substitution is designed to preserve the structural and statistical properties of the original data so that systems, tests, or analytics function correctly without exposing real values.

Static masking creates a permanently altered copy of the dataset — used for non-production environments where developers need realistic data without real personal data. Dynamic masking intercepts queries in real time and returns masked values to unauthorized users while returning real values to authorized ones — the underlying database contains real data, but unprivileged users never see it.

Data masking is not a document-level technique. It is the appropriate tool for protecting personal data in databases, development environments, and data pipelines. The appropriate tool for protecting personal data in documents is redaction.

The practical distinction matters because organizations sometimes apply masking thinking to document workflows: replace names with fake names before sharing. This is pseudonymization, not anonymization — the fake names are substitutes, not removals, and the document still contains data about real individuals even if their real names aren’t present.

The Decision Framework: Which Technique for Which Use Case

You need to share a document externally and remove identifying information before sending: Use redaction. Remove direct identifiers — names, contact details, ID numbers. Assess whether indirect identifiers in the remaining content are sufficient to re-identify the individual. If they are, redact further or generalize. The goal is a document where the recipient cannot identify the individuals described.

You need to use data for analysis, testing, or ML training without exposing real personal data, but you need to retain the ability to link records to individuals: Use pseudonymization. Replace identifiers with consistent tokens, store the mapping separately with strict access controls, maintain all GDPR obligations for the pseudonymized data.

You need to share data publicly or for broad research purposes with no future need to link back to individuals: Aim for true anonymization. This requires not just removing direct identifiers but ensuring the combination of remaining attributes cannot re-identify individuals through any reasonably likely means. Have a qualified privacy professional assess the dataset before claiming it is anonymous.

You need to give developers or analysts access to realistic data in a non-production environment: Use data masking to create a masked copy of the database. Real structural and statistical properties, no real personal data.

You need to protect personal data in a live production database from unauthorized access: Dynamic masking at the database level. Real data for authorized users, masked data for everyone else.

The 2025 Regulatory Shift Worth Knowing

The EDPS v SRB case decided in 2025 introduced a nuance that changes the pseudonymization analysis in specific contexts: the legal status of pseudonymized data may depend on the recipient’s ability to re-identify, not just the sender’s.

Under the earlier framework, if an organization pseudonymized data and the recipient had no access to the key, some argued the data was effectively anonymous from the recipient’s perspective. The 2025 EDPS ruling moved away from this position, reinforcing that pseudonymized data remains personal data unless re-identification is impossible for all parties — including the recipient in combination with other data they hold.

The practical implication: sharing pseudonymized data with a third party who could theoretically combine it with other data to re-identify individuals is still a personal data transfer under GDPR, regardless of how the sender classified it.

Why Getting This Right Matters Beyond Compliance

There is a practical argument for precision here that goes beyond regulatory risk.

Organizations that correctly distinguish between anonymized and pseudonymized data make better decisions about their data governance architecture. They don’t remove access controls from pseudonymized data thinking it’s anonymous. They don’t apply anonymization techniques to datasets where re-identification needs to remain possible. They don’t redact documents and then treat them as fully de-identified when the remaining content still identifies individuals.

Precision about these terms is the foundation of a data governance strategy that works — not just one that looks compliant until someone examines it closely.

PII Redaction Pro automates the redaction step — detecting and removing personal identifiers from PDF, CSV, XLSX, DOCX, and TXT files locally on your Windows machine. Try it free for 7 days.