Security Incident Response Plan for SOC 2: 2026 Guide

Every SOC 2 audit will test your incident response program. It is not a peripheral control that auditors glance at briefly before moving on. It sits at the center of the Common Criteria under CC7 — one of the most operationally scrutinized sections of any SOC 2 examination. And yet, across first-time SOC 2 programs, incident response is consistently one of the top sources of audit findings, exceptions, and qualified opinions.

The reason is straightforward. Most early-stage and growth-stage SaaS companies handle security incidents informally. An engineer notices something unusual, messages a colleague on Slack, the issue gets investigated and resolved, and life moves on. There is no documented plan. There is no defined escalation path. There is no evidence trail demonstrating that the incident was identified, contained, investigated, and resolved in a controlled manner. When an auditor asks for documentation of how your organization detects and responds to security events, the answer cannot be that it is handled informally by whoever is available.

Building an incident response plan that satisfies SOC 2 requirements is not about writing a lengthy document that lives in a folder and is never opened again. It is about building an operational capability — a defined process that your team understands, can demonstrate through evidence of its operation, and improves over time as your organization learns from real and simulated incidents. This guide explains exactly what SOC 2 requires, what a compliant incident response plan must contain, how auditors evaluate it, and what evidence you need to demonstrate that it operates effectively throughout your audit period.

What SOC 2 Requires for Incident Response

Incident response is addressed primarily under the Common Criteria CC7, which covers system operations and the detection and mitigation of security events. CC7 applies to all SOC 2 programs regardless of which Trust Services Criteria you have selected because it is part of the mandatory Security criterion.

CC7.1 requires that your organization use detection and monitoring procedures to identify configuration changes or the introduction of new vulnerabilities. In practice, this means your organization must have monitoring in place that would surface anomalous activity, configuration changes, and potential security events. This is the detection layer that feeds into your incident response process.

CC7.2 requires that your organization monitor system components and their operation for anomalies indicative of malicious acts, natural disasters, and errors that affect the entity's ability to meet its objectives. For a SaaS company, this means monitoring your production infrastructure, application layer, and network for behavioral anomalies — unusual login patterns, unexpected data access volumes, anomalous API activity, and system errors that could indicate an active threat or a control failure.

CC7.3 requires that your organization evaluate security events to determine whether they meet the definition of a security incident. This is where the formal incident response process begins. Not every security alert is a security incident. CC7.3 requires that your organization have a defined process for triaging detected events, assessing their severity and potential impact, and determining whether they constitute a security incident requiring a formal response.

CC7.4 requires that your organization respond to identified security incidents by executing a defined incident response program. This is the core of what your incident response plan must document. It requires that your organization have a structured response process — including containing the incident, investigating its root cause, communicating appropriately with affected parties, remediating the underlying cause, and documenting the incident and its resolution.

CC7.5 requires that your organization identify, develop, and implement activities to recover from identified security incidents. Recovery addresses how your organization restores normal operations after an incident — not just how it stops the incident.

Across these five criteria, SOC 2 is asking a single fundamental question: when something goes wrong, does your organization know about it quickly, respond to it in a controlled and documented way, and learn from it to prevent recurrence? Your incident response plan is the documented answer to that question, and your incident records are the evidence that demonstrates the answer is true.

What a SOC 2-Compliant Incident Response Plan Must Contain?

A compliant incident response plan is a living operational document — not a template downloaded from the internet with your company name substituted in. Auditors can tell the difference immediately. A plan that uses generic language, references organizational roles that do not match your actual team structure, or describes procedures that do not reflect how your systems actually work will generate findings regardless of how polished the document looks.

Your incident response plan must address the following elements with specificity to your environment.

Scope and Definitions

The plan must define what constitutes a security incident in your organization's context. This is more important than it sounds. If your team does not have a shared understanding of what qualifies as a security incident versus a routine operational issue, your triage process will be inconsistent, and your incident records will be incomplete.

Define security incident broadly enough to capture the events that matter — unauthorized access to systems or data, suspected or confirmed data breaches, malware infections, denial of service attacks, insider threat activity, third-party vendor security events that affect your systems, and any event that could affect the confidentiality, integrity, or availability of customer data. Then define severity levels — typically three or four tiers based on potential impact — so that your team knows which incidents require immediate escalation and which can be handled through a standard response process.

Roles and Responsibilities

Your incident response plan must identify who is responsible for each phase of the response process. Named roles are more effective than named individuals because individuals change — the Incident Response Lead, Security Operations, Engineering On-Call, Legal Counsel, and Executive Sponsor are role-based designations that remain valid when team members change.

The Incident Response Lead is responsible for coordinating the overall response, making escalation decisions, communicating status to internal stakeholders, and ensuring that the incident record is maintained throughout the response.

Engineering or Security Operations is responsible for the technical investigation — identifying the scope of the incident, containing it, collecting forensic evidence, and implementing the remediation.

