Telling your customers about a breach

There is a moment in every serious data incident when the technical work pauses and a harder question takes the room: what do we tell people, and when? It is the moment companies most want to postpone, and the one they are judged on longest. Years later, nobody outside your team will remember your containment strategy. Everyone will remember whether you told them straight.

Most of what is written about breach notification is about the regulator — the 72-hour filing. That letter matters, but it is one letter, and a lawyer can help you write it. This piece is about the harder, less-regulated audience: the customers whose data it was. Who must be told, when, in what words, and the specific ways good companies get this wrong under pressure.

Three audiences, three different clocks

The single most useful thing to understand in advance is that "notification" is three separate duties that arrive on different schedules:

The regulator. Under the General Data Protection Regulation (GDPR), a personal-data breach that poses risk to individuals must be reported to the supervisory authority within 72 hours of your becoming aware — a clock with its own rules about when it starts. Other regimes have cousins of this duty; some United States state laws and sector rules run on different definitions and timelines.

The people whose data it is. GDPR Article 34: when the breach is likely to result in a high risk to individuals, you must tell them directly, "without undue delay," in clear and plain language. Note the asymmetry — the regulator threshold is lower than the individual threshold, so filing with the authority while lawfully not notifying individuals is a real and common outcome. But where individuals could protect themselves by acting — changing a password, watching a card statement — delay has a cost measured in their losses.

Your business customers. Here is the clock small vendors forget: if you sell to businesses, your contracts almost certainly contain breach-notice clauses — and business-to-business data-processing agreements commonly promise notice within 24, 48, or 72 hours of awareness. Those promises frequently run shorter than the regulatory clock, and missing them is a contract breach layered on top of a security incident. In the first hours, while the technical team investigates, someone should be pulling the notice clauses from your top contracts. In a business-to-business incident this list, not the regulator, usually determines your real deadline.

What a good notice contains

Every good breach notice, to any audience, answers five questions in order. Plain language is not a courtesy here — for individual notifications under GDPR it is a legal requirement, and for everyone it is the difference between a notice that helps and a notice that frightens:

What happened. Two or three sentences, no technology tour. "Someone gained access to a database containing customer contact details between the 12th and the 14th. We discovered it on the 14th and closed the access the same day."

What data was involved — and what was not. Be specific in both directions. "Names, email addresses, and billing addresses. No passwords and no payment-card numbers were involved." If you do not yet know, say what you know now and when you will update. The "not involved" sentence is the one readers scan for; earn it carefully, because you will live with it.

What we have done. Contained, revoked, engaged investigators, notified the authority. Short, factual, no adjectives.

What you should do. The actionable core: reset this password, watch for these phishing emails (breach notices are reliably followed by scam waves impersonating you — warn people), check that statement. If there is genuinely nothing for the reader to do, say so plainly; it is the kindest sentence in the letter.

Where to ask questions. A named channel with a human behind it — and brief your support team before the notice goes out, with a short answers sheet. The notice lands on your helpdesk within minutes; a support team reading it for the first time alongside customers compounds the harm.

The failure modes, named

The ways breach communications go wrong are so consistent they have become clichés. Under pressure, each will present itself as the reasonable option:

The minimising notice. "Out of an abundance of caution, we are informing you of a security event affecting a limited subset of users." Three hedges in one sentence, and the reader trusts none of them. If it was bad enough to write to them, write to them straight.

The "sophisticated attack." Calling the attacker sophisticated is self-defence, and readers hear it as such. Say what happened; let others characterise it.

The buried ask. If customers need to reset a password, that instruction goes at the top, bold, not in paragraph six. Notices are skimmed, not studied.

The drip-feed. Announcing "500 accounts" then revising to 50,000 destroys more trust than 50,000 announced once. The fix is honest scoping language: give the number you can stand behind, flag what is still being counted, and commit to a dated update. Never state a floor as if it were the total.

The silence while lawyers perfect it. Waiting until every fact is final usually means someone else — a researcher, a journalist, a paste site — tells your customers first. Once you have confirmed impact on identifiable people, the choice is rarely "say everything or say nothing"; it is "say something true now, or something complete too late." True-now, with a promised update, wins nearly every time it is tried.

The holding-statement pattern

The instrument for "true now" is the holding statement, and it is worth drafting the skeleton on a quiet day, not during the incident: we are investigating an incident affecting X; here is what we know now; here is what we are doing; here is what you can do meanwhile; we will update by [date and time]. Then — the part that separates the trusted from the resented — actually update at that time, even if the update is "still investigating, next update Friday." Every kept promise in a breach buys back a little of what the breach spent.

Channels, briefly: notice by email assumes deliverability, so send from your established domain, never from a new one bought for the occasion (it reads as phishing and gets filtered as phishing); mirror the notice on a status page or your website so forwarded copies can be verified; and keep every channel saying the same thing, updated at the same moments.

Decide the machinery before you need it

None of the above is hard to agree with. What makes it hard to do is that every sentence needs an owner and an approver at a moment when everyone is busy: who drafts, who signs off, how fast, and who can say "send" on a Saturday. At a small company the honest answers are usually "the founder" — which is precisely why they must be written down and, ideally, exercised in a tabletop before the real Saturday arrives. The companies that communicate well in a breach are not braver; they decided the machinery in advance.

When you want this ready to use

Sylvan Assurance's GDPR Breach Response toolkit ships the communication machinery alongside the regulatory clock: the notification decision tree, the Article 33 filing template, the customer and individual notice templates with the five questions pre-structured, the holding-statement skeleton, and the support-team briefing sheet — in editions for a solo operator, a response team, or an organisation with data-protection-officer review, from $49. The companion Sylvan Press volume, GDPR Compliance — whose second volume covers breach, enforcement, and operations — carries the full depth.

The free GDPR breach triage at sylvanassurance.com/free/gdpr-breach returns the notifiable-or-document verdict and computes your 72-hour deadline from the moment of awareness. It runs entirely in your browser. Your answers are never transmitted.

Prefer the long form? The companion Sylvan Press title, GDPR Compliance, covers the same ground in depth.