IR Playbook Framework for AI Systems
Incident response playbook framework for AI systems: playbook design principles, common structure, adaptation guidelines, and integration with existing IR processes.
IR Playbook Framework for AI Systems
A playbook transforms incident response from improvisation into a repeatable, auditable process. When a production AI system is compromised, the responder should not be designing the response procedure in real time -- they should be executing a pre-defined playbook adapted for the specific incident type. This page establishes the framework used by the playbooks in this section.
Why AI Systems Need Specialized Playbooks
Traditional IR playbooks assume you are responding to incidents in deterministic systems with well-understood evidence types. AI incidents introduce challenges that require specialized procedures:
| Challenge | Traditional Playbook Assumption | AI Reality |
|---|---|---|
| Evidence type | Logs, memory dumps, disk images | Prompt logs, model weights, inference traces, conversation histories |
| Containment | Isolate the host or network segment | Isolate the model, but conversation context may vary per session |
| Reproducibility | Reproduce the exploit to confirm the vulnerability | Non-deterministic; statistical reproduction required |
| Root cause | Vulnerability in code or configuration | Could be model weights, training data, system prompt, or input |
| Fix verification | Deploy patch, test once | Deploy fix, test statistically across many attempts |
| Blast radius | Network topology and access control determine scope | Model's training data and tool access determine scope |
Playbook Structure
Every AI IR playbook in this section follows a consistent structure designed for use under pressure.
Standard Sections
| Section | Purpose | What It Contains |
|---|---|---|
| Trigger Criteria | When to activate this playbook | Specific conditions or alerts that warrant this playbook |
| Roles and Responsibilities | Who does what | Named roles with specific responsibilities |
| Immediate Actions (first 30 min) | Stop the bleeding | Evidence preservation, initial containment, stakeholder notification |
| Investigation (hours 1-4) | Understand what happened | Log analysis, scope determination, root cause identification |
| Containment and Remediation | Fix the problem | Specific containment and fix actions for this incident type |
| Verification | Confirm the fix works | Statistical verification procedure |
| Communication | Keep stakeholders informed | Templates for internal and external communication |
| Post-Mortem | Learn from the incident | Post-mortem checklist with AI-specific items |
Roles
Each playbook references these standard roles:
| Role | Responsibility | Typical Owner |
|---|---|---|
| Incident Commander (IC) | Overall coordination, decision authority, communication | Senior engineer or security lead |
| AI Investigator | Technical investigation of model behavior, logs, and artifacts | ML engineer or AI security specialist |
| Application Investigator | Investigation of application layer, system prompts, and tool configuration | Application engineer |
| Evidence Custodian | Evidence preservation, chain of custody, documentation | Security or compliance team member |
| Communications Lead | Internal and external communication | PR, legal, or management |
Playbook Design Principles
Principle 1: Executable Under Stress
Playbooks must be usable at 3 AM by someone who is stressed and underslept. This means:
- Short sentences, active voice. "Disable the model endpoint" not "Consideration should be given to potentially disabling the endpoint."
- Checklists, not paragraphs. Numbered steps that can be checked off.
- Exact commands, not descriptions. Include the actual CLI command or API call, not "restart the service."
- Decision trees, not judgment calls. "If X, do Y. If not X, do Z." rather than "Use your judgment."
Principle 2: AI-Specific at Every Step
Every step must account for AI system characteristics:
- Preservation steps must include prompt logs, model version, and system prompt -- not just system logs
- Containment steps must address the model, not just the host
- Investigation steps must include behavioral analysis, not just log review
- Verification must be statistical, not single-test
Principle 3: Layered Response
Not every incident requires every step. Playbooks support layered response based on severity:
| Severity | Response Depth |
|---|---|
| Critical | Full playbook execution, all roles activated |
| High | Core playbook steps, IC and AI Investigator activated |
| Medium | Abbreviated playbook, single investigator |
| Low | Documented investigation, routine resolution |
Integrating With Existing IR
AI playbooks should integrate with, not replace, your organization's existing IR framework.
Map AI playbooks to existing incident categories
Your organization likely has existing incident categories (data breach, unauthorized access, etc.). Map each AI playbook to the most relevant existing category. This ensures AI incidents flow through established communication and escalation channels.
Extend existing tools
Add AI-specific data sources to your existing SIEM, ticketing, and communication tools. The AI investigator should use the same ticketing system and communication channels as other IR activities.
Cross-train responders
Traditional IR responders need awareness of AI-specific evidence types and investigation techniques. AI engineers need awareness of IR processes, evidence handling, and communication protocols.
Conduct tabletop exercises
Run tabletop exercises using the AI playbooks before a real incident occurs. Exercises reveal gaps in procedures, missing tools, and unclear responsibilities.
Playbook Maintenance
Playbooks are living documents that must be updated based on experience.
| Trigger | Update Action |
|---|---|
| Post-mortem finding | Incorporate lessons learned; update steps that failed or were missing |
| New attack technique | Add detection indicators and response procedures |
| Tool or infrastructure change | Update commands, paths, and access procedures |
| Team structure change | Update roles and escalation contacts |
| Tabletop exercise | Address gaps identified during the exercise |
| Quarterly review | Verify all steps, contacts, and tools are current |
Available Playbooks
This section contains three detailed playbooks for the most common AI incident types:
| Playbook | Incident Type | Key Focus |
|---|---|---|
| Jailbreak Incident | Production jailbreak or safety bypass | Detection, containment, system prompt hardening, verification |
| Data Exfiltration IR | AI-mediated data exposure or exfiltration | Scope determination, data classification, notification procedures |
| Model Compromise | Compromised model weights, adapters, or training pipeline | Isolation, replacement, supply chain investigation, retraining |
Related Topics
- Triage Procedures -- first-response before playbook activation
- Escalation Paths -- escalation during playbook execution
- Evidence Preservation -- evidence handling referenced by all playbooks
- Red Team Operations -- operational procedures for red team exercises
References
- "NIST SP 800-61 Rev. 3: Computer Security Incident Handling Guide" - NIST (2024) - Foundation IR framework that AI playbooks extend
- "Incident Response Playbook Best Practices" - SANS Institute (2024) - Playbook design methodology
- "AI Incident Response: A Practical Guide" - Cloud Security Alliance (2025) - AI-specific IR guidance
Why must AI incident playbooks specify statistical verification rather than single-test verification?