SOC 221 April 2026 8 min read

SOC 2 Incident Response Plan: What Auditors Need to See

Learn exactly what your incident response plan must contain to satisfy SOC 2 CC7.3, CC7.4, and CC7.5 — from detection and containment to post-incident review.

Key Takeaways

CC7.3 requires that you identify and respond to security incidents; CC7.4 requires you to contain and remediate them; CC7.5 requires post-incident disclosure and review.
Your incident response plan must define severity levels, escalation paths, roles, containment steps, and communication requirements.
Auditors test incident response by reviewing your documented runbook, checking whether past incidents were logged and followed the process, and interviewing staff about their roles.
Every declared incident — even minor ones — should have a written record: what happened, when, how it was contained, and what was changed afterward.
Tabletop exercises performed annually provide evidence that your team practices the plan, not just that it exists on paper.

In this guide

Which Criteria Apply
Required Plan Components
Defining Severity Levels
Detection and Logging
Containment and Remediation
Post-Incident Review
Evidence Auditors Collect
Tabletop Exercises

Which Criteria Apply

Incident response spans three Common Criteria in the SOC 2 framework. CC7.3 requires that the entity evaluate security events to identify incidents, prioritize them, and communicate to affected parties. CC7.4 requires that identified incidents be contained, remediated, and recovered from. CC7.5 requires that post-incident reviews identify the root cause, assign corrective actions, and communicate findings internally and — where required — externally.

These three criteria sit within the broader CC7 cluster on system monitoring and response. Auditors treat them as a logical sequence: you cannot satisfy CC7.4 without CC7.3, and you cannot satisfy CC7.5 without CC7.4. A gap in any one of the three will produce findings across all three.

Although CC7 is part of the mandatory Security category, the depth of testing increases when an actual incident occurred during the observation period. Auditors will request the incident record and verify that your team followed the documented process.

Required Plan Components

An effective incident response plan for SOC 2 purposes must address six elements: (1) definition of what constitutes a security incident versus a normal operational event; (2) severity classification tiers with criteria for each level; (3) roles and responsibilities — who declares an incident, who leads containment, who communicates externally; (4) detection sources and intake channels; (5) step-by-step response procedures for common incident types; and (6) post-incident review and disclosure requirements.

The plan does not need to be long. Many successful SOC 2 companies have a two-page incident response policy supplemented by runbooks in their runbook management tool (Notion, Confluence, PagerDuty runbooks, etc.). What matters is that the document is current, accessible to the team members named in it, and demonstrably followed.

Your incident response plan should reference your monitoring tools explicitly. If you use Datadog for alerting and PagerDuty for escalation, the plan should name those tools and describe the alert-to-incident workflow. Auditors frequently ask "How would you know if an incident occurred?" — the answer should be grounded in actual tooling, not aspirational language.

Defining Severity Levels

Most SOC 2-ready incident response plans use three or four severity levels. A common taxonomy: SEV-1 (critical) — active breach, data exposure, or complete service outage; SEV-2 (high) — suspected breach, significant service degradation, or unauthorized access to production systems; SEV-3 (medium) — policy violation, attempted but unsuccessful attack, or minor service disruption; SEV-4 (low) — security event that requires tracking but not immediate action.

Each severity level should specify: maximum time to acknowledge (e.g., SEV-1 must be acknowledged within 15 minutes), maximum time to declare containment (e.g., SEV-1 within 4 hours), communication requirements (e.g., SEV-1 and SEV-2 require executive notification), and external disclosure triggers (e.g., any SEV-1 involving customer data requires legal review for breach notification obligations).

Define your severity criteria in terms of observable indicators, not subjective judgments. "Unauthorized access to production database" is clear; "significant security concern" is not. Auditors will look at whether your team applied severity levels consistently across logged incidents.

Detection and Logging

CC7.3 requires that you have mechanisms to detect security events. In practice, this means your monitoring stack must generate alerts that a human sees and evaluates. Common detection sources include: AWS GuardDuty for cloud threat detection, Datadog or Grafana for anomaly alerting, Okta System Log for suspicious authentication events, GitHub Advanced Security for code-level secrets or dependency vulnerabilities, and endpoint detection agents (CrowdStrike, SentinelOne, Jamf Protect) for device-level threats.

Every security event that is evaluated — even those that are determined not to be incidents — should leave a log entry. Auditors testing CC7.3 will ask how many security events were evaluated during the observation period and what the disposition was for each. A common approach is a dedicated Slack channel or Jira project where security alerts flow and are triaged. The triage record serves as evidence.

Incident records themselves must be retained. Each declared incident should have a written record capturing: date and time detected, source and type of event, initial severity classification, actions taken in sequence with timestamps, final disposition, and any corrective actions assigned. A shared incident register (Notion database, spreadsheet, or dedicated tool) satisfies this requirement.

Containment and Remediation

CC7.4 covers what you actually do once an incident is declared. Auditors verify that your team took documented, timely containment steps proportional to severity. For a credential compromise incident, containment typically means: revoking the compromised credential immediately, auditing all sessions and API calls made with that credential, checking for persistence mechanisms (new API keys, IAM role changes, scheduled jobs), and resetting access for affected accounts.

