In short: Anyone who must or wants to inform customers after a data breach first decides with the data protection officer and a lawyer whether there is an obligation under Art. 34 GDPR, and clarifies whether business customers are controllers themselves. Then come customer groups, safe channels, prepared customer service and a closing message. Notices contain no login links, so that they do not become a template for phishing. This page is general information and not legal advice.
The email everyone dreads
The server is cleaned, the vulnerability closed, forensics has first results. Now a question is on the table that many managing directors would rather avoid: do we have to tell our customers? And if so, how, without doing more harm than the incident itself?
The situation around PHP2Shell has raised this question anew for many companies, even without a break-in. Websites were offline as a precaution, customers asked questions, and fraudsters, experience shows, use such situations for fake messages. How crisis communication is built in principle, in which order and with what content, is described in Crisis communication after an attack. This article goes one step deeper: the decision, the customer groups and the practical implementation.
Informing customers after a data breach: obligation or decision?
Art. 34 GDPR requires data subjects to be notified without undue delay when a personal data breach is likely to result in a high risk to their rights and freedoms. The notification describes the nature of the breach in clear and plain language and contains at least a contact point, the likely consequences and the measures taken or planned.
Art. 34(3) lists exceptions: where the data is, for example, unintelligible to unauthorised persons through encryption, where subsequent measures are likely to eliminate the high risk, or where notification would involve disproportionate effort; a public communication then takes its place. Whether one of these exceptions applies is a legal assessment in the individual case. It belongs with the data protection officer and a lawyer, as does the notification to the supervisory authority, see GDPR notification duty: 72 hours after the incident.
Even without an obligation, informing can make sense. Customers who learn about the incident from another source lose trust faster than those who hear it from you.
That leaves the question of timing. Anyone who informs too early may have to correct statements. Anyone who waits too long risks customers coming to harm in the meantime, for example through phishing with leaked addresses. A proven middle course: communicate early what is established and what customers can do themselves, and announce explicitly that further information will follow. “Without undue delay” within the meaning of Art. 34 does not mean waiting for the end of the investigation.
Which customers you reach, and how
Not all customers need the same message. Distinguish at least three groups:
| Customer group | Your role | What this means for the notice |
|---|---|---|
| Private customers with an account or order | usually controller | consider notification under Art. 34, plain language, concrete recommendations |
| Business customers whose data you use for your own purposes | usually controller | factual notice to named contacts, context for their own obligations |
| Business customers for whom you process data on their behalf | processor | notice without undue delay under Art. 33(2), support with their notifications |
The third group is often overlooked. If you operate shops or portals for customers, for example, they are generally controllers themselves and must meet their own notification duties. For that, they need your information quickly and completely.
Choosing channels without promoting phishing
The safest channel is one that customers already know. These have proven their worth:
- Email from the usual sender address, without login links and without attachments, with a note to visit the website yourself.
- A notice after login in the customer account, as soon as the system is running securely again.
- A notice on the website, as a public supplement or, where Art. 34(3) provides for it, as a public communication.
- A letter for customers without a current email address or for particularly sensitive data.
- Phone and customer service as a point of contact for questions, with a number that customers already know from your website or invoice.
State explicitly in every notice that you will never ask for passwords, codes or payment details by email or phone. After known incidents, fraudsters like to send messages that look like yours.
From the decision to the closing message
This is what the process can look like in practice:
- Record the facts: what is proven, what is probable, what is unknown. Only what is proven goes out.
- Obtain a legal assessment: obligation under Art. 34, role towards business customers, coordination with the notification to the authority.
- Define customer groups and channels, pull the distribution list from your own system, not from a possibly manipulated copy.
- Prepare customer service: internal questions and answers, a clear line to take, escalation of difficult cases to a named person.
- Formulate recommendations for customers: for example change the password if credentials might be affected, and watch for suspicious messages.
- Send and document: who was informed, when and through which channel.
- Follow up: communicate new findings and send a closing message when the investigation has ended.
Anyone who has defined the contact routes internally in advance saves a lot of time here, see Emergency contacts: who must be informed, and when?. Technical steps that should precede the notice are summarised in the checklist after a hack.
How does PHP SOS help?
- We deliver the technical facts of the incident prepared so that the data protection officer and lawyer can assess the obligations.
- We check your customer notices for technical accuracy and to make sure they give attackers no hints.
- We make sure that distribution lists and customer accounts come from a cleaned system before you send.
- Through incident response, we supply the findings for follow-up and closing messages at the agreed pace.
Conclusion: Good customer information is legally reviewed, separated by group, sent through safe channels and carried through to the end. This page is general information and not legal advice; you make the decision in the individual case with the data protection officer and a lawyer.
Frequently asked questions
When must I inform customers after a data breach?
Under Art. 34 GDPR, when the breach is likely to result in a high risk to the rights and freedoms of the data subjects. There are exceptions, for example where the data is effectively encrypted. You make the assessment with the data protection officer and a lawyer; this page is not legal advice.
What applies if I process data on behalf of my business customers?
Then your customers are usually controllers themselves. Under Art. 33(2) GDPR, the processor informs the controller without undue delay after becoming aware of a personal data breach. The notification to the authority and to data subjects remains a matter for your customer.
May I inform customers even though there is no obligation?
Yes. A voluntary notice can make sense, for example if the website was taken offline as a precaution because of PHP2Shell or customers are asking questions. It is important to state only established facts and not to give a premature all-clear.
How do I prevent fraudsters from imitating my notice?
Leave login links and attachments out of the notice, refer to your well-known website and state explicitly through which channels you will never ask for passwords or payment details.