SOC 2 CC7.3: Evaluating Security Events to Identify Incidents

SOC 2 CC7.3 requires a company to evaluate detected security events, decide which of them are incidents, and act on the ones that are. It sits in the CC7 series (System Operations), between the monitoring criterion that generates the events and the response criterion that handles the ones that qualify. A frequent finding under it is a team with a working monitoring tool that clears alerts without recording that anyone investigated them.

What does SOC 2 CC7.3 require?

In plain terms, CC7.3 is the triage step. Monitoring under CC7.2 produces a stream of security events: failed logins, firewall denials, intrusion alerts, anomalies flagged by a SIEM. CC7.3 asks what the company does with that stream. Each event has to be looked at and sorted into one of two buckets: routine noise that needs no further action, or a security incident that could affect the company's objectives and therefore has to be handled.

The word that matters in the criterion is evaluates. It is not enough to have events land in a dashboard. Someone has to review them, decide whether they represent an incident, and record that decision. That evaluation is what turns a monitoring capability into an operating control, and it is the difference between a tool that watches and a program that responds.

CC7.3 also draws a line for what happens next. When an event is judged to be an incident, the criterion expects the company to take action to prevent or address the failure. For a minor incident that action may be complete in the same step. For a serious one, CC7.3 hands off to the incident-response program under CC7.4, which governs how the company contains, remediates, and communicates. The boundary is useful to keep clear: CC7.3 is the decision that something is an incident, and CC7.4 is the machinery for resolving it.

What are the CC7.3 points of focus?

The AICPA defines 3 points of focus for CC7.3. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Respond to security incidents. Procedures exist for responding to security incidents, and the company periodically evaluates whether those procedures are working. This is the point of focus that connects event evaluation to a defined response rather than an ad hoc reaction.
• Communicate and review detected events. Detected security events are passed to and reviewed by the people responsible for running the security program, and action is taken where the review calls for it. Evaluation is a named responsibility, not something that happens by chance when someone glances at a screen.
• Analyze incidents and determine impact. Procedures are in place to analyze a security incident and work out its effect on the system, so the company understands scope and severity before deciding how far the response has to go.

How do you meet CC7.3 in cloud environments?

Cloud environments give a team a running start on the detection side, so meeting CC7.3 is mostly about the disciplined evaluation layer on top of what the platform surfaces:

• A managed detection pipeline that feeds a queue. Findings from services such as GuardDuty, Microsoft Defender, or a cloud-native SIEM route into a single queue or ticketing system rather than staying scattered across consoles, so nothing is evaluated only if someone happens to notice it.
• A triage workflow with recorded decisions. Every finding that warrants a look becomes a case with a timestamp, the alert that triggered it, the observables reviewed, and the conclusion. A conclusion of no action needed is a valid outcome as long as it is written down.
• Severity classification. Findings are ranked by severity so the team can tell a blocked port scan from credential compromise and route the serious ones into the incident-response process under CC7.4.
• Automated enrichment where it helps. Playbooks that attach context to a finding (the identity involved, the resource, recent related events) speed evaluation, but the human decision and its rationale are still recorded.

How do you meet CC7.3 on-prem?

On-prem environments have to build the same evaluation layer on top of a logging pipeline they assemble themselves. The logging and SIEM for bare metal guide covers the collection and aggregation detail; for CC7.3 specifically the shape is:

• A central place where events land. Logs from servers, network appliances, and the firewall are aggregated into a SIEM or log platform so events can actually be reviewed, rather than sitting in per-device logs no one correlates.
• A named reviewer and a review cadence. A person or rotation owns event review on a defined schedule, often a weekly dashboard review during the observation period, so evaluation is a routine with a record instead of an occasional habit.
• A case for every event that warrants investigation. The same case format applies: timestamp, triggering alert, events and observables reviewed, and conclusion. On a small team this takes minutes per case and accumulates into the response evidence the audit needs.
• A path into the incident process. When evaluation concludes that an event is an incident, there is a defined route into the response and recovery steps, so the decision does not dead-end in a closed alert.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC7.3?

How does CC7.3 map to ISO 27001:2022?

The overlap is direct: A 5.25 is the ISO control for assessing security events and deciding whether they are incidents, which is exactly what CC7.3 governs, and A 5.24 provides the planning and preparation behind it. Evidence produced for CC7.3 can be reused for both. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC7.3 is the hinge of the CC7 series. The previous criterion, CC7.2, builds the monitoring that detects security events; CC7.3 evaluates those events and decides which are incidents; and the next criterion, CC7.4, executes the incident-response program on the ones that qualify. Reading the three in order shows the full path from a raw alert to a resolved incident, with CC7.3 as the decision point in the middle. Teams often have the monitoring of CC7.2 well covered and the evaluation of CC7.3 undocumented, which is why the two are best assessed together.

Frequently Asked Questions

What does SOC 2 CC7.3 mean?

SOC 2 CC7.3 means the company evaluates the security events its monitoring detects, decides which of them are security incidents that could affect its objectives, and takes action on those. It is the triage step between detecting an event and running a full incident response.

What evidence satisfies CC7.3?

The core evidence is a defined event-evaluation or incident-response procedure, case or ticket records showing that alerts were investigated and closed with a rationale, a periodic event-review log, and severity classification and escalation records for events judged to be incidents.

What is the difference between CC7.2 and CC7.3?

CC7.2 is about monitoring: putting detection in place so security events are surfaced. CC7.3 is about evaluation: reviewing those events, deciding which are incidents, and acting. A team can pass CC7.2 with a working dashboard yet fail CC7.3 if it never documents that anyone investigated what the dashboard showed.

Does a quiet dashboard with no alerts satisfy CC7.3?

No. An empty dashboard shows nothing was evaluated, and auditors read it as a gap rather than a clean bill of health. CC7.3 is satisfied by evidence that events were reviewed and triaged, including events that turned out to need no action, not by the absence of alerts.

How is CC7.3 different from CC7.4?

CC7.3 is the decision that a security event is an incident and the initial action on it. CC7.4 is the defined incident-response program that then contains, remediates, and communicates that incident. CC7.3 identifies the incident; CC7.4 resolves it.