Ask a SOC 2 auditor which control area makes growing companies stumble most often, and incident response is usually near the top. Not because the idea is hard. Most teams have something: a Slack channel, a wiki page, an on-call rotation. The problem is that the something is rarely written down, rarely tested and almost never leaves a paper trail an examiner can sample.
This guide explains what auditors look for in a SOC 2 incident response plan, how the plan maps to the Trust Services Criteria, what evidence to keep, and how to run a tabletop exercise that counts. It is written for founders, security leads and compliance owners preparing for a first SOC 2 Type II examination or tightening an existing program.
What SOC 2 actually says about incident response
SOC 2 is an attestation report issued by an independent CPA firm. It is not a certification and it does not prescribe a specific plan format. The AICPA Trust Services Criteria set outcomes, and your company designs the controls that meet them. For security incidents, the relevant criteria sit in the System Operations family of the Common Criteria (CC7):
| Criterion | What it covers | What it means in practice |
|---|---|---|
| CC7.2 | Monitoring for anomalies and security events | Alerts and monitoring that can surface suspicious activity |
| CC7.3 | Evaluating security events to decide whether they are incidents | A triage step with defined severity levels and ownership |
| CC7.4 | Responding to identified incidents | Containment, eradication, communication and a documented response |
| CC7.5 | Recovering from incidents | Restoring systems and applying lessons learned |
| CC2.2 / CC2.3 | Internal and external communication | Staff know how to report problems; customers are told when required |
The exact wording of the criteria and points of focus is published by the AICPA, so confirm against the current Trust Services Criteria on the AICPA SOC suite of services page. If you want the bigger picture of how those criteria fit together, our guide to the five Trust Services Criteria covers it.
The seven things an auditor expects in your plan
There is no official checklist, but experienced auditors tend to test the same themes. If your plan covers these, you are in good shape.
1. A clear definition of “event” versus “incident”
A security event is anything observable that might matter, such as a failed login spike or a malware alert. An incident is an event that has, or could have, a real effect on confidentiality, integrity or availability. CC7.3 is essentially about the decision between the two, so your plan should say who makes it and on what basis.
2. Severity levels with defined responses
Define three or four severity tiers (for example low, medium, high, critical). For each, record who is notified, how quickly the team aims to respond, and when leadership or customers are brought in. Avoid promising response times you cannot meet. An auditor will test against your stated targets, and a missed target without explanation becomes an exception.
3. Named roles and an escalation path
List an incident commander, a technical lead, a communications owner and a decision-maker for legal or regulatory questions. Small companies can combine roles, but write down who holds each one and who the backup is. Use role titles rather than individual names where possible so the document does not go stale when someone leaves.
4. Detection and reporting channels
Employees and contractors need a simple way to report suspected incidents, and the plan should say so. Auditors often ask staff how they would report a lost laptop or a phishing email. If the answer differs from the policy, that is a finding waiting to happen. This is also where your logging and alerting tools connect to the process.
5. Containment, eradication and recovery steps
Describe the response at a level a tired on-call engineer can follow at 2 a.m. Typical content includes isolating affected systems, revoking credentials, preserving logs, restoring from clean backups and validating the fix. For availability-focused threats such as ransomware, see our ransomware and SOC 2 availability blueprint.
6. Communication and notification rules
State when and how customers, partners, regulators and law enforcement are told. Contracts, privacy laws and sector rules (HIPAA, GDPR, state breach laws) can create notification duties with their own deadlines. SOC 2 does not set those deadlines, so involve legal counsel and keep the plan consistent with your customer agreements.
7. Post-incident review
Every meaningful incident should end with a written review: what happened, root cause, what worked, what did not and which follow-up actions were assigned. This is the evidence that connects CC7.4 to CC7.5 and shows the control environment improves over time.
The evidence package for a Type II examination
A Type II report tests whether controls operated effectively throughout the observation period, not just whether a document exists. If you are new to how that window works, read our explainer on the SOC 2 observation period. For incident response, an auditor commonly requests:
- The current incident response plan, with version history and evidence of annual (or more frequent) review and approval.
- A population list of all security incidents or tickets during the period, from which the auditor samples.
- For each sampled incident: the ticket, timeline, severity rating, response actions, communications and closure notes.
- Post-incident review documents for significant events.
- Evidence of at least one test of the plan, such as a tabletop exercise report with attendees, scenario, findings and follow-ups.
- Training or awareness records showing employees know how to report incidents.
- Where relevant, customer notification records and vendor incident handling.
A question we hear constantly: “What if we had no incidents during the period?” That is fine, but it creates a testing problem. The auditor cannot sample incidents that never happened, so they will lean on your tabletop exercise, your population of security events or alerts, and your monitoring configuration. A clean year without a tabletop is a weaker position than a year with one. For help planning the documents that surround all of this, see what documentation is required for a SOC 2 audit.
How to run a tabletop exercise that counts
A tabletop is a facilitated discussion in which the team walks through a realistic scenario using the real plan. It is cheap, takes a couple of hours, and produces exactly the kind of evidence auditors like.
- Pick a scenario that fits your business. A leaked cloud access key, a compromised employee laptop, a ransomware infection on a file store, or a vendor breach that exposes customer data. Avoid generic scenarios that do not touch your actual systems.
- Invite the right people. Engineering, IT, security, customer support, leadership and whoever handles legal or contracts.
- Walk the plan step by step. Who detects it? Who declares an incident? Who contains it? When do customers hear? Write down every point where the answer was “we are not sure.”
- Record the output. Capture date, attendees, scenario, decisions, gaps found and action items with owners and due dates.
- Close the loop. Update the plan based on what you learned and keep evidence that the actions were completed.
The gaps you uncover are not a problem. An exercise that finds issues and fixes them is stronger evidence than one that claims perfection.
Common incident response mistakes that lead to exceptions
| Mistake | Why it causes trouble | Fix |
|---|---|---|
| Incidents handled only in Slack or chat | No ticket means no sampleable evidence | Require a ticket for every declared incident and link the chat thread |
| Plan copied from a template and never adapted | Roles, tools and systems do not match reality | Edit the plan to match your stack and team |
| No annual review or approval | Control operated without evidence of oversight | Calendar a yearly review with a recorded approver |
| Severity levels not recorded in tickets | Auditor cannot confirm classification occurred | Add a mandatory severity field |
| No tabletop or test | Plan is untested; common finding | Run and document at least one exercise per period |
| Post-incident reviews skipped | No evidence of learning or improvement | Template the review and set a completion target |
| Contractual notification terms ignored | Plan says one thing, contracts require another | Cross-check the plan against customer agreements |
Many of these overlap with the patterns we see across failed engagements. Our article on common SOC 2 audit mistakes covers the broader list.
Connecting incident response to the rest of your program
Incident response does not live alone. It borrows from, and feeds, other controls:
- Risk assessment: The scenarios in your plan should reflect your top risks. See how to perform a SOC 2 risk assessment.
- Access control: Revoking compromised credentials quickly depends on a clean account inventory, which is why user access reviews matter to incident response.
- Vendor management: Incidents often start at a subservice organization or supplier. Your plan should explain how vendor-originated incidents are tracked, which ties into third-party risk management.
- Change management: Emergency fixes still need a record. Define how urgent changes are approved after the fact.
What this means for your business
For a startup pursuing its first report, a lightweight plan that is actually used beats a 40-page binder nobody has read. Write the shortest document that covers the seven themes above, run one tabletop before the observation window ends, and make every incident leave a ticket. If you are early in the journey, our SOC 2 readiness service helps you find gaps like missing incident evidence before the auditor does, and the SOC 2 for startups page explains how smaller teams can stay lean.
Teams that want expert eyes on day-to-day evidence can also use our 24×7 GRC chat and Slack support to sanity-check incident tickets, review plan updates and prepare for auditor sampling. Remember that readiness consulting is separate from the independent attestation: the SOC 2 opinion itself is issued by a licensed CPA firm.
Frequently asked questions
Is an incident response plan required for SOC 2?
For the Security category (the Common Criteria), which every SOC 2 report includes, the criteria expect you to identify, evaluate and respond to security incidents. In practice auditors expect a documented, approved plan. SOC 2 does not mandate a specific format.
How often should we test our incident response plan?
SOC 2 does not set a fixed frequency. Annual testing is the common baseline, and many organizations also test after major system changes. Whatever you commit to in your policy is what the auditor tests against.
Does a tabletop exercise satisfy the testing expectation?
Generally yes, if it is documented with the scenario, participants, findings and follow-up actions. Technical simulations can add value but are not required by the criteria.
What if we had no security incidents during the audit period?
That is acceptable. The auditor will rely on other evidence, such as your monitoring setup, a population of alerts or events, the tabletop exercise and the plan itself. Be ready to explain how you would know if an incident occurred.
Do we have to notify customers of every incident?
No. Notification depends on the nature of the incident, your customer contracts and applicable laws. Your plan should define the decision process and who approves external communication. Consult legal counsel for specific obligations.
Who should own the incident response plan?
Typically a security lead, head of engineering or CISO owns the document, with executive approval. The key is that ownership is named and review is recorded.
Conclusion
A SOC 2 incident response plan succeeds when it is specific to your company, short enough to be used, tested at least once a year and backed by tickets that show it working. Cover detection, triage, containment, communication and review, keep evidence in a form an auditor can sample, and treat every exercise or real incident as input for improving the plan. That is the standard CC7.3 through CC7.5 is really asking for.
