Incident Response Control Evidence Requirements for SOC 2

A SOC 2 Type II audit tests whether the organization's controls actually worked, consistently, across the full observation window, which can run anywhere from three months to a year, rather than reviewing what the organization intends to do when something goes wrong. Every company under audit has an incident response plan sitting somewhere in a wiki or a shared drive. What separates a program that passes cleanly from one that collects a list of exceptions is simpler than most teams expect: did the plan get followed when a real event happened, and can the team pull up proof of that months after the fact? Incident response asks more of an organization than most control areas because it forces engineering, security, legal, and leadership to coordinate under pressure, often at the worst possible hour. The sections that follow walk through what each relevant control, CC7.3, CC7.4, and CC7.5, actually demands in terms of evidence, and where programs tend to lose points with auditors.

What CC7.3 requires

CC7.3 asks whether an organization evaluates security events to determine if they could result, or already have resulted, in a failure to meet its objectives. In practice, that means every event flagged by a detection tool has to get triaged and classified, not just stored in a log somewhere. The auditor's actual question is whether every alert received a documented disposition. A dismissed alert needs a note explaining why it was dismissed. An escalated alert needs to connect forward to an incident record. If that chain from detection to disposition can't be traced, the control reads as something that exists on paper but not in practice.

The mechanical expectation is that every security event gets tracked in a ticketing system, Jira or ServiceNow are common choices, with timestamps marking when it was detected, when it was triaged, when it was classified, and when it was resolved. Auditors check three layered pieces of evidence to confirm the monitoring behind CC7.3 is functioning: the policy that defines what gets monitored and why, the actual tool configuration showing which alert rules are live, and the ticket history proving someone reviewed and dispositioned what the tools surfaced. All three need to be present together. A policy without configuration evidence looks aspirational. Configuration without ticket history looks like nobody's watching. One of the most common findings in SOC 2 audits is exactly this gap: organizations collect plenty of logs but can't show anyone ever looked at them.

The three artifact classes auditors expect for CC7.4 response execution

CC7.4 is where incident response shifts from detection to action, and it tends to generate more findings than any other control in this group. The criterion requires an organization to respond to identified incidents by running a defined response program that covers roles, containment, remediation, communication, and documentation. A written plan by itself does not satisfy it. Auditors look for three separate kinds of evidence, each proving something different, and the absence of any one of them undercuts the other two.

The first is the written incident response plan itself. It needs sign-off from leadership, a review at least once a year, and enough specificity that someone new to the team could actually follow it during a live event. A complete plan defines what counts as a security incident, lays out severity tiers (commonly P1 through P4), names roles such as incident commander, communications lead, and technical lead, and spells out detection and reporting channels, triage and classification steps, containment and eradication and recovery procedures, internal and external communication requirements, expectations for a post-incident review, and any regulatory or contractual notification obligations. Auditors check the date the plan was last reviewed, and a plan that hasn't been touched in a few years is itself a finding regardless of its content. Generic, templated plans are an especially common failure point: an auditor can simply ask how the plan applies to the organization's actual infrastructure, whether that's AWS, Azure, or GCP, and to the top risks identified in its own risk assessment. A plan that can't answer that question specifically doesn't hold up.

The second artifact class is evidence that the plan has actually been tested, most often through a tabletop exercise that walks a team through a simulated scenario and records the decisions made and the time it took to make them. The output, an agenda, a description of the scenario, a list of participants, the decisions reached, and the gaps the exercise exposed, is the evidence an auditor will ask to see. The accepted floor is at least one tabletop a year covering a realistic scenario, and more mature programs run them quarterly, especially in regulated or high-risk environments, rotating through different threat types each time. Runbooks built for specific scenarios, such as credential compromise, ransomware, data exfiltration, a DDoS event, a compromised vendor, an insider threat, or a lost device, round out this evidence class and demonstrate that the organization has thought through its actual threat model.

The third artifact class is the record for every real incident that occurred during the observation period. Each record needs an incident ID and title, the time and source of detection, the severity assigned at declaration along with any later revisions, a timeline of actions taken, the systems, data, and individuals affected, the containment and remediation steps, a log of communications sent to internal teams, customers, regulators, or law enforcement as applicable, the root cause, and the lessons learned along with any remediation items assigned. The specific system used to track these records matters less than consistency: a dedicated incident platform, a ticketing system, or even a structured set of documents can all work, as long as every incident is documented the same way. Auditors sample across the entire observation window, so a gap in documentation for even one declared incident stands out against the rest of the population.

CC7.5 recovery artifacts and the post-incident review as an evidence object

CC7.5 covers recovery: identifying, developing, and carrying out the activities needed to restore systems, confirm their integrity, and apply what was learned from the incident. The central evidence artifact here is the post-incident review, sometimes called a retrospective, and it deserves to be treated as its own evidence object rather than a formality tacked onto the end of an incident record. A proper PIR captures the root cause, the contributing factors, and a list of remediation items with owners and due dates attached. Auditors may pull PIRs for a sample of incidents from across the period, and the expected format is a blameless post-mortem that focuses on what happened and why.

What the criterion actually tests is not whether the PIR document exists, but whether the actions it identifies were carried out. A PIR with no remediation tasks attached fails to satisfy CC7.5. So does a PIR where tasks were created but never finished, because the criterion asks for evidence of implemented recovery activities, not merely identified ones. That's why the second required artifact is a task tracker showing that each remediation item coming out of a PIR was created, assigned to someone, and eventually closed, not just listed as a future intention. Recovery also means confirming that systems were actually restored to a trustworthy state, so change records or configuration verification logs tied to the incident serve as supporting evidence here as well. CC7.5 is the point in the audit where evidence has to connect across systems: PIR actions must appear as tracked work in change management records or a risk register, not sit as an isolated document nobody followed up on.

