Incident Response Plan: The Complete Template + Implementation Guide for 2026

#Why every IR plan we review fails the first real test

I've reviewed maybe 60 incident response plans in the last three years. Maybe five of them would survive first contact with a real incident. The rest are compliance artifacts. Boards asked for one, so one got written. It sits on a shared drive. Nobody has read it. When a real incident fires, the team freestyles and the plan never gets opened.

This is not an anti-documentation post. Documented plans matter. They're how you train new responders, meet compliance requirements, satisfy insurance carriers, and demonstrate due care in court. But a plan that can't be executed is worse than no plan. It's a false sense of preparedness.

This post is the complete 2026 incident response plan template + implementation guide. What an effective plan contains. How it gets tested. The specific structure that actually survives real use. And the failure patterns that show up in post-incident reviews.

#Why plans fail

Five patterns we see consistently.

1. Written by consultants who won't execute it. Compliance consultant writes the plan. Hands it off. Nobody on the in-house team has contributed. Nobody has authority. Nobody has practiced.

2. Too abstract. The plan describes phases generically. Actual commands, actual contacts, actual decision trees don't exist. During an incident, the responder has to invent the specifics under stress.

3. Too rigid. The plan assumes specific sequences that don't match reality. Real incidents branch. A plan that requires "Phase 1 before Phase 2" breaks on the first incident that doesn't match.

4. Never tested. Tabletop exercises are scheduled annually, skipped twice, done half-heartedly once, not updated after.

5. Stale. Plan written in 2022 references tools, people, and processes that no longer exist.

#The structure that works

Think of the IR plan as three linked documents, not one monolithic doc.

#Document 1. The IR Plan (governance + framework)

10-20 pages. Stable. Reviewed annually.

Contents:

• Purpose, scope, authority
• Definitions (what counts as an incident, severity classifications)
• Incident response team structure
• Role definitions (Incident Commander, Forensic Lead, Communications Lead, etc.)
• Phase framework (detection, containment, eradication, recovery, post-incident)
• Escalation criteria
• External resource lists (with redundant contacts)
• Reporting obligations (regulators, customers, insurance)
• Documentation requirements
• Exercise + testing schedule
• Review + update schedule

#Document 2. Runbooks (operational playbooks)

Per-scenario playbooks. Concrete. Updated as tools change.

Typical runbooks:

• Ransomware response
• Business email compromise
• Cloud account compromise (AWS/Azure/GCP)
• Compromised endpoint
• Data exfiltration confirmed
• Insider threat
• DDoS
• Third-party vendor breach
• Supply chain compromise
• Ransom demand received

Each runbook:

• Indicators / detection signals
• Immediate response steps (first 30 min)
• Containment options with specific commands
• Evidence preservation steps
• Communication templates
• Escalation triggers

#Document 3. Contact + resource directories

Live document. Updated continuously.

Contents:

• IR team contacts (multiple channels per person)
• External forensic firm contacts
• Legal counsel contacts
• Insurance carrier contacts + policy numbers
• Law enforcement contacts (FBI field office, local)
• Executive team contacts
• Key customer contacts (if customer notification might be needed)
• Key vendor contacts
• Regulator contacts (HIPAA OCR, SEC, state AGs, etc.)

#The Incident Commander role

Most critical role. Least understood.

The IC is the single decision-maker during an incident. Not the CISO. Not the CEO. The person who has authority to make rapid decisions and whose decisions the rest of the team follows.

Authority:

• Declare or de-escalate the incident
• Assign roles
• Approve containment actions
• Approve payment negotiations
• Authorize external engagement
• Control communications

Good ICs:

• Technical enough to understand what's happening
• Experienced enough to make calls under pressure
• Senior enough that others follow their decisions
• Available on-call

Who makes a good IC:

• CISO at companies large enough to have one
• Director of IT at mid-market
• CTO at startups
• Sometimes: external IR consultant if internal authority is unclear

The IR plan specifies the IC and two backups. Rotation or specific coverage windows.

#The severity classification

Not every alert is an incident. Not every incident is a crisis.

Severity 1 (Critical)

• Active ongoing attack with business impact
• Confirmed data exfiltration of regulated data
• Active ransomware encryption
• Public-facing service outage affecting revenue

Response: IC activated immediately. Full team engaged. Executive notification within 1 hour.

Severity 2 (High)

• Confirmed compromise, attacker activity paused or contained
• Regulated data exposure under investigation
• Significant partial service disruption

Response: IC activated. Core team engaged. Executive notification within 4 hours.

Severity 3 (Medium)

• Suspicious activity that might be compromise
• Limited scope compromise
• Vendor breach with unclear impact to us

