Writing an Incident Response Policy for SOC 2
An incident response policy for SOC 2 must define how you detect a security event, classify its severity, escalate it to named roles, contain and recover from it, notify affected parties within committed timelines, and review it afterward. That chain maps directly to Trust Services Criteria CC7.3 through CC7.5: evaluating events, responding to incidents, and recovering from them. An assessor reads your policy against those criteria clause by clause. But the document is only half the control. The other half is evidence that you actually ran the policy at least once during the audit period. This guide covers what the policy must say and how an assessor proves it works.
What do CC7.3-CC7.5 actually require from an IR policy?
The 2017 Trust Services Criteria split incident handling across three criteria. CC7.3 requires you to evaluate detected security events to determine whether they rise to an incident. CC7.4 requires a defined response: containment, eradication, mitigation, and communication to affected stakeholders. CC7.5 requires recovery and remediation, including root-cause fixes so the same incident does not recur. Your policy needs an explicit clause for each, because assessors build their test procedures from that mapping.
The upstream criterion, CC7.2, covers monitoring and anomaly detection through your SIEM, EDR, and log review. Your IR policy should reference how events reach the response process, not restate your monitoring stack. Keep the policy about the decisions and actions that follow a flagged event. A common structural mistake is folding detection tooling into the IR policy and leaving the response steps thin. Those response steps are exactly what CC7.4 and CC7.5 grade.
- CC7.3 - evaluate security events, decide incident vs. non-incident
- CC7.4 - contain, eradicate, mitigate, and communicate during response
- CC7.5 - recover operations and remediate root cause to prevent recurrence
What must the policy cover to pass?
A defensible policy runs the full lifecycle in a way a first responder can follow at 2 a.m. without asking who is in charge. "The team will respond appropriately" is not a control. Name the roles, set the clocks, and define what escalation looks like at each severity level.
- Detection intake - how events from CC7.2 monitoring, employee reports, or customer tickets enter the process, and who triages them
- Severity classification - a tiered scheme (for example Sev-1 through Sev-4) with concrete criteria such as confirmed data exfiltration, production outage, or PII exposure, so severity is not left to interpretation
- Roles and escalation - a named Incident Commander, an on-call rotation, and an escalation path to legal, engineering leadership, and the executive sponsor with defined trigger thresholds and time targets per severity
- Containment, eradication, recovery - isolating affected systems, removing the root cause, rotating credentials, restoring from known-good backups, and validating before return to production
- Breach-notification timelines - explicit regulatory, contractual, and customer commitments, referencing GDPR's 72-hour notification clock (which starts when you become aware of the breach, not when you finish investigating) and any state or contractual windows you are bound to
- Post-incident review - a blameless retrospective within a set number of business days that produces a documented root cause, corrective actions with named owners and due dates, and a control-improvement decision
How does an assessor test the incident response policy?
Existence of the document is the easy part. A Type II report tests operating effectiveness across the entire period, so the assessor needs evidence the policy ran, not just that it exists. They ask one question first: did you have a security incident during the audit window? If yes, that incident becomes the primary sample, and they trace it end to end against your policy.
If you had no incident, the accepted substitute is a tabletop exercise. A documented tabletop with a realistic scenario, dated attendance from the named roles, decisions recorded at each phase, and a written after-action report satisfies the operating-effectiveness test for the response controls. No tabletop and no real incident is one of the most common ways CC7.4 lands as an exception in a Type II.
- Real incident sampled - the assessor traces the ticket: detection timestamp, severity assigned, escalation, containment actions, recovery, and the post-incident review with corrective actions closed
- Tabletop as evidence - scenario, agenda, dated sign-in from IR roles, decisions per phase, and an after-action report with follow-up items
- Consistency check - the actions taken must match what the policy commits to; a policy promising 4-hour Sev-1 escalation against a ticket showing three days is a worse finding than having no target at all
- Type I vs. Type II - a Type I tests design at a point in time, so the policy plus evidence of implementation may suffice; a Type II demands the run evidence above, sampled across the period
What are the common gaps that produce findings?
IR exceptions rarely come from anything exotic. They come from the policy and reality drifting apart, or from the policy making commitments the organization never operationalized. Closing these before fieldwork costs far less than remediating an exception in the report.
- No tabletop and no real incident during the period, leaving CC7.4 with no operating evidence
- Severity tiers defined in the policy but never assigned on actual tickets, so classification exists only on paper
- Breach-notification timelines that contradict your customer contracts or signed DPA, or that ignore GDPR's 72-hour obligation
- Post-incident reviews that identify root cause but leave corrective actions open indefinitely with no owner or due date
- Escalation to roles that no longer exist after a reorganization, or an on-call rotation the policy references but the team does not maintain
- An IR policy not reviewed and re-approved annually, which reads as a stale control and often triggers a separate finding on policy governance
Skip the blank page
Get all 19 SOC 2 policies — editable, mapped to the Trust Services Criteria and ISO 27001, with a 90-day readiness plan and an evidence index.
Get the SOC 2 Policy Pack — $149FAQ
Do I need a real incident to pass the SOC 2 incident response criteria?
No. If you had no security incident during the audit period, a documented tabletop exercise is the accepted substitute for testing operating effectiveness. It needs a realistic scenario, dated attendance from your named IR roles, decisions recorded at each phase, and a written after-action report. Assessors treat a well-run tabletop as valid evidence for CC7.4. Having neither a real incident nor a tabletop is a frequent Type II exception.
How is an incident response policy different from an incident response plan?
The policy states what must happen and who is accountable, the governing commitments an assessor maps to CC7.3-CC7.5. The plan, or runbook, is the operational detail: specific steps, tooling, contact lists, and per-scenario playbooks. SOC 2 expects both. The policy is the control artifact that gets sampled; the plan is what your responders execute during an incident.
How often should the IR policy be reviewed for SOC 2?
Review and re-approve it at least annually, and after any major incident or significant change to your systems or org structure. Assessors check the last-reviewed and approved date. A policy that has not been formally re-approved within the year reads as a stale control and can produce a separate finding on policy governance, independent of the incident-handling criteria themselves.
A SOC 2 incident response policy passes CC7.3-CC7.5 only when it names roles, defines severity tiers and escalation clocks, sets breach-notification timelines, and requires a post-incident review, and when you can show a real incident or a documented tabletop where you actually followed it.