5 MIN READ
Every incident response runbook eventually gets opened at the worst possible time. Often at 2 AM on a Sunday, by an analyst who has been on the security org for six months, has never worked this particular incident before, and is trying to figure out which page of the document actually applies. The runbook, almost every time, has the wrong page. Same four things go wrong, in the same order, in almost every organisation.
Reason 1: the people are wrong
Names in the runbook age fast. The on call rotation has changed three times since the document was last updated. The escalation contact is on parental leave. The CISO who approved the runbook left six months ago, and the current CISO sits on a different email distribution list than the one the document assumes. Legal, PR, executive, and insurance carrier contacts are not in the runbook at all.
The runbook still carries the names of people who left the company two years ago. The current security org, the current engineering org, the current legal lead, and the current PR lead are not in the document. The 2 AM on a Sunday scenario is exactly when those missing names cost the most.
Reason 2: the systems are wrong
The system inventory in the runbook ages just as fast as the people list. The cloud account structure has been reorganised three times. The endpoint fleet has shifted from Windows to a mix of Windows, macOS, and Linux. SaaS providers that have stayed have changed their APIs, and the ones that have not stayed have been replaced by a long tail of new ones, none of which are in the document.
Hostnames, IP addresses, and configuration details in the runbook all point at systems that no longer exist. The cloud account the on call engineer needs to triage, the S3 bucket they need to check, the Kubernetes cluster they need to roll back, none of those are in the page the responder just opened.
Reason 3: the scenarios are wrong
Scenarios age out faster than people or systems do. Supply chain compromise, deepfake of the CEO, AI generated phishing that perfectly mimics the voice of the CFO. None of those were on the list when the runbook was last updated. Two of them are now the most common breach patterns of the year.
Response steps for the classic ransomware scenario, the data exfiltration scenario, and the denial of service scenario are still in the document, and they are solid. Steps for the supply chain compromise, the AI generated social engineering, and the insider threat, the ones the on call engineer is going to be facing in 2026, are not.
Reason 4: the context is wrong
The runbook assumes a different reader. The 2 AM analyst who opens it has six months on the job, has never worked this particular incident before, does not have the production access the document assumes, and does not have the authority to make the calls the document says to make. The author of the runbook was a senior engineer with ten years of context. The 2 AM analyst is not that person.
Worse, the document was written by the senior engineers who do not get paged, for the people who do get paged. The author reads the document once, the responder reads the document when the alert fires. The first reader has context. The second reader does not, and the document does not give them any.
What to do about it
Treat the runbook as a living document, not as a project deliverable. Update it every time someone joins or leaves the security org, every time the systems change, every time a new scenario emerges, and every time a real incident reveals a gap. A runbook that does not get updated in the same week as a real incident will cost the company the next one.
Run a tabletop against the runbook every quarter. A 90 minute session with a fake phishing email, a fake compromised account, and a fake external notification will surface more missed contacts and outdated hostnames than another six months of letting the document sit. The exercise is cheap. The gap it finds in the next real incident is not.
Move the runbook from the document to the system. In 2026, the runbook runs as a set of automation scripts, a set of decision trees in the SOAR platform, and a set of runbooks in the paging system. The system executes the runbook when the alert fires. The responder follows the document when the automation needs a human. The runbook that lives in code gets reviewed every time the code gets reviewed. The runbook that lives in a shared drive gets reviewed when someone has the time, which is never.
The bottom line
The runbook that holds up in 2026 lives in three places at once. In the AppSec team’s weekly maintenance, in the IR lead’s quarterly tabletop, and in the engineering org’s paging system. Everything else sits in a shared drive and ages out between reviews. The difference is the maintenance, not the document.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
