SOC 2 Incident Response

Incident response is where SOC 2 moves from theory to practice

Every SOC 2 program has an incident response plan. Auditors see hundreds of them. What separates a program that passes Type II cleanly from one that collects exceptions is whether the plan is actually executed when something happens — and whether there is evidence the team can produce six months later.

A SOC 2 Type II audit tests operating effectiveness. Incident response is one of the most operationally demanding control areas because it requires coordinated action across engineering, security, legal, and leadership, often under time pressure. The controls that matter are CC7.3 (evaluation of security events), CC7.4 (response execution), and CC7.5 (recovery) in the Trust Services Criteria. Each generates evidence that auditors will sample and test.

What CC7.3 through CC7.5 expect

The CC7 series defines a closed loop from detection through recovery.

CC7.3 — The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents). This requires that detected events are triaged and classified, not just logged. Auditors look for evidence that events were evaluated — not every alert becomes an incident, but every alert should have a disposition.

CC7.4 — The entity responds to identified security incidents by executing a defined incident response program that includes assigned roles, containment, remediation, communication, and documentation. This requires a written plan, trained responders, and evidence that real or simulated incidents followed it.

CC7.5 — The entity identifies, develops, and implements activities to recover from identified security incidents. Recovery includes restoring systems, verifying integrity, and applying lessons learned.

CC2.2 and CC9 also touch incident response — internal and external communication during an incident and risk mitigation through incident learnings.

Components of a SOC 2-ready incident response program

A program that passes auditor scrutiny has six components.

1. A written incident response plan

The plan should be approved by leadership, reviewed annually, and specific enough that a new team member could follow it. Required elements include:

• Definition of a security incident
• Severity classifications (for example, P1 through P4)
• Roles and responsibilities (incident commander, communications lead, technical lead)
• Detection and reporting channels
• Triage and classification process
• Containment, eradication, and recovery procedures
• Internal and external communication requirements
• Post-incident review expectations
• Regulatory and contractual notification obligations

2. Runbooks for common scenarios

The plan covers the framework; runbooks cover the specifics. Typical runbooks address credential compromise, ransomware, data exfiltration, DDoS, vendor compromise, insider threat, and lost or stolen device. Runbooks reduce decision latency when an incident is active and demonstrate maturity to auditors.

3. Defined detection and escalation paths

Alerts from continuous monitoring tools must flow into a triage process. Each alert is either dismissed with a note or escalated to an incident with a severity rating. Auditors look for the linkage between detection and incident records — if the chain is unclear, the control appears theoretical.

4. Documented incidents

Every real incident during the observation period must have a record. Minimum fields:

• Incident ID and title
• Detection time and source
• Severity at declaration and revision history
• Timeline of actions taken
• Systems, data, and individuals affected
• Containment and remediation steps
• Communications sent (internal, customers, regulators, law enforcement)
• Root cause
• Lessons learned and assigned remediation items

The system of record can be a dedicated incident platform, a ticketing system, or a structured document repository. What matters is consistency across incidents.

5. Tabletop exercises

If no real incidents occur during the observation period, tabletop exercises demonstrate the plan works. A tabletop walks a team through a simulated scenario, capturing decisions and timing. At minimum, conduct one tabletop annually covering a realistic scenario. Mature programs run them quarterly. See evidence collection for how to document.

6. Post-incident review

Every declared incident above a threshold severity should produce a post-incident review (PIR) or retrospective. The PIR captures the root cause, contributing factors, and remediation items with owners and due dates. Auditors may request to see PIRs for a sample of incidents from the observation period.

How this fits into SOC 2

Incident response is tightly coupled to other SOC 2 control areas. Continuous monitoring feeds the detection engine. Change management failures sometimes manifest as incidents. Vendor management governs how you respond when a third party is compromised. Strong incident response also supports the availability criterion when applicable — outage response is an incident response subset with its own RTO and RPO targets.

Auditors often use incident records to validate controls elsewhere. An incident that required access to production shows up in access control logs. A change that caused an incident shows up in change management records. Inconsistencies between these artifacts create findings.

Evidence expectations

During fieldwork, the auditor will typically request:

• The current incident response plan with approval evidence
• Runbooks for common scenarios
• A list of incidents declared during the observation period
• Full documentation for a sampled subset of those incidents
• Evidence of tabletop exercises during the observation period
• Evidence of incident response training for relevant staff
• Breach notification templates and examples if any notifications were sent

If no incidents occurred, the auditor relies heavily on tabletop and training evidence. Skipping these is a red flag.

Common mistakes

• Plan without practice. A polished document that no one follows creates more audit risk than a simple plan that is actually used. Test it.
• Severity drift. Teams reclassify incidents down to avoid paperwork. Auditors notice when severity distributions do not match the alert volume.
• Missing communication records. Incidents often require customer or regulatory notifications. If communications happened verbally with no record, the evidence is gone.
• No lessons learned. Running an incident and not capturing what to improve shows the program is reactive, not mature.
• Breach notification as an afterthought. Regulatory timelines (GDPR 72 hours, some state laws 30 to 60 days) apply whether or not your plan accounts for them. See breach notification.

Implementation tips

• Keep the incident response plan in version control. Each approved version should be dated and linked to a leadership review.
• Integrate your alerting tool with your ticketing system so every escalated alert creates an incident record automatically.
• Use a consistent template for post-incident reviews so comparisons across incidents are possible.
• Run one tabletop per quarter, rotating scenarios. Capture the output as a PDF and store it with the other SOC 2 evidence.
• Train all employees annually on how to report a suspected incident. The earliest detection often comes from a non-security team member.

How episki helps

episki provides templates for incident response plans, runbooks, and post-incident reviews mapped to CC7.3 through CC7.5, along with evidence collection for tabletop exercises and training. Start a free trial or review the full SOC 2 framework guide to see how incident response integrates with monitoring, change management, and vendor controls.