# Do I have to tell my customers and the regulator after a hack

> A compromised online shop handles names, addresses and purchase histories. The GDPR sets out precisely what the data controller must do, within what deadline, and when nothing needs reporting at all.

- Source canonique : [https://allaux.fr/en/securite/dois-je-prevenir-mes-clients-et-la-cnil](https://allaux.fr/en/securite/dois-je-prevenir-mes-clients-et-la-cnil)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Before any decision, establish what was made accessible: which tables held personal data — customer accounts, addresses, order histories — and which of them were within reach of the compromised component. Use the host access log to place the incident in time. Keep the internal breach register, including for an incident you decide not to notify.

## I’m not a lawyer

> I’m a developer. What follows is the guidance published by the French data protection authority, the CNIL, together with Articles 33 and 34 of the GDPR, applied to the very concrete case of a compromised online shop. On a high-stakes incident, have your assessment reviewed by a lawyer or your data protection officer. What I contribute is the technical half: scoping what was reachable and when, without which no legal assessment is possible.

## What the GDPR calls a personal data breach

The definition is broader than most merchants assume. A personal data breach is a security incident leading, accidentally or unlawfully, to the destruction, loss, alteration or unauthorised disclosure of personal data.

Three practical consequences, routinely misunderstood:

Theft isn’t required. An order table wiped by an attacker, or made unusable by encryption, already counts.

Intrusion isn’t required. Log files containing customer names, addresses and phone numbers, simply readable from outside, are an unauthorised disclosure. The May 2026 advisory on the upsshipping module for PrestaShop explicitly asks affected merchants to assess their GDPR obligations.

Fault isn’t required. The obligation sits with the data controller — you — whatever the technical origin of the incident.

Conversely, not every security incident is a data breach: a defaced home page, with no access to the database or to files holding personal data, isn’t one. The line is drawn on the data, not on how alarming it felt.

## When the 72 hours actually start

The deadline for notifying the competent supervisory authority is 72 hours from the moment you become aware of the breach. It’s that starting point that causes trouble in practice.

Becoming aware doesn’t mean having finished your analysis, or being certain data left. The clock starts once you have a reasonable degree of certainty that a security incident affecting personal data has occurred — the day you find a tampered plugin or a foreign file that had database access, not the day your consultant hands you a report.

The GDPR explicitly covers unfinished analysis: notification can be made in phases, with the information available, then completed. And if the deadline is missed, the notification must set out the reasons for the delay. A late, explained notification beats no notification.

## Three scenarios, and what each triggers

1. **No risk to individuals** — No notification to the authority, no notice to customers. But the incident must still be recorded in your internal breach register, along with the reasoning that led to that conclusion. Failing to justify it is itself a breach of your obligations.
2. **Risk to rights and freedoms** — Notify the supervisory authority within 72 hours. No individual notice required. This is the most common case on a shop: identity and order data were reachable, without it being established that they were used.
3. **High risk** — Notify the authority and inform the individuals concerned without undue delay, with concrete protective advice: change a password reused elsewhere, watch bank statements, be wary of messages claiming to come from your shop.
4. **In every case: the register** — Nature of the breach, categories and approximate number of people affected, likely consequences, measures taken. The register stays internal — it isn’t submitted — but it must exist and be producible.

## Working out which scenario you’re in

This is where the technical work drives the legal decision. Risk assessment depends on the nature of the reachable data, its volume, how easily individuals can be identified, and the plausible consequences for them.

Recent incidents illustrate the gradient. A backdoor exfiltrating technical credentials and a plugin inventory, like the flaw fixed in March 2026 in the Gravity SMTP plugin, doesn’t touch your customers directly — but it opens other doors, and the question becomes what was done next with those keys. At the other end, the payload described in June 2026 in a WordPress plugin publisher’s distribution-chain compromise extracted the last three months of WooCommerce orders: there the named scope is clear, and dated. And when code captures card details as they are typed, as in the double-form theft Sansec documented in February 2026, you are in the heaviest case, with a duty to inform customers and to alert your payment provider.

One point that matters: customer passwords being stored as hashes is a mitigating factor, not an exemption. The GDPR allows exemptions from individual notice in particular where data was encrypted with uncompromised keys, where later measures removed the risk, or where contacting everyone would take disproportionate effort — but it is on you to show you fall into one of those cases.

## What to write to customers, and in what tone

The notice to affected individuals is neither a press release nor an apology. It should describe the nature of the breach in plain terms, state the likely consequences, give a point of contact, set out the measures taken and planned, and above all give recommendations the person can act on themselves.

Three mistakes I see regularly: playing it down so far that the customer doesn’t realise they need to act; sending something so generic it reads like a phishing attempt itself; and waiting until everything is understood before writing anything. A short, dated notice that is precise about what was and wasn’t affected beats three weeks of silence.

The channel matters too. If your own email system was affected, send from somewhere else and say so — it stops your legitimate notice being taken for the next stage of the attack.

## Related reading

- **Checking whether your site is compromised** — The technical checks for scoping the breach — the prerequisite for any risk assessment. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **What to do in the first two hours** — The order of priorities, including preserving the logs everything else depends on. ([/securite/que-faire-dans-les-deux-heures](/securite/que-faire-dans-les-deux-heures))
- **Staying protected after a clean-up** — The measures you’ll be able to cite in your notification as corrective action taken. ([/securite/se-proteger-apres-un-nettoyage](/securite/se-proteger-apres-un-nettoyage))

## FAQ

### I’m not sure any data left. Should I still notify?

Notification is due once the breach presents a risk to people’s rights and freedoms, not only when exfiltration is proven. Since exfiltration is rarely demonstrable, the reachable scope is what the assessment rests on. If you conclude there is no risk, you notify nothing — but you must be able to justify that reasoning.

### Do the 72 hours run from the intrusion or from finding it?

From becoming aware, meaning the point at which you have a reasonable degree of certainty that an incident affecting personal data occurred. An intrusion that happened three months ago and is found today leaves 72 hours from today.

### Should my host or my agency notify on my behalf?

No. The duty to notify the authority sits with the data controller, meaning whoever runs the shop. A processor who spots a breach must inform you without delay, but you are the one who notifies.

### My customers’ passwords are hashed — does that let me skip telling them?

Not automatically. The GDPR allows an exemption from individual notice where data was rendered unintelligible, for example encrypted with uncompromised keys. Strong hashing is a serious mitigating factor, but it covers neither order data held in clear nor weak passwords reused elsewhere.

### What happens if I don’t notify?

Failing to notify and failing to document are themselves sanctionable, independently of the original technical flaw. Many merchants discover this too late: having no register is a breach of your obligations, even where the incident itself didn’t need reporting.