CC7.2 — Anomaly and security event monitoring

System components and operations are monitored for anomalies indicative of malicious acts, natural disasters, and errors, and for security events.

Also written as CC 7.2, TSC CC7.2, SOC2 CC7.2, SOC 2 Type 2 CC7.2.

Written by Jett N. · Last reviewed 22 July 2026

What SOC 2 CC7.2 requires

Anomaly and security event monitoring is one of 5 criteria in the System Operations (CC7) series of the Security (Common Criteria) category. System components and operations are monitored for anomalies indicative of malicious acts, natural disasters, and errors, and for security events. CC7 covers detection and response, so the evidence is operational: monitoring configuration, alert samples, incident tickets with timestamps, and proof that identified issues were actually closed out.

Audit evidence assessors look for

When preparing for a SOC 2 audit against CC7.2, gather artefacts such as:

Points of focus for CC7.2

The Trust Services Criteria set out points of focus that describe what an auditor considers when assessing CC7.2. They are not themselves requirements, but they shape the testing:

• Monitoring is designed to detect anomalies indicative of malicious acts or errors.
• Monitoring covers the system components that matter, including infrastructure and applications.
• Detected anomalies are evaluated to determine whether they represent security events.
• The design of monitoring considers the threats the system faces.

How to implement CC7.2

1. Document log source coverage and the deliberate gapsA coverage matrix — system, log type, ingested yes or no, retention — is the single most useful artefact for this criterion. Declared gaps with a rationale are acceptable; undeclared gaps found during testing are not.
2. Set retention to exceed the review periodIf retention is 90 days and the review period is 12 months, evidence for the first nine months does not exist, and no amount of preparation recovers it. This is a decision to get right before the period starts, not before fieldwork.
3. Write detection rules against your own threat modelDefault rule packs generate noise and miss what is specific to you. Rules derived from your architecture — unusual access to the customer database, changes to the production deployment role — are both better security and better evidence of design.
4. Keep triage records including the false positivesAuditors sample alerts from across the period and ask what happened. A record showing an alert was investigated and dismissed as benign is exactly as good as one showing an incident, because both evidence the process operating.
5. Evidence the on-call or review scheduleSomeone has to be responsible for looking. Shift rosters, on-call schedules or an MSSP service report all work; the absence of any of them means the monitoring has no operator.

Common audit findings for CC7.2

What actually gets raised against CC7.2, in rough order of how often it comes up:

• Log retention shorter than the audit period, making early-period sampling impossible.
• Alerts with no triage record, particularly in the first months of the period before the audit was front of mind.
• Significant systems absent from log collection and not declared during scoping.
• Detection rules never tuned since deployment.

Scoping CC7.2

CC7.2 is Common Criteria. If you outsource monitoring to an MSSP, their service reports and your own review of them both form part of the evidence, and the auditor may ask for the MSSP own assurance report. Confirm your provider can supply that before you rely on them.

ISO 27001 mapping

CC7.2 corresponds to the following ISO 27001:2022 Annex A control(s): A.7.4, A.8.15, A.8.16, A.8.17. If you already run an ISO 27001 ISMS, map your existing evidence for these controls to CC7.2 rather than duplicating work.

Other System Operations criteria

All CC7 System Operations criteria →