Security Logging and Monitoring for SaaS: What SOC 2 and CMMC Both Require (And Why DevOps Owns It)
Compliance teams write the policies. DevOps teams build the infrastructure that either satisfies them or doesn't.
Nowhere is that tension more visible, and more consequential, than in security logging and monitoring.
Both SOC 2 and CMMC have direct, specific requirements around logging and monitoring. Both are tested rigorously during assessments. And in both frameworks, the evidence that satisfies the control lives entirely in systems that engineers build and maintain. Here is what each framework requires, where the gaps appear, and why this is one of the few compliance controls where the engineering team's choices matter more than the compliance team's documentation.
What SOC 2 Requires
SOC 2's monitoring controls sit in the CC7 cluster. CC7.1 requires that your organization uses detection tools and techniques to identify anomalies that may be indicative of malware, breaches, or other security events. CC7.2 requires that security events are monitored and evaluated to determine whether they represent incidents. CC7.3 and CC7.4 address incident identification and response.
What this means in practice: you need to be collecting logs from in-scope systems, monitoring those logs for security-relevant events, and demonstrating that your team reviews and acts on what those logs produce. An alerting system that fires into a channel no one monitors does not satisfy the control. A SIEM that collects logs but has no defined review process does not satisfy the control.
Auditors testing CC7 will ask what systems you are logging, where those logs are stored, how long they are retained, who reviews them, and what the process is for escalating an anomaly to an incident. They will also test whether your log retention policy is enforced — specifically whether logs from your audit window are actually available to review.
What CMMC Requires
NIST SP 800-171's audit and accountability domain — which maps directly to CMMC Level 2 — is one of the more technically detailed control families in the framework. It requires organizations to create, protect, and retain audit logs of user activity, security-relevant events, and system access sufficient to enable monitoring, analysis, and investigation.
Specifically, 3.3.1 requires creating and retaining system audit logs. 3.3.2 requires ensuring that individual user actions can be traced. 3.3.5 requires correlating audit record review, analysis, and reporting processes. 3.3.6 requires providing reduction and report generation to support analysis.
In plain language: you need logs, you need to be able to trace actions to specific users, you need to review those logs, and you need to be able to produce meaningful reports from them. CMMC assessors will ask for evidence of each of these capabilities. They will look at your logging configuration, your retention settings, your review process, and your ability to reconstruct a timeline of activity for a specific user or system.
Where the Gaps Appear
Incomplete log coverage is the most common finding. Organizations log their primary application but not their cloud infrastructure. They log authentication events but not privileged command execution. They log at the application layer but not at the network layer. Auditors assess coverage against your declared system boundary. If a system is in scope and not generating logs, that is a finding.
Log retention gaps. SOC 2 does not specify a minimum retention period. NIST SP 800-171 does not either — but CMMC assessors look for retention that is sufficient to support investigation of events that occurred during the audit window. Most organizations target 90 days of hot storage and one year of archived storage. Organizations that have logs rolling off after 30 days will be asked why.
No defined review process. Logs that are collected but never reviewed are compliance theater. Auditors will ask who reviews logs, at what frequency, and what the process is for escalating an event. If the answer is "our SIEM sends alerts," the follow-up is "show me the alert review history and the process for acting on them." Alert fatigue is a known problem. Documented triage procedures are the answer.
Inability to attribute actions to specific users. Shared accounts, shared credentials, and systems that log at the session level rather than the user level make individual attribution impossible. This is a specific CMMC requirement and a consistent gap in environments where service accounts are used broadly without logging granularity.
Why DevOps Owns This
Log collection, retention, and tooling are engineering decisions. The compliance team can write a logging policy. Only the engineering team can configure CloudWatch, set up a SIEM, establish log retention rules, and build the alerting logic that makes the policy real.
This is not a criticism. It is a structural reality that compliance programs need to account for. The most effective approach is a joint working session where the compliance requirements are translated directly into engineering tasks: what systems need to be logging, to what destination, with what retention settings, with what alerting rules, reviewed by whom on what schedule. That translation from policy language to infrastructure configuration is where compliance programs either work or fail in SaaS environments. Our compliance program services include working directly with engineering teams to translate control requirements into buildable infrastructure specifications.
