Communicating while the incident is still running

Why this matters

The previous lesson covered what gets written down. This one covers the harder case: communicating while the facts are incomplete, changing hourly, and being demanded by people with the authority to demand them.

It is where responses are most often judged, and where they most often go wrong in ways that have nothing to do with technical skill. An incident handled well technically and communicated badly is remembered as handled badly — and the communication failure is usually one of three: too little, too confident, or on a channel the attacker was reading.

The lesson

Cadence: who is told what, how often

The single most effective thing you can do is establish a rhythm, early.

Without one, the pattern is familiar: the team is deep in the work, nobody upstairs hears anything for three hours, anxiety grows, and then executives begin interrupting individual responders for status — which stops the response to service the anxiety that the silence created.

A workable cadence:

• A fixed update interval per audience, set at the start and announced. The response team may sync every 30–60 minutes; leadership might get an update every 2 hours early on, stretching as things stabilise.
• Updates go out even when there is nothing new. "No change since 14:00, next update 16:00" is a real and valuable update. It is the message that prevents the interruptions, because it proves the process is running.
• One person communicates outward. A communications lead or the incident commander, not whichever responder someone catches. This protects the responders' attention and prevents four slightly different versions circulating.
• A consistent format, so a reader can find what changed: what we know, what changed since last time, what we are doing now, what we need, next update at.
• Audience-appropriate content, per lesson 36: the response team needs technical detail, leadership needs impact and decisions, the wider business needs practical instructions.

Announcing the interval is the part that does the work. "Next update at 16:00" buys the team two uninterrupted hours in a way that no amount of asking to be left alone does.

Out-of-band channels when the network is suspect

The point from lesson 29, at the moment it is needed.

If the corporate network, email or identity provider may be compromised, discussing the response on them hands the attacker your plan. This is not theoretical: intruders read incident response email threads and chat channels, learn what has been discovered and when containment is scheduled, and act accordingly.

Practically:

• Assume compromise of corporate comms until you have reason not to, whenever the incident involves the identity system, the mail platform, or administrative access.
• Move to a pre-arranged channel that does not depend on corporate identity or the affected infrastructure — a separate messaging platform on separate credentials, a phone bridge, or phones.
• Authenticate the participants. Once you are off the corporate directory, you need a way to be sure who is on the call. Agreeing this in advance is why it is a preparation item.
• Restrict the channel to those who need it. Wider distribution raises the chance of the attacker or an unintended recipient reading it.
• Keep the notes there too, per lesson 38.
• Consider what an attacker learns from the disruption itself. A sudden company-wide password reset announces exactly as much as an email would.

Two cautions. Out-of-band channels are less convenient, so people drift back to email within hours unless the incident commander keeps enforcing it. And an ad hoc channel created during the incident — a personal messaging group, say — is better than nothing and usually has no retention, no access control and no record, which causes problems afterwards. Prepared beats improvised here for reasons that go beyond speed.

Holding statements and saying what is not yet known

A holding statement acknowledges the situation without asserting facts you do not have. It exists because the alternative to communicating early is not silence — it is somebody else's version.

A usable holding statement:

• Confirms that you are aware of an issue and are investigating.
• Says what you are doing, in general terms.
• Says what you know that is definitely true, which may be very little.
• Says explicitly that the investigation is ongoing and figures may change.
• Commits to a next update, with a time.
• Gives the reader something to do, if there is anything.

What it must not do is anticipate the findings. The failure mode is an early statement that says "a small number of accounts" or "no customer data was affected" because that is what somebody hopes, followed days later by a correction. The correction is a second incident, and it does more damage than the original disclosure would have.

Phrases worth having ready, because they are accurate and hold up:

• "We are investigating and will confirm details as we establish them."
• "We have no evidence of X at this stage; our investigation is ongoing." — which says precisely what is true, and does not say X did not happen.
• "We are not yet able to confirm the scope. We expect to know more by [time]."
• "I don't know. Here is how we would find out, and how long it would take."

That last one is the hardest to say to an executive mid-incident and the most valuable. An analyst who says it once, and is right about everything they do assert, ends the incident with more credibility than one who answered everything.

Internal versus customer versus regulator

Three audiences with different needs, different obligations, and different consequences for getting it wrong.

Internal. The widest range of readers and the easiest to neglect. Staff notice when systems are down and will fill the gap with rumour if nobody tells them anything. They generally need: something is happening, here is what is affected, here is what to do, here is what not to do, here is where updates come from. Be careful with sensitive detail — internal communications are forwarded, screenshotted and leaked routinely, so write them expecting external readership.

Customers. Owned by communications and legal, informed by your facts. Timing is a genuine tension: too early and you communicate wrong information; too late and you have concealed it. The practical resolution is usually an early acknowledgement with a commitment to detail, rather than a delayed complete statement. Contractual deadlines may remove the choice entirely, per lesson 38.

Regulators. Formal, deadline-driven, and specific in what they want. Initial notifications are often required before the facts are complete and there is normally a process for updating. The analyst's role is supplying accurate facts and being clear about confidence; the submission is legal's. Two practical notes: the notification's content is drawn from your timeline and scope statements, so their quality directly determines the quality of a legal filing — and under-reporting is treated far more seriously than reporting something that turns out to be less severe.

The rule across all three: do not let the versions diverge. Different audiences get different detail and emphasis, and they must not get different facts. Journalists, staff and customers compare notes, and a contradiction between two of your own statements becomes the story.

Avoiding the update that later has to be retracted

The closing discipline of this domain, and the one that decides whether anything else in it worked.

Why retractions are so costly:

• They reset trust to zero, and everything you said before is re-examined.
• They are more newsworthy than the original, because "company misled" is a better story than "company breached".
• They invite regulatory attention, since an inaccurate statement can be a problem in its own right.
• They make the response harder, because every subsequent update is now doubted internally as well as externally.

How to avoid them:

• Never state a negative you cannot evidence. "No customer data was affected" requires proof of a negative across your whole estate. Almost nobody has that in the first days. Say "we have no evidence of" — a different statement, defensible, and honest about its own limits.
• Never give a number you are not sure of. Numbers are quoted, remembered and compared. Give a range with its basis, or none.
• Never say the incident is contained until it is verified — verified being lesson 32's standard, not the absence of alerts.
• Label everything provisional as provisional, and mean it.
• Have one person check outbound statements against the evidence. That person is usually the analyst, and it is the single highest-value thing you do all week.
• Prefer an early acknowledgement to an early conclusion. You can always add detail; you cannot withdraw a claim.
• When you are wrong, correct it immediately and plainly. A prompt correction is a functioning process. A late one, or one that emerges from outside, is a credibility failure of a different order.

Which is the same principle this course has returned to in every domain, stated one last way. A scan that could not authenticate is not a clean result. An untested rule is not a detection. A control nobody verified is not a control. A system that stopped alerting is not a system that is safe. And "we have found no evidence" is not "it did not happen" — the difference between those two sentences is the entire discipline, and saying the accurate one out loud, to someone who wanted the other, is what the job actually consists of.

Topics this lesson owns

• [x] Cadence: who is told what, how often
• [x] Out-of-band channels when the network is suspect
• [x] Holding statements and saying what is not yet known
• [x] Internal versus customer versus regulator
• [x] Avoiding the update that later has to be retracted