In a crisis, consistency beats craft.
During an incident you need the same confirmed facts in 6 formats, fast. That is work AI is good at — and it is bounded by judgment it cannot take from you.
- An incident does not need original writing. Crisis communications needs the same confirmed facts, in every format, within the hour.
- That makes crisis comms the clearest case where AI earns its place: conventional, repetitive, and time-critical.
- Work from 1 source of human-verified facts. Never from the model's memory of similar incidents.
- Keep the caveats and the unknowns identical across every version, including what you are deliberately not saying yet.
- Speed is the benefit. Approval, sequencing, and the call on what counts as confirmed stay with people.
The first hour of an incident is not a writing problem, but it produces an enormous amount of writing. Someone has to tell the company, brief the managers who will be asked, give support a line to use, hold the customers who have noticed, and start the record that legal and the regulator will read later.
All of it has to say the same thing. None of it benefits from being interesting.
What an incident actually demands
The requirement is fidelity at speed across audiences who need different levels of detail — in a specific order.
Divergence between versions is how 1 incident becomes 2.
When the support macro says something the holding statement does not, or the all-hands note is more confident than the regulator summary, you have created a second problem on top of the first
Why this is the right job for AI
Everything that makes AI a liability in market-facing writing makes it useful here. It converges on the conventional phrasing, it does not get tired at version 5, and it will hold a structure exactly. In an incident, all 3 are features.
It is the mirror image of the problem in content that all sounds the same: there, sameness costs you distinctiveness you needed. Here, sameness is the deliverable.
The one-source rule
Everything downstream comes from a single fact sheet that a human has verified: what happened, what is affected, what the timeline is, what is still unknown, and what has been ruled out. That document is the input to every draft.
- Draft only from that sheet. A model asked to write about an incident without one will fill gaps with plausible detail from incidents it has read about, which is the worst possible failure in this context.
- Generate every variant from the same source in the same pass, so the facts cannot drift between audiences.
- Carry the unknowns forward verbatim. “We do not yet know” has to appear in every version that touches the question.
- Reissue rather than patch. When the facts change, regenerate the whole set from the updated sheet instead of editing the versions individually.
This is also the point at which good incident documentation stops being a compliance chore and starts saving you hours — the same argument as writing the resilience documentation before you need it.
What stays with people
The model produces the artifacts. It does not get to make any of the following calls.
- What counts as confirmed. This is a judgment about evidence, and getting it wrong early is what forces retractions later.
- Sequencing. Who hears it first, and how long the gap is before the next audience, is a decision with legal and human consequences.
- What is material, and to whom. Disclosure obligations turn on that determination rather than on the drafting.
- Anything that leaves the building. Speed is the benefit; authority is not delegable, and no draft goes out unapproved.
The timing pressure is real and worth knowing before an incident rather than during one: public companies in the US have 4 business days to disclose a material cybersecurity incident once materiality is determined. The drafting is not what makes that deadline hard. The determination is.
Set it up before you need it
None of this can be assembled at the time. What you want ready:
- A fact sheet template with named fields, including an explicit unknowns section.
- Pre-approved language for the things you always have to say and the things you never say.
- The 6 output formats as templates, so generation is a fill rather than an invention.
- A named approver per artifact, and a deputy, because incidents do not respect calendars.
- One dry run against a scenario, which is where you find out your templates assume facts you will not have.
If you already run exercises, this belongs in them. A tabletop that produces no written artifacts has skipped the part that consumes the most time on the day. Standard incident-handling guidance, including NIST's incident handling guide, treats communication as a phase of response rather than an afterthought to it.
What not to do
- Do not let a model research the incident on its own. Its only inputs are your fact sheet and your approved language.
- Do not auto-send anything, to any audience, ever.
- Do not let it soften the unknowns. Reassurance that outruns the evidence is the most expensive sentence in the set.
- Do not use generated text as the regulatory filing. It can prepare the summary; counsel decides what is filed.
Handled this way, AI takes the volume out of the worst hour of the quarter and leaves the judgment where it belongs. What it does not do is settle what the incident means for your position in the market — that gets decided by how the disclosure is framed, long before anyone drafts the customer note.
Part of our work on marketing resilience internally.