01
Step one: define triggers and severity
Begin by naming the events that start the checklist and grading them by severity. Worked example: a regional software firm lists a data exposure, a payment outage over one hour and a public complaint gaining traction. For each, it writes who can declare an incident and what level of response follows. Keep levels to three at most, so nobody debates definitions mid-event. Add a plain sentence on what is not a crisis, so routine problems stay with normal teams. Review triggers against past incidents, since real history exposes gaps that imagined scenarios often miss.
02
Step two: assign owners and backups
Next, give each task a named owner and a backup. In the software firm, the operations lead runs the technical fix, the founder approves outside statements, and the customer success head manages client contact. Record phone numbers, alternates and the place where the team gathers, whether a call line or shared channel. Decide who may spend money or call outside counsel without waiting for approval. Keep the list to one page. Test it by asking a colleague to find their role in under thirty seconds. If they cannot, simplify the layout before adding any further detail.
03
Step three: script the first hour and rehearse
Finally, write the first-hour sequence: confirm facts, protect people and data, notify the core team, and issue a short holding message. The software firm drafts a statement template with blanks for what happened, what is known and when the next update will arrive. It then runs a thirty-minute tabletop exercise using one trigger and notes what slowed the team. Update the checklist after each exercise and after every real event. Set a review date twice a year, and store the current version where staff can open it without special access or searching.