SOC 2 Incident Response: Requirements, Evidence and What Auditors Test

Short answer: SOC 2 incident response requirements sit mainly in Common Criteria CC7.3 to CC7.5. You need a documented process to evaluate security events, respond to confirmed incidents, recover and learn from them. In a Type 2 audit, the auditor samples real incidents from the period and checks that each one followed your written process.

Related guides:

• Incident response plan template
• SOC 2 controls list and what auditors expect
• Security incident management guide

Key takeaways

• SOC 2 does not prescribe a specific incident response framework. It asks you to define one, follow it and prove you followed it.
• The criteria that matter most are CC7.3 (evaluating events), CC7.4 (responding to incidents) and CC7.5 (recovering and improving). Monitoring under CC7.2 and communication under CC2.3 support them.
• A common SOC 2 exception is not a missing plan. It is a plan that says one thing while tickets, timestamps and post-incident reviews show another.
• If nothing happened during your audit window, auditors will still review the design of your process, and many will ask for your plan and any tabletop exercise records.
• HealthTech companies should build HIPAA breach assessment into the same workflow so one process supports both SOC 2 and the HIPAA Breach Notification Rule.

What does SOC 2 require for incident response?

The SOC 2 criteria expect a defined, operating program to identify, evaluate, respond to and recover from security incidents, mapped to the 2017 Trust Services Criteria (with points of focus revised in 2022).

The Trust Services Criteria are written as outcomes, not checklists. For incident response, the relevant criteria break down like this:

Criterion	Plain-language requirement	What it looks like in practice
CC7.2	Monitor systems for anomalies that could indicate attacks or errors	Alerting from logs, endpoint tools, cloud security findings
CC7.3	Evaluate security events to decide whether they are incidents	A triage step with criteria, owners and a record of the decision
CC7.4	Respond to identified incidents with a defined program	Roles, containment, eradication, communication, tracked to closure
CC7.5	Recover from incidents and prevent recurrence	Restoration, root cause analysis, follow-up actions, plan updates
CC2.3	Communicate with external parties	Customer and regulator notification procedures

If your report includes the Availability or Privacy categories, expect additional scrutiny on recovery time and on how personal information incidents are handled. The full criteria and their points of focus are published by the AICPA.

Security event or security incident: where is the line?

An event is anything observable that might matter; an incident is an event you have confirmed actually compromises, or threatens, the confidentiality, integrity or availability of your system.

This distinction drives your audit population. Auditors typically ask for "a list of all security incidents during the period" and then sample from it. If you call every alert an incident, the sample becomes noisy and every gap in a minor ticket becomes an exception. If you never call anything an incident, auditors will question whether your triage works.

Write down concrete classification criteria, for example:

1. Event: a failed login spike, a malware detection that was quarantined automatically, a vulnerability scanner finding.
2. Incident: confirmed unauthorized access, data sent to the wrong recipient, ransomware execution, an outage caused by malicious activity, a lost unencrypted device holding customer data.
3. Severity levels: typically three or four, each with a response time target and a named escalation path.

Then make sure every triage decision leaves a trace. A one-line note in the alert ticket saying "reviewed, false positive, closed" is often enough to show CC7.3 is operating.

What should your SOC 2 incident response process include?

A SOC 2-ready incident response process covers preparation, triage, containment, eradication, recovery, communication and lessons learned, with an owner and a record for each step.

Use this as a design checklist for your policy and runbooks:

• Roles: an incident commander, technical lead, communications owner and an executive sponsor, with named backups.
• Intake: one channel where alerts and employee reports land, so nothing lives only in chat.
• Severity matrix: definitions, response targets and who must be paged at each level.
• Containment playbooks: for your most likely scenarios, such as compromised credentials, leaked secrets, exposed storage buckets and endpoint malware.
• Evidence preservation: how to capture logs and snapshots before systems are rebuilt.
• Communication rules: who decides whether customers, partners or regulators are notified, and within what timeframe your contracts require.
• Recovery and verification: how you confirm systems are clean and back to normal operation.
• Post-incident review: root cause, contributing factors, action items with owners and due dates.
• Annual testing: a tabletop exercise or simulation, with attendance and outcomes recorded. This is common practice that many auditors ask for, rather than a specific criteria requirement.
• Annual review: the plan is reviewed, approved and versioned at least once a year.

If you are starting from nothing, an incident response plan template gives you the skeleton, and an incident postmortem template covers the review step.

What evidence do SOC 2 auditors ask for?

Auditors want proof that the documented process exists, was approved, was tested and was followed for the incidents that actually occurred during the period.

In a Type 1 report, the auditor checks design at a point in time. In a SOC 2 Type 2 report, they also test operating effectiveness across the observation window. Typical requests include:

