In a high-risk data breach, GDPR says to tell everyone affected, not only your users

In the last days of June 2025, an attacker logged in to the patient record system of Hôpital Privé de la Loire, a private hospital in France, using the account of a single outside doctor. The login needed only a password. Over five days the attacker read 524,867 patient files, about 73 a minute, and nobody noticed. The hospital later emailed, texted or wrote to its patients. It did not write to the 202,246 people those patients had named as trusted contacts, although their names, phone numbers and relationship to the patient had been taken too. The CNIL, France's data protection authority, fined the hospital 500,000 euros, and one of its two findings was that silence 1. Under GDPR Article 34, everyone whose data is taken and who faces a high risk has to be told, directly wherever the company can reach them, not only its customers.

I think the notification finding is the one worth studying, because it is the easiest to repeat. Weak logins get fined every year. Forgetting that a database holds people who never signed up is a mistake almost any product can make: the invitee who never accepted, the emergency contact in an HR tool, the friend entered for a referral credit. Nobody sees those people in the user count.

What happened at Hôpital Privé de la Loire?

The attack came to light on 1 July 2025, when an outside doctor contacted the hospital to say they could no longer log in 1. The hospital did the regulator side properly. It notified the CNIL three days later, and the CNIL found no failing under Article 33, the rule that sets the 72-hour deadline for that report 2. It then told patients by email, text message and letter, about 424,000 messages in all, plus a notice on its website 1.

The other finding was security, under Article 32, where the CNIL listed five failings 1. The three behind the attack, as the CNIL's English summary puts them: about 450 external users logged in with a password alone, although the software already offered multi-factor authentication; any account could open every patient's file; and nobody analysed the access logs, so 73 files a minute for five days raised no alert.

Why did the hospital have to write to the trusted contacts?

Because they were data subjects in the breach, and the risk to them was high. Article 34(1) requires a controller to tell the people affected "without undue delay" when a breach is likely to result in a high risk to them 2. It does not limit that duty to customers, patients or account holders.

A trusted contact is someone a patient names on admission, often a spouse, parent or friend, whom the hospital can call. The hospital held their name, phone number, sometimes a postal address, and their relationship to the patient.

The hospital's defence was its own risk assessment 1. It said the data was fragmentary, usually a name, a phone number, the relationship and a yes/no flag, and not laid out in a structured way, so the breach did not put these people at high risk.

The CNIL disagreed with the conclusion 1. It found that the stolen data exposed these people to serious risks, naming phishing campaigns and identity fraud, including attempts to carry out administrative formalities in the name of a patient who has died. A caller who knows someone's name, their number, and that their mother was a patient at a named hospital has most of what a convincing scam needs.

The hospital had also put a notice about the breach on its website. The CNIL held that a breach communication must in principle be direct, and that the trusted contacts, never having been treated at the hospital themselves, had even less reason than patients to visit its website. It also pointed out that the hospital held their phone numbers and could have texted them, as it had texted patients.

The European Data Protection Board (EDPB), where the EU's national regulators agree common guidance, says the same in its guidelines on breach notification. They state that "a notification solely confined within a press release or corporate blog would not be an effective means of communicating a breach to an individual", and that direct channels such as email, SMS or post come first 3. Article 34(3)(c) allows a public notice instead only where direct contact would involve disproportionate effort 2, and a controller that already holds a phone number for each person will struggle to show that.

Who else counts as affected in a breach?

Anyone whose personal data sat in what the attacker reached. Who has to tell them depends on the company's role. For a controller, Article 34 is its own duty. A processor, holding the data on a business customer's behalf, must under Article 33(2) tell that customer without undue delay, and the customer notifies the people 2. Either way, somebody has to know these people exist. A trusted contact in a hospital system has close equivalents in ordinary software:

• Invitees: email addresses a user typed in to invite a colleague who never signed up.
• Emergency contacts and dependants: in HR, payroll, childcare and travel products.
• Referrals and shared contacts: a friend's details entered to claim a referral credit.
• People inside uploaded content: names in a CV, a contract, a support attachment or a spreadsheet import.
• Recipients: the other side of a message, an e-signature request or a shared invoice.

Each group raises the same two questions the hospital failed to ask. Would this data, in an attacker's hands, put these people at high risk? And does the company hold a way to reach them?

The threshold is high risk, which is higher than the threshold for telling the regulator 3. An email address on its own may fall below it. A name tied to a relationship, a health condition or money usually will not.

I wrote about the regulator side of this, the report a company files within 72 hours, in the post on the EDPB's 100-field breach template. That template asks for the categories of people affected. The hospital case shows what happens when a category is left out of the list.

What should a product that holds data about non-users do?

If you run a product that stores data about people who are not your users, and those people are in a breach that puts them at high risk, not telling them is a separate infringement, as it was for the hospital. Here is what I would do before that happens.

• List the non-users. Go through your schema and note every table or field that holds data about someone other than the account holder, and whether that data would put them at high risk if stolen. Invitees and contacts are the usual first finds.
• If you are a processor, name the groups in your DPA. Article 28(3) already requires the contract to list the categories of data subjects 2. Put invitees, recipients and people in uploads there, and name the affected groups in your first message to customers after a breach.
• Record how you would reach them. For each group, write down the contact channel you hold. Where you hold none, note that a public notice is your fallback under Article 34(3)(c), and say where it would appear.
• Put the list in your breach runbook. When an incident happens, the first scoping question should be which groups of people were in the affected data, not how many accounts.
• Close the gaps the hospital had. A second factor on every external or administrative login (the hospital had this feature and postponed it), access scoped to the records a person needs, and an alert on bulk reads. The CNIL's guide to cybersecurity under the GDPR covers the same basics.

The list goes stale each time a pull request adds a new contact field. Lawcel, the compliance tool we build, reads each pull request against your legal documents, so a change that starts storing data about a new group of people is flagged in review. That flag is your cue to add the group to the list.