Remediation refers to closing the root cause, not just the immediate exposure. If a phishing attack succeeded because MFA was not enforced on a particular application, remediation includes enforcing MFA on that application — not just revoking the phishing session. Auditors will ask whether the corrective action addressed the root cause or only the symptom.

Document the containment timeline with specific timestamps. If your SEV-1 policy says containment within 4 hours but your incident record shows 7 hours, the auditor will note this as an exception. Either the policy needs to be updated to reflect realistic timelines or the response needs to improve — both are acceptable, but the discrepancy cannot be left unaddressed.

Post-Incident Review

CC7.5 requires a post-incident review for significant incidents. The review should identify root cause, contributing factors, what went well, what went poorly, and corrective actions with owners and due dates. A formal post-mortem document — commonly called a post-mortem or RCA (root cause analysis) — is the expected artifact.

Auditors also look for evidence that corrective actions were actually completed. If your SEV-2 incident from six months ago generated three action items, the auditor will check whether those items were closed. Unresolved corrective actions from prior incidents are a common finding in SOC 2 Type II reports.

CC7.5 also addresses disclosure. For incidents involving customer data, you must have a process for notifying affected customers within the timeframes required by your contractual commitments and applicable law. Document who makes the disclosure decision, who drafts customer communications, and who approves them before sending.

Evidence Auditors Collect

For the incident response criteria, auditors typically request: (1) your current incident response plan or policy; (2) a list of all incidents declared during the observation period; (3) the incident record for each declared incident (or a sample if there are many); (4) post-mortem documents for SEV-1 and SEV-2 incidents; (5) evidence of corrective action completion; and (6) an incident response training or awareness record showing staff know their roles.

If no incidents were declared during the observation period, auditors will note that in the report but will still test the plan design and your detection capabilities. A company with zero incidents but strong detection tooling and a tested runbook is in a better position than one with zero incidents and no monitoring.

A common gap found in first-time SOC 2 audits: companies have an incident response policy but no incident register. Every event evaluated — even routine security alerts that are dismissed after triage — should be logged somewhere. The log is evidence of CC7.3 operating.

Tabletop Exercises

A tabletop exercise is a facilitated simulation of an incident scenario where participants walk through the response steps without actually executing them. Common scenarios: ransomware infection of a developer laptop, data exfiltration via a compromised API key, and a phishing attack targeting the finance team. Tabletop exercises test whether your team understands their roles and whether your plan's procedures are realistic.

For SOC 2 purposes, one tabletop exercise per year is typically sufficient. Document the exercise: date, participants, scenario, key findings, and action items identified. This documentation serves as evidence of CC7.5 operating — specifically the requirement to improve incident response procedures based on lessons learned.

Tabletop exercises are also valuable for identifying gaps in your plan before auditors or a real incident does. Teams frequently discover during tabletops that escalation paths are unclear, that key staff don't know their roles, or that runbooks reference tools that have been replaced. Fixing these gaps during a drill is far less costly than discovering them during a real SEV-1 at 2am.

Frequently Asked Questions

Does SOC 2 require a specific incident response framework like NIST?

No. SOC 2 does not mandate a specific framework for incident response. The Trust Service Criteria describe what outcomes you must achieve (detect, respond, contain, remediate, review) but not how you structure your program. NIST SP 800-61 is a commonly referenced framework that maps well to CC7.3–CC7.5, but you can satisfy the criteria with any structured approach that produces documented evidence of each phase.

What counts as a "security incident" for SOC 2 purposes?

The TSC defines a security incident broadly as any event that threatens the confidentiality, integrity, or availability of your systems or data. This includes unauthorized access attempts (even failed ones if they triggered an alert), data exposures (even to internal staff who should not have had access), malware infections, and significant service disruptions with a security cause. Routine operational outages without a security dimension (e.g., an AWS region going down) are not security incidents under this definition.

We had zero security incidents last year. Will auditors penalize us?

No. Zero incidents is not a finding. Auditors will note that no incidents occurred and will test your detection and response capabilities through plan review and interviews rather than incident records. The important thing is that your monitoring tools were operational and that you can demonstrate they would have alerted you had an incident occurred. Companies with zero incidents but no monitoring tooling are in a worse position than companies with zero incidents and strong detection.

Does our incident response plan need to address ransomware specifically?

SOC 2 does not require ransomware-specific runbooks, but it is best practice. Given that ransomware represents one of the most severe and common threat types for cloud-hosted software companies, a ransomware runbook demonstrates the maturity expected at CC7.4. It also helps you respond faster if an incident actually occurs. Include it in your runbook library even if the main policy document does not reference ransomware explicitly.

How long must we retain incident records for SOC 2?

SOC 2 does not specify a minimum retention period for incident records. Best practice is to retain incident records for at least the duration of your current observation period plus one prior period — effectively at least two years. This allows auditors in future engagements to reference prior incidents when evaluating your corrective action follow-through. Many companies retain incident records for three years aligned to their general records retention policy.