The incident response document becomes the artefact the auditor is going to ask for, the artefact the security team is going to point to when the incident happens, and the artefact the responder is going to open when the responder is trying to figure out what to do next. The document is also the artefact that nobody is going to read until the document stands as the artefact the responder needs, and the document becomes the artefact the responder is going to find out is wrong at the worst possible time. The document is wrong in almost every organisation, and the runbook is wrong for the same four reasons every time.
Reason 1: the people are wrong
The runbook lists the people who were on the team when the runbook was written, the people who have moved on, and the people who have never been in the runbook at all. The on call rotation has changed three times since the runbook was last updated. The escalation contact is on parental leave. The CISO has been replaced, and the replacement CISO is on a different email distribution list than the runbook assumes.
The runbook still has the names of the people who were on the team two years ago. The runbook does not have the names of the people who are on the team now. The runbook does not have the contact information for the legal team, the public relations team, the executive team, or the insurance carrier, and the document becomes the artefact that needs to be opened at 2 AM on a Sunday when the breach is in progress.
Reason 2: the systems are wrong
The runbook lists the systems that were in scope when the runbook was written, the systems that have been deprecated, and the systems that have never been in the runbook. The cloud account structure has been reorganised three times. The endpoint fleet has shifted from Windows to a mix of Windows, macOS, and Linux. The SaaS providers have come and gone, and the SaaS providers that have stayed have changed their APIs.
The runbook still has the hostnames, the IP addresses, and the configuration details for the systems that no longer exist. The runbook does not have the details for the systems that do exist, and the document counts as the artefact the responder is going to open when the responder is trying to figure out where the breach is happening.
Reason 3: the scenarios are wrong
The runbook was written for the scenarios the team could imagine when the runbook was written, the scenarios the team could not imagine, and the scenarios that have become the new normal in the year since the runbook was last updated. The supply chain attack was not on the list. The deepfake of the CEO was not on the list. The AI generated phishing that perfectly mimics the voice of the CFO was not on the list.
The runbook still has the response steps for the ransomware scenario, the data exfiltration scenario, and the denial of service scenario. The runbook does not have the response steps for the supply chain compromise, the AI generated social engineering, or the insider threat. The team is going to be facing the scenarios the runbook does not cover, and the team is going to be facing the scenarios the runbook does not cover at 2 AM on a Sunday.
Reason 4: the context is wrong
The runbook assumes the responder knows the context, has the access, and has the authority. The responder at 2 AM is a mid level analyst who has been on the team for six months, who has never worked this particular incident before, who does not have the production access the runbook assumes, and who does not have the authority to make the calls the runbook says to make. The runbook assumes the responder is a senior engineer with ten years of context, and the responder is not the senior engineer the runbook assumes.
The runbook is written for the people who wrote the runbook, not for the people who are going to use the runbook. The runbook is written by the senior engineers, the senior engineers are the people who do not get paged at 2 AM, and the people who get paged at 2 AM are the people who are not the senior engineers who wrote the runbook.
What to do about it
Treat the runbook as a living document, not as a project deliverable. The runbook needs to be updated every time the team changes, every time the systems change, every time a new scenario emerges, and every time a real incident reveals a gap. The runbook runs as the artefact the team is going to use, and the runbook becomes the artefact the team is going to find out is wrong if the runbook is not maintained.
Run the tabletop exercise against the runbook at least quarterly. The tabletop becomes the test that reveals the gaps in the people, the systems, the scenarios, and the context. The tabletop runs as the test that finds the people who are on the team but not in the runbook, the systems that are in the environment but not in the runbook, and the scenarios that the runbook does not cover. The tabletop that finds the gaps counts as the tabletop that is worth running.
Move the runbook from the document to the system. The runbook in 2026 is a set of automation scripts, a set of decision trees in the SOAR platform, and a set of runbooks in the paging system. The runbook runs as the thing the system does when the alert fires, and the document amounts to the thing the responder follows when the automation needs a human. The document that is in the system sits as the document that gets used, and the runbook that gets used amounts to the runbook that gets maintained.
The bottom line
The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.
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.
