Incident Response Plan: What to Include, How to Build One, and What Auditors Expect

Published March 2026  ·  Continuity Strength  ·  11 min read

An incident response plan is a documented set of procedures that defines how an organization detects, contains, and recovers from security incidents. It assigns roles, establishes severity classifications, defines communication protocols, and provides the step-by-step actions teams follow when a breach, ransomware attack, unauthorized access, or system compromise occurs. Every organization that handles sensitive data needs one. Every major compliance framework requires one. And every auditor evaluating your security program will ask to see it.

But having a plan is not the same as having one that works. The gap between a document in a shared drive and an operational control that auditors can validate is where most organizations fail. The plan was last updated two years ago. It names a response team that no longer includes the right people. It has never been tested. The auditor asks when it was last exercised, and the answer is silence.

This guide covers what an incident response plan must contain, how to build one that reflects how your organization actually operates, what each major compliance framework specifically requires, and how to avoid the most common audit findings.

What Is an Incident Response Plan

An incident response plan (IRP) is the documented playbook for how your organization handles security incidents. It is not the same as a business continuity plan, which addresses maintaining operations during disruptions. The IRP specifically addresses the detection, investigation, containment, and resolution of security events where data confidentiality, integrity, or availability may be compromised.

The plan serves two purposes. Operationally, it ensures the response team knows exactly what to do under pressure rather than making decisions ad hoc during a crisis. For compliance, it provides the documented evidence that auditors, certification bodies, and enterprise customers require to validate that your organization is prepared for security incidents. SOC 2 auditors expect one. ISO 27001 certifiers require one. NIST CSF references one. DORA mandates one. SEC examiners reviewing Regulation S-P compliance will request one.

What Every Incident Response Plan Must Contain

Regardless of which framework you are certifying against, auditors evaluate the same core components. The frameworks differ in terminology and emphasis, but the structural requirements converge around seven elements.

1. Scope and Purpose

The plan must define what it covers and what it does not. Which systems, data types, and operational environments fall within scope? What constitutes an "incident" under this plan versus a routine operational issue? A plan that covers everything in theory covers nothing in practice. Auditors want to see that you have drawn clear boundaries around what triggers the response process.

2. Incident Classification and Severity Levels

Not every incident requires the same response. A failed login attempt is not the same as an exfiltration of customer data. The plan must define severity levels with specific criteria for each. Common models use three to four tiers: low (no customer data affected, contained internally), medium (potential exposure, limited scope), high (confirmed unauthorized access to sensitive data), and critical (active breach with ongoing data loss or system compromise).

The classification drives everything downstream: who gets notified, how quickly, what containment steps are taken, and whether customers or regulators must be informed. Without defined severity levels, the response team makes ad hoc decisions under pressure, which is exactly what auditors flag as a control weakness.

3. Roles, Responsibilities, and Contact Information

The plan must name the individuals responsible for each phase of the response. This includes the incident response lead, the technical investigation team, the communication lead (internal and external), legal counsel, and the executive sponsor who authorizes customer notification and regulatory reporting.

Auditors check whether the named individuals are current. A plan that lists a former employee as the incident response lead is a finding. Contact information must be complete and updated: direct phone numbers, email addresses, and escalation paths that work outside business hours.

Key Point Name Real People, Not Titles A plan that says "the CISO will lead the response" is weaker than one that says "Jane Smith, CISO, will lead the response" with her direct number and a named backup. Auditors evaluate whether your team can actually execute the plan at 2am on a Saturday, not whether the org chart looks correct.

4. Detection and Identification Procedures

How does your organization identify that an incident has occurred? The plan should describe the monitoring systems, alerting mechanisms, and reporting channels that surface potential incidents. This includes automated alerts from security tools (SIEM, endpoint detection, intrusion detection), reports from employees, and notifications from third parties including service providers required to notify you within 72 hours under Regulation S-P.

Auditors want to see that detection is not dependent on a single channel. If your only detection mechanism is an employee noticing something unusual, that is a gap. The plan should document multiple detection paths and the process for triaging incoming alerts to determine whether they constitute an incident.

5. Containment, Eradication, and Recovery Procedures

Once an incident is confirmed and classified, the plan must describe the steps to contain it, eliminate the root cause, and restore normal operations. These procedures should be specific enough to guide action under pressure but flexible enough to adapt to different incident types.

Containment includes short-term actions (isolating affected systems, revoking compromised credentials, blocking malicious IP addresses) and long-term actions (patching vulnerabilities, rebuilding compromised systems, implementing additional monitoring). The plan should distinguish between the two and define who authorizes each.

Recovery procedures should include criteria for determining when systems are safe to return to production, how data integrity is verified after restoration, and what enhanced monitoring is applied during the recovery period.