Response: Security team investigates. IC consulted if escalation likely.

Severity 4 (Low)

• Routine alerts requiring investigation
• Isolated events with no active impact

Response: Standard queue, SLA-driven.

The classification drives team activation and notification timelines. Get it wrong and you over- or under-respond.

#The phases

Five phases. Real responses cycle through them non-linearly.

#Phase 1. Detection + validation

Signal received. Is it real?

Detection sources:

• SIEM alerts
• EDR alerts
• Cloud security tool alerts (GuardDuty, Defender for Cloud, SCC)
• User reports
• Third-party notifications
• Threat intelligence
• Regulatory / law enforcement notification

Validation:

• Corroborate across sources
• Check for false positive patterns
• Gather context before declaration
• Time-box validation (30 min max for high-urgency signals)

#Phase 2. Declaration + activation

Incident declared. Team assembled. Clock starts.

• IC assigned
• Role assignments made
• Communication channel established (dedicated Slack channel or war room)
• Initial severity classification
• Executive notification if Sev 1-2
• External engagement considered

#Phase 3. Containment

Stop the bleeding without destroying evidence.

Principles:

• Preserve evidence (don't reboot, don't delete, snapshot before changes)
• Scope matters (contain without over-reacting)
• Reversible actions preferred
• Document every action taken

Common containment actions:

• Isolate affected systems from network
• Disable compromised accounts
• Rotate compromised credentials
• Block C2 domains
• Quarantine suspicious files
• Stop malicious processes

#Phase 4. Eradication

Remove attacker presence after containment.

• Root cause identified
• Compromised systems cleaned or rebuilt
• Attacker persistence removed (backdoors, scheduled tasks, IAM changes)
• Credentials rotated across blast radius
• Detection rules updated

#Phase 5. Recovery

Return to normal operations.

• Restore from known-good state
• Monitor for attacker return
• Reintegrate systems in staged manner
• Performance validation
• All-clear declaration

#Phase 6. Post-incident

The part that makes the next incident easier.

• Timeline documented
• Root cause analysis completed
• Lessons learned captured
• IR plan updated
• Controls updated
• Detection rules refined
• Follow-up actions tracked to completion

#Exercise cadence

Plans get tested or they atrophy.

#Quarterly. Tabletop exercises

2-4 hour exercises. One scenario. Core team only. No production systems touched.

Purpose:

• Validate plan against current reality
• Train team
• Identify gaps in communication, decision-making, authority
• Update plan based on findings

#Annually. Purple team exercises

Longer, more realistic. External red team runs an attack scenario. Internal blue team responds. IR plan used for real.

Purpose:

• Test technical detection + response capabilities
• Test IR plan under realistic conditions
• Identify technical gaps

#As-needed. Post-incident drills

After every material incident, run a simulation of the same scenario with variations. Tests whether remediation actually fixed the underlying gap.

#Specific drills for high-stakes scenarios

• Ransomware decision drill (Should we pay?)
• Customer notification drill (Board + Legal + Comms decision on messaging)
• Regulator notification drill (Timing, content, counsel coordination)

#Specific scenario runbooks

#Ransomware response

Indicators:

• Mass file renaming across shares
• Ransom note appearing
• Multiple systems unresponsive
• EDR alerting on known ransomware families
• Users reporting file access failures

Immediate actions (first 30 minutes):

