SOC 2 CC7.3: incident triage, explained for startups

What usually proves it

An auditor wants records from the period being examined, pulled from the systems that hold them rather than written up afterwards. Dates matter. A record with a date and a named owner carries more weight than a screenshot with neither. For CC7.3, the usual records are these.

• An incident response plan with severity definitions
• Tickets showing events triaged and classified
• An incident log

What Polara asks about it

The free readiness assessment asks 3 questions that bear on CC7.3. A yes becomes a task to show the proof. A no becomes a task to fix the gap, with the steps written out.

• Alerting configured for security events? If yes, show it: PagerDuty service with security alerts, Datadog monitor list, alert routing policy, or on-call schedule screenshot. If no, the fix: configure alerts for authentication failures, privilege changes, and other security events, and export the alert rules.
• Incident Response Plan exists and is approved? If yes, show it: incident Response Plan with approval signature, on-call escalation chart, tabletop exercise notes, or incident response runbook. If no, the fix: approve an incident response plan with roles, severity levels, and escalation paths.
• Security events logged with severity, date, and status? If yes, show it: incident ticket template, PagerDuty incident list, incident Slack channel log, or post-incident review record. If no, the fix: record every security event in a tracker with severity, date, and status fields.

Policies, templates and connected evidence

A policy states the rule, a template gives you the record to keep, and a connected system pulls the proof from the source. An auditor checks that the three agree: the cadence in the policy, the dates in the record and what the system shows.

In the policy pack, the Incident Response Policy and Information Security Policy cover CC7.3.

Free templates that help, printed in full with Word, PDF or Excel downloads:

• Incident response plan template

Connected systems that pull evidence for it:

• Amazon Web Services, CloudTrail trails: audit log configuration per region.

If you also run ISO 27001, the Annex A controls A.5.24, incident readiness, A.5.25, triaging security events and A.6.8, reporting security events ask for overlapping evidence. One record can serve both when it names what it proves.

Where it goes wrong

One gap a remediation playbook covers here is incident Response Plan. The fix: draft an incident response plan and get executive approval. The proof: signed incident response plan document (PDF with executive signature).

An auditor asks two things about it. Is there a documented incident response plan? Has the IR plan been approved by management and communicated to the team?

Is it in your scope?

Yes, always. CC7.3 is one of the 33 common criteria, and the common criteria are in every SOC 2 report, Type 1 or Type 2. The common criteria. Every SOC 2 report covers them, whatever else you add: governance, risk, access, operations, change and vendors. Most of the work in any SOC 2 sits here.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

System operations: the criteria around it

CC7.3 is one of 5 criteria in system operations, CC7.1 to CC7.5. Reading a group together shows how its outcomes fit, and one record often serves more than one of them.

• CC7.1, vulnerability monitoring
• CC7.2, anomaly monitoring
• CC7.3, this page
• CC7.4, incident response
• CC7.5, incident recovery

Before it: CC7.2, anomaly monitoring. After it: CC7.4, incident response. All the criteria are on the Trust Services Criteria page, grouped by category.