Part 1 of our series on Privacy Enhancing Technologies
Here is a fact worth bringing to your next compliance meeting: you can “anonymize” a dataset under the Health Insurance Portability and Accountability Act (HIPAA), ship it to your European Union office, and be in breach of the General Data Protection Regulation (GDPR) immediately. It is the same word and the exact same data, yet it results in two entirely different legal outcomes.
This discrepancy is not a mere translation issue. The terms “anonymized,” “de-identified,” and “pseudonymized” carry genuinely different meanings depending on which regulatory body is evaluating the data. Most engineering and data science teams learn this the hard way, usually right after a client asks the critical question: is this dataset actually anonymous, or not?
The Standards, Side by Side
To understand why this happens, we must examine the differing standards applied by major regulatory frameworks globally. The practical trap lies in the fact that a dataset clearing HIPAA’s Safe Harbor checklist—where direct identifiers have been removed—can still contain enough indirect identifiers, such as a combination of ZIP code, birth year, and diagnosis code, to re-identify an individual under GDPR’s much tougher standard. It is a different legal bar applied to the same data, resulting in a different verdict.
Below is a comprehensive breakdown of how different jurisdictions define and require data anonymization and de-identification:
| Jurisdiction | Term | What it actually requires |
|---|---|---|
| EU - GDPR | Anonymization | Re-identification must be impossible for anyone using any reasonably available means, including foreseeable technological developments. Recital 26 sets a deliberately high standard. |
| EU - GDPR | Pseudonymization | A key, lookup table, or other additional information could be used to re-identify the person. The information remains personal data, so GDPR obligations still apply. |
| US - HIPAA | Safe Harbor | Requires the removal of 18 specified identifiers, including names, dates, and certain ZIP-code information. It is primarily a checklist-based method rather than a general test of whether re-identification is possible. |
| US - CCPA | De-identified | Requires reasonable measures to prevent the data from being associated with a person, along with public commitments and contractual controls against re-identification. The standard is reasonableness, not absolute impossibility. |
| Brazil - LGPD | Anonymization | Data must not be reasonably capable of being associated, directly or indirectly, with an individual using available and reasonable technical means. |
| China - PIPL | Anonymization | The information must be processed so that a person cannot be identified and the process cannot be reversed. Practical interpretation remains less developed because there is limited public judicial and regulatory guidance. |
Why This Keeps Biting Companies
The GDPR problem is far from theoretical. A significant amount of what organizations label as “anonymization” work is, in reality, pseudonymization wearing a disguise. Direct identifiers may be removed, but enough indirect identifiers are left behind—such as location data, timestamps, or device IDs—that re-identification becomes a mere data-linking exercise rather than a cryptographic impossibility.
The obvious non-answer is doing nothing and hoping no one checks, but that is a strategy we will not entertain. Instead, there are several directions worth understanding, though this should not be construed as legal advice for your specific dataset.
Pseudonymization as a Stepping Stone
Pseudonymization involves replacing private identifiers with fake identifiers or pseudonyms. While it does not exempt your data from GDPR scope, it meaningfully reduces the severity of a potential breach and is often a required baseline before implementing further privacy measures.
Generalization and Suppression
This technique involves broadening specific values for example, changing an exact age to an age range and removing outlier records that make individuals stand out within small groups. This helps to obscure individual identities while retaining the dataset's overall utility.
k-Anonymity as a Design Target
k-anonymity is a structural approach where data is organized so that any individual within the dataset is indistinguishable from at least *k* other individuals concerning the identifying attributes that were retained. This provides a quantifiable measure of privacy.
Synthetic Data
Generating synthetic data involves creating statistically representative data that was never tied to a real person in the first place. This approach sidesteps the re-identification question entirely, rather than attempting to win the arms race against re-identification techniques. This is an exciting development in the field of data privacy, which is exactly why it will receive its own dedicated post.
As we navigate these complex regulatory environments, it is crucial to continually assess our own skills and the value we bring to our organizations. Understanding the nuances of data privacy is not just a compliance requirement; it is a strategic advantage. Take the time to evaluate your capabilities and consider taking calculated risks to elevate your expertise in this vital area. The market rewards those who can confidently guide their teams through these intricacies.
Coming Up
Next in our series: Differential privacy.
We will explore the one anonymization approach that provides an actual mathematical guarantee of privacy, rather than relying on a checklist or a promise.
---
This post is for general informational purposes and does not constitute legal advice. Anonymization adequacy is fact-specific. If you are unsure whether your data would hold up under regulatory scrutiny, our attorneys who specialize in data privacy are available to review your processes before you declare anything “anonymized” in a contract.
- The same dataset can be legally "anonymized" under HIPAA's Safe Harbor checklist while still being in breach of GDPR, because the two frameworks apply very different standards to the same word.
- GDPR anonymization requires that re-identification be impossible by any reasonably available means, including foreseeable future technology, a far higher bar than HIPAA's 18-identifier removal checklist.
- GDPR pseudonymization is meaningfully different from anonymization: if a key or lookup table could re-identify someone, the data remains personal data and GDPR obligations still apply.
- CCPA, Brazil's LGPD, and China's PIPL each define anonymization or de-identification slightly differently, so a dataset that clears one jurisdiction's bar can still fail another's.
- Much of what companies label "anonymization" is actually pseudonymization in disguise, since indirect identifiers like location, timestamps, or device IDs are often left behind, making re-identification a simple data-linking exercise.
- Practical mitigation options include pseudonymization as a baseline, generalization and suppression, k-anonymity as a design target, and synthetic data, which sidesteps the re-identification question by generating data never tied to a real person.
| The core trap | A dataset can be legally anonymized under HIPAA and still breach GDPR, because different regulators apply very different tests to the same word. |
|---|---|
| GDPR's bar | GDPR anonymization requires re-identification to be impossible by any reasonably available means, including foreseeable future technology, per Recital 26. |
| GDPR pseudonymization | If a key or lookup table could reverse it, the data is still personal data and GDPR obligations remain in force. |
| HIPAA's approach | HIPAA's Safe Harbor is a checklist requiring removal of 18 specified identifiers, not a general test of re-identification risk. |
| Other jurisdictions | CCPA uses a reasonableness standard, LGPD requires data not be reasonably capable of re-association, and PIPL requires the process be irreversible, with less developed guidance. |
| The common failure mode | Companies frequently call data "anonymized" when it's really pseudonymized, since indirect identifiers like ZIP code, timestamps, or device IDs are often left in place. |
| Mitigation techniques | Pseudonymization, generalization/suppression, k-anonymity, and synthetic data each offer different levels of protection and engineering complexity. |
| What's next in the series | The next post covers differential privacy, the one approach offering a mathematical guarantee of privacy rather than a checklist. |
Can data be "anonymous" under one law and not another?
Yes. A dataset can clear HIPAA's Safe Harbor checklist by removing 18 specified identifiers while still containing enough indirect identifiers, like ZIP code, birth year, and diagnosis code, to be re-identifiable under GDPR's much stricter standard.
What's the actual legal difference between anonymization and pseudonymization under GDPR?
Anonymized data must be impossible to re-identify by any reasonably available means. Pseudonymized data could still be re-identified using a key or lookup table, which means it remains personal data and GDPR obligations still apply to it.
Why do so many companies mislabel their data as anonymized?
Because direct identifiers are removed but indirect identifiers, such as location data, timestamps, or device IDs, are often left behind, making re-identification a matter of simple data-linking rather than a real cryptographic barrier.
What are the practical options if my "anonymized" data doesn't actually meet GDPR's standard?
Options include pseudonymization as a baseline step, generalization and suppression of identifying values, designing toward k-anonymity, or generating synthetic data that was never tied to a real person in the first place.
What's coming next in this privacy series?
The next post covers differential privacy, described as the one anonymization approach that offers an actual mathematical guarantee of privacy rather than relying on a checklist or a promise.
- A GDPR-Compliant Vendor Doesn't Automatically Mean Your Data Transfer Is LegalYour vendor says they're GDPR compliant. That doesn't mean your data transfer to the US is legal—those are two separate question
- Synthetic Data: The Most Exciting Privacy-Enhancing Technology, and the Most OversoldSynthetic doesn't mean private. Generative models can leak real records—here's what testing catches.
- Federated Learning: Great Idea and Expensive RealityMove the model, not the data. Great for privacy, expensive for infrastructure.