Incident Response Plan Template 2026: A CISO-Grade Playbook

IT/Security Operations (Responsible)

This is the "hands-on" team comprising SOC analysts, network engineers, endpoint security specialists, and cloud engineers. They are Responsible for executing the technical aspects of the response under the direction of the Incident Commander. Their tasks include collecting and analyzing forensic data, implementing containment measures (e.g., disabling compromised accounts, isolating hosts), eradicating the threat, and restoring affected systems from secure backups.

Executive Leadership (Informed)

The CEO, CFO, and other C-suite members must be kept Informed of the incident's business impact, not its granular technical details. They need a clear understanding of the operational disruption, potential financial implications, and the strategic decisions being made by the IC. They are the ultimate stakeholders, responsible for the business but must trust the IC to manage the incident itself. The IC's reports to this group should be concise, business-focused, and aligned with materiality thresholds.

Triage and Escalation: The Severity Classification Matrix

Not all incidents are created equal. A malware infection on a marketing intern's laptop is not the same as a ransomware event encrypting the entire ERP system. A severity classification matrix provides a standardized, objective framework for triaging incidents, ensuring that resources are allocated proportionately to the risk.

This matrix should be simple enough to be used under pressure. It typically defines 3-5 severity levels based on business impact.

Severity Level	Data Impact	Systems/Service Impact	Brand/Financial Impact
1 - Critical	Widespread PII, PHI, or critical IP exfiltration/destruction.	Core production systems or entire cloud environment unavailable.	Direct, material financial loss. Widespread negative media. Regulatory reporting is certain.
2 - High	Localized but significant data breach.	A critical business application or key network segment is down.	Significant operational disruption. Potential for reputational damage. Regulatory reporting is likely.
3 - Medium	Unauthorized access to non-sensitive data.	Non-critical systems are impaired, or a single server is compromised.	Minor operational friction. Limited external visibility.
4 - Low	Suspected access with no confirmed exfiltration.	A single user endpoint is compromised.	Negligible impact. Managed through standard operational procedures.

A real-world example of a Severity 1 event is the /case-studies/mgm-resorts-ransomware-case-study, where social engineering led to a widespread system lockdown, causing hundreds of millions in lost revenue and operational chaos. This matrix forces the initial responder to quickly assess impact across multiple vectors and triggers the appropriate level of escalation as defined in the plan.

The First 60 Minutes: A Tactical Runbook

The first hour of a major incident sets the tone for the entire response. A lack of clear, immediate action can lead to greater data loss, deeper system compromise, and significant business disruption. The goal of the first-hour runbook is to move from chaos to a structured, controlled response.

Minutes 0-15: Alert, Verification, and Initial Triage

• Action: The on-duty analyst in the Security Operations Center (SOC) receives a high-fidelity alert (e.g., from an EDR, SIEM, or cloud security tool).
• Process: The analyst immediately works to verify the alert. Is it a false positive? Initial indicators of compromise (IoCs) like malicious IP addresses, file hashes, or suspicious user account activity are collected in a dedicated incident ticket or log. The analyst makes a preliminary severity assessment using the matrix.

Minutes 15-30: Declaration and Assembly

• Action: Upon verification of a legitimate incident (Severity 1-3), the analyst executes the escalation procedure. This involves contacting the on-call Incident Commander via a primary and backup communication method (e.g., phone call, secure messaging app).
• Process: The IC officially declares an incident, which formally activates the IR plan. The IC convenes the core incident response team (e.g., key contacts from Security, IT, Legal) on a pre-designated conference bridge or secure chat channel. This "war room" becomes the central hub for coordination.

Minutes 30-60: Initial Containment and Communication

• Action: The IC, armed with initial IoCs from the technical team, makes the first critical containment decisions. This is not about eradication; it is about stopping the bleeding.
• Process: Decisions may include:
  • Isolating affected network segments from the rest of the enterprise.
  • Disabling compromised user or service accounts.
  • Blocking malicious domains or IPs at the firewall/proxy.
  • Engaging Legal to establish attorney-client privilege over the investigation.
  • Notifying your cyber insurance carrier. The /cyber-insurance/cyber-insurance-claims-process is often triggered by this first call, which must happen within the policy's specified window (typically 24-72 hours). This step is non-negotiable and often dictates which third-party experts you are permitted to engage.

Navigating the Regulatory and Insurance Minefield