How auditors sample and test IR evidence

A Type II audit covers a period of time, not a single snapshot, so auditors start by asking for a complete population listing of every incident that occurred during that window before they select anything to sample. A gap in that population listing is itself a finding, before the auditor has even picked which tickets to examine closely. From that population, auditors typically pull a sample weighted toward higher-severity incidents, and for each one they check the detection source, whether the timeline is complete, how the severity was declared and whether it changed, the containment and remediation notes, any communication records the organization's own policy required, and whether the incident links to a completed PIR.

Auditors are evaluating whether a control operated the way it was designed to, so the evidence has to match what's actually being tested. Submitting a written policy when the auditor is asking for operational proof is a common reason evidence gets rejected. Submitting a screenshot of a tool's dashboard in place of a documented process, or a plan for what the team intended to do instead of a record of what it actually did, is also grounds for rejection. A single gap tends to multiply. Consider a high-severity incident that has no PIR on file: that gap appears as a finding under CC7.4, again under CC7.5, and potentially again in change management records if the incident required an emergency fix that was never logged as a change. IR evidence doesn't sit in isolation. An incident that touched production access appears in access control logs; one caused by a bad deployment appears in change management records. When those adjacent records don't agree with each other, the inconsistency becomes a finding across more than one control area at once. For a Type II audit, the expected package isn't a folder of documents but a structured set: population listings, the sample the auditor selected from it, and proof that remediation actually happened.

The hardest gap to close: organizations with low incident volumes

The entire evidence model described above assumes there's a meaningful population of real incidents to sample from across the observation period. Organizations with genuinely low incident volumes run into a structural problem: if the sample set is trivially small or empty, per-incident evidence alone can't demonstrate that CC7.4 operated effectively, because there's little to point to.

The common workaround is to treat tabletop exercises and simulated incidents as a substitute for real incident evidence, but this is not a fully settled practice. Auditors give varying weight to a simulation relative to an actual incident record, and organizations have to navigate that inconsistency case by case. The tension at the center of this is genuinely unresolved: a company that declared zero incidents during its audit period might reasonably be read as having strong security, yet that same absence of incidents can make it harder to satisfy CC7.4's operating effectiveness standard through simulation alone.

A defensible floor has emerged among practitioners, even without a universal standard behind it. At minimum, that floor includes one documented tabletop exercise a year, covering the scenario, the participants, the decisions made, and the gaps it surfaced. It includes runbooks built around the threat scenarios most plausible for the organization's specific environment. And it includes alert disposition records from ongoing monitoring, showing that the detection-to-triage chain functioned even in a period where nothing crossed the threshold for a declared incident. The strongest challenge an auditor can raise against a simulation-heavy program is to ask how a given tabletop scenario maps to the organization's actual technology stack and the risks named in its own risk assessment. A generic tabletop run against a cloud-native SaaS company's real threat model is weaker evidence than one built specifically around it, and auditors know the difference when they see it.

Where IR evidence programs most commonly fall short

The single most common incident response failure in SOC 2 audits is a plan that exists but has never been exercised. Auditors treat an untested plan as functionally equivalent to having no plan at all, because there's no way to infer that a control works from its design on paper alone. A few other deficiencies recur repeatedly across audits. Response plans missing specific, defined components, such as clearly assigned roles or severity levels with no concrete thresholds attached, routinely trigger findings, and a generic template that was never tailored to the organization's own technology stack is one of the most common triggers of all. Monitoring tools are frequently active and generating alerts, but there's no record showing anyone reviewed them, so the logs exist without a disposition trail behind them. PIRs often get written in good faith but the remediation tasks they identify never get tracked to closure, which satisfies the letter of documentation without satisfying what CC7.5 is actually testing. And IR evidence frequently sits in a silo apart from the rest of the control environment: an emergency fix made during an incident leaves no trace in change management records, and PIR action items never make their way into a risk register or a vulnerability tracker where someone would actually be accountable for closing them.

GRC platforms such as Vanta, Drata, and Secureframe can automatically pull system-configuration evidence and generate the logs, reports, and timestamps that map cleanly to several Trust Services Criteria, particularly CC6.1 and CC7.1. None of them fully automate the artifacts CC7.3 through CC7.5 actually demand, because post-mortems, severity classifications, escalation decisions, and communication records require human judgment and can't be generated from a system configuration alone. Onspring's GRC platform takes a more structural approach to this specific gap, mapping evidence directly to controls, tracking remediation tasks through to closure, and maintaining the cross-control linkage that connects an incident record to change management and risk register entries, rather than treating incident response evidence as a standalone collection task separate from the rest of the control environment.

For a team starting from scratch or auditing its own readiness, follow this sequence. Start with the written plan and confirm it's current and built around the organization's actual infrastructure and risks, not a generic template. Next, confirm that at least one tabletop exercise has been run and documented in the current period. Then pull the full incident population for the period and check that every declared incident has a complete record against the required fields. Finally, confirm that every PIR tied to an incident above the severity threshold has remediation tasks that were assigned, tracked, and actually closed. Each step closes a gap the previous one would otherwise expose.