When customers learn about a breach from a journalist, a Reddit thread, or a fraud alert from their bank before they hear it from you, the damage to trust is usually worse than the breach itself. This guide covers how to communicate a security incident to customers: when to notify, what to say, which legal clocks apply, and how to avoid the mistakes that turn a contained technical problem into a reputational one. It is written for developers, security leads, and site owners who may have to write that message one day, possibly at 2 a.m. with incomplete facts.
Why the First Message Matters More Than the Perfect One
Customers forgive incidents more readily than they forgive silence or spin. A short, honest notice sent early lets them protect themselves by resetting passwords, watching card statements, and ignoring phishing emails that copy your branding. A polished statement that arrives three weeks late gives them none of that.
There is a practical benefit too. Clear early communication cuts support ticket volume. Without it, the support team ends up improvising answers, and every improvised answer becomes something you have to correct later.
Legal Deadlines That Set the Pace
Before anyone drafts a word, an experienced incident lead works out which notification clocks are running. Under GDPR Article 33, the supervisory authority must be notified within 72 hours of becoming aware of a personal data breach. Article 34 adds a separate duty to inform affected individuals “without undue delay” when the breach is likely to result in a high risk to their rights and freedoms. The timing details are covered in our guide to GDPR breach notification timelines.
Other regimes can apply at the same time. Entities in scope of NIS2 owe their CSIRT or competent authority an early warning within 24 hours, a full notification within 72 hours, and a final report within one month. US-listed companies have to file Form 8-K Item 1.05 within four business days of deciding an incident is material. In the US, each state has its own breach law, with different deadlines and content requirements. If payment card data is involved, PCI DSS obligations and your acquirer’s contract usually require prompt notice to the acquirer and the card brands.
There is an important exception. Notifying the regulator and notifying customers are separate decisions. Encrypted data whose keys were not exposed often doesn’t trigger the duty to notify individuals under GDPR. In a single-tenant B2B deployment, the contract may make your client responsible for notifying its own end users. Read the data processing agreement before you email someone else’s customers.
A Realistic Scenario: The Friday Skimmer
Here is a pattern most e-commerce teams will recognize. On a Friday afternoon, an integrity check flags an unfamiliar script on the checkout page. It loads from a lookalike domain that was registered three weeks earlier. Server logs show the injected code went live nine days ago, through an outdated plugin on a WooCommerce store.
During those nine days, roughly 1,400 orders went through checkout. The team removes the script within an hour. The harder question is what to tell 1,400 customers whose card details may now be on a carding forum.
An effective response looks like this. Logs and the injected file are preserved before cleanup, following the steps in preserving evidence after a compromise. That evidence matters because it lets the team state the exposure window with confidence. The acquirer is told the same day. By Monday morning, affected customers receive an email naming the dates, the data involved (card number, expiry, CVV, billing address), and what was not involved (stored passwords, because the skimmer only captured form fields). The email tells them to contact their bank. A support FAQ page goes live at the same time, so agents and customers are working from the same information.
Step-by-Step: Writing the Customer Notice
Plain language works better than legal language. A seasoned communications lead builds the notice around five elements:
1. What happened – one or two sentences, without jargon. “Malicious code was added to our checkout page” is better than “a third-party script integrity anomaly.”
2. When – exact dates and times, including the time zone. If you don’t know the start date yet, say so and give the earliest date you can confirm.
3. What data was affected – list the specific fields, and say what was not affected.
4. What you have done – containment, reporting to authorities, and any outside forensics firm you have brought in.
5. What customers should do – concrete actions, plus a contact channel staffed by a real person.
Send the notice from your normal domain, with SPF, DKIM, and DMARC all passing. Don’t put login links in it. Attackers often follow a breach with phishing that imitates the real notice, so tell customers to go to your site directly rather than clicking links. For international customers, translate the notice. An English-only email to a Finnish or German customer base gets misread or ignored.
The Myth of Waiting Until You Know Everything
A common belief is that a responsible company says nothing until the forensic investigation is finished. In practice, investigations take 4-12 weeks, and regulators and customers will not wait that long. GDPR explicitly allows notification in phases: you can give what you know now and add details later.
The better approach is to commit to update intervals, for example every 48 hours until the incident is closed. Telling people “We’ll update this page by Wednesday at 17:00 UTC” earns more trust than going silent for a month.
Common Mistakes That Make Incidents Worse
Minimizing words that later turn out to be wrong. Writing “a small number of users” before the scope is known leaves you to retract it when the number grows tenfold. Use only figures you can stand behind, and put a date on them.
Letting legal write the whole message. Counsel should review the notice, but a customer email written entirely in defensive legal language reads like evasion. Draft it in plain English first, then have legal check it for accuracy.
Having no pre-approved channel or owner. Teams waste hours arguing over who sends the email and from which system. Decide this in advance in an incident response runbook, including template drafts and named approvers, so nobody is improvising in the moment.
A fourth, quieter mistake is promising “this will never happen again.” No honest security team can make that promise. Describe the specific controls you added instead.
FAQ
Do I have to notify customers if no data was actually stolen?
Not always. If you can show the attacker had no access to personal data, or the data was strongly encrypted and the keys were not exposed, notifying individuals may not be legally required. Record your reasoning either way, because regulators may ask for it.
Should the notice go out before the vulnerability is fixed?
Normally you should contain the issue first, but containment should take hours, not days. If customers need to act right away, for example to cancel compromised cards, notify them in parallel with remediation rather than waiting for a full patch.
Who should sign the customer notification?
A named senior person, usually the CEO or the head of the affected business unit. A notice signed by “The Team” comes across as anonymous and undermines the accountability the message is meant to show.
Final Practical Tip
Write your notification templates now, while nothing is on fire. Have legal pre-approve them, store them somewhere that stays reachable if your main systems are down, and practise with them once a year in a tabletop exercise. When a real incident happens, you will only have to fill in facts, not argue over wording. That is often what makes it possible to send a clear notice within 24 hours instead of a defensive one 10 days later.