A one-page zero-day runbook lists what triggers it, who owns it, the first-hour steps, the patch versus mitigate decision, update times, and the criteria for closing. Keep it short enough that people read it under stress, and store it where it is reachable if your main systems are down.
Why one page
Long plans get skipped in a crisis. A single page is a prompt, not a manual. Link out to detail for the parts that need it, such as the network team's firewall change procedure.
Template
1. Trigger. Start the runbook when any of these happens: a vendor advisory for something in our inventory, a KEV catalog entry matching our products, a credible report of exploitation of a library we ship.
2. Roles. Incident owner, technical lead, communications lead, legal contact, executive sponsor. Names and deputies, with phone numbers. See roles and handoffs.
3. First hour.
- Read the primary advisory.
- Open the channel and the log.
- Query the inventory: affected, not affected, unknown.
- Apply stopgaps to internet-facing systems.
- Set the next update time.
4. Decide. Use the patch or mitigate table: fix available, exposed, exploitation reported. Record the decision and who made it.
5. Communicate. Executives at set times, staff when action is needed, customers when affected or when asked. Use approved templates.
6. Verify. For each system, record the version after change and a scan or test result. No "done" without proof.
7. Check for compromise. Define the exposure window, preserve evidence, hunt for indicators.
8. Close. Close when all systems are fixed or mitigated with an expiry, the compromise check is complete, notices are sent or ruled out, and a review is scheduled.
What to put in the appendix
| Item | Where it lives |
|---|---|
| Inventory location and query steps | Link |
| Emergency change approval path | Link |
| Customer and regulator notice templates | Link |
| Contact list, kept offline | Printed or separate system |
Test it
Run the runbook against a made-up advisory once a quarter. Fix the places where people hesitated. NIST SP 800-61 Rev. 3 frames incident response as part of ongoing risk management, which fits this habit of preparing and refining.
Common gaps
Teams most often forget three things: who can approve an emergency change after hours, where the inventory query lives, and who tells customers. Fill those three lines first, and the rest of the page is easier to complete.
Try it yourself
Click through it at your own pace, or open it full screen.
See how ongoing monitoring surfaces a new issue after a scan.
Quick check
How often should we update the runbook?
After every real event and at least once a year. Update contacts whenever a role changes hands.
Where should we store it?
Somewhere reachable when email and chat are down, plus in your usual wiki.
Sources
Last reviewed: 19 October 2026.