Responding to a cyber incident is no longer a purely technical exercise. It is a complex process governed by contractual obligations to insurers and legal duties to regulators. A failure in this domain can be as costly as the breach itself.

Insurer Notification Windows

Cyber insurance policies are not "get out of jail free" cards; they are contracts with specific performance clauses. Nearly every policy contains a strict notification requirement. Organizations must formally report a known or even suspected incident to their carrier, typically within 24 to 72 hours of discovery. "Discovery" is a legally significant term, often defined as the moment a key individual becomes aware of the situation. Waiting until the incident is fully contained is a recipe for a denied claim.

This initial notification triggers the engagement of the insurer-provided breach coach (an external lawyer specializing in incident response) and provides access to a panel of pre-approved forensic and remediation vendors. Deviating from this panel without explicit written consent from the carrier can also jeopardize coverage.

Regulatory Timelines

The regulatory landscape has become a patchwork of aggressive timelines that demand rapid assessment and disclosure.

• SEC Materiality Rule (2023): Publicly traded companies are now required to disclose a "material" cybersecurity incident on Form 8-K within four business days of determining materiality. The challenge lies in the materiality assessment itself, which is a complex business judgment made under extreme pressure with legal counsel. The clock starts ticking not on discovery of the incident, but on the determination of its material impact.
• GDPR (EU): The General Data Protection Regulation requires notification to the relevant Data Protection Authority within 72 hours of becoming aware of a personal data breach, "unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons."
• NIS2 Directive (EU): For entities covered by the Network and Information Security 2 Directive, the rules are even more demanding. It mandates a multi-stage reporting process: an "early warning" within 24 hours of becoming aware of a significant incident, a more detailed incident notification within 72 hours, and a final, comprehensive report no later than one month after.

Evidence Preservation and Legal Hold

Parallel to containment and notification is the critical duty to preserve evidence. As soon as an incident is declared, Legal must issue a formal legal hold notice to all relevant employees. This instructs them to preserve all potentially relevant information—including logs, disk images, emails, chat messages (e.g., Slack, Teams), and system configurations. Technical teams must be trained to understand that their remediation efforts cannot come at the cost of destroying forensic evidence. Capturing volatile memory and creating forensic images of affected systems before wiping and rebuilding them is a standard, defensible procedure. Spoliation (destruction) of evidence can result in severe sanctions in any subsequent litigation or regulatory investigation.

The Feedback Loop: Tabletop Exercises and Post-Mortems

An incident response plan that sits on a shelf is a liability. Its value is realized only through constant testing, refinement, and integration into the organization's muscle memory.

Tabletop Exercise Cadence

Tabletop exercises are simulated walk-throughs of the IR plan. They are not technical drills but decision-making workshops. A mature program incorporates a multi-tiered cadence:

• Quarterly Operational Tabletops: Involving the core technical and security response team. These exercises test specific tactical runbooks—for example, responding to a phishing campaign that bypasses EDR controls.
• Annual Executive Tabletops: Involving the C-suite, Legal, and Communications. These simulations focus on the business decisions required during a major crisis. A scenario based on a sophisticated and patient adversary, like the compromise detailed in the /case-studies/solarwinds-supply-chain-attack, is an excellent test of strategic response and communication capabilities. The goal is to stress-test the RACI matrix and the flow of information to leadership.

The Post-Mortem Template (Post-Incident Activity)

After every significant incident or tabletop exercise, a formal post-mortem is mandatory. The objective is not to assign blame but to identify systemic weaknesses and drive improvement. A blameless post-mortem culture is essential. The final report should be structured to answer five key questions:

1. What happened? A concise, factual, and chronological summary of the incident, from initial detection to final resolution.
2. What was the impact? Quantify the business impact wherever possible. This includes metrics like hours of downtime, number of systems affected, number of records breached, and estimated financial costs. This process of quantification should inform a /breach-costs/post-breach-recovery-budget-framework to better forecast future needs.
3. What went well? It is crucial to identify and reinforce successful actions. Did the team follow the runbook? Was communication clear? Did a specific technology perform as expected?
4. What could be improved? This is the core of the analysis. Identify specific gaps in process, technology, or skills. Was detection too slow? Were containment tools ineffective? Was there confusion about roles?
5. Action Items: Every identified area for improvement must be converted into a SMART (Specific, Measurable, Achievable, Relevant, Time-bound) action item. Each item must have a clear owner and a due date. These action items are tracked to completion by the security leadership, ensuring the organization actually learns from the event and hardens its posture.