Use this when an organization needs a security incident response plan before an incident happens, or when a security incident has occurred and the response needs structure. Covers the full lifecycle: detection, containment, eradication, recovery, and lessons learned.

Related skills: Use /crisis-comms-playbook for communication framework during security scenarios. Use /incident-postmortem for blameless post-incident review. Use /stakeholder-comms for breach notification drafting. Use /compliance-map for regulatory notification requirements.

Process

Step 1: Gather organization context

Collect the following from the user:

• Team structure -- who is on-call, who has production access, who has authority to take systems offline
• Systems in scope -- production services, data stores, infrastructure, third-party integrations
• Existing monitoring and alerting -- SIEM, log aggregation, intrusion detection, uptime monitoring
• Regulatory requirements -- GDPR (72-hour notification), state breach notification laws, PCI-DSS, HIPAA, industry-specific mandates
• Communication channels -- incident Slack channel, phone tree, video bridge, out-of-band communication (if primary channels are compromised)
• Legal counsel contacts -- internal counsel, external breach counsel, cyber insurance carrier
• Existing incident history -- past incidents, what worked, what didn't

Step 2: Define incident severity levels

Build a classification matrix specific to security events:

| Severity | Criteria | Examples | Response Time | Escalation |
|---|---|---|---|---|
| Critical (S1) | Active data breach, ransomware, complete system compromise | Customer PII exfiltrated, ransomware encrypting production, root access compromised | Immediate -- all hands | CEO, Legal, Board (if applicable) |
| High (S2) | Unauthorized access detected, credential compromise, active exploitation | Admin credentials leaked, lateral movement detected, zero-day exploitation | < 1 hour | VP Engineering, CISO, Legal |
| Medium (S3) | Suspicious activity, policy violation, contained compromise | Anomalous access patterns, unauthorized configuration change, phishing success (contained) | < 4 hours | Security team lead, Engineering manager |
| Low (S4) | Failed attack attempt, minor policy deviation | Blocked brute force, policy exception request, low-severity vulnerability discovered | Next business day | Security team |

Step 3: Build response playbooks per incident type

For each incident type, produce a step-by-step playbook. Each playbook follows this structure:

Incident types to cover: data breach, unauthorized access, malware/ransomware, DDoS, insider threat, supply chain compromise.

Playbook template per type:

## {{incident_type}} Playbook

### Detection triggers
- {{specific_alert_or_signal_1}}
- {{specific_alert_or_signal_2}}

### Immediate containment (first 30 minutes)
1. {{containment_step_1}}
2. {{containment_step_2}}
3. {{containment_step_3}}

### Evidence preservation
- [ ] {{evidence_item_1}}
- [ ] {{evidence_item_2}}

### Communication protocol
- Notify: {{role}} via {{channel}} within {{timeframe}}
- Do NOT: {{action_to_avoid}}

### Escalation path
- If {{condition}}, escalate to {{role}}

### Eradication steps
1. {{eradication_step}}

### Recovery steps
1. {{recovery_step}}

### Regulatory notification required?
- {{framework}}: {{requirement_and_deadline}}

Playbooks must be usable under stress. Clear numbered steps, not dense paragraphs. Someone reading this at 2 AM during an active breach should be able to follow it.

Step 4: Map roles and responsibilities

Define the incident response team with clear ownership:

Define who activates the plan and how: war room channel creation, bridge line, physical assembly point.

Step 5: Generate notification timeline templates

Build notification sequences aligned with regulatory deadlines:

Internal notifications:

• T+0: Incident Commander notified, activates response team
• T+15min: Technical Lead confirms severity classification
• T+1hr: Executive Sponsor briefed (S1/S2 only)
• T+4hr: Legal Counsel briefed with preliminary scope

External notifications (if required):

• T+24hr: Regulatory body preliminary notification (where required)
• T+48hr: Customer notification draft reviewed by Legal
• T+72hr: GDPR supervisory authority notification deadline
• T+varies: State breach notification deadlines (range from 30-90 days)

Public communication (if required):

• Only after Legal and Communications Lead approve
• Template: acknowledge the incident, state what's known, describe actions taken, provide contact for affected parties

Step 6: Evidence preservation procedures

Before any remediation that might destroy evidence, capture:

• System logs (application, authentication, network, firewall) -- export and hash
• Memory dumps from affected systems
• Network packet captures from the incident timeframe
• Access records (who accessed what, when, from where)
• Malware samples (if applicable) -- isolate, do not delete
• Screenshots of attacker activity (if visible)
• Chain of custody documentation -- who collected what, when, how it was stored

Store evidence in a separate, access-controlled location. Document the chain of custody. If law enforcement involvement is possible, do not modify evidence.

Step 7: Post-incident process

After the incident is resolved:

1. Immediate (within 48 hours): Hand off to /incident-postmortem for blameless review
2. Within 1 week: Complete regulatory reporting if required
3. Within 2 weeks: Customer follow-up with remediation details
4. Within 30 days: Insurance notification and claims process (if cyber insurance exists)
5. Ongoing: Track remediation items from postmortem to completion

Step 8: Review

Ask the user:

• Does the team have prior incident response experience?
• Are there legal requirements we haven't addressed?
• Who is the designated Incident Commander, and do they know?
• Does cyber insurance exist, and what are its notification requirements?
• Is there an out-of-band communication plan if primary channels (email, Slack) are compromised?
• Has the plan been tested with a tabletop exercise?

Output location

Deliver as a markdown document. Suggested filename: incident-response-plan-{{org-name}}-{{date}}.md. This document should live somewhere the on-call team can access during an incident -- not buried in a wiki nobody checks.