Request	Why the auditor wants it
Incident response policy and plan, with approval date	Confirms the process is defined and owned
Population of incidents during the period	Lets the auditor select a sample
Tickets for sampled incidents, with timestamps	Shows triage, containment and closure followed the plan
Post-incident review documents	Proves CC7.5 root cause and improvement activities
Evidence of follow-up actions completed	Shows lessons learned were acted on, not just written
Tabletop or test records	Demonstrates the plan was exercised
Customer or regulator notifications, where required	Confirms external communication commitments were met
On-call schedule and escalation configuration	Shows people were actually reachable

Keep the ticket as the system of record. Chat transcripts are useful context, but auditors move faster when the ticket links to the timeline, the decisions and the review.

What if you had no incidents during the audit period?

If no incidents occurred, the auditor cannot test the response control's operation on real events, but you still need to show the process is designed and ready.

This is common for smaller companies, and it is not a problem in itself. In practice, many auditors will:

1. Inspect the plan, its approval and its annual review.
2. Ask for the incident population and confirm, often through inquiry and log review, that it really is empty.
3. Review your tabletop exercise as evidence the team knows the process.
4. Look at triage records for security events, to confirm CC7.3 is operating even if nothing escalated.

Your report may note that certain controls did not operate during the period because no incidents occurred. That wording is normal. What you want to avoid is an empty incident list alongside triage records that clearly show an event that should have been escalated.

How does SOC 2 incident response fit with HIPAA breach rules?

For HealthTech companies, one incident workflow should cover both: SOC 2 tests that you follow your process, and HIPAA adds a specific breach risk assessment and notification clock when protected health information (PHI) is involved.

Add a mandatory step to your triage: "Does this incident involve PHI?" If yes, run the HIPAA four-factor risk assessment (45 CFR 164.402) to decide whether it is a reportable breach. Then keep these rules in view:

• Your deadline: under the HIPAA Breach Notification Rule, a business associate must notify the covered entity without unreasonable delay and no later than 60 days after discovery (45 CFR 164.410). Treat 60 days as the legal ceiling, not a target.
• Contract and state deadlines: business associate agreements and some state breach laws often set shorter deadlines.
• Agency: if you act as the covered entity's agent, your discovery of a breach may also start the covered entity's own clock.
• Who notifies whom: notifying affected individuals, HHS and, where required, the media is the covered entity's responsibility, unless your BAA delegates those tasks to you.

Track the deadline from your BAA inside the incident ticket so it is visible to everyone working the incident.

Handling both in one ticket gives your SOC 2 auditor a consistent record and helps you meet the notification commitments your healthcare customers expect. HIPAA still has its own documentation and notification content requirements, so keep those in the HIPAA part of the workflow.

Which incident response gaps cause SOC 2 exceptions?

Many exceptions come from inconsistency between the written plan and what actually happened, not from the absence of a plan.

Watch for these patterns:

• Response targets you did not meet. If the policy says critical incidents are acknowledged within 30 minutes, the timestamps must support it. Set targets you can hit consistently.
• Post-incident reviews that never happened. A plan that requires a review within ten business days creates an exception for every incident that skipped it.
• Action items left open. Reviews that list fixes with no owner or completion evidence weaken CC7.5.
• Plan not reviewed in the last year. An outdated approval date is an easy finding to avoid.
• No tabletop exercise. Especially risky when there were no real incidents to test.
• Roles that no longer exist. The plan names someone who left the company months ago.

If you are also certified to ISO 27001, align the two processes. Our guide to ISO 27001 incident management shows how the requirements overlap, so one runbook can serve both audits.

How SecureSlate helps

SecureSlate helps you map your incident response policy and procedures to the SOC 2 criteria and keep the related evidence in one place, alongside your ISO 27001 and HIPAA controls. That makes it easier to see which documents, reviews and test records support each control before your auditor asks for them.

Start your free SecureSlate trial

FAQ

Is an incident response plan required for SOC 2?

Yes in practice. The Trust Services Criteria do not use the phrase "incident response plan", but CC7.4 requires a defined incident response program, and auditors expect it to be documented, approved and communicated to the people who run it.

How often should we test our incident response plan for SOC 2?

The criteria do not set a frequency, but testing at least once a year is common practice and many auditors ask for it. A tabletop exercise with recorded attendees, scenario, decisions and follow-up actions is usually sufficient evidence for a small or mid-sized company.

Do we have to tell customers about every security incident?

No. SOC 2 asks you to define and follow your communication procedures. Your actual notification obligations come from customer contracts, data protection laws and, for PHI, HIPAA. Write those triggers into the plan so the decision is consistent.

Can our incident tickets live in the same tool as engineering tickets?

Yes. Many teams use their existing ticketing system with a dedicated incident type, restricted visibility and required fields for severity, timeline and review. What matters is that the record is complete and easy to export for the auditor.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.