Skip to content
AuditFront
CC7.2 SOC 2

SOC 2 CC7.2: System Operations - Monitoring of System Components for Anomalies

What This Control Requires

The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.

In Plain Language

Detecting a breach six months after it happened is almost as bad as never detecting it. CC7.2 is about real-time monitoring - watching your systems for behaviour that deviates from the norm and investigating it before damage is done.

This goes beyond vulnerability scanning into active monitoring of system behaviour, user activity, and operational metrics. You need a SIEM or equivalent, baselines for normal behaviour, alerts for anomalies, and - critically - a process for actually investigating those alerts. Monitoring without investigation is a finding in itself.

Auditors evaluate monitoring coverage, the types of anomalies being detected, how quickly alerts are investigated, and whether your programme can distinguish between noise and genuine security events. If your team is drowning in false positives and ignoring alerts, that's a red flag.

How to Implement

Deploy a centralised security monitoring platform. A SIEM or equivalent should aggregate logs from all critical systems: authentication, network, application, database, and cloud infrastructure. Configure correlation rules for patterns like brute-force attacks, privilege escalation, data exfiltration, and lateral movement.

Establish baselines for normal behaviour. Document expected patterns for network traffic, authentication activity, system resource usage, and application performance. Use these to set anomaly detection thresholds, and update them as your environment evolves.

Set up alerting for security-relevant anomalies. At minimum, alert on: multiple failed authentication attempts, access from unusual locations or times, privileged account anomalies, large or unusual data transfers, system configuration changes, malware detections, and availability threshold breaches.

Build a tiered alert management process. Categorise by severity and define response procedures for each tier. Critical alerts need immediate investigation. Lower-severity alerts can be reviewed in regular monitoring cycles. Ensure 24/7 coverage for critical alerts - either through an internal SOC, a managed security service provider, or automated response with on-call escalation.

Tune your monitoring rules regularly. False positives cause alert fatigue, which causes real threats to get missed. Review alert volumes, investigate false positive patterns, and refine rules to improve the signal-to-noise ratio. Track what percentage of alerts lead to genuine investigations.

Document everything. Keep records of alerts generated, investigations conducted, and outcomes. Report to management on monitoring coverage, alert trends, and security events detected. Use this data to keep improving the programme.

Evidence Your Auditor Will Request

  • SIEM or monitoring platform deployment documentation showing log sources and coverage
  • Alerting rules and correlation logic configured for security-relevant anomalies
  • Alert investigation records showing timely review and triage of security alerts
  • Monitoring coverage reports demonstrating all in-scope systems are being monitored
  • Alert tuning records and metrics on monitoring effectiveness (false positive rates, detection rates)

Common Mistakes

  • Monitoring covers only a subset of systems, leaving gaps in visibility for critical infrastructure
  • Alerts are generated but not investigated in a timely manner, allowing real threats to go unaddressed
  • Alert fatigue from excessive false positives leads to legitimate alerts being ignored
  • No baseline established for normal behavior, making it difficult to identify genuine anomalies
  • Monitoring is limited to business hours with no coverage during nights, weekends, or holidays

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.8.15 Related
ISO 27001 A.8.16 Equivalent
nist-csf DE.AE-02 Equivalent
nist-csf DE.CM-01 Related

Frequently Asked Questions

Do we need 24/7 security monitoring?
For critical alerts, yes. Attackers don't work business hours. Your options: build an internal SOC with shift coverage, use an MSSP or MDR service for after-hours monitoring, or combine automated response for the most critical scenarios with on-call escalation for human review. Most smaller organisations start with an MDR service.
What is an acceptable false positive rate for security alerts?
A well-tuned environment typically lands around 20-30% false positives. If more than half your alerts are false positives, your monitoring needs serious tuning. On the flip side, a very low alert volume might mean your coverage is too narrow rather than your security being excellent. Track this metric and report on it regularly.
Can cloud-native monitoring tools replace a SIEM?
Cloud-native tools like AWS CloudWatch, Azure Monitor, and GCP Cloud Logging are excellent for cloud environments but may not cover on-premises systems or give you cross-platform correlation. For cloud-only organisations, pairing cloud-native monitoring with a cloud SIEM (Microsoft Sentinel, Splunk Cloud, etc.) works well. What matters is comprehensive coverage and the ability to correlate events across your whole environment.

Track SOC 2 compliance in one place

AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.

Start Free Assessment