Prepare the Crisis Response Plan in Seven Steps

The Crisis Response Plan Template

Companion to The Code Takes Care of Itself · Updated 2026-09-30

This is the full playbook from “In a Crisis, Your Job Is to Keep Everyone Informed.” The book prints a shorter version at the end of that chapter, and this page keeps every step and every example.

Build the Crisis Response Plan Template before you need it.

  1. Name the roles in advance. The Incident Commander directs the technical response, sets priorities, makes the operational calls, and protects the engineers doing the hands-on work; the Commander speaks to the response team, not to executives or customers. The Communications Lead owns all reporting outside the response team, and can be the CTO or an authorized delegate. The Executive Sponsor is the single point of contact who gets the most detailed update and can decide resourcing and business tradeoffs without convening the full leadership team. Name real people for all three, and a backup for each. Do not write “we will find who is available.”

  2. Agree on the severity definitions before an incident occurs. Write down what makes an incident a Sev1, a Sev2, or a Sev3 in your organization, using your own systems and your own business impact rather than a generic tier system. Attach a required communication cadence to each level: a Sev1 might need an update to the Executive Sponsor every fifteen to thirty minutes and one to the company every hour, while a Sev3 needs one update at resolution. The cadence starts automatically when someone declares the severity; you do not negotiate it during the incident. Declare early, on incomplete information, and reduce it later if the evidence permits. If you wait for certainty, you create the silence “In a Crisis, Your Job Is to Keep Everyone Informed” warns about.

  3. Use one update template. Every status update, to every audience, answers four questions and no more. What do we know now? What don’t we know yet? What do we do next? When will you hear from us again? Skip detail this audience doesn’t need and reassurance you cannot support. The structure builds confidence even when the update carries little news.

  4. Check the vocabulary before you send. Hunt for two patterns. First, hedged passive language with no owner: “issues have been identified,” “it is being investigated.” Replace it with a named owner and a concrete action. Second, unearned reassurance: “everything is under control,” “this will not happen again,” written before you know it’s true. Replace it with what you can honestly commit to, the specific action in progress and the time you’ll confirm the result.

  5. Build the contingency inventory. List the five most consequential single points of failure in your organization: a vendor, a key person, a system with no redundancy, a compliance deadline with no slack. For each, write down who acts if it fails, what the fallback path is, and what “stable” means before anyone can close the incident. Review the list quarterly. It goes stale the moment your architecture or your team changes.

  6. Set the postmortem protocol. Commit to two rules in writing, before an incident occurs. First, anyone who discloses a near-miss or an honest mistake takes no disciplinary consequence. Second, every postmortem produces at least one change to the system, not just an account of what happened. A postmortem that ends with “we’ll be more careful next time” hasn’t found the root cause. Ask the systems question again.

  7. Run the tabletop drill. Test the plan against a hypothetical incident at least twice a year, with the full team and the communications side, not only the technical response. The scenario barely matters. The value is in what you find in a calm room with nothing at stake: that your named Incident Commander is away that week, that nobody knows who can post to the public status page, that the Executive Sponsor left the company four months ago and nobody updated the document. Every gap you find in a drill is a gap you don’t find for the first time in a real crisis.

Try this with AI.

“Invent a plausible Sev1 for a system like ours and walk me through it one development at a time. Make me produce the status update at each step, and afterward show me where my plan had no answer.”

Schedule the first drill this quarter. The teams that perform best under real pressure are the ones that rehearsed when nothing was on fire.

All of the playbooks are listed on the playbooks page.