Legal Counsel is responsible for advising on notification obligations — when a data breach triggers mandatory notification requirements under GDPR, HIPAA, CCPA, or other applicable regulations, legal counsel determines the notification timeline and content.

Executive Sponsor is responsible for decisions that have a material business impact — engaging external incident response support, making public communications about significant incidents, and approving major remediation investments.

Communications Lead is responsible for customer-facing and public communications if the incident requires external notification.

Detection and Reporting

The plan must describe how security incidents are detected and reported internally. Detection sources for a SaaS company typically include automated monitoring and alerting from your security information and event management system, cloud provider security alerts, intrusion detection systems, vulnerability scanning results, and internal reports from employees who observe suspicious activity.

Internal reporting must have a defined channel. Employees need to know how to report a suspected security incident — a dedicated email address, a Slack channel, a ticketing system workflow, or a direct escalation path to the security team. The reporting channel must be documented in the plan and communicated to all employees as part of your security awareness training program.

Response Phases

The core of your incident response plan is the structured response process. A standard incident response lifecycle comprises six phases, and your plan must document your organization's approach to each phase.

Preparation covers the activities that happen before an incident occurs — maintaining the incident response plan, conducting tabletop exercises, ensuring monitoring systems are operational, maintaining incident response tooling, and training the team. Preparation is what auditors look for evidence of, in addition to the plan document itself.

Identification covers how your organization detects and confirms a security incident. This includes the triage process for evaluating security alerts, the criteria for escalating a detected event to an active incident, and the process for documenting the initial incident record. The incident record should be opened at the time of identification and maintained throughout the response — it is one of the primary evidence artifacts your auditor will review.

Containment covers the immediate actions taken to limit the impact of the incident while the investigation continues. Containment actions vary by incident type — isolating a compromised system from the network, revoking access credentials for a potentially compromised account, blocking a malicious IP address, or suspending a vendor API integration that may be the source of unauthorized data access. Your plan should describe containment strategies for the incident categories most likely to affect your environment.

Investigation covers the forensic analysis of the incident — determining how it occurred, what systems and data were affected, whether customer data was involved, and what the root cause was. The investigation phase produces the findings that inform remediation decisions and notification obligations. Detailed investigation notes should be maintained in the incident record — auditors review investigation documentation to assess whether your organization's response was thorough and systematic.

Remediation covers the actions taken to eliminate the root cause of the incident and restore systems to a secure state. Remediation is distinct from containment — containment stops the immediate damage while remediation addresses the underlying vulnerability or control failure that allowed the incident to occur. Remediation actions should be documented in the incident record, along with evidence of their completion.

Recovery and Post-Incident Review covers restoring normal operations, verifying that remediation was effective, and conducting a post-incident review to identify lessons learned and improvements to the incident response program. The post-incident review is a SOC 2 audit focus — it demonstrates that your organization learns from incidents rather than simply resolving them and moving on. The output of a post-incident review should be documented, and any resulting improvements to controls or procedures should be tracked to completion.

Communication and Notification Procedures

Your incident response plan must address both internal communication during an active incident and external notification obligations when customer data is involved.

Internal communication during an active incident should follow a defined process — status updates to the incident response team on a set cadence, escalation triggers for executive involvement, and a communication channel separate from production systems if they are affected by the incident.

External notification is an area where many SaaS companies have gaps in their incident response plans. When a security incident involves the unauthorized access to, disclosure of, or loss of customer personal data, regulatory notification obligations may apply. Under GDPR, affected individuals and supervisory authorities must be notified within 72 hours of the organization becoming aware of a breach.(GDPR notification requirements) Under HIPAA, covered entities and business associates have defined notification timelines. Under the CCPA, California residents whose personal information was exposed in a data breach have the right to be notified.

Your incident response plan must address how your organization determines whether a security incident constitutes a notifiable breach, who makes that determination, the notification timeline for each applicable regulation, the content the notification must include, and who is responsible for executing the notification. If your organization processes personal data under the GDPR, your incident response plan must explicitly reference your 72-hour notification obligation and describe your process for meeting it.

Customer notification — separate from regulatory notification — should also be addressed. Your customer agreements likely include provisions about security incident notification. Your incident response plan should define when and how customers are notified of incidents affecting their data, what the communication includes, and who is responsible for customer-facing communications.

Evidence Your Auditor Will Look For

A SOC 2 auditor evaluating your incident response program is looking for two categories of evidence: evidence that the plan exists and is appropriate, and evidence that the plan actually operates as documented.

Evidence of plan existence and appropriateness includes the written incident response plan itself; documentation that the plan has been reviewed and approved at the appropriate organizational level; evidence that the plan has been communicated to relevant team members; and evidence that team members have been trained on the plan.

Evidence of operational effectiveness is what separates companies with genuine incident response programs from those with documents that exist only on paper. For a SOC 2 Type II audit, your auditor will review the following evidence over your audit period.

