The pattern repeats itself: a company invests in de-identification tools, processes the data, declares it anonymous, and then a regulator disagrees. Italy's Garante per la protezione dei dati personali fined IQVIA Solutions Italy 7 million euros in September 2025 for treating health records as anonymous when they remained identifiable. France's CNIL reached the same conclusion about IQVIA's French operations in May. Two countries, same company, same mistake.
These aren't isolated incidents. The failures reveal structural problems in how organizations approach anonymization, affecting eDiscovery transfers, analytics platforms, and cross-border data flows. The mistakes aren't technical; they're conceptual, stemming from misunderstandings about what anonymization requires under GDPR.
Why These Mistakes Persist
Anonymization seems like a technical problem, so teams treat it as one. You hash identifiers, suppress some fields, aggregate the rest, and check a box. However, GDPR Article 4(5) defines anonymous data by what a recipient cannot do with it: single out an individual, link records to a person, or infer information about them. This is a legal standard, not a technical one, and it depends on context, who holds the data, what else they can access, and what means they could reasonably use.
Another reason these mistakes persist is the confusion between pseudonymization and anonymization. Pseudonymized data is still personal data under GDPR. It separates the identifier from the rest of the record. Anonymization goes further, removing the ability to re-identify anyone by reasonable means. The difference matters because pseudonymized data still triggers all of GDPR's obligations: legal basis, transparency, security, retention limits, and impact assessments.
Mistake 1: Treating the Dataset as Anonymous Because You Can't Reverse the Hash
Why it happens: Your vendor replaces patient IDs with random codes. The re-linking key stays with the data source. You never see the original identifiers, so you assume the data is anonymous in your hands.
The consequence: The Garante rejected this argument. IQVIA received health records with a persistent patient code (Pat ID) but no key to reverse it. The regulator found the data identifiable because each patient appeared multiple times across prescriptions, diagnoses, symptoms, tests, and vaccinations. A clinical history observed over years can identify a person. The persistent code let IQVIA single out individuals and trace their medical trajectories, which is enough.
The fix: Ask what the rest of the record contains. If you can follow a unique individual over time through their attributes, even without knowing their name, you're holding personal data. The Court of Justice's September 2025 ruling in EDPS v. SRB (Case C-413/23 P) confirmed that pseudonymized data can be anonymous for a recipient who lacks the means to re-identify anyone. But that only applies if you genuinely can't single people out. A longitudinal record with a persistent code fails that test.
Mistake 2: Accepting an Affiliate's Risk Assessment Without Independent Verification
Why it happens: You commission a re-identification risk assessment from a privacy analytics vendor, often one in your own corporate group. The assessment scores the risk as low. You rely on that conclusion and move forward.
The consequence: The Garante credited IQVIA's risk assessments as a mitigating factor, then faulted the company for accepting them passively. The assessments came from Privacy Analytics, part of the IQVIA group. The regulator noted that IQVIA had not challenged the conclusions or re-examined its position after earlier rulings in Italy and France found similar datasets pseudonymous.
The fix: Treat anonymization assessments like audit reports. Get independent review. Ask the assessor to show their work: what quasi-identifiers they tested, what equivalence-class sizes they used, what they did with free-text fields and outlier records. If your legal team can't explain the method to a regulator, the assessment isn't defensible. And if the same regulator has already rejected a similar claim, by you or anyone else, you need a documented reason why your case is different.
Mistake 3: Assuming You're Just a Data Recipient When You Designed the De-identification
Why it happens: You contract with data sources to send you de-identified records. The sources run the anonymization on their own systems. You never touch the raw data, so you assume you're a processor or a downstream recipient, not a controller.
The consequence: IQVIA made this argument. The Garante found otherwise. Contracts showed that IQVIA supplied the extraction software to doctors, contracted with the developer, and instructed that developer on how the data would be de-identified. The regulator concluded that IQVIA controlled the entire processing chain from the moment of collection. That put the company outside the SRB safe harbor, which applies only to recipients who don't determine the means of pseudonymization.
The fix: If you specify the de-identification method, you're a controller for that processing. GDPR Article 4(7) defines a controller as anyone who determines the purposes and means of processing. Designing the anonymization pipeline counts. Your contracts should reflect that role, and your legal basis, transparency obligations, and impact assessments must cover the de-identification itself, not just what you do afterward.
Mistake 4: Ignoring the Data You Didn't Pseudonymize
Why it happens: You focus on the fields you designated as quasi-identifiers, age, location, diagnosis codes, and apply k-anonymity or similar techniques to those. The rest of the record stays intact because it's "clinical data," not identifying data.
The consequence: K-anonymity applied to quasi-identifiers leaves the rest of the record untouched, the Garante wrote. A detailed clinical history is itself identifying. In IQVIA's case, doctors had also typed names, tax codes, addresses, and contact details into free-text fields. The extraction tool pulled those fields, and directly identifying data for 3,370 patients reached IQVIA. The regulator held the company responsible for failing to verify that the tool skipped free text.
The fix: Map every field. For each one outside your designated quasi-identifiers, decide: Does it go into the equivalence classes? Does it get processed through secure multiparty computation or a similar technique that keeps the full data out of your hands? Or does it get removed? The Garante's remedy order to IQVIA spelled out those three options. If you pass the data on to another party, the same obligations apply. And run automated checks on incoming data to flag free-text content or outliers that your method didn't catch.
Mistake 5: Skipping the Legal Basis for the Anonymization Step Itself
Why it happens: You treat anonymization as a compliance exit. Once the data is anonymous, GDPR no longer applies, so you don't need a legal basis for holding it. You focus on the legal basis for the original collection, not for the de-identification.
The consequence: The Garante treated anonymization as processing in its own right. It required IQVIA to establish a legal basis for the anonymization, inform patients, and complete a data protection impact assessment. The decision also noted that IQVIA had retained data going back to 2001 without defining retention periods.
The fix: Document the legal basis for the de-identification processing. If you're anonymizing under Article 6(1)(f) (legitimate interests), complete a balancing test. If you're doing it under Article 9(2)(j) (public-interest research), confirm you meet the conditions. Inform data subjects that their data will be de-identified, how, and for what purpose. And set retention limits for the pseudonymized or intermediate data you hold before the anonymization is complete.
Prevention Checklist
Before you label a dataset anonymous:
- Document who designed the de-identification method and who controls the processing chain
- Identify all fields in the record, including free text, and decide what happens to each one
- Confirm equivalence-class sizes (the Garante required no fewer than 10)
- Test whether you can single out individuals or link records using the data you retain
- Get independent review of your re-identification risk assessment
- Establish a legal basis for the anonymization processing itself, not just the original collection
- Inform data subjects and complete a GDPR Article 35 impact assessment
- Run automated checks on incoming data to catch identifiers your method missed
- Review recent regulatory decisions on anonymization claims in your sector and jurisdiction
- If a regulator has rejected a similar claim, document why your case differs
The Garante's decision is one national ruling, and IQVIA has reserved the right to challenge it. But the reasoning travels. If your eDiscovery transfer, analytics corpus, or research dataset rests on a de-identification claim, and you can't answer these questions, you're holding personal data. Treat it accordingly.
