Incident Communication: What to Say While You Still Do Not Know
Breach communication fails on timing, not wording. Publish a holding statement within the hour, commit to a next-update time, and refuse to guess at cause, scope or blame.
On This Page
At 09:40 a support agent notices password reset emails going to addresses nobody recognises. By 10:05 four people are on a call and not one of them can say whether this is a bug, a misconfiguration, or somebody else inside the account system. By 10:20 a customer has posted a screenshot. Nothing in the runbook covers the next twenty minutes, because the next twenty minutes are not technical.
Breach communication fails on timing far more often than it fails on wording. Teams hold the first message back because they want it to be right, and by the time it is right the story has already been written by somebody with worse information. The instinct is understandable. It is also the most expensive habit in incident response.
So here is the position, plainly. Publish inside the hour. Say only what you can defend. Commit in writing to when you will speak again, and then speak at that time whether or not anything has changed. An update that admits you do not yet know the cause is not a failure of communication. Silence is.
What follows is the shape of that first message, the cadence that has to follow it, the four things you must not guess at, and the notification duty that runs on its own clock regardless of what you decide to publish.
The first hour, when you know almost nothing
Split the situation into three questions, because they have different answers, different owners, and very different levels of certainty.
What happened is unknown. It will stay unknown for hours, sometimes for days, and every hour spent trying to answer it before you speak is an hour the vacuum fills on its own.
What we are doing is known immediately. You took a service offline. You forced a session reset. You isolated a host, rotated a key, rolled back a deployment. All of that is verified fact within minutes of doing it, and all of it is publishable.
What people should do now is the part readers actually came for, and it is usually answerable before the cause is. Sometimes the honest answer is that there is nothing for them to do yet. Say that too, because a reader who is told to wait behaves very differently from a reader who is told nothing.
- Name one incident lead. One person decides what gets published and when. Not a committee, and not whoever happens to have the status page password.
- Freeze the change surface. No unrelated deploys, no configuration edits outside the response. Half of all confusing incident timelines are two changes overlapping.
- Preserve evidence before you repair. Snapshot logs, sessions, tokens and the running state before you rebuild the host. Repair destroys the record you will need for both the postmortem and the notification assessment.
- Choose the channel of record. Decide where the authoritative updates live, and make every other channel point at it rather than paraphrase it.
- Publish the holding statement. Written by the lead, approved by one named other person, out inside the hour.
- Start the notification assessment in parallel. The statutory clock does not wait for your engineers to finish, and it does not restart when you learn something new.
What a holding statement actually contains
A holding statement is not an apology, a diagnosis or a legal filing. It is a short public note that establishes four things: that you know, that you are working, what the reader should do, and when they will hear from you next. It can be written in five minutes because it contains nothing you have to discover.
What goes in
- The fact of the incident, in ordinary words. “We are investigating unauthorised access to part of our account system.” Not “a potential anomaly in our security posture”.
- The time you became aware. Not the time it started, which you do not know, and which you will look dishonest for having guessed at.
- What you have already done, in the past tense. Actions taken are verifiable. Actions planned are hostages.
- What the reader should do now. One instruction, or an explicit statement that no action is needed yet.
- The time of the next update, as a clock time. “By 13:00 BST”, never “shortly” and never “as soon as we know more”.
What stays out
Keep the word breach out until you can defend it, because in several jurisdictions it is a term with legal consequences attached rather than a synonym for “bad day”. Use incident while the facts are open. Keep out the reassurance that has not been verified, keep out the technical detail that tells an attacker what you have detected, and keep out any sentence written in the passive voice to avoid naming who is responsible for the fix.
“No customer data was affected” is the most common line in a first update and the one most often withdrawn a week later. At hour one you have not finished looking. Write what you have confirmed, in the form “we have so far found no evidence that…”, and let the qualifier do its job.
The four things you must not guess at
Cause. The first plausible explanation is wrong often enough that you should treat it as a hypothesis with a name on it, not a finding. A compromised package in the supply chain looks exactly like an application bug until somebody reads the lockfile diff, which is one of several reasons the code you shipped but did not write deserves its own inventory before an incident, not during one.
Scope. The number of affected accounts is the figure everybody asks for first and the figure you are most likely to revise. Every upward revision reads as concealment even when it is honest arithmetic. Describe scope qualitatively while it is moving, and give a number only when you would be willing to defend it in a regulator’s office.
Attribution. Do not name an attacker, a country, a supplier or a former colleague. You are one sentence away from a defamation problem and two away from wrecking whatever investigation follows. “We are working with external specialists” carries everything the reader needs.
Restoration time. A missed estimate is worse than no estimate, because it converts a technical problem into a credibility problem. Commit to the time of the next update instead. That is a promise entirely within your control, which is exactly why it is the only one worth making at hour one.
Breach communication is a cadence, not a statement
Readers forgive a thin update. They do not forgive an unexplained gap. The mechanism that buys you patience is mechanical rather than rhetorical: every update ends with the time of the next one, and you publish at that time even when nothing has changed. “No change since 14:00. Next update at 17:00.” That is a complete update. It tells the reader the incident still has an owner.
Setting the interval
Pick an interval you can sustain at three in the morning, not the one that feels responsive at eleven in the morning. Hourly while the response is active, then lengthen it deliberately and announce that you are lengthening it. Going quiet is a decision your readers will interpret for themselves; announcing a longer interval is a decision you have explained.
Who holds the pen
One person drafts and one named person approves, and both are decided before an incident rather than during one. Engineers reading logs should not also be drafting public copy: the two jobs pull in opposite directions, one toward precision about systems and the other toward precision about people. Wording under pressure is a messaging discipline, and the organisations that do it well have already agreed on the vocabulary they use for severity, for uncertainty, and for the difference between suspected and confirmed.
The update that closes the thread
The last update is a different document from all the ones before it. It states what happened, what was affected, what you changed so it cannot recur in the same way, and what remains open. Findings written during a response are fragmentary by nature, and turning them into something a customer or an auditor can read is real work: tooling such as Prooflin exists for exactly that step, resolving AI-assisted findings, severities and recommendations into a reviewable report. The structure of a single finding matters more than most teams expect, which our parent company has written about in the anatomy of a finding.
The legal clock runs whether you speak or not
Public communication and regulatory notification are separate obligations with separate deadlines, and confusing them is how teams end up compliant but publicly silent, or loud and non-compliant.
Under the General Data Protection Regulation, a controller must notify the supervisory authority of a personal data breach without undue delay and, where feasible, not later than 72 hours after becoming aware of it. Read that phrase carefully. The clock starts at awareness, not at certainty, and a notification that is incomplete may be supplied in phases. Where the risk to the individuals concerned is high, those individuals must be told as well.
Your own jurisdiction, sector regulator and enterprise contracts may impose shorter windows and different thresholds, and contractual notice terms are frequently tighter than statutory ones. Someone should have extracted those clauses into a single list long before the incident, because reading four master service agreements at midnight is not a plan.
Deciding that a duty does not apply is a legal judgement, not an engineering one, and it must be written down with the reasoning and the date attached. An undocumented decision looks identical to no decision when it is examined a year later. Keep the internal record even where no external notification is made.
One incident, several audiences
The same set of facts has to reach people who need very different things from it. Write once, then adapt deliberately, and keep every version consistent with the channel of record.
| Audience | What they need first | Channel | Timing |
|---|---|---|---|
| Customers | Whether they must act, and how | Status page, then account email | Every published update |
| Your own staff | What to say if asked, and what not to | One internal thread | Ahead of every public update |
| Supervisory authority | Dates, facts, your risk assessment | The prescribed form | Inside the statutory window, then supplements |
| Contracted clients | The notice terms they signed | Named contact, in writing | Usually faster than the public update |
| Partners and integrators | Whether their keys or tokens are implicated | Direct and technical | Immediately, before the public note |
| Press | A named spokesperson and a written line | One spokesperson only | On request, never proactively at hour one |
The customer email is an operational problem as much as an editorial one. It has to reach people who unsubscribed from marketing, which means it cannot ride the ordinary promotional path, and whoever owns your lifecycle email infrastructure needs a transactional route that suppression lists do not swallow. Test that route before you need it. Discovering on the day that a service notice was filtered as a newsletter is a particularly bleak way to learn the lesson.
Why silence is the expensive option
Silence is not neutral. It does three things at once, and each of them costs more than a thin, honest update would have.
It hands the narrative to whoever is loudest. A customer with a screenshot and a theory becomes the primary source, and the theory is usually worse than the truth. It also puts your own people in an impossible position: support agents, salespeople and account managers will answer the question anyway, and without an agreed line they will improvise five different ones. Then it produces a timeline that reads badly in retrospect, because after the event nobody remembers how uncertain hour two felt, only that there was a six-hour gap between the first report and the first word from you.
You cannot control whether people talk about the incident. You can only control whether they are quoting you or guessing.
The honest concession: there are genuine reasons to narrow what you publish. An active law-enforcement investigation, an attacker still resident in your network, or a detail that would tell that attacker precisely which of their tools you have detected. All three are arguments for saying less, and none of them is an argument for saying nothing on no schedule. Narrow the content. Keep the cadence.
A second concession is worth making. Not every alarming event is an incident, and publishing at the wrong threshold trains your audience to ignore you. Agree in advance what triggers a public update, so the decision on the day is a lookup rather than an argument. The judgement about what is serious enough to act on is the same one that separates a real weakness from an interesting one when you are deciding whether to run a penetration test or fix the obvious first, and it is far better settled while nothing is on fire.
Write it on an ordinary Tuesday
Everything above is achievable in the first hour only because it was prepared in a quiet week. The artefacts are small and dull, which is why they never get made: a holding statement with blanks in it, a named lead and a named deputy, an approval path with two people on it, a list of contractual notice deadlines, and a status page hosted somewhere that does not depend on the infrastructure it reports on. That last one catches people out. A status page inside the failure domain is not a status page.
The preparation that reduces how often you need any of this is separate and unglamorous. Knowing what is publicly visible about your own systems is a good first move, because an automated scan of your own site tells you roughly what an opportunist already knows. The controls that cost least and prevent most tend to be the ordinary ones: current versions, removed admin accounts, restores you have actually tested, and the response headers that quietly close off whole categories of attack. Most of that belongs to whoever owns ongoing site maintenance, not to a project that ended last year.
If you take one thing from this piece, take the rule rather than the template. The first update is not judged on how much it explains. It is judged on whether it arrived, whether it was honest about the limits of what you knew, and whether the next one came when you said it would. Get those three right and you can be wrong about the cause for two days without losing anybody who matters.
And if you have never written the holding statement, write it this week rather than after the call at 09:40. If it would help to have someone read your version and argue with it, send us what you have drafted.
Common questions.
How quickly should you tell customers about a security incident?
Publish something within the first hour of confirming that an incident is real, even if the cause is unknown. The first message does not need a diagnosis. It needs the fact of the incident, the time you became aware, the actions already taken, whether readers must do anything, and the clock time of the next update. Waiting for certainty means somebody with worse information describes the event for you.
What should a holding statement say when the cause is unknown?
It should say that you are investigating, when you became aware, what you have already done in the past tense, what the reader should do now, and exactly when the next update will appear. It should leave out cause, affected numbers, attribution and restoration estimates. A holding statement can be written in five minutes because every element in it is a fact you already hold.
Is there a legal deadline for reporting a data breach?
Yes, and it varies by jurisdiction and sector. Under the General Data Protection Regulation a controller must notify the relevant supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, with affected individuals informed where the risk to them is high. Contracts with enterprise clients frequently set shorter notice windows than the statutory one.
Should you use the word breach in your first update?
Not until you can defend it. In several jurisdictions breach is a defined term carrying regulatory consequences, so applying it before the facts are established can create obligations and headlines you did not intend. Incident is the accurate word while the situation is still open. Change the vocabulary deliberately, in a later update, once the assessment actually supports it.
Who should write incident updates?
One named person drafts and one named person approves, both agreed before an incident begins. The drafter should not be an engineer actively reading logs, because the two tasks demand different kinds of precision and compete for the same attention. Everyone else, including support and sales, points at the channel of record rather than paraphrasing it in their own words.
Where should incident updates be published?
On a status page hosted independently of the systems it reports on, with every other channel linking to it rather than restating it. If the page shares infrastructure with the affected service, it goes down at exactly the moment it is needed. Email, social posts and support macros should carry a short summary and a link, so there is only ever one authoritative version.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.