SOC 2 incident response: the plan and proof auditors want
Under the CC7 criteria, auditors do not just want an incident response plan on file; they want evidence you have detected, evaluated, and practiced responding to events. Here is what that looks like, even in a clean period with no real incidents.
Where incident response sits in SOC 2
Incident response is spread across the CC7 system operations criteria rather than living in a single control. CC7.1 and CC7.2 cover detection and monitoring, requiring you to watch system components for anomalies that could indicate malicious activity, errors, or disasters. CC7.3 requires you to evaluate detected events and decide whether they rise to the level of a security incident, meaning detection alone is not enough; events have to be triaged and classified. CC7.4 covers the response itself, including containment and corrective action, and CC7.5 addresses recovery and the lessons learned afterward. Read together, these criteria describe a full lifecycle from noticing something is wrong through resolving it and improving so it does not recur. A mature program treats the incident response plan as the connective tissue that ties monitoring, triage, response, and recovery into one repeatable workflow.
What a defensible IR plan contains
A documented incident response plan should define roles and responsibilities, a severity classification scheme, and the workflow that carries an event from detection to resolution. Roles matter because auditors want to see who decides an event is an incident, who leads the response, and who is authorized to communicate externally. A severity or priority scheme lets the team scale its response, applying heavier process to a confirmed data exposure than to a low-risk anomaly. The workflow should describe detection sources, escalation paths, containment and eradication steps, and the criteria for declaring an incident resolved. It also needs a breach notification component that spells out when and how you would notify affected customers and regulators, since contractual and legal obligations under regimes like GDPR and various US state breach laws often impose tight timelines. The plan should be specific enough that a new on-call engineer could follow it during a stressful 2 a.m. page.
Proving the plan works when nothing went wrong
A common misconception is that a quiet period with no incidents means there is nothing to show the auditor. The opposite is true: CC7 expects evidence that the plan has been tested, and the standard way to demonstrate this without a real breach is a tabletop exercise. In a tabletop, the response team walks through a realistic scenario, makes the decisions they would make in a live event, and documents what happened. Auditors generally expect at least one such exercise during the Type 2 observation period, along with the artifacts it produces: an agenda or scenario, an attendance list, observations, and an action-item log capturing what the team would improve. The action items are the part assessors weigh most heavily, because they show the exercise actually changed something rather than being a box-ticking meeting. Where real incidents did occur, ticket logs and post-incident reviews serve the same evidentiary purpose and tend to be even more persuasive.
Detection and triage evidence
Because CC7.1 through CC7.3 are about noticing and evaluating events, auditors look for evidence that monitoring is actually running and that someone is reviewing what it surfaces. That typically means centralized logging, alerting configured on security-relevant events, and a record that alerts route to a person or queue rather than into a void. For triage, the evidence is the trail showing that flagged events were assessed and either dismissed with a rationale or escalated into the incident process. Many teams capture this in their ticketing or SIEM platform, where each alert has a disposition. The detail auditors probe is whether your detection coverage actually maps to your in-scope systems; alerting that watches only a fraction of production is a frequent weak point. Demonstrating that anomalies were analyzed to determine whether they represented security events, even when the answer was usually no, is what satisfies the spirit of CC7.2 and CC7.3.
Common gaps and post-incident review
The most frequent failures are an IR plan that exists but was never tested, a tabletop that produced no documented action items, and detection that does not cover the systems in scope. Another recurring gap is a plan that names roles which no longer match the org chart, or escalation contacts that are out of date, which becomes obvious the moment a real event hits. Post-incident review, which lives in the spirit of CC7.5, is where many programs underinvest; auditors want to see that real incidents and tabletop exercises both feed a feedback loop that updates the plan. The practical advice is to schedule at least one tabletop well inside your observation window, assign and close the action items it generates, and keep the plan, contacts, and severity definitions current. Treating incident response as a living process rather than a static document is what separates a clean CC7 result from a string of exceptions.