The Communication Plan Is the Part Everyone Forgets

Every business continuity plan has a gorgeous runbook for restoring the database and three vague sentences for talking to actual humans. Guess which one determines whether customers still trust you afterward.

Every business continuity plan I've ever read has a lovingly detailed section on technical recovery. Failover procedures, backup restoration steps, RTOs and RPOs specified down to the minute, escalation trees for every system component. Then you hit the communication section and it's three sentences: “Notify stakeholders as appropriate. Update status page. Coordinate with PR.” That's the entire plan for the part of the incident that decides whether your customers still trust you next week.

Nobody designs it this way on purpose, but the incentives point straight there. Technical recovery feels like real work: it has diagrams and things you can test in a staging environment at 2am and feel good about afterward. Communication feels soft, like something you bolt on once the engineers have fixed the actual problem. Nobody gets promoted for writing a good incident-notification template. Plenty of people get promoted for shaving four minutes off a database failover.

Then the incident happens, and the plan reveals its real design: a communication strategy that depends entirely on the systems currently on fire.

The channels that go down with the ship

Somewhere in your plan there's a line telling customers to check the status page for updates. Nobody asks where the status page actually lives. If it's hosted on the same cloud account, the same DNS, or the same CDN as the product it's reporting on, you've built a smoke detector that suffocates in smoke. The instinct survives every tabletop exercise because tabletop exercises rarely simulate the status page itself returning a 503. Fixing this isn't hard: separate login, separate DNS, separate everything. Most teams know this in the abstract and still skip it, because doing it once feels like busywork next to shipping features.

The internal version is funnier and worse. Every company has a designated incident channel that the plan assumes will be reachable. Nobody stress-tests that assumption. If the chat tool authenticates through the identity provider that just fell over, or the emergency bridge line routes through an office phone system that's currently dark, your “reliable” backup channel is exactly as reliable as everything else. I've watched a team try to coordinate a recovery in a group chat gated behind single sign-on, provided by the very identity service that had gone down. They ended up on personal phones, texting like it was 2009, which was somehow both the funniest and the most functional part of the whole incident. Meanwhile the employees who most need to know what's happening often hear it last, through a customer complaint on social media, because the official channel is email and email is one of the things that's down.

Who's allowed to say anything

The other gap isn't infrastructure, it's authority. When something breaks in public, someone needs to know immediately whether they're allowed to post an update, talk to a journalist, reassure a customer on the phone, or say literally anything on the record. In practice most companies have a policy that exists on paper and evaporates under pressure. Three well-meaning employees say three slightly different things, one of them wrong, and now the postmortem has a second workstream just for cleaning up the first one.

Customers who get an honest, boring, well-timed update forgive an outage faster than customers who get silence followed by a vague statement drafted by committee two days later. Confused communication doesn't just look bad. It multiplies the damage, because it turns one incident into two: the outage itself, and the credibility problem you created by handling it badly.

A serious plan treats communication with the same rigor as failover: redundant channels that don't share a blast radius with the product, pre-approved templates, a named person with actual authority to hit send, and a rehearsal that assumes the phone system is also part of what's broken. Test it the way you test a database restore, by doing it, not by reading the paragraph and nodding.

If your crisis communication plan collapses the moment you lose the thing you're trying to communicate about, you don't have a plan. You have a hope, formatted to look like a document.