SOC 2 Incident Response Checklist: 8 Evidence Items

Most compliance teams treat incident response evidence as a documentation exercise: write the plan, run the annual tabletop, file the sign-in sheet. SOC 2 auditors evaluate incident response under three distinct criteria: CC7.2 (detection), CC7.3 (evaluation), and CC7.4 (response and recovery) [AICPA TSC CC7.2-CC7.4]. Each criterion demands a separate evidence artifact. The sign-in sheet satisfies none of them.

Incident response evidence drives more CC7 findings than any other control area in SOC 2 examinations [AICPA TSC CC7.3]. The pattern repeats across engagements: teams detect and resolve incidents effectively, then fail the audit because the evidence trail is incomplete. One missing timestamp, one skipped post-mortem, one undocumented triage decision transforms operational competence into a qualified opinion.

Eight evidence items determine whether your SOC 2 incident response passes the CC7 examination. Each item maps to a specific criterion. Each requires a specific documentation format. Organizations preparing all eight before the observation period begins clear the control area without findings.

Why CC7 Drives SOC 2 Incident Response Findings

SOC 2 evaluates incident response under Common Criterion 7 (CC7): System Operations [AICPA TSC CC7.1-CC7.5]. CC7 requires organizations to detect anomalies, evaluate events, respond to incidents, and recover operations. The criterion is mandatory for every SOC 2 engagement, regardless of which additional categories (Availability, Processing Integrity, Confidentiality, Privacy) are in scope.

The Cross-Criteria Problem

Incident response evidence appears in auditor requests beyond CC7. CC2 (Communication) requires evidence of stakeholder notification during incidents [AICPA TSC CC2.2]. CC5 (Control Activities) requires proof your team followed documented procedures during each response [AICPA TSC CC5.2].

A single incident with incomplete documentation triggers findings across three criteria. Auditors cross-reference incident records against communication logs, procedure adherence, and remediation timelines.

Type I vs Type II: Different Evidence Standards

Type I audits test design: the auditor reviews whether your Incident Response Plan exists and addresses the required elements. Type II audits test operating effectiveness: the auditor samples actual incidents from the observation period and verifies your team followed the plan consistently [AICPA TSC SOC 2 Guidance].

The Type II standard is where organizations fail. A detailed incident record in January paired with a one-line ticket in August creates an inconsistency finding. Auditors test for uniform documentation quality across the full observation period.

The 8 Evidence Items Auditors Request

SOC 2 auditors send a Prepared By Client (PBC) list before fieldwork begins. The SOC 2 incident response checklist section requests these eight items. A gap in any single item creates a finding. The table below shows each evidence item, its auditor purpose, and the most common failure mode.

How Auditors Test Each Item

Auditors do not accept documents at face value. For the IRP, they verify contact information matches current employees. For incident records, they cross-reference timestamps against SIEM logs. For post-incident reviews, they check whether corrective actions were implemented within the stated timeline.

The ticket log receives the most scrutiny. Auditors pull alerts directly from your SIEM or monitoring tool, select a sample, and trace each alert to a corresponding ticket. A missing ticket for a high-severity alert triggers an immediate finding [AICPA TSC CC7.2].

The Completeness Trap: Why Manual Incident Logs Fail

Manual incident tracking is the primary reason organizations receive CC7 findings. When your IT team maintains incidents in a spreadsheet, the auditor faces a Completeness and Accuracy (C&A) problem: no mechanism exists to verify whether rows were deleted or events were omitted.

Auditors are required to test completeness for any manually maintained population [AICPA AT-C Section 205]. System-generated logs with immutable timestamps pass this test automatically. Spreadsheets require hours of additional testing and produce findings regardless of actual incident handling quality.

The Three-Step Auditor Verification

Every SOC 2 auditor follows this pattern for incident completeness:

1. Direct system access: Log into your SIEM (GuardDuty, Splunk, Datadog) and identify alerts from the observation period.
2. Trace to ticket: Request the corresponding Jira or ServiceNow ticket for each selected alert.
3. Evaluate documentation: Verify the ticket contains detection time, classification rationale, containment actions, and resolution confirmation.

A missing ticket for any sampled alert means the incident population is incomplete. One gap invalidates the entire log.