6. Communication and Notification Protocols

The plan must define who is notified at each severity level and through which channels. Internal communication (response team, executive leadership, board of directors) follows one path. External communication (affected customers, regulators, law enforcement, media) follows another.

For regulated entities, notification timelines are not optional. Regulation S-P requires customer notification within 30 days. GDPR requires supervisory authority notification within 72 hours. DORA requires initial notification to competent authorities within defined timeframes. Your plan must reference the specific notification obligations that apply to your firm and include pre-drafted notification language that can be adapted to different incident scenarios.

7. Post-Incident Review and Lessons Learned

Every incident, including tabletop exercises, should produce a documented post-incident review. What happened, what worked, what failed, and what changes to the plan are needed. Auditors treat the post-incident review as evidence that the organization learns from incidents and improves its response capability over time.

A plan that does not include a post-incident review process is incomplete. A plan that includes the process but has no records of reviews ever being conducted is a finding.

What Each Framework Requires

The seven components above form the common foundation. Each framework layers specific requirements on top.

SOC 2 evaluates incident response under CC7 (System Operations). Auditors expect a formal plan approved by management and reviewed annually, a defined Computer Security Incident Response Team (CSIRT) with documented roles, and evidence of annual tabletop exercises with documented findings. If your audit includes the Availability criteria, the requirements expand to include business continuity and disaster recovery integration.

ISO 27001 requires incident management planning (A.5.24), assessment of security events (A.5.25), incident response (A.5.26), learning from incidents (A.5.27), and evidence collection (A.5.28). Certifiers place particular emphasis on continuous improvement and documented evidence that corrective actions from past incidents are tracked to completion and integrated back into the ISMS.

NIST CSF organizes incident response across the Respond and Recover functions. While not a certification, many organizations use it as their baseline and auditors reference it when evaluating response program maturity. NIST SP 800-61 (Revision 3, published 2024) provides the detailed technical guidance on incident handling.

DORA requires financial entities to establish ICT-related incident management processes including detection, classification, response, recovery, and reporting to competent authorities. Regular scenario-based testing is mandatory. For significant entities, threat-led penetration testing (TLPT) is required at least every three years.

SEC Regulation S-P requires covered institutions to maintain written policies and procedures for an incident response program that detects, responds to, and recovers from unauthorized access to customer information. Customer notification must occur within 30 days. Service providers must notify covered institutions within 72 hours. The plan must address vendor-originated breaches in addition to internal incidents.

The Evidence Gap: Why Plans Fail Audits

The most common reason incident response plans fail audits is not that they are missing components. It is that they cannot be proven operational. Auditors distinguish between a documented plan (necessary but insufficient) and an operating control (what they actually test).

The evidence gaps auditors find most often:

• No testing evidence. The plan has never been exercised through a tabletop or simulation. SOC 2 Type 2 auditors specifically require annual testing evidence. A plan that has never been tested is a plan that has never been validated.
• No update history. The plan was written once and never revised. Auditors look for version history, annual review dates, and documented changes. A static document signals a compliance checkbox, not an operational program.
• Stale contact information. Named individuals have left the organization. Phone numbers are outdated. The escalation path no longer reflects the current team structure.
• No incident log. If no incidents have occurred during the audit period, the auditor expects a documented statement of non-occurrence. If incidents did occur, the auditor expects records of how the plan was activated, what actions were taken, and what the post-incident review produced.
• No integration with vendor oversight. For regulated entities, the plan must address how vendor-originated breaches are handled. A plan that only covers internal incidents misses the third-party risk dimension that auditors and examiners now evaluate.

Key Point Auditors Test the Evidence, Not the Document A well-written plan with no testing records, no update history, and no incident log will receive a finding. A simpler plan with documented annual exercises, version control, and a maintained incident log will pass. The plan itself matters less than the evidence that it is alive and operational.

How to Build an IRP That Survives the Audit

For organizations building or rebuilding their incident response plan for an upcoming audit or certification, here is the practical sequence.

