# Ir Playbook Templates > - Skill: `frank-luongt/ir-playbook-templates` (Agent Skill) - Install (CLI): `npx skillmds@latest add frank-luongt/ir-playbook-templates` - Raw SKILL.md: https://api.skillmd.com/api/skills/frank-luongt/ir-playbook-templates/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: frank-luongt (https://skillmd.com/u/frank-luongt) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/frank-luongt/ir-playbook-templates --- --- name: ir-playbook-templates description: Incident response playbook templates following NIST SP 800-61 phases for six common incident types tags: [playbook, security] --- # Incident Response Playbook Templates ## Overview Structured incident response playbooks reduce mean-time-to-contain (MTTC) by 70% compared to ad-hoc responses. These templates follow the NIST SP 800-61r2 framework and provide ready-to-execute runbooks for the six most common security incident types. **Core principle:** Every minute without a plan during an active incident is a minute of uncontrolled damage. Each playbook covers the full NIST IR lifecycle: 1. **Preparation** -- readiness posture before incidents occur 2. **Detection & Analysis** -- identifying and classifying the incident 3. **Containment** -- stopping the spread of damage 4. **Eradication** -- removing the root cause 5. **Recovery** -- restoring systems to normal operations 6. **Post-Incident Activity** -- lessons learned and process improvement ## When to Use This Skill - A security alert fires and you need a structured response plan - You are building or updating your organization's IR runbooks - An active incident requires step-by-step guidance for containment - You need to define escalation criteria and communication plans - A compliance audit requires documented IR procedures (SOC 2, ISO 27001, GDPR) - You are running a tabletop exercise or IR drill ## How It Works ### Step 1: Detect and Classify the Incident Determine the incident type and assign a severity level. **Severity Classification Matrix:** | Severity | Criteria | Response SLA | Escalation | |----------|----------|--------------|------------| | **SEV-1 Critical** | Active data exfil, ransomware spreading, full compromise | 15 min | CISO + Legal + Exec immediately | | **SEV-2 High** | Confirmed breach, credential theft, active attacker in network | 30 min | Security Lead + Engineering Lead | | **SEV-3 Medium** | Suspicious activity, single account compromise, contained DDoS | 2 hours | Security Team on-call | | **SEV-4 Low** | Failed attack attempts, policy violations, phishing (no click) | 24 hours | Security Team queue | **Incident Type Decision Tree:** ``` Alert Received | +-- Is it encrypting/locking files? --> RANSOMWARE | +-- Is data leaving the network? --> DATA BREACH / EXFILTRATION | +-- Is service availability impacted by traffic? --> DDoS ATTACK | +-- Are credentials confirmed compromised? --> ACCOUNT COMPROMISE | +-- Is the actor an internal employee/contractor? --> INSIDER THREAT | +-- Is the vector a third-party tool/dependency? --> SUPPLY CHAIN COMPROMISE ``` ### Step 2: Activate the Response Team **Core IR Team Roles:** | Role | Responsibility | Backup Required | |------|---------------|-----------------| | Incident Commander (IC) | Overall coordination, decision authority | Yes | | Security Analyst | Technical investigation and forensics | Yes | | Communications Lead | Internal/external messaging | Yes | | Engineering Lead | System access, containment actions | Yes | | Legal Counsel | Regulatory obligations, liability | On-call | | Executive Sponsor | Business decisions, public statements | On-call | **Activation checklist:** ``` [ ] Incident Commander identified and acknowledged [ ] War room / incident channel created (Slack: #inc-YYYY-MM-DD-) [ ] Bridge call initiated (for SEV-1/SEV-2) [ ] Incident ticket created in tracking system [ ] Initial severity assigned [ ] Relevant playbook selected ``` ### Step 3: Contain the Threat Containment strategies vary by incident type. Select the appropriate playbook below. General containment principles: - **Short-term containment** -- stop the bleeding immediately (isolate host, block IP, disable account) - **Long-term containment** -- stabilize while preparing eradication (segment network, apply temporary rules) - **Evidence preservation** -- NEVER wipe or reboot a system before capturing forensic data ### Step 4: Eradicate the Root Cause After containment, identify and remove: - Malware artifacts, backdoors, persistence mechanisms - Compromised credentials (rotate ALL affected credentials) - Vulnerable software or configurations that enabled the attack - Attacker-created accounts, scheduled tasks, cron jobs ### Step 5: Recover Systems - Restore from known-good backups (verified pre-compromise) - Rebuild compromised systems from hardened images - Re-enable services incrementally with monitoring - Validate integrity of restored data - Confirm no residual attacker presence ### Step 6: Conduct Post-Mortem ``` Post-Incident Review Template: ================================ Incident ID: INC-YYYY-NNNN Date of incident: YYYY-MM-DD Date of review: YYYY-MM-DD Severity: SEV-N Type: [Incident Type] Timeline: - HH:MM Detection - HH:MM Triage started - HH:MM Containment achieved - HH:MM Eradication complete - HH:MM Recovery verified Root Cause: [Description] What Went Well: - [Item] What Needs Improvement: - [Item] Action Items: - [ ] [Action] -- Owner: [Name] -- Due: [Date] ``` ## Examples ### Example 1: Complete Ransomware Response Playbook **Trigger conditions:** Endpoint detection alert for file encryption activity, user reports of locked files, ransom note displayed on screen. **Severity:** SEV-1 Critical (assume lateral movement until proven otherwise) ``` RANSOMWARE RESPONSE PLAYBOOK ============================== PHASE 1: DETECTION & ANALYSIS (0-15 min) ------------------------------------------ [ ] Confirm ransomware (check file extensions, ransom note content) [ ] Identify ransomware variant (use ID Ransomware or similar) [ ] Determine patient zero (first infected host, timestamp) [ ] Assess scope: how many hosts show encryption activity? [ ] Check if backups are accessible and unaffected [ ] Capture initial indicators of compromise (IoCs): - File hashes of ransomware binary - C2 server IPs/domains - Ransom note text (for variant identification) PHASE 2: CONTAINMENT (15-60 min) ---------------------------------- IMMEDIATE (first 5 minutes): [ ] Isolate infected hosts from network (disconnect, do NOT power off) [ ] Block known C2 IPs/domains at firewall and DNS [ ] Disable SMB/lateral movement protocols on affected VLANs [ ] Suspend compromised service accounts NETWORK-LEVEL: [ ] Segment affected network zones [ ] Enable enhanced logging on all boundary devices [ ] Block ransomware-associated file extensions at email gateway [ ] Review and block suspicious scheduled tasks across domain DECISION TREE -- TO PAY OR NOT TO PAY: | +-- Are backups available and verified clean? | YES --> Do NOT pay. Proceed to eradication. | NO --> Continue assessment: | +-- Is the data critical with no alternative recovery? | YES --> Engage legal counsel and law enforcement. | Negotiate through professional negotiator ONLY. | NO --> Accept data loss. Proceed to eradication. | NOTE: FBI and CISA recommend AGAINST paying ransom. Payment does not guarantee decryption keys. PHASE 3: ERADICATION (1-24 hours) ------------------------------------ [ ] Identify initial access vector (phishing, RDP, vulnerability) [ ] Remove all ransomware artifacts from affected hosts [ ] Scan entire environment for dormant payloads [ ] Reset ALL credentials (assume domain-wide compromise): - Domain admin accounts - Service accounts - Local admin accounts - KRBTGT (twice, 12 hours apart for Kerberos) [ ] Patch the exploited vulnerability [ ] Revoke and reissue certificates if CA was compromised PHASE 4: RECOVERY (24-72 hours) --------------------------------- [ ] Restore from verified clean backups (test restore first) [ ] Rebuild systems that cannot be verified clean [ ] Re-enable services incrementally: 1. Core infrastructure (AD, DNS, DHCP) 2. Internal business applications 3. External-facing services [ ] Monitor for re-infection indicators for 72 hours minimum [ ] Validate data integrity of restored systems PHASE 5: POST-INCIDENT (72 hours - 2 weeks) ---------------------------------------------- [ ] Conduct blameless post-mortem within 5 business days [ ] File law enforcement report (FBI IC3, local CERT) [ ] Notify cyber insurance carrier [ ] Update detection rules based on observed TTPs [ ] Schedule follow-up vulnerability assessment ``` ### Example 2: Data Breach Notification Timeline (GDPR 72-Hour Rule) **Trigger conditions:** Confirmed unauthorized access to personal data of EU residents. ``` GDPR BREACH NOTIFICATION TIMELINE ==================================== HOUR 0: BREACH CONFIRMED -------------------------- [ ] Document: what data, how many records, what categories of data subjects [ ] Assign Data Protection Officer (DPO) as notification coordinator [ ] Begin risk assessment: likelihood and severity of impact on individuals HOUR 0-24: INTERNAL ASSESSMENT -------------------------------- [ ] Complete Data Protection Impact Assessment (DPIA): - Nature of breach (confidentiality, integrity, availability) - Categories of personal data (Art. 4 GDPR) - Approximate number of data subjects affected - Likely consequences for data subjects - Measures taken or proposed to mitigate [ ] Determine if notification to supervisory authority is required (required unless "unlikely to result in a risk to rights and freedoms") [ ] Draft notification to supervisory authority (Art. 33) [ ] Prepare data subject notification if high risk (Art. 34) HOUR 24-48: LEGAL REVIEW -------------------------- [ ] Legal counsel reviews notification drafts [ ] Identify ALL applicable jurisdictions (GDPR, CCPA, state laws) [ ] Confirm notification obligations per jurisdiction: - EU/EEA: 72 hours to supervisory authority (Art. 33) - CCPA: "most expedient time possible" to individuals - HIPAA: 60 days to HHS, individuals, media (if >500) - PCI DSS: Immediately to card brands and acquiring bank HOUR 48-72: NOTIFICATION -------------------------- [ ] Submit notification to lead supervisory authority [ ] Notify additional supervisory authorities if cross-border [ ] If high risk to individuals: notify data subjects directly - Clear, plain language - Description of breach - DPO contact details - Likely consequences - Measures taken to mitigate [ ] Document everything in breach register (Art. 33(5)) POST-72 HOURS: ONGOING ------------------------ [ ] Provide supplementary information to authority as investigation progresses [ ] Respond to authority inquiries within requested timeframes [ ] Monitor for evidence of data misuse [ ] Offer credit monitoring/identity protection if appropriate ``` ### Example 3: Slack/PagerDuty Alert Template for Incident Communication ``` INCIDENT COMMUNICATION TEMPLATES =================================== --- PAGERDUTY ALERT (INITIAL) --- Title: [SEV-N] [INCIDENT TYPE] - [Brief Description] Service: [Affected Service] Urgency: [High/Low] Details: What: [1-sentence description of what was detected] Impact: [What is affected -- users, data, systems] Status: Investigating IC: [Name] Channel: #inc-YYYY-MM-DD- --- SLACK: INITIAL NOTIFICATION (#incidents) --- :rotating_light: **INCIDENT DECLARED** **Severity:** SEV-N **Type:** [Ransomware / Data Breach / DDoS / Account Compromise / Insider / Supply Chain] **Summary:** [1-2 sentence description] **Impact:** [Who/what is affected] **Incident Commander:** @[name] **War Room:** #inc-YYYY-MM-DD- **Bridge:** [Zoom/Meet link] **Status:** :yellow_circle: Investigating DO: Join the war room if you are on the response team. DO NOT: Speculate in public channels. All comms go through IC. --- SLACK: STATUS UPDATE (every 30 min for SEV-1/2) --- :loudspeaker: **INCIDENT UPDATE** | [Incident ID] **Time:** HH:MM UTC **Status:** :yellow_circle: Containing / :large_blue_circle: Eradicating / :green_circle: Recovering **Update:** [What changed since last update] **Next Steps:** [What the team is doing next] **ETA to Resolution:** [Estimate or "Unknown"] --- SLACK: RESOLUTION --- :white_check_mark: **INCIDENT RESOLVED** | [Incident ID] **Duration:** [X hours Y minutes] **Root Cause:** [Brief description] **Impact Summary:** [Users affected, data impacted, downtime] **Post-Mortem:** Scheduled for [Date] at [Time] **Action Items:** [Link to tracking ticket] ``` ## Best Practices ### Do This - **Prepare before incidents happen** -- run tabletop exercises quarterly, keep contact lists updated, and verify backup restoration procedures monthly - **Follow the playbook even under pressure** -- the playbook exists because calm thinking during chaos is unreliable - **Preserve evidence first, contain second** -- take memory dumps and disk images before wiping anything - **Communicate early and often** -- stakeholders tolerate uncertainty far better than silence - **Assume breach scope is larger than initial findings** -- attackers rarely compromise only one system - **Document everything with timestamps** -- your incident log is a legal document - **Rotate ALL credentials in the blast radius** -- partial credential rotation leaves doors open - **Test your playbooks with realistic drills** -- an untested playbook is a false sense of security ### Don't Do This - **Don't skip the post-mortem** -- organizations that skip post-mortems repeat the same incidents - **Don't assign blame** -- blameless post-mortems produce actionable improvements; blame produces silence - **Don't reboot compromised systems** -- volatile memory evidence is lost forever on reboot - **Don't communicate through unofficial channels** -- all incident communications must go through the IC - **Don't negotiate directly with ransomware operators** -- use professional negotiators if payment is being considered - **Don't assume one playbook fits all** -- each incident type has unique containment and eradication requirements - **Don't treat the first affected system as patient zero** -- the real initial compromise is usually earlier and elsewhere - **Don't restore from backups without verifying they pre-date the compromise** -- attackers often persist in backups ## Security Checklist ### IR Readiness - [ ] IR policy documented and approved by executive leadership - [ ] IR team roster with primary and backup for each role - [ ] Contact list for legal counsel, law enforcement, cyber insurance, PR firm - [ ] Communication templates pre-approved by legal (internal, customer, regulator, media) - [ ] Playbooks exist for all six incident types listed in this document - [ ] Playbooks reviewed and updated within the last 6 months - [ ] Tabletop exercise conducted within the last quarter - [ ] Full IR simulation (red team + blue team) conducted within the last year ### Communication Plan - [ ] Internal escalation paths defined for each severity level - [ ] External notification obligations documented per jurisdiction (GDPR, CCPA, HIPAA, PCI) - [ ] Pre-drafted holding statements for public communications - [ ] Designated spokesperson(s) identified and media-trained - [ ] Customer notification templates prepared - [ ] Regulatory notification templates prepared with required data fields ### Evidence Chain of Custody - [ ] Forensic imaging tools available and tested (FTK Imager, dd, AVML) - [ ] Evidence handling procedures documented (hash verification, chain of custody forms) - [ ] Secure evidence storage location designated (encrypted, access-controlled) - [ ] Log retention policies ensure logs are available for investigation (minimum 90 days hot, 1 year cold) - [ ] Network traffic capture capability available (full PCAP for critical segments) - [ ] Memory forensics capability available (Volatility, Rekall) ### Lessons Learned Process - [ ] Post-mortem template standardized across the organization - [ ] Post-mortem scheduled within 5 business days of incident closure - [ ] Action items tracked in a ticketing system with owners and due dates - [ ] Action item completion rate reviewed monthly by security leadership - [ ] Incident metrics tracked: MTTD, MTTC, MTTR, incidents by type/severity - [ ] Annual IR maturity assessment conducted ## Related Skills - @mitre-attck-reference -- map observed attacker techniques to MITRE ATT&CK for better detection and response - @sigma-rules-guide -- create and deploy detection rules based on incident indicators - @cve-epss-guide -- prioritize vulnerability remediation to prevent incidents from known CVEs ## Additional Resources - **NIST SP 800-61r2** -- Computer Security Incident Handling Guide (primary framework) - **NIST SP 800-86** -- Guide to Integrating Forensic Techniques into Incident Response - **SANS Incident Handler's Handbook** -- practical field guide for incident responders - **FIRST CSIRT Services Framework** -- capability maturity model for IR teams - **GDPR Articles 33-34** -- breach notification requirements for EU personal data - **CISA Incident Response Playbooks** -- US government IR playbooks for common incident types - **The Ransomware Response Checklist (CISA)** -- step-by-step ransomware-specific guidance - **VERIS Framework** -- vocabulary for describing security incidents in a structured format