Building Incident Response PlaybookCAUTION

817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATT&CK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF & MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI & 20+ platforms · 29 security domains ·

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: building-incident-response-playbook
description: Designs and documents structured incident response playbooks with step-by-step
  procedures per incident type, decision trees, escalation criteria, RACI matrices,
  and SOAR platform integration, aligned to NIST SP 800-61r3 and SANS PICERL. Use
  when creating or maturing an IR program, documenting response runbooks for a new
  incident type, or designing SOAR playbooks.
domain: cybersecurity
subdomain: incident-response
tags:
- IR-playbook
- runbook
- NIST-800-61
- SOAR-integration
- response-procedures
mitre_attack:
- T1486
- T1566
- T1190
- T1041
- T1078
version: 1.0.0
author: mahipal
license: Apache-2.0
nist_csf:
- RS.MA-01
- RS.MA-02
- RS.AN-03
- RC.RP-01
---

# Building Incident Response Playbooks

## When to Use

- Establishing or maturing an incident response program from scratch
- Documenting procedures for a new incident type after a novel attack
- Automating response workflows in a SOAR platform (Cortex XSOAR, Splunk SOAR)
- Preparing for compliance audits requiring documented IR procedures (SOC 2, PCI-DSS, HIPAA)
- Conducting a gap analysis of existing IR capabilities against specific threat scenarios

**Do not use** for one-time ad hoc investigations; playbooks are reusable procedure documents, not case-specific reports.

## Prerequisites

- Organizational risk assessment identifying top incident scenarios by likelihood and impact
- NIST SP 800-61r3 or SANS PICERL framework adopted as the organizational IR standard
- Asset inventory with business criticality ratings and data classification
- RACI chart defining roles: Incident Commander, SOC analysts, system administrators, legal, communications
- Existing detection capabilities inventory (SIEM rules, EDR detections, IDS signatures)
- SOAR platform access if building automated playbooks

## Workflow

### Step 1: Select and Scope the Incident Type

Define the specific scenario the playbook will address:

- Identify the top incident types based on organizational risk assessment and historical data
- Scope each playbook to a single incident type for clarity (do not combine unrelated scenarios)
- Define trigger conditions that activate the playbook

Common playbook types:
```
Priority Playbooks (build first):
1. Ransomware incident response
2. Phishing/credential compromise
3. Business email compromise
4. Malware infection
5. Data breach/exfiltration
6. DDoS attack
7. Insider threat
8. Account takeover
9. Web application compromise
10. Cloud infrastructure compromise
```

### Step 2: Define the Playbook Structure

Every playbook should follow a consistent structure:

```
PLAYBOOK TEMPLATE
━━━━━━━━━━━━━━━━
1. Playbook Metadata
   - Name, version, owner, last review date
   - Trigger conditions
   - Severity criteria

2. RACI Matrix
   - Who is Responsible, Accountable, Consulted, Informed for each step

3. Detection & Triage
   - How the incident is detected
   - Initial triage checklist
   - Severity classification criteria

4. Containment
   - Short-term containment actions
   - Long-term containment actions
   - Evidence preservation requirements

5. Eradication
   - Root cause identification
   - Malware/threat removal steps
   - Verification procedures

6. Recovery
   - System restoration steps
   - Validation criteria
   - Monitoring requirements post-recovery

7. Post-Incident
   - Lessons learned meeting trigger
   - Report template
   - Detection improvement actions

8. Communication
   - Internal notification matrix
   - External notification requirements (regulators, customers, law enforcement)
   - Status update cadence

9. Appendices
   - Tool-specific procedures
   - Contact lists
   - Evidence collection checklists
```

### Step 3: Write Decision Trees and Escalation Criteria

Define clear decision points with binary outcomes:

```
Detection Alert Received
├── Is the alert a true positive?
│   ├── YES → Classify severity
│   │   ├── P1 (Critical) → Page incident commander, begin containment immediately
│   │   ├── P2 (High) → Notify IR lead, begin investigation within 30 min
│   │   ├── P3 (Medium) → Queue for investigation within 4 hours
│   │   └── P4 (Low) → Document and investigate within 24 hours
│   └── NO → Document as false positive, tune detection rule
└── Cannot determine → Escalate to Tier 2 for deeper analysis
```

Escalation triggers:
- Any P1 incident: Immediate escalation to IR lead and CISO
- Data exfiltration confirmed: Legal counsel and privacy officer notified
- Customer data involved: Customer notification process activated
- Third-party involvement: Vendor security contact engaged
- Law enforcement needed: General counsel authorizes before contact

### Step 4: Define Specific Technical Procedures

Write tool-specific instructions for each step (not generic guidance):

```
CONTAINMENT - Endpoint Isolation via CrowdStrike:
1. Open Falcon Console > Hosts > Search for affected hostname
2. Click on the host > Host Details
3. Click "Contain Host" button in upper right
4. Confirm isolation (host will only communicate with CrowdStrike cloud)
5. Document containment action in incident ticket with timestamp
6. Verify containment: Host should show "Contained" status badge

CONTAINMENT - Block C2 Domain at DNS:
1. SSH to DNS server: ssh [email protected]
2. Add to block zone: echo "zone evil.com { type master; file /etc/bind/db.sinkhole; };" >> /etc/bind/named.conf.local
3. Reload DNS: rndc reload
4. Verify: dig @dns-primary evil.com (should resolve to sinkhole IP 10.0.0.99)
5. Document blocked domain in incident ticket
```

### Step 5: Integrate with SOAR Platform

Convert manual playbook steps into automated workflows:

- Map each playbook step to a SOAR action (API call, script, human decision point)
- Define automation boundaries (what runs automatically vs. what requires analyst approval)
- Build enrichment automations for the triage phase
- Create containment automations with approval gates for high-impact actions
- Configure notif

CAUTIONgrade B · trust 89/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

declared (4 observation(s))

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (2)

"name": "Data Breach / Exfiltration Response",

"Block exfiltration channel (IP, domain, cloud service)",

Gates applied: no_behavioural_pass.