What Your Incident Response Runbook Needs to Pass a SOC 2 Audit

The Compliance-Functional Gap in Incident Response

There is a specific failure pattern in SOC 2 incident response documentation that appears regularly across early-stage SaaS companies. The policy document is formally structured, covers the required categories, uses the right terminology, and checks every box on a compliance checklist. The runbook — the actual document an engineer uses when an alert fires at 2 AM — is either missing, out of date, or contains generic guidance that cannot be followed without already knowing what to do.

These are not the same problem. SOC 2 CC7.1 requires that you have documented incident response procedures and that personnel are trained to execute them. A compliance-formatted policy document satisfies part of this — it documents that procedures exist. What it often does not demonstrate is that the procedures are functional: that an engineer who receives an escalation page can actually follow the runbook to a resolution.

Auditors have become better at distinguishing between these two things. A common interview technique during fieldwork is to ask an engineer — not the compliance lead — to describe what they would do if a specific type of alert fired. If the answer reveals unfamiliarity with the documented procedures, the auditor notes a gap between policy and practice.

What CC7.1 Actually Requires

CC7.1 under the Common Criteria framework covers the detection and monitoring of threats to achieving the entity's objectives. The sub-requirements that relate to incident response specifically cover:

• That processes exist to detect the use of unauthorized software, hardware, or systems
• That events indicating system failures, errors, or vulnerabilities are detected
• That events are evaluated to determine if they constitute security incidents
• That incidents are responded to according to documented procedures
• That the status of incidents is communicated to affected parties
• That root cause analysis is performed for significant incidents

Translated into evidence requirements, this means your auditor will look for: a documented incident response policy (including severity classification, escalation paths, and response timelines), training records showing relevant personnel have reviewed the policy, logs showing that alerts are actually being reviewed, incident records showing the response process was followed, and post-incident reviews for any significant events during the audit period.

The Seven Elements of a Functional Incident Response Runbook

1. Severity Classification with Objective Criteria

A severity classification system is only useful if the criteria are objective enough to be applied consistently. "Severity 1: Critical impact" means nothing to an engineer evaluating an alert at 2 AM. Functional criteria look like: "Severity 1: Confirmed unauthorized access to customer data, active exfiltration in progress, or complete service unavailability affecting 100% of customers."

Each severity level should have a corresponding response time target and escalation path. SOC 2 auditors reviewing CC7.1 typically sample incident records and check whether the response times match the stated policy. Incidents classified as Severity 1 that received a Severity 3 response time will be flagged.

2. Escalation Paths with Named Roles (Not Just Titles)

A policy that says "escalate to the Security Team" is not useful when a new engineer is the only person on call and does not know who is on the Security Team at 2 AM. Functional runbooks include specific escalation paths: the name of the on-call rotation, the paging mechanism (PagerDuty policy name), the backup contact, and the communication channel to use.

These details need to be current. An escalation path that was accurate six months ago but points to an employee who has since left is a CC7.1 evidence problem — it shows your procedures were not maintained.

3. Containment Steps by Incident Type

Containment procedures should be specific to the incident type. Generic guidance — "isolate the affected system" — is less useful than "disable the affected IAM user in the AWS console, revoke all active sessions via Okta, and snapshot the instance for forensic review." The more specific the runbook, the faster the response and the cleaner the evidence trail.

Common incident types to document specifically for SOC 2 purposes include: suspected unauthorized access to production infrastructure, detection of data exfiltration, alerts from the vulnerability scanner indicating an actively exploited vulnerability, and detection of unusual API activity in CloudTrail logs.

4. Evidence Collection Requirements During the Incident

This element is frequently absent from compliance-formatted policies and almost universally absent from engineering runbooks. CC7.1 and CC7.3 require post-incident analysis and documentation of root cause. If engineers do not collect evidence during the incident — logs, configuration snapshots, network flow records — the post-incident analysis has no foundation.

The runbook should specify exactly what to preserve: which CloudTrail events to export, which VPC flow logs to capture, which API request records to retain. The window of preservation matters — logs have retention policies, and evidence not captured promptly may be unavailable when the post-incident analysis begins.

