Pseudonymization vs Anonymization: US, GDPR and HIPAA Rules
Table of Contents
Direct answer
Pseudonymization replaces identifiers with aliases and keeps the mapping data separately. The result is still personal data under GDPR. Anonymization makes data unlinkable to any individual, so GDPR no longer applies. HIPAA de-identification is a third, US-specific standard. It is context-dependent and does not automatically meet the GDPR anonymization threshold.
Definitions and scope
Pseudonymization
GDPR Article 4(5) defines pseudonymization as processing personal data so that it can no longer be attributed to a specific person without additional information. The additional information must be kept separately and protected by technical and organizational measures. Recital 26 of the GDPR states that pseudonymized data attributable to a person through additional information is information on an identifiable person.
The European Data Protection Board describes pseudonymization as a safeguard that reduces linkability without aiming to cut the link completely. The EDPB Guidelines 01/2025 on Pseudonymisation, adopted on 16 January 2025 in a version for public consultation, state that this holds even when the data and the additional information are held by different parties.
The UK ICO takes the same position: pseudonymized personal data is in scope of data protection law.
Anonymization
In data protection law, anonymous information does not relate to an identified or identifiable person. The ICO states that data protection law does not apply to anonymous information. The Spanish data protection authority (AEPD) cites Recital 26 for the same definition and notes that the two concepts are often confused.
De-identification
In the US health sector, HIPAA permits a covered entity or its business associate to create information that is not individually identifiable. The HHS guidance on de-identification recognizes two methods:
Safe Harbor: removal of 18 specified identifiers.
Expert Determination: a qualified expert with statistical knowledge documents that the risk of identification is very small.
HIPAA de-identification is not the same legal concept as GDPR anonymization. A dataset can meet one standard and fail the other.
Comparison table
Criterion | Pseudonymization | GDPR anonymization | HIPAA de-identification |
Legal status of output | Personal data | Not personal data | Not protected health information if method is met |
Reversibility | Reversible with additional information | Not reasonably reversible | Not reasonably reversible for the stated context |
Key held separately | Yes, required | No key should exist | Re-identification code allowed only under conditions in the Privacy Rule |
Assessment basis | Security and separation controls | Likelihood of identification by any means | Safe Harbor list or documented expert analysis |
Main purpose | Risk reduction | Exit from regulatory scope | Permitted use or disclosure without authorization |
Steps: owner and control
The sequence below applies to a regulated document or dataset, such as clinical study reports, patient records, contracts or financial filings, before it is shared, translated or analyzed.
Classify the data. Owner: data protection officer or privacy counsel. Control: data inventory that lists direct identifiers, quasi-identifiers and special categories.
Identify the governing regimes. Owner: legal and regulatory affairs. Control: written jurisdiction map covering GDPR, HIPAA and applicable state law.
Set the target state. Owner: privacy counsel with the business owner. Control: documented decision to pseudonymize, de-identify or anonymize, with the purpose stated.
Apply the technique. Owner: data engineering or the language service provider under contract. Control: documented transformation rules, version control and access control on tools.
Separate the additional information. Owner: security lead. Control: mapping tables or keys stored apart from the data, encrypted, with role-based access control and an audit trail.
Test for re-identification. Owner: independent statistician or privacy engineer. Control: linking-attack test against reasonably available external data, recorded in a risk report.
Review the output. Owner: quality manager. Control: QA check against the transformation rules, plus subject-matter expert review where context can reveal identity.
Contract and monitor. Owner: procurement and compliance. Control: data processing agreement, sub-processor list, deletion certificate and periodic re-assessment.
Decision criteria
When pseudonymization fits
Choose pseudonymization when the data must stay linkable. Typical needs are longitudinal patient follow-up, pharmacovigilance case management, fraud investigation and software testing with traceable records. All GDPR obligations continue to apply, including lawful basis, data subject rights and security.
When anonymization fits
Choose anonymization when no one needs to return to the individual. Typical needs are public release of statistics, open research datasets and aggregated analytics. The organization must be able to show that identification is not reasonably likely, taking into account the means available to it and to others.
When HIPAA de-identification fits
Choose HIPAA de-identification when a US covered entity or business associate must use or share health data outside the permitted-use framework. Safe Harbor suits structured data where the 18 identifiers are known fields. Expert Determination suits data where dates, locations or free text carry analytic value. HHS notes that the expert method does not set a single numerical threshold for a very small risk. The assessment depends on the dataset, the recipient and the context.
Cross-border checks
US data that reaches the EU, or EU data that reaches the US, needs both tests. A HIPAA-compliant dataset may still be personal data under GDPR. The Office of the Privacy Commissioner of Canada published a 2024 comparison of statutory definitions of anonymization, pseudonymization and de-identification across G7 jurisdictions. It shows that the terms are defined differently from one jurisdiction to the next. The EDPB treats anonymization as dependent on context, so decisions are made case by case.
Examples
Pseudonymization examples
Clinical trial listings: subject names are replaced by subject codes. The code list stays with the sponsor or site under access control. The study data remains personal data.
Customer support logs: account numbers are replaced by random tokens. The token vault sits in a separate system with its own audit trail.
Translation of patient narratives: names and medical record numbers are replaced with placeholders before translation. The placeholders are restored after QA in the client environment.
Anonymization examples
Aggregated statistics: counts by region and age band, with small cells suppressed, published without row-level records.
Synthetic data: a generated dataset that reproduces statistical properties without carrying real records. It still requires a re-identification test, because a model can leak training records.
HIPAA de-identification examples
Safe Harbor release: a registry extract with the 18 identifier categories removed and no actual knowledge that the remainder could identify a person.
Expert Determination release: a dataset keeping dates at month level, accompanied by a documented statistical risk analysis for a named recipient.
Failure modes and mitigations
Failure mode | Effect | Mitigation |
Treating pseudonymized data as anonymous | Security and GDPR duties are skipped. A breach of the separate key exposes identities. | Label pseudonymized data as personal data. Store keys apart with access control and an audit trail. |
Linking attacks | Combining a dataset with outside data re-identifies people. | Run linkage tests. Generalize or suppress quasi-identifiers. |
Redaction of names only | Dates, rare diagnoses, job titles and free text still identify people. | Review quasi-identifiers. Use subject-matter expert review for free text. |
Assuming HIPAA de-identification equals GDPR anonymization | EU transfers or publication occur without a valid legal basis. | Run a separate GDPR assessment for EU subjects. |
One-time assessment | New external data raises risk later. | Schedule re-assessment and record the date of each review. |
Uncontrolled vendors | Identifiers reach public cloud tools or unvetted sub-processors. | Require a processor agreement, sub-processor disclosure and defined hosting location. |
Why “irreversible” is a risky claim
NIST SP 800-188 warns that many de-identification procedures can be readily reversed if a dataset exists that maps the data back to people. It also advises caution with the term anonymization. NIST SP 800-226 adds that de-identifying data is hard in practice because it is difficult to tell which fields are identifying. Treat identifiability as a spectrum of risk, managed through technical controls, governance and disclosure review, not as a binary state.
The same discipline applies to intake data. Controls at the point of collection reduce later errors and exposure. One example from another regulated field is this article on data quality and controls at intake, which discusses audit-ready records in anti-money-laundering workflows.
Perspective
We see the same error in language projects across regulated sectors. A team masks names in a document, calls it anonymized, and sends it to a vendor. The document still contains dates, device serial numbers, site names and rare conditions. Under GDPR it remains personal data. Under HIPAA it may not meet Safe Harbor.
Our position is that the label matters less than the controls. Decide the legal status first. Then fix the hosting location, access control, audit trail and QA. Keep terminology governance in place so placeholders and codes translate consistently across 150+ languages. Process regulated text on infrastructure where the client can name the location and the sub-processors. Add subject-matter expert review, because only a medical, legal or engineering reader can tell which context details identify a person.
— Eric Brown
Where AD VERBUM fits
AD VERBUM provides AI+HUMAN hybrid translation and localization for life sciences, legal, finance, defense and manufacturing content. Processing runs on a proprietary LangOps System hosted on EU servers. Certifications include ISO 27001, ISO 42001, ISO 17100, ISO 18587 and ISO 13485, audited by Bureau Veritas. AD VERBUM states alignment with GDPR and HIPAA. A network of 3,500+ subject-matter expert linguists reviews regulated content. Service scope is listed on the AD VERBUM services page. Pricing is by quote.
Key points
Pseudonymized data is personal data under GDPR Article 4(5) and Recital 26.
Anonymized data is outside GDPR only if people are not identifiable by reasonably likely means.
HIPAA offers Safe Harbor (18 identifiers) and Expert Determination (documented, very small risk).
HIPAA de-identification does not by itself satisfy the GDPR anonymization threshold.
NIST advises treating identifiability as a spectrum of risk and cautions against the term anonymization.
Keep the additional information separate, with access control and an audit trail.
Re-assess after release, because new external data can change re-identification risk.
FAQ
What is the main difference between anonymization and pseudonymization?
Pseudonymization keeps a way back to the person through separately held additional information, so the data stays personal. Anonymization removes that link so the data no longer relates to an identifiable person. GDPR applies to the first and not to the second.
Is HIPAA de-identification the same as anonymization?
No. HIPAA de-identification means meeting Safe Harbor or Expert Determination under the Privacy Rule. GDPR anonymization is a separate test of whether identification is reasonably likely. A dataset can pass the first and still be personal data in the EU.
Does pseudonymization remove the need to comply with GDPR?
No. Pseudonymized data is personal data, so lawful basis, data subject rights and security duties continue. Pseudonymization is a safeguard that reduces risk. It is not an exemption.
Can a translation vendor receive pseudonymized documents?
Yes, if a data processing agreement, access control, hosting disclosure and deletion terms are in place. The vendor must not hold the mapping data unless the contract requires it. The client remains responsible for the legal classification of the data.
Sources