1. Define scope and classify incidents. Identify which systems, data types, and environments the plan covers. Create a severity classification matrix with specific criteria for each level and the response actions each level triggers.
2. Assign roles with names and contact details. Map every phase of the response to a named individual with a backup. Include direct phone numbers and after-hours escalation paths. Schedule quarterly reviews of the contact list to keep it current.
3. Document detection and response procedures. Write procedures that are specific enough to follow under pressure. For each incident type your organization is most likely to face (data breach, ransomware, unauthorized access, vendor breach, system outage), define the detection triggers, containment steps, eradication actions, and recovery criteria.
4. Map notification obligations to your regulatory environment. If you are subject to Regulation S-P, GDPR, DORA, or state breach notification laws, reference the specific timelines and requirements in the plan. Include pre-drafted notification language.
5. Conduct a tabletop exercise. Walk through a realistic scenario with the response team. Document the date, participants, scenario, decisions made, gaps identified, and corrective actions planned. This single exercise produces more audit evidence than the plan document itself. Continuity Strength produces tabletop exercise documentation in the format auditors and enterprise customers expect.
6. Establish a review cadence. Set an annual review date at minimum. Document every revision with a date, author, and description of changes. Build the review into your compliance calendar so it does not get missed.
7. Create the incident log. Even before an incident occurs, establish the log structure: date, classification, description, actions taken, notification decisions, and post-incident review. If the audit period passes with no incidents, document the non-occurrence.

The entire process produces two categories of audit evidence: the plan document itself (the written control) and the operational records around it (the evidence that the control operates). Both are required. Continuity Strength produces incident response documentation, tabletop exercise records, and business continuity plans in a structured format designed for audits, enterprise customer reviews, and certification programs.

Connecting the IRP to Your Broader Compliance Program

An incident response plan does not exist in isolation. It connects to and depends on several other compliance artifacts:

• Business continuity plan: The BCP addresses maintaining operations during a disruption. The IRP addresses detecting, containing, and recovering from a security incident. They overlap in scenarios where a security incident causes an operational disruption (ransomware is the obvious example). Auditors check that the two plans reference each other and do not contradict.
• Vendor oversight documentation: If your service providers are contractually required to notify you within 72 hours of a breach, the IRP must describe how that notification triggers your response process. The vendor oversight program documents the due diligence and monitoring. The IRP documents what happens when a vendor reports an incident.
• Risk assessment: The IRP should be informed by your risk assessment. The incident types you plan for, the severity classifications you define, and the resources you allocate should reflect the risks your organization actually faces.
• Training and awareness: Employees need to know their role in incident detection and reporting. The IRP should reference (or be referenced by) your security awareness training program.

Auditors increasingly evaluate these artifacts as a system rather than as isolated documents. A strong IRP that contradicts the BCP, ignores vendor risk, or disconnects from the risk assessment will draw scrutiny. Continuity Strength's compliance evidence packages produce these artifacts in a consistent format with built-in cross-references across document types.

Incident Response Documentation: Built for Audits and Real Incidents

Startups and SMBs use Continuity Strength to produce incident response documentation, tabletop exercise records, business continuity plans, and vendor oversight evidence in a review-ready format. Select the compliance evidence package that fits your certification program and start producing documentation today.

See Compliance Evidence Packages

Not sure which package fits? Email us and we will point you in the right direction.

Frequently Asked Questions

What is an incident response plan?

An incident response plan is a documented set of procedures that defines how an organization detects, investigates, contains, and recovers from security incidents such as data breaches, ransomware attacks, unauthorized access, and system compromises. It assigns roles and responsibilities, establishes severity classifications, defines communication and notification protocols, and provides step-by-step actions for the response team to follow during a crisis. It is a required artifact for SOC 2, ISO 27001, NIST CSF, DORA, and SEC Regulation S-P.

Is an incident response plan required for SOC 2?

Yes. SOC 2 auditors evaluate incident response under the Security Trust Services Criteria, which is mandatory for every SOC 2 audit. They expect a formal plan approved by management, reviewed annually, and tested through tabletop exercises. For Type 2 audits, the auditor tests whether the plan operated effectively during the observation period, which means testing evidence and incident logs or documented non-occurrence are required.

What is the difference between an incident response plan and a business continuity plan?

An incident response plan addresses how the organization detects, contains, and recovers from security incidents such as data breaches, ransomware attacks, and unauthorized access. A business continuity plan addresses how the organization maintains operations during any type of disruption, including natural disasters, infrastructure failures, and key personnel loss. The two plans overlap in scenarios where a security incident causes an operational disruption, and auditors expect them to be consistent with each other.

How often should an incident response plan be tested?

At minimum, annually. SOC 2, ISO 27001, and DORA all expect regular testing through tabletop exercises or simulation drills. For organizations with higher risk profiles or regulatory obligations, semi-annual testing is recommended. Every test should produce documented evidence including the date, participants, scenario, decisions made, gaps identified, and corrective actions planned.

Does the incident response plan need to cover vendor breaches?

For regulated entities, yes. Under SEC Regulation S-P, the incident response program must address breaches that originate at service providers. The plan should describe how vendor breach notifications, required within 72 hours under Reg S-P, trigger the firm's response process. Even for non-regulated organizations, auditors increasingly expect the IRP to address third-party incidents as part of a mature response program.