SOC 2 logging and monitoring: building the CC7 evidence trail
Logging and monitoring is where many SOC 2 Type 2 audits get stuck, because auditors want proof that someone actually watched the alerts over the whole period. Here is what CC7 expects and the evidence that satisfies it.
Where logging and monitoring lives in the criteria
The relevant anchor is CC7.1 and CC7.2 in the AICPA's 2017 Trust Services Criteria (with the revised points of focus issued in 2022), which sit under the System Operations group of the Common Criteria. CC7.1 deals with defining configuration baselines and detecting changes that could introduce new vulnerabilities, while CC7.2 is the heart of monitoring: the entity monitors system components and their operation for anomalies indicative of malicious acts, natural disasters, and errors. CC7.3 then covers evaluating those detected events to decide whether they rise to the level of a security incident, and CC7.4 and CC7.5 cover responding to and recovering from confirmed incidents. Monitoring also touches CC4 (Monitoring Activities), which is about evaluating whether controls themselves are operating, so logging is both a control and a source of evidence for other controls. In a Type 2 audit, CC7.2 is one of the most frequently scrutinized criteria because it is operational and continuous rather than a one-time configuration.
Centralized logging and what should flow in
Auditors expect logs from every in-scope system to land in a central place rather than living in isolation on individual hosts. In practice that means aggregating events from cloud infrastructure (CloudTrail, GuardDuty, VPC flow logs, or the Azure and GCP equivalents), the identity provider, application logs, endpoints, and network devices into a SIEM or log platform such as Splunk, Datadog, Elastic Security, Microsoft Sentinel, or a managed service like AWS Security Hub. The point of centralization is twofold: it lets you correlate events across layers, and it puts logs out of reach of an attacker who compromises a single box. Auditors will ask you to demonstrate coverage, so a documented inventory mapping in-scope systems to their log sources is far more persuasive than a verbal assurance that everything is captured. A common weakness is partial coverage, where the SIEM ingests cloud control-plane events but misses application or database activity that would actually reveal misuse.
Retention, integrity, and what gets logged
Your logging policy should state explicitly what events must be captured, how long they are retained, and how their integrity is protected. There is no single AICPA-mandated retention number, but the retention window must at minimum cover the audit period, and many organizations standardize on twelve months of searchable retention with longer cold storage for forensic value. Auditors look for log immutability or tamper-evidence, such as write-once storage, restricted delete permissions, and separation between the people who administer systems and those who can alter logs. The events worth capturing skew toward security-relevant activity: authentication successes and failures, privilege escalations, configuration changes, access to sensitive data, and administrative actions. Logging everything at debug level is not the goal; auditors care that the events that would let you detect and reconstruct a security incident are reliably retained.
Alerting, anomaly detection, and the review cadence
Collecting logs is necessary but not sufficient; CC7.2 is about monitoring for anomalies, which means alerts have to be defined, tuned, and acted on. Auditors want to see alert rules tied to meaningful conditions such as impossible-travel logins, spikes in failed authentication, changes to security groups, or new IAM principals, plus a defined owner and escalation path for each. A SIEM emitting ten thousand low-fidelity alerts a day with no triage process is treated as a control weakness, not as evidence of vigilance, so alert tuning and a documented severity model matter. The single most common gap is the absence of a defined review cadence: there is a SIEM, there are alerts, but no recurring, documented review of dashboards or alert queues by a named role. Establishing a cadence (for example, daily alert triage and a weekly or monthly review with sign-off) and capturing the artifacts of that cadence is what converts a tool into an auditable control.
What auditors test and the evidence they request
Because Type 2 is about operating effectiveness across the period, auditors sample rather than inspect a single snapshot, so your evidence needs to span the whole window. Expect requests for the SIEM or log platform configuration showing which sources are connected, screenshots or exports of alert rules, samples of actual alerts that fired with the corresponding triage or ticket records, and log samples demonstrating that retention and content match the policy. They will also ask for records of the periodic log and alert reviews, ideally with timestamps and reviewer identity, and they will trace a detected event through to its disposition under CC7.3. To tie monitoring to incident detection, auditors often pull a real alert and follow it into your incident response process, confirming the handoff from CC7.2 to CC7.4 actually works. The recurring failures are predictable: gaps in log coverage during part of the period, alerts with no evidence of human review, retention that quietly fell short of the audit window, and a tabletop or detection capability that exists on paper but produced no artifacts.