SOC 2 CC7.2: Monitoring System Components for Anomalies

SOC 2 CC7.2 is the security monitoring criterion in the Trust Services Criteria: it requires an organization to monitor its systems for anomalies and to analyze what turns up. It anchors the CC7 series (System Operations), and the finding that comes up repeatedly under it is monitoring without a triage trail: alerts fired, someone cleared them, and no record shows an investigation.

What does SOC 2 CC7.2 require?

In plain terms, CC7.2 asks two questions: is anyone watching the systems, and does anything happen when the watching turns something up. The criterion names malicious acts, natural disasters, and errors as anomaly sources, which makes it wider than attack detection. A failing disk that corrupts data and a misconfigured job that deletes records are anomalies under CC7.2 in the same way an intrusion attempt is.

The second clause carries the operational weight. Detecting an anomaly is half the requirement; the organization must also analyze it and decide whether it represents a security event. That analysis step is a frequent source of audit findings, because it produces no evidence unless someone writes the decision down.

CC7.2 is technology-neutral. It does not require a SIEM, a specific detection product, or around-the-clock coverage. What it requires is monitoring proportionate to the environment: logs collected from in-scope systems, detection rules that examine them, and a documented path from alert to disposition. Scope extends into the application itself: sign-ins, permission changes, and MFA configuration changes need capturing, and each log entry needs an actor, an action, a target, and a UTC timestamp to support analysis.

What are the CC7.2 points of focus?

The AICPA defines 4 points of focus for CC7.2. 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.

• Detection governance. Policies and procedures for detecting anomalies are defined, implemented, and maintained through a governance process, with threat intelligence sources informing what the organization watches for.
• Anomaly coverage. Detection measures are designed to identify anomalies such as compromise attempts, unauthorized access to systems and data, credential misuse, and unauthorized hardware or software in the environment.
• Filtering and analysis. Filters and rules are implemented to analyze detected anomalies and flag the ones that need investigation, turning raw event volume into a manageable set of alerts.
• Effectiveness over time. The organization monitors whether its detection tools continue to work as intended, tuning rules and coverage as the environment changes.

How do you meet CC7.2 in cloud environments?

Cloud environments meet CC7.2 by enabling the provider's log and detection services and wiring their output into a documented handling process:

• Native log services as the foundation. CloudTrail, VPC Flow Logs, Azure Monitor activity logs, and GCP Cloud Audit Logs capture control-plane and network activity. Enable them organization-wide and centralize them into a dedicated logging account or project.
• Managed detection rules. GuardDuty, Microsoft Defender for Cloud, and Security Command Center run provider-maintained detections, backed by provider threat intelligence, against those logs, covering the threat intelligence point of focus without an in-house detection engineering function.
• Alert routing into a ticketing system. Route findings to Jira, ServiceNow, or PagerDuty so each alert becomes a ticket that carries its own disposition. The routing configuration proves the analysis step exists; the closed tickets prove it happens.
• Retention sized to the observation window. Archive logs to object storage with a lifecycle policy of at least 12 months.
• Application and SaaS coverage. Pull in identity provider sign-in logs, SaaS admin audit logs, and the application's own audit events.
• Rule effectiveness reviews. On a set cadence, review which detections fire, which are suppressed, and whether newly adopted services send logs anywhere.

The logging and monitoring architecture guide covers pipeline design, detection use cases, and pipeline resiliency in technical depth.

How do you meet CC7.2 on-prem?

On-prem environments build what cloud platforms embed: Windows servers, Linux hosts, a hypervisor, and a firewall appliance have no default log pipeline, so the architecture itself is the control. The on-prem logging and SIEM guide covers the full implementation; the shape is:

• A self-hosted SIEM as the aggregation point. Open-source platforms in the Wazuh class combine log collection, host-based detection rules, and file integrity monitoring behind a single agent. Teams of two to five people that cannot absorb SIEM operations can use a managed SOC service instead: agents installed internally, triage delivered externally.
• Explicit collection decisions. Windows Event Forwarding or agents for Windows hosts, syslog from Linux systems and the firewall appliance, and database audit logs. CIS Benchmarks specify which audit event categories to enable per platform, so the SIEM receives security-relevant events rather than noise.
• Retention covering the observation window. A Type 2 period typically runs 6 to 12 months; confirm the SIEM's storage supports the full window before it opens, because retention gaps cannot be backfilled.
• Detection rules matched to the environment. Failed login thresholds, new local account creation, service installations, and changes to critical files. A short rule set that fires and gets triaged produces stronger evidence than a large one nobody tunes.
• A weekly triage cadence. Thirty to sixty minutes to review the dashboard, create cases for alerts that warrant investigation, and confirm every source still sends logs; a source that went silent mid-period becomes an evidence gap.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC7.2?

CC7.2 evidence follows a three-part structure: proof the control was configured, proof it ran, and proof findings were resolved. A screenshot of a configured SIEM could mean the tool was set up once and never ran. Alert history without triage records could mean findings are being ignored. The chain is complete only when all three stages cover the observation period.

Auditors treat a period of investigated alerts as stronger evidence than a period with none; the triage trail is what distinguishes a monitored environment from a silent one. What happens after an alert escalates belongs to CC7.3.

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

Organizations pursuing both frameworks can reuse CC7.2 evidence almost wholesale; A 8.17 adds clock synchronization, which log correlation already depends on. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC7.2 is the middle of the System Operations detection chain: CC7.1 covers detecting configuration changes and new vulnerabilities, and CC7.3 covers evaluating the security events that monitoring identifies. The access CC7.2 watches is granted under CC6.1; the CC6.1 guide covers logical access security software, infrastructure, and architectures. The Trust Services Criteria guide summarizes every series.

Frequently Asked Questions

What does SOC 2 CC7.2 mean?

SOC 2 CC7.2 requires an organization to monitor system components and their operation for anomalies that could indicate malicious acts, natural disasters, or errors, and to analyze those anomalies to determine whether they represent security events. It is the security monitoring criterion of the CC7 System Operations series.

What evidence satisfies CC7.2?

CC7.2 evidence covers three stages: configuration (detection rule inventory, SIEM settings, retention policy), execution (log ingestion trends and alert history across the observation period), and resolution (triage cases documenting what was reviewed and concluded). Auditors sample from the actual audit window, so triage documentation has to run throughout the period.

Does SOC 2 require a SIEM?

No. CC7.2 requires monitoring for anomalies and does not prescribe tooling. Native cloud detection services, a self-hosted SIEM, a managed SOC service, or a combination all satisfy the criterion, provided logs from in-scope systems are collected, detection rules run against them, and alert handling is documented.

What log retention does SOC 2 require?

SOC 2 does not set a specific retention period. A Type 2 observation window typically runs 6 to 12 months, and log retention needs to cover it so the auditor can sample from any point in the period. Twelve months is a common baseline; contracts and some industries require more.

What if we had no security incidents during the audit period?

An incident-free period still needs monitoring evidence. Alert history, triage cases closed as false positives or benign activity, and weekly review records demonstrate the control operated even when nothing escalated. A dashboard showing zero alerts with no triage trail raises questions about whether monitoring ran at all.