Quick Answer
What is the difference between pseudonymization and anonymization under GDPR?
Pseudonymized data is still personal data. It can be re-identified using additional information held separately — and GDPR applies to it in full. Anonymized data has been processed so that re-identification is not reasonably possible using any means likely to be used — and GDPR does not apply to it at all.
Standard masking (replacing characters with asterisks) and substitution (replacing real values with fake ones) are almost always pseudonymization — not anonymization. The practical bar for true anonymization is very high and rarely met by routine data processing operations.
TL;DR: Most privacy techniques applied to CSV data — masking, hashing, substitution, pseudonymization — leave the data regulated under GDPR. Only true anonymization removes GDPR obligations entirely. GDPR Article 4(5) governs pseudonymized data (still personal data). GDPR Recital 26 governs the narrow category of genuinely anonymous data (outside GDPR scope). Getting this distinction wrong creates false confidence in data that remains legally protected.
Your analytics team wants to share customer purchase data with a third-party research firm. Someone suggests "just anonymizing the names" — replacing customer names with random IDs and masking the email addresses. The file goes out. No DPA was signed. No data subject notice was sent.
Three months later, a GDPR investigation begins. The supervisory authority's analysis finds that the "anonymized" file still contained postcode, age band, purchase date, and device type. Combining those four fields makes 94 percent of the records uniquely re-identifiable in a population of 50,000. The file was pseudonymized — not anonymized. GDPR applied in full. Every obligation that applied to the original dataset applied to the shared file.
Key principle: A person can be identifiable without their name appearing anywhere in the file. GDPR's definition of personal data — Article 4(1) — covers any information relating to an identified or identifiable natural person. Identifiability is assessed by reference to all the means reasonably likely to be used, not just the obvious fields. Removing a name column does not remove identifiability if other fields in combination can single out an individual.
This is not a hypothetical pattern. The Irish Data Protection Commission's guidance on re-identification risk and the EDPB's guidance on anonymization techniques document exactly how mosaic re-identification allows pseudonymized data to be treated as identifiable even after apparent de-identification steps.
Regulatory requirements in this guide were verified against official GDPR text, EDPB published guidance on anonymization techniques, and the European Data Protection Supervisor's glossary, March 2026.
Table of Contents
- The Three Data States: Raw, Pseudonymized, Anonymized
- Pseudonymization vs Anonymization: Quick Reference Matrix
- GDPR Article 4(5): The Legal Definition of Pseudonymization
- GDPR Recital 26: The Anonymization Standard
- Why Most CSV Masking Is Pseudonymization, Not Anonymization
- GDPR Obligations: What Changes at Each Stage
- The Re-identification Risk Problem
- Choosing the Right Technique for Your Use Case
- Additional Resources
- FAQ
This guide is for: Data Protection Officers, compliance managers, data analysts, and anyone responsible for assessing whether a processed CSV file still requires GDPR protections.
The Three Data States
Before examining the legal definitions, it helps to understand the three states personal data can occupy — and which GDPR framework governs each.
Pseudonymization vs Anonymization: Quick Reference Matrix
This matrix is designed as a bookmark artifact for DPOs conducting vendor reviews or data sharing assessments.
| Question | Pseudonymized Data | Truly Anonymized Data |
|---|---|---|
| GDPR definition applies? | Yes — Art. 4(5): still personal data | No — Recital 26: outside GDPR scope |
| Can individual be re-identified? | Yes, using additional information held separately | No — not by any reasonably likely means |
| Legal basis (Art. 6) required? | Yes | No |
| Data subject rights apply? | Yes (access, erasure, portability, objection) | No |
| DPA required if shared with processor? | Yes — Art. 28 | No |
| International transfer safeguards needed? | Yes — Chapter V | No |
| Breach notification obligations? | Yes — risk assessment required | No |
| Standard masking qualifies? | Almost always Yes | Rarely — only if Recital 26 standard fully met |
| Hashing qualifies? | Almost always Yes (reversible for low-entropy inputs) | Only with high-entropy inputs + full quasi-identifier assessment |
| Aggregated statistics only? | Potentially No — if truly aggregate with no individual-level data | Potentially Yes — if no individual records remain |
| Safe to share without compliance obligations? | No — full GDPR posture required | Yes — once Recital 26 standard is confirmed |
How to use this matrix: If you are assessing whether a processed CSV file still requires GDPR protections, work down the "can individual be re-identified?" row first. If re-identification is feasible using reasonably available means — including quasi-identifier combinations — the data is pseudonymized and the entire left column applies.
| Dimension | Raw Personal Data | Pseudonymized Data | Truly Anonymized Data |
|---|---|---|---|
| GDPR definition | Personal data (Art. 4(1)) | Personal data (Art. 4(5)) | Not personal data (Recital 26) |
| GDPR applies? | Yes — fully | Yes — fully | No |
| Can individual be re-identified? | Yes, directly | Yes, with additional information | No — not by any reasonably likely means |
| Legal basis required to process? | Yes (Art. 6) | Yes (Art. 6) | No |
| Data subject rights apply? | Yes | Yes | No |
| DPA required if processor involved? | Yes (Art. 28) | Yes (Art. 28) | No |
| Can be shared freely? | Only with safeguards | Only with safeguards + DPA | Yes, without GDPR restrictions |
| Example | Name: Maria Santos, Email: [email protected] | Name: User_4821, Email: m***@example.com | Name: [absent], Email: [absent], only aggregate statistics retained |
The practical implication: the middle column — pseudonymized data — is regulated in exactly the same way as raw personal data. Pseudonymization is a security measure that reduces the risk of misuse, but it does not reduce the legal obligations that come with holding personal data.
GDPR Article 4(5): The Legal Definition of Pseudonymization
GDPR Article 4(5) defines pseudonymization as:
"the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person."
Two elements are essential in this definition. First, the data can no longer be directly attributed to a specific individual — the obvious identifiers have been removed or replaced. Second, it remains possible to re-identify individuals using additional information that exists separately, provided that additional information is not combined with the pseudonymized data.
What this means in practice: replacing customer names with random IDs, masking email addresses, or substituting real dates with offset dates all produce pseudonymized data. The original data still exists somewhere (in your CRM, your database, your key table). The pseudonymized file can be re-linked to individuals if that source is available. Therefore, the pseudonymized CSV is still personal data.
GDPR Recital 29 explicitly states that pseudonymization should not exclude the data from the GDPR's scope. Article 25 encourages pseudonymization as a Privacy by Design measure — not because it removes GDPR obligations, but because it reduces the risk of harm when data is misused or disclosed.
GDPR Recital 26: The Anonymization Standard
GDPR Recital 26 establishes when data falls entirely outside GDPR's scope:
"The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable."
The operative phrase is "not or no longer identifiable." Recital 26 continues: "To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, having regard to the available technology at the time of the processing and technological developments."
The anonymization standard is therefore dynamic and contextual. What counts as "reasonably likely" means at the time of the processing matters. Data that was effectively anonymous in 2015 may not be anonymous in 2026 given advances in re-identification techniques, publicly available data sources, and AI-assisted analysis.
For a CSV file to qualify as truly anonymized under Recital 26, re-identification must not be achievable by any means reasonably likely to be used — accounting for available technology, the data available to potential re-identifiers, and the scale of the population involved.
Why Most CSV Masking Is Pseudonymization, Not Anonymization
This is the most common source of GDPR misunderstanding in data operations. Teams apply masking or substitution to a CSV and describe the result as "anonymized data." Under GDPR, it almost never is.
Character masking (replacing parts of values with asterisks: [email protected] → j***@e***.com) leaves enough structure for re-identification in many contexts. The domain fragment and first initial may be sufficient to identify individuals within a known population. This is pseudonymization — the original can be recovered from a source holding the complete values.
Full redaction (removing values entirely: email → [REMOVED]) eliminates the specific identifier but leaves every other field intact. If the remaining fields in combination allow re-identification, the record is still pseudonymized. Removing one column from a 30-column dataset rarely creates anonymous data.
Consistent substitution (replacing real names with persistent fake names: Maria Santos → User_4821, always the same pseudonym for the same person) is textbook pseudonymization. The key table linking real names to pseudonyms exists somewhere. The pseudonymized data can be re-linked.
Hashing (replacing values with cryptographic hashes: SHA-256 of the email address) is pseudonymization unless the hash inputs can be brute-forced. For common formats like email addresses, rainbow tables make many hashed values re-identifiable. Salted hashing improves this, but the EDPB has noted that hashing alone does not achieve anonymization for low-entropy input values.
True anonymization requires eliminating the realistic possibility of re-identification entirely. In practice, this means: removing or generalizing all direct identifiers, applying k-anonymity or differential privacy techniques to quasi-identifiers, and confirming that the remaining dataset cannot be re-linked to individuals using any reasonably available external data source.
GDPR Obligations: What Changes at Each Stage
Understanding which obligations apply at each stage helps you make better decisions about what techniques to use before sharing, exporting, or processing data externally.
For raw personal data and pseudonymized data — obligations are identical:
- Legal basis required under Article 6 before processing
- Data subject rights apply: access, rectification, erasure, portability, restriction, objection
- Data Processing Agreements required with any processor under Article 28
- International transfer safeguards required under Chapter V for non-EEA transfers
- Security measures required under Article 32
- DPIA potentially required under Article 35 for high-risk processing
- Breach notification obligations under Article 33/34
Pseudonymization does not reduce any of these obligations. It may be a relevant factor in the risk assessment for breach notification (a breach of pseudonymized data may be less likely to result in high risk to data subjects), but it does not change the fundamental legal status of the data.
For truly anonymized data — GDPR does not apply: No legal basis required. No data subject rights. No DPA requirement. No transfer safeguards. No breach notification obligations under GDPR.
This is why the distinction matters so much operationally. Getting to genuine anonymization — if your use case permits it — removes the entire compliance framework for that data.
The Re-identification Risk Problem
The EDPB's guidance on anonymization techniques identifies three criteria for assessing whether anonymization is effective: singling out (can you isolate a specific individual?), linkability (can you link two records relating to the same individual?), and inference (can you deduce information about an individual from the dataset?).
A CSV file fails the anonymization standard if any of these three attack vectors is feasible using reasonably available means.
The mosaic effect is the most practically significant risk in CSV data. Individual quasi-identifiers — age band, postcode sector, employer industry, device type, purchase category — may each appear innocuous. Combined, they can uniquely identify individuals in surprisingly small populations. Research published in Nature Communications (Montjoye et al.) demonstrated that 95 percent of individuals are unique across just four spatio-temporal data points. The threshold for effective anonymization is much higher than most teams assume.
For CSV workflows, the practical implication is: before treating any processed file as anonymous, assess whether the combination of remaining fields — not just the fields you modified — can be used to re-identify individuals. If the answer is yes, the file is pseudonymized. GDPR applies.
Two documented re-identification cases that shaped this standard:
AOL search data release (2006): AOL published 20 million "anonymized" search queries from 658,000 users, replacing usernames with random numeric IDs. Within days, journalists at the New York Times identified specific individuals by cross-referencing their search history with publicly available information — searches for "landscapers in Lilburn, Ga" combined with queries about specific medical conditions identified a 62-year-old woman by name. The dataset contained no names, no emails, no explicit identifiers — only search text and a user ID.
Netflix Prize dataset (2007): Netflix published 100 million "anonymized" movie ratings for a public machine learning competition, removing subscriber names and replacing them with random IDs. Researchers Narayanan and Shmatikoff demonstrated that 99% of subscribers could be uniquely re-identified by cross-referencing the anonymized ratings with publicly available IMDb reviews — using as few as eight movie ratings with approximate dates. The data contained no names, no contact information, and no direct identifiers.
Both cases involve data that met the common-sense definition of "anonymized" — no names, no emails, no obvious identifiers — and failed the legal standard because quasi-identifier combinations enabled re-identification using reasonably available external data.
Choosing the Right Technique for Your Use Case
The right technique depends on what you need to do with the data after processing. This decision tree guides the choice.
What do you need to do with the processed data?
│
├─ Share externally with a third party (research firm, vendor, partner)
│ │
│ ├─ Recipient needs individual-level records
│ │ └─ Use pseudonymization + DPA + data minimization
│ │ (GDPR still applies; sign DPA; strip unnecessary columns first)
│ │
│ └─ Recipient only needs aggregate statistics / trends
│ └─ Use aggregation + differential privacy if possible
│ (If genuinely anonymous by Recital 26 standard: no DPA needed)
│
├─ Process internally (analytics, ML training, testing)
│ │
│ ├─ Need to re-link to individuals later (fraud investigation, SAR response)
│ │ └─ Use pseudonymization (keep key table secure and separate)
│ │ (GDPR applies; implement Privacy by Design under Art. 25)
│ │
│ └─ Do not need re-linking capability
│ └─ Target anonymization (generalize quasi-identifiers, apply k-anonymity)
│ Confirm re-identification is not feasible before treating as anonymous
│
└─ Use as test/development data
└─ Use pseudonymization or synthetic data generation
(Never use raw production data in non-production environments)
One practical rule for CSV workflows: Apply pseudonymization before any external transmission — this reduces the harm if a breach occurs. Apply genuine anonymization only when you have assessed all quasi-identifiers and confirmed the Recital 26 standard is met. When in doubt, treat the data as pseudonymized and maintain full GDPR compliance posture.
For de-identification before external processing, SplitForge's Data Masking tool applies substitution, masking, and redaction techniques locally in your browser. For raw file contents, no server receives the data — materially reducing the Article 28 processor risk even for pseudonymized data that remains regulated under GDPR.
Additional Resources
Related SplitForge guide: For actually masking PHI in patient CSVs client-side, see HIPAA Data Masking: Anonymize 1M Patient Records Without Uploading PHI.
Official GDPR Text:
- GDPR Article 4(5) — Definition of pseudonymisation — Legal definition; confirms pseudonymized data is still personal data
- GDPR Recital 26 — Anonymous information — The anonymization standard under which GDPR ceases to apply
- GDPR Article 25 — Data protection by design and by default — Pseudonymization as a technical measure
Supervisory Authority Guidance:
- EDPB Guidelines 05/2014 on Anonymization Techniques — The authoritative EDPB framework for assessing whether data is truly anonymous
- EDPB 2025–2027 Work Programme — EDPB priorities including updated anonymization and pseudonymization guidance
- EDPS Glossary — Pseudonymisation and Anonymisation — European Data Protection Supervisor definitions
Technical Reference:
- NIST Privacy Framework — Technical guidance on de-identification and privacy-enhancing technologies