1. IC activated, team assembled
2. Power state preservation (don't shut down, isolate)
3. Backup system status check (are backups also affected?)
4. Legal + insurance notification
5. Forensic firm engaged (if retainer exists)
6. Initial scope assessment

Key decisions:

• Are backups intact?
• Is the attacker still active?
• Is data exfiltrated (double extortion)?
• What regulators are involved?
• Do we pay?

#Business Email Compromise

Indicators:

• User reports strange email activity
• Mail rules created without user's knowledge
• Wire transfer request comes in that feels off
• External email auth failures on inbound that claims to be internal

Immediate actions:

1. Compromised account isolated (revoke sessions, reset password + MFA)
2. Forensic snapshot of mailbox
3. Mail rules review + cleanup
4. OAuth grants review
5. Finance team alerted to watch for fraudulent requests
6. Downstream contact notification (customers, vendors who might have received phishing from the account)

#Cloud account compromise

Indicators:

• Unusual API activity in CloudTrail/Activity Log/Audit Log
• Unexpected cost spike
• New IAM entities appearing
• Credentials showing up in public (GitHub, pastes, stealer logs)

Immediate actions:

1. Forensic role assumed via break-glass if needed
2. Compromised credentials rotated
3. Session tokens revoked
4. Audit logs preserved
5. Attacker-created resources identified + contained
6. Full scope assessment

See our cloud IR playbook.

#Data exfiltration

Indicators:

• Large outbound data transfers
• Access to data the user doesn't typically access
• DLP alerts
• Third-party notification
• Data appearing for sale

Immediate actions:

1. Scope assessment
2. Preserve logs
3. Legal engaged for regulatory analysis
4. Affected data classification
5. Customer notification planning
6. Regulator notification clock started

#Insider threat

Indicators:

• HR-reported concern
• Unusual access patterns
• Mass data downloads near termination
• Privilege escalation attempts

Immediate actions (sensitive):

1. HR + legal involvement before taking action
2. Evidence preservation without tipping off subject
3. Access limitation (not immediate termination yet)
4. Forensic investigation
5. Decision on employment action + notification

This one requires delicate handling. Get it wrong and you create legal exposure.

#Third-party vendor breach

Indicators:

• Vendor notification of breach
• Public news of vendor breach
• Customer receiving phishing appearing to come via vendor
• Vendor service disruption

Immediate actions:

1. Vendor information gathering (scope, affected data, timeline)
2. Our data classification (what of ours does vendor hold?)
3. Customer/employee impact assessment
4. Legal + insurance
5. Regulator notification if our data was affected
6. Vendor relationship decisions

#Reporting obligations

Different jurisdictions, different data types, different timelines.

#Federal US

• HIPAA Breach Notification. 60 days to individuals and HHS. More for affected populations > 500.
• SEC Cybersecurity Disclosure (public companies). 4 business days for material incidents.
• DoD CUI incidents (CMMC). 72 hours to DoD Cyber Crime Center.
• Federal Trade Commission Safeguards Rule. 30 days for non-bank financial institutions.

#State US

• State breach notification laws. 50 different timelines. Most 30-45 days. Some states 72 hours for specific data types.
• New York (NYDFS, SHIELD). 72 hours to DFS.
• California (CCPA). "Without unreasonable delay."
• Texas. 30 days plus notification to AG if > 250 affected.
• Virginia (VCDPA). Reasonable timeline, commercially reasonable controls required.

#International

• GDPR (EU residents). 72 hours to supervisory authority.
• UK DPA. 72 hours to ICO.
• Canada PIPEDA. Without unreasonable delay.

Maintain a breach notification matrix. Pre-built content templates. Legal counsel engaged early to drive accurate reporting within deadlines.

#Communication templates

Pre-drafted content templates for common scenarios. Faster + more controlled than writing during an incident.

Types:

• Internal all-staff notification
• Executive briefing
• Customer notification (by severity)
• Vendor notification
• Regulator notification (by regulator)
• Law enforcement notification
• Press statement
• Board notification
• Insurance carrier notification

Templates include:

• Approved language
• Legal-reviewed boilerplate
• Blanks for incident-specific details
• Escalation triggers (when to use what template)

#Insurance coordination

Cyber insurance carriers have specific requirements for coverage.

Upon incident:

1. Notification within policy-required window (typically 24-72 hours)
2. Pre-approved forensic firm engagement (carrier often has approved list)
3. Pre-approved breach counsel engagement
4. Documentation requirements
5. Cooperation obligations

Failure to follow these can void coverage. Review your policy. Integrate carrier requirements into the plan.

#Legal coordination

Incidents produce legal exposure. Counsel involvement early matters.

Attorney-client privilege considerations:

• Engage outside counsel early
• Frame investigation as legal privilege protected
• Work product doctrine for forensic findings
• Careful with internal emails about the incident

Regulatory counsel:

• Breach notification counsel (HIPAA, state breach laws)
• SEC counsel for public companies
• International counsel for GDPR
• State AG counsel for jurisdictions where notification will land

#Plan maintenance

Plans that live get updated.

• Quarterly review for contact accuracy
• After every exercise
• After every real incident
• After significant organizational changes (M&A, leadership transitions)
• Annual full review

Owner: Security leadership. Accountability: Board or executive.

#Templates

We have a plan + runbook template library we work with clients on. Customization for industry + scale + existing tooling.

For a mid-market organization from scratch:

• 4-6 weeks to stand up initial plan + top 5 runbooks
• 3-6 months to full maturity with exercises + updates

#Working with us

We run IR plan development + tabletop engagements. Typical work:

• Current-state assessment
• Plan development using proven templates
• Runbook development for priority scenarios
• Tabletop exercise facilitation
• Plan integration with SIEM / EDR / SOAR
• Post-incident retrospectives

We are not first-responder IR. We prepare you so you're ready before you need first-responders.

Valtik Studios, valtikstudios.com.