5. Communication Templates and Thresholds

CC7.1 requires that affected parties are notified of incidents. For SaaS companies with enterprise customers, this involves contractual notification timelines — often 72 hours for confirmed security incidents. Many companies also have regulatory notification requirements (GDPR Article 33, HIPAA Breach Notification Rule, state data breach laws).

The runbook should include the notification threshold (at what severity or data exposure level do you notify customers), the notification timeline (72 hours from confirmation, or 24 hours for incidents affecting regulated data), and a template for the notification itself. Auditors reviewing CC7.1 will check that your notification procedures match any commitments made in your customer agreements.

6. Post-Incident Review Process

Root cause analysis and post-incident review are required by CC7.1 for significant incidents. The key word is "significant" — you do not need a formal post-mortem for every alert that fires. But you do need a documented process for deciding which incidents require a review, and evidence that reviews are actually completed for those incidents.

A functional post-incident review template includes: timeline of events from first detection to resolution, root cause analysis (not just "unauthorized access" but the specific vulnerability or misconfiguration that enabled it), impact assessment, and corrective actions with owners and due dates. The corrective actions section is particularly important for auditors — it demonstrates that incidents result in control improvements, not just resolution.

7. Annual Review and Training Records

CC7.1 evidence requires not just that the procedures exist but that they are maintained and that personnel are trained. Annual review records for the incident response policy — a dated document showing who reviewed it and approved the current version — satisfy the maintenance requirement. Training records showing that all personnel with incident response responsibilities completed the training satisfy the training requirement.

Training does not need to be elaborate. A tabletop exercise where the team walks through a simulated incident scenario and documents the walkthrough qualifies. The documentation just needs to exist and be current within the audit period.

Evidence of Actual Incidents (Or the Absence of Them)

A frequently misunderstood aspect of SOC 2 incident response evidence is what auditors expect when there were no significant incidents during the audit period. The answer is: evidence that your monitoring was active and that alerts were being reviewed, even if they did not escalate to incidents.

This is where the distinction between having a monitoring tool and having evidence of monitoring becomes important. CompliRun surfaces CC7.2 evidence — documentation that your monitoring system was running, that alerts were generated, and that they were reviewed — even in periods without security incidents. This satisfies the auditor's need to see continuous monitoring without requiring you to manufacture incidents.

If incidents did occur during the audit period, the evidence requirements are more specific. Auditors will review the incident record against the documented procedure: Was the incident classified with the correct severity? Was the escalation path followed? Was the notification sent within the required timeframe? Was a post-incident review completed? CompliRun maintains a linked incident record that connects the alert event, the response documentation, the notification record, and the post-incident review in one auditor-readable thread.

ISO 27001 Parallel: Annex A.5.24 and A.5.26

For companies pursuing ISO 27001 alongside SOC 2, the relevant Annex A controls are A.5.24 (Information security incident management planning and preparation) and A.5.26 (Response to information security incidents). ISO 27001 is somewhat more prescriptive than SOC 2 about the content of incident response procedures — A.5.24 specifically requires documented criteria for classifying incidents and a process for reporting incidents to management and relevant external authorities.

The primary difference in practice is that ISO 27001 auditors often ask for evidence of the incident management process rather than just the policy document — specifically, how incidents are tracked, who receives escalations, and how the organization learns from incidents over time. A well-maintained incident record system satisfies both frameworks simultaneously.

The Practical Recommendation

The most efficient approach to incident response documentation for SOC 2 is to separate the compliance policy document from the operational runbook — and maintain both. The policy document, formatted for auditor review, satisfies the CC7.1 requirement for documented procedures. The operational runbook, formatted for engineers, ensures that the procedures can actually be followed.

Keeping both current requires a review process. CompliRun's policy management module tracks the last review date for each policy document and generates a task when the review schedule comes due. Version history is maintained in the platform, so an auditor asking "was this policy current during Q2 of the audit period?" can get an immediate, timestamped answer.