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:

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:

Activation checklist:

[ ] Incident Commander identified and acknowledged
[ ] War room / incident channel created (Slack: #inc-YYYY-MM-DD-<short-name>)
[ ] 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-<shortname>

--- 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-<shortname>
**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