A general incident response plan describes principles and roles. A runbook describes specific, step-by-step procedures for recurring scenarios, written so that whoever is on-call at 3 a.m. can follow it directly without needing to first reconstruct the appropriate response from general principles under time pressure. Building this level of specific, executable detail is what turns incident response readiness from an aspiration into something that actually works when needed.
Write runbook entries for the specific scenarios discussed throughout this content series
Build dedicated runbook entries for the recurring AI-specific scenarios covered elsewhere: a confirmed prompt injection incident, a suspected data leakage event, a tool abuse incident, an agent behaving anomalously according to the detection guidance covered in monitoring content. Each entry should walk through the specific steps for that scenario, not a generic template that makes the responder adapt principles to the specific situation in real time.
Include exact commands, links, and access instructions
A useful runbook entry includes the actual, specific steps needed: the exact dashboard or query to check first, the specific kill switch or configuration to trigger and how to access it, the specific escalation contact for this scenario type. Writing these details concretely, rather than describing them abstractly, "check the relevant monitoring," removes the need for a stressed responder to figure out what "relevant" even means in the moment.
Structure entries with a clear, sequential flow
Write each runbook entry as a clear, sequential set of steps: what to check first, what decision that check leads to, what to do next depending on the outcome. This sequential structure, rather than an unordered list of considerations, mirrors how a responder actually needs to work through an incident in real time, making decisions as new information becomes available rather than trying to hold every consideration in mind at once from the start.
Include decision points explicitly, not just actions
Where a runbook entry involves a judgment call, is this severity level high enough to escalate immediately, does this specific finding warrant a broader investigation, make the decision point explicit with the specific criteria that should inform it, rather than leaving the judgment entirely implicit and hoping the responder applies appropriate judgment with no structured guidance for what "appropriate" even means in this specific context.
Keep the runbook current as systems and tools change
A runbook describing a dashboard, tool, or process that's since changed provides false confidence and wastes time when a responder follows outdated steps during an actual incident. Assign explicit ownership for keeping each runbook entry current, tied to changes in the underlying systems it references, rather than letting runbook maintenance happen only sporadically or after someone notices it's stale during an actual incident, which is the worst possible time to find that out.
Test runbook entries during tabletop exercises
Use the tabletop exercises covered in earlier testing guidance specifically to test whether runbook entries actually work as written: have a participant follow the runbook's exact steps during the exercise and note where the instructions are unclear, outdated, or missing a step that turned out necessary. This is a far more direct test of the runbook's practical usefulness than a document review alone.
Make the runbook accessible under realistic incident conditions
Make sure the runbook is accessible through a channel that will actually be available during an incident, not dependent on a system that might itself be affected by the incident being responded to, and make sure whoever's on-call knows where to find it without needing to search, since search time during an active incident is time not spent on actual response.
Capture lessons from real incidents back into the runbook
After a real incident, following the investigation guidance covered elsewhere, update the relevant runbook entry based on what actually got learned: a step that took longer than expected, a decision point that needed additional criteria, a scenario variant the existing entry never anticipated. This feedback loop is what keeps the runbook improving based on real experience rather than staying static after its initial creation.
Where TELEON fits
Where TELEON's audit trail and policy enforcement are part of the operational response process, applied through the gateway or supported middleware, the runbook should include specific instructions for how to query the audit trail for a given scenario and how to trigger any policy-level restriction as part of a documented response step.
Writing the specific procedures, keeping them current, and capturing lessons from real incidents remain operational documentation work that has to be maintained directly by the team responsible for AI security operations.
A short checklist
- Write dedicated runbook entries for each recurring AI-specific
scenario.
- Include exact commands, links, and access instructions, not abstract
descriptions.
- Structure entries as a clear, sequential flow matching real-time
decision-making.
- Make judgment-call decision points explicit with specific criteria.
- Assign ownership for keeping each entry current as systems change.
- Test runbook entries directly during tabletop exercises.
- Ensure the runbook is accessible under realistic incident conditions.
- Update runbook entries based on lessons from real incidents.
An AI security operations runbook earns its value through specific, executable detail that a stressed, time-pressured responder can follow directly, and building and maintaining that level of specificity is what separates genuine operational readiness from a general plan that sounds reasonable but leaves execution to improvisation.