Incident records are the primary evidence that your incident response process operates. Every security incident that occurred during your audit period should have a corresponding incident record — documenting the detection timestamp, the triage assessment, the severity classification, the assigned incident response lead, the containment actions taken, the investigation findings, the remediation actions completed, and the post-incident review outcome. If your audit period passes without a single security incident being documented, your auditor may question whether your detection and monitoring controls are operating effectively or whether incidents are occurring but not being formally documented.

Monitoring alerts and logs demonstrates that your detection systems are generating signals that feed into your incident response process. Your auditor will want to see evidence that monitoring systems are operational and that alerts are being reviewed.

Tabletop exercise records demonstrate that your team has tested the incident response plan through simulated incident scenarios. A tabletop exercise — a structured walkthrough of a hypothetical incident scenario with your incident response team — should occur at least annually and produce a documented record of the exercise, who participated, what scenarios were tested, and what improvements were identified. Tabletop exercises are one of the most commonly missing evidence items in first-time SOC 2 programs and one of the most straightforward to implement.

Post-incident review documentation for significant incidents during the audit period demonstrates that your organization evaluates incidents systematically and acts on the lessons learned.

Access reviews and remediation tracking related to incidents demonstrate that when incidents identify control gaps — an overprivileged account that was exploited, a misconfigured security group, an unpatched vulnerability — your organization tracks those gaps to remediation rather than identifying them and moving on.

Common Audit Findings in Incident Response

Across SOC 2 audits, incident response yields a consistent set of findings that recur in programs at different stages of maturity. Understanding these findings before your audit helps you address them proactively.

No documented incident response plan. The most fundamental finding — your organization handles incidents informally but has not documented the process. The remediation is straightforward: document the plan. The harder part is ensuring that the documented plan reflects actual practice rather than an idealized process that nobody follows.

A plan exists but has never been tested. Your organization has a written incident response plan, but cannot produce evidence of a tabletop exercise or any other form of plan testing. Auditors treat an untested plan as a design-only control — it may be appropriately designed, but its operational effectiveness has not been demonstrated. Conducting and documenting a tabletop exercise prior to your audit period will resolve this finding.

Incident records are incomplete or inconsistent. Your organization has resolved security incidents during the audit period, but the incident records are incomplete — missing investigation notes, remediation actions, or post-incident review documentation. Establish a defined incident record template and require consistent documentation for every incident from the start of your audit period.

No defined notification procedures for data breaches. Your incident response plan addresses technical response, but does not document your organization's obligations and process for notifying affected individuals or regulators in the event of a data breach. This finding is particularly common in companies that have not previously engaged legal counsel on their notification obligations. Resolve it by working with legal counsel to document your notification obligations and incorporate a notification procedure into the plan.

Monitoring gaps that affect detection capability. Your auditor identifies systems or data types within your SOC 2 scope that are not covered by your monitoring program — meaning that incidents affecting those systems might not be detected by your current alerting infrastructure. This finding requires remediation of your monitoring coverage, not just your documentation.

Post-incident reviews were neither conducted nor documented. Your organization resolves incidents but does not conduct systematic post-incident reviews. Auditors view this as a gap in your continuous improvement process. Establish a requirement that every incident above a defined severity threshold receives a post-incident review and that the review is documented.

Maintaining Your Incident Response Program Between Audits

SOC 2 Type II requires evidence of consistent control operation throughout the audit period — not just at the beginning and end. Your incident response program needs to be operational and continuously generate evidence, not a document you activate when the audit window opens.

Review and update your incident response plan at least annually and whenever significant changes occur — such as new product launches, major infrastructure changes, new regulatory obligations, or material changes in your threat environment. Each review should be documented with the review date, the reviewers' names, and any changes made.

Conduct tabletop exercises at least annually. Vary the scenarios across years — a ransomware scenario one year, a data breach scenario the next, a third-party vendor compromise the year after. The goal is to test different aspects of your plan and identify gaps before a real incident does.

Maintain your incident record system consistently. Every security event that is triaged — even if it is assessed as a non-incident — should have a brief record in your incident management system. This demonstrates that your detection and triage process operates continuously, not just during significant events.

Track remediation actions to completion. When incidents identify control gaps, create tracked remediation tasks with assigned owners and target completion dates. Your auditor will want to see that identified gaps are being closed, not just documented.

Review your notification procedures when regulations change. Privacy and breach notification regulations are not static. As GDPR implementing guidance evolves, state breach-notification laws are updated, and new regulations may apply to your business as it expands into new markets. Your legal counsel should review your notification procedures annually to ensure they reflect current obligations.

A mature incident response program is one of the clearest signals of security maturity that a SOC 2 audit can surface. It demonstrates that your organization takes security seriously, not just as a compliance exercise but as an operational discipline — that you have invested in detecting threats, that you have a plan for responding when things go wrong, and that you learn from every incident to build a more resilient system. That signal matters to your auditor. It matters more to your customers.

dsalta helps SaaS companies build incident response programs that satisfy SOC 2 CC7 requirements and maintain the evidence infrastructure needed to demonstrate operational effectiveness throughout every audit period.