SOC 2 criteria requiring security monitoring
CC6 (Logical and Physical Access Controls) and CC7 (System Operations) are the criteria most relevant to a security monitoring programme. CC6.1 requires controls to restrict logical access — monitoring enforces those controls and detects bypass. CC7.2 requires the entity to monitor system components for anomalies that indicate malicious acts, natural disasters, or errors affecting the ability to meet objectives.
CC7.3 requires evaluation of security events to determine if they constitute a security incident. CC7.4 requires incident response procedures. Together, these criteria describe a functioning detection-and-response programme — not just a logging implementation.
The examiner's question for each criterion is not 'do you have a tool?' but 'can you demonstrate the control operated effectively during the period?' For CC7.2 and CC7.3, this means producing evidence of alert review, triage decisions, and incident escalations over the audit period.
Evidence ManySignal produces for each criterion
CC6.1 (logical access): the entity graph provides the authoritative record of which identities accessed which systems during the period. Access review reports are generated by the report agent quarterly. Anomalous access findings are the detective control evidence.
CC7.2 (anomaly monitoring): the active detection catalogue demonstrates what the organisation monitors for. The weekly metrics report (autonomous verdict rate, alerts reviewed, MTTV) demonstrates the monitoring operated continuously. The case timeline for each security event is the evidence of anomaly detection.
CC7.3 (event evaluation): every case in ManySignal has a verdict with attached evidence — this is the 'evaluation of security events' the criterion requires. The verdict includes the determination (true positive, false positive, informational) and the evidence used to reach it.
Preparing for the observation period
SOC 2 Type II covers an observation period — typically 6 months for first-time reports, 12 months for renewals. Start the monitoring programme at least 3 months before the observation period begins so that baselines are stable, the detection catalogue is tuned, and the weekly metrics reports have a history that demonstrates the programme is routine, not exam-preparation.
Document the monitoring programme in a Security Monitoring Policy: what sources are ingested, what is monitored, how alerts are reviewed, how incidents are escalated. The policy is the design evidence; the case timeline and metrics reports are the operating evidence.
- Security Monitoring Policy drafted and approved
- All systems in scope for SOC 2 have active log ingestion in ManySignal
- Detection catalogue covers CC7.2 monitoring requirements
- Weekly metrics reports archived from start of observation period
- Quarterly access review reports generated by the report agent
- At least one security incident case closed with documented verdict during the period
Common examiner questions and answers
'How do you monitor for unauthorised access to production systems?' — ManySignal ingests authentication logs from all production systems, correlates them in the entity graph against the authorised user list from the IdP, and detects access by users without current authorisation within minutes.
'How do you know your monitoring programme is working?' — Weekly metrics reports show the autonomous verdict rate, TP:FP ratio, and MTTV trend. Cases closed as true positives during the period demonstrate the detection programme is effective. Examiners respond well to trend data that shows improvement.
Continuous compliance after the report
SOC 2 is annual — the report date is not the end of the compliance cycle, it is the renewal date. The security monitoring programme should operate identically during and between audit periods. ManySignal's report agent generates the quarterly access reviews and weekly metrics digests continuously — there is no 'exam mode'.
Use the period between reports to close gaps identified during the audit, expand coverage to additional systems, and mature the detection catalogue. The next examiner will review the entire 12-month period — improvements made in month 6 are as visible as the state at month 12.
Key takeaways
- CC7.2 and CC7.3 require demonstrating effective anomaly monitoring and event evaluation over the audit period.
- Evidence is operating evidence: case timelines, metrics reports, access reviews — not just policies.
- Start the monitoring programme 3 months before the observation period for stable baselines.
- The weekly metrics report and case timeline are the primary operating evidence artefacts.
- Document the monitoring programme in a Security Monitoring Policy for design evidence.
- Operate identically between audit periods — there is no exam mode.