Here’s what actually happens during a technology incident at an unprepared business: the technical people disappear into the recovery, the phones start ringing, staff invent their own explanations, three different employees tell three different clients three different stories, and someone posts “we’ve been hacked!!” in a group chat that includes a customer. The systems come back in a day; the version of events runs loose for a month. An incident communication plan exists to prevent that second problem — and unlike the technical response, you can build the whole thing on a calm afternoon.

Why this is its own plan

Your incident response plan covers containing and fixing the problem. The communication plan covers the parallel track that technical people, mid-crisis, will not have bandwidth for: keeping staff, clients, and obligations handled while the fixing happens. Merging the two means communication gets done last and worst — which is backwards, because in most incidents, how you communicated is what people remember longer than the downtime itself.

Decide the roles now

Three assignments, written down with backups for each:

  • One voice. A single person authorizes and sends all external statements. Not because others aren’t trusted — because consistency is the entire game, and consistency requires one throat the message passes through.
  • One incident narrator. Someone (often your IT lead or provider) translates technical status into plain English for the one voice, on a schedule. The people doing the recovery shouldn’t also be drafting client emails.
  • One keeper of the contact tree. Staff phones, key clients, your IT provider, the insurer’s breach hotline, your attorney — printed and kept somewhere that isn’t a server, because the plan that lives only on the encrypted file share is a punchline we’ve seen in real life.

The messages, pre-drafted

Mid-incident is the worst time to write. Draft skeletons now, blanks and all:

To staff, within the first hour: what’s affected, what to do instead, and — critically — what not to say: “Please don’t discuss this outside the company; direct any client questions to [name].” Staff speculation is the leak in nearly every mishandled incident, and one early instruction prevents most of it. Include how you’ll reach people if email itself is down (text tree, a group call — decide now).

To clients, when they’re affected: honest, brief, and promise-shaped only where you can keep the promise. “We’re experiencing a systems outage affecting X. Your data/orders/deadlines: [status]. Next update by [time].” The commitment to a next update by a stated time is the single most trust-preserving sentence available — it converts silence from an alarm into an interval.

The holding line for inbound calls: two sentences everyone who answers phones can say verbatim, so callers get the same calm answer from anyone.

One rule governs all three: don’t speculate about cause. “We’re investigating” is a complete sentence. Early guesses are usually wrong, and wrong statements about a security incident create their own liabilities.

Know your obligations before you have them

Some notifications aren’t optional, and their clocks start at discovery, not at your convenience: your cyber insurer (most policies require prompt notice, and late notice can jeopardize the claim — the breach hotline goes on the printed tree); breach notification laws — Oregon, Washington, and every other state require notifying affected individuals when personal data is exposed, on defined timelines, so the plan’s rule is simple: if personal data may be involved, the attorney and insurer are called before any public statement; and industry-specific duties — health information and financial-client data carry their own regulators and clocks. The plan doesn’t need the legal details memorized; it needs the trigger — “personal data possibly involved → call counsel first” — in bold.

After: the version of record

Within a week of resolution, send the closing message inside and out: what happened (in the plainest true words), what was and wasn’t affected, and what’s changing as a result. The “what’s changing” line is the one clients quote later — it’s the difference between an incident that reads as bad luck handled well and one that reads as a preview. Then walk the communication plan itself through the same lessons-learned pass as the technical response: which numbers were wrong, which message was missing, who was unreachable.

The bottom line

Incidents are graded twice — once on how fast you recovered, and once on how you sounded while it happened. The second grade is the one clients remember, and it’s the one you can fully prepare for in an afternoon: three named roles, three pre-drafted messages, one printed contact tree, and one bolded rule about when to call the lawyer first. Do it this month, staple it to the response plan, and the worst day gets a script.