The Zero-Incident Problem

Organizations with no security incidents during the observation period face a distinct documentation challenge. The absence of incidents does not satisfy CC7. Auditors require negative assurance: evidence proving your monitoring was active and your team was prepared to respond [AICPA TSC CC7.1].

The Negative Assurance Package

Three artifacts satisfy the zero-incident requirement:

1. Monitoring configuration evidence: Screenshots or exports proving your alerting tools (GuardDuty, Splunk, Datadog) operated continuously throughout the observation period. Include uptime reports and configuration settings.
2. Triage logs: A sample of events reviewed and closed as false positives or non-incidents. These prove your team actively monitored and investigated alerts, even when none escalated.
3. Tabletop exercise documentation: A signed memo from a simulated incident exercise covering the scenario, participants, gaps identified, and corrective actions planned [AICPA TSC CC7.4].

The tabletop exercise carries the most weight in a zero-incident year. Without real incidents to demonstrate response capability, the exercise becomes your primary evidence for CC7.3 and CC7.4. Review the recommended testing frequency to determine the right cadence for your organization.

The 4-Week Pre-Audit Preparation Timeline

Start this timeline 30 days before audit fieldwork begins. Each week addresses one evidence category from the SOC 2 incident response checklist.

Week 1: Discovery and Reconciliation

Pull the incident ticket log from your ITSM platform. Cross-reference against SIEM alert counts for the observation period. Identify gaps where alerts exist without corresponding tickets. Flag any tickets with incomplete documentation.

Week 2: Gap Closure

Address every gap identified in Week 1. For missing tickets, create retrospective entries with available evidence from SIEM logs, Slack messages, and email threads. Schedule a tabletop exercise if one has not been conducted in the current period.

Week 3: Documentation Review

Verify the IRP was updated within the last 12 months. Confirm all listed team members still hold their designated roles. Update contact information, escalation paths, and tool references. Save the current version with a documented revision date.

Week 4: Evidence Assembly

Compile all eight evidence items into a single CC7 evidence package. Select one closed incident ticket and read it end-to-end. Verify it tells the complete story: detection, classification, containment, resolution, and post-mortem. If the narrative has gaps, add a retrospective note now.

Frequently Asked Questions

What should a SOC 2 incident response checklist include?

A SOC 2 incident response checklist includes eight evidence items: the Incident Response Plan, written incident definitions, system-generated ticket logs, triage evidence for dismissed alerts, detailed incident records, post-incident reviews, tabletop exercise documentation, and plan version history [AICPA TSC CC7.2, CC7.3, CC7.4]. Each item addresses a specific auditor verification step under CC7.

What happens if we have zero incidents during the SOC 2 audit period?

Zero incidents require a negative assurance package: monitoring configuration evidence proving your tools operated continuously, triage logs showing reviewed and dismissed alerts, and a documented tabletop exercise. The tabletop carries the most weight because it demonstrates response capability without a real incident [AICPA TSC CC7.4].

Why do manual spreadsheets fail SOC 2 incident response audits?

Auditors perform Completeness and Accuracy (C&A) testing on manually maintained populations [AICPA AT-C Section 205]. Spreadsheets lack immutable timestamps, provide no deletion audit trail, and require hours of additional verification. System-generated ticket logs with automated timestamps pass completeness testing automatically.

How does SOC 2 Type II test incident response differently from Type I?

Type I audits test design: the auditor verifies your Incident Response Plan exists and addresses required elements. Type II audits test operating effectiveness: the auditor samples actual incidents from the observation period and verifies consistent adherence to documented procedures across every sampled event.

How often should we update the Incident Response Plan for SOC 2?

Update the IRP at minimum annually, with version history documenting each revision [AICPA TSC CC7.4]. Trigger additional updates when team members change, tools are replaced, or post-incident reviews identify process gaps. Auditors check the version history for evidence of active maintenance.

Does a tabletop exercise satisfy the SOC 2 incident response testing requirement?

A documented tabletop exercise satisfies the CC7.4 annual testing requirement. The exercise must include a realistic scenario, the full incident response team, documented discussion points, identified gaps, and planned corrective actions. A two-page signed memo serves as the audit artifact [AICPA TSC CC7.4].