Seven enforcement cases about what a third party held — not about hackers

Why these seven

Ask most boards what a data-protection fine looks like and they picture a breach.

An attacker, a ransom note, a press statement.

The decisions below are mostly not that at all.

In five of the seven, nobody broke in.

A company took data it lawfully held and put it in someone else's hands.

A partner, an ad platform, a data warehouse.

And it did that for a purpose the people in the data hadn't been told about, or a supplier kept real records it should never have held, or an analytics tool quietly sent identities along with everything else.

In the two that did involve an attacker, the finding that mattered was what the supplier was holding when the attacker arrived.

Think of it like a burglary at a self-storage unit.

The police will ask about the lock. But the size of the loss was decided long before, by what you chose to leave in there.

The cases below describe different failures: purpose, transparency, retention and security. They are prompts for reviewing a data flow, not evidence of how a particular product would have changed the outcome.

One rule runs through all of it.

Pseudonymised data stays personal data for whoever can reverse it. The duty to tell people applies at collection, whatever the recipient can see.

No technical control would have made these fines impossible. What changes is what a third party ever holds.

1. Amadeus (AEPD, €18 million, May 2026)

Amadeus reused traveller booking records to build travel-history profiles and shared the results with hotel-chain partners in a 2021 to 2022 pilot.

There was no lawful basis for the new purpose (Article 6, €9m) and no notice to travellers (Article 14, €9m).

There was no Article 6(4) compatibility assessment either, and the data was kept beyond Amadeus's own limits.

What did the recipient hold?

Profiles of identifiable travellers.

Pseudonymisation is a safeguard Article 6(4)(e) names in the compatibility test. It does not supply the lawful basis or the notice that were missing.

2. A loyalty programme and a social network (CNIL, €3.5 million, December 2025)

Since 2018 a French retailer had systematically sent the email addresses and phone numbers of its loyalty-programme members, more than 10.5 million people in all, to a social-media platform so that it could target advertising at them there.

The CNIL found no valid legal basis under Article 6 and no information about the transfer on the sign-up form or in the privacy policy.

Sixteen European authorities co-signed the decision.

What did the recipient hold?

Real contact details, matched against the platform's own accounts.

Would pseudonymisation have changed that?

Hardly at all, and it's worth saying so!

Ad-platform matching needs the real identifier.

There's no version of this processing that works on stand-ins. This is a case where the honest answer is a valid basis and proper information, or not doing it at all.

Not every sharing problem is a pseudonymisation problem. Some are just sharing problems.

3. Mobius Solutions (Optimove) and Deezer (CNIL, €1 million, December 2025)

A marketing-technology processor kept a copy of 46.9 million Deezer users' data after its contract ended.

It processed that data without the controller's instructions (Article 29) and kept no records of processing (Article 30).

The copy later surfaced in a breach.

What did the recipient hold?

A full, real user base, years after it should've been deleted.

The retained copy and the deletion process both deserve review. Replacing some fields would not excuse retaining records without instructions, and the remaining context could still identify people.

4. IQVIA's health data warehouses (CNIL, €5 million, May 2026)

IQVIA operated two authorised health-data warehouses fed by pharmacies and doctors, and it described the data as anonymous.

The CNIL found it was pseudonymous.

Year of birth, sex, prescriptions, diagnoses and a stable patient identifier meant re-identification was possible with reasonable means. The pharmacies' customers had never been told their data was transferred (Article 14).

And security controls on the warehouses were found wanting too.

What did the recipient hold?

Detailed health records the operator believed were outside the regulation.

They weren't. Not close.

This case is a warning rather than an advertisement.

It's exactly why Synthaveil never describes its output as anonymous and never claims a compliance outcome.

Stable identifiers plus rich attributes are re-identifiable.

Replacing identifiers before data leaves narrows that risk. The data stays personal in the sender's hands, and the duty to tell people stands.

5. LinkedIn (Irish DPC, €310 million, October 2024)

LinkedIn processed members' data for behavioural analysis and targeted advertising without a valid lawful basis.

Consent was found not to be freely given, informed, specific or unambiguous. Legitimate interest was rejected.

Transparency fell short (Articles 6, 13 and 14).

The inquiry began with a 2018 complaint.

What did the recipient hold?

Here the "recipient" was the controller's own advertising machinery and its partners.

A reminder that reuse inside a group is still reuse.

For analytics and modelling over behaviour, analysis can often run without the identities travelling. The beauty of Synthaveil is that you keep all the statistical nuances that make the data meaningful, without revealing a single individual.

It changes nothing about the basis for showing an ad to a real person.

6. Apoteket and Apohem (IMY, Sweden, SEK 37 million and SEK 8 million, July 2025)

Two Swedish online pharmacies ran Meta's Pixel analytics tool on their websites with a matching feature switched on.

It sent Meta identifiable customers' purchases, including over-the-counter treatments for specific conditions, self-test kits and treatments for sexually transmitted infections.

Neither company had procedures that would've caught it. Outsiders did.

The finding was Article 32 security failings.

What did the recipient hold?

An advertising platform holding real customers matched to sensitive health purchases.

This is the cleanest "analytics provider received real identities" case of the seven.

A reduced analytics feed needs evaluation against its purpose and remaining identifying information. Removing a name does not establish that a platform cannot match the record.

Whether such a feed is a good idea at all for health purchases is a separate question.

But the harm was defined by the identities that travelled.

7. Advanced Computer Software (ICO, £3.07 million, March 2025)

The ICO's first fine against a processor under UK GDPR.

A ransomware attacker entered through a customer account without multi-factor authentication and took the personal data, including health data, of 79,404 people.

The supplier held it on behalf of NHS bodies and others. Article 32 security failings again.

What did the recipient hold?

Real patient records, at a supplier, reachable through one un-hardened account.

The supplier still needed MFA.

Nothing about pseudonymisation excuses that.

But the exposure the attacker walked away with is defined by what the supplier held.

A supplier may need real patient information to provide its service. Review necessity alongside access controls, and assess every retained copy.

Questions to take into your own review

Area	What to check
Purpose and transparency	Does this use have the required basis, and have people been informed?
Retention	Which copies remain, who holds them, and how is deletion checked?
Identification	Could direct identifiers or combinations of attributes identify someone?
Security	Are access controls, authentication and monitoring appropriate for the actual data?

Assess these together. Pseudonymisation can be a safeguard, but it does not replace purpose, transparency or security decisions. Synthaveil can help prepare selected identifying fields for the identification check; review the output and keep those decisions alongside it. These cases do not establish that substitution would have prevented a fine or exposed no one.