SOC 2 CC7: System Monitoring Requirements Explained
CC7 is the part of SOC 2 that deals with whether you actually know what is happening in your systems. It covers vulnerability detection, anomaly monitoring, and incident management. Auditors spend significant time on CC7 because it is the category that most clearly separates companies with real operational security from those who have only built the documentation.
This post breaks down each CC7 sub-criterion, what evidence satisfies it, and the gaps auditors find most often.
CC7.1: Vulnerability Detection and Management
CC7.1 requires that your organization identifies vulnerabilities in system components and manages the risk of exploitation.
What this means in practice:
- A scheduled vulnerability scanner runs against your production systems
- Findings are triaged by severity
- Critical and high findings have a defined remediation SLA (commonly 30 days for critical, 90 days for high)
- You have evidence that the SLA is being met, not just defined
What auditors look for: Scan reports from within the audit period showing coverage across production systems, a documented remediation SLA, and evidence that at least some findings were remediated within that SLA. A single scan run before the audit is not sufficient.
Common gap
Scans run against developer or staging environments but not production, or scans that run but whose findings sit in a backlog with no documented triage process.
CC7.2: Anomaly Detection and Monitoring
CC7.2 requires that anomalies in system operation are detected and responded to.
What this means in practice:
- Production systems are monitored with active alerting
- Alerts route to someone who can respond (not a dead-end inbox)
- There is evidence that alerts have triggered and been responded to
What auditors look for: Active monitor configurations in your observability tool, routing configuration showing alerts go to an on-call system, and at least one alert-response event documented in the audit period.
Common gap
Monitors exist but route to a Slack channel that nobody watches. The monitor configuration is not the control, the response process is. An alert with no response path is not evidence of anomaly management.
CC7.3: Evaluating Security Events as Incidents
CC7.3 requires that detected security events are evaluated to determine whether they constitute incidents and are classified accordingly.
What this means in practice:
- You have a definition of what constitutes a security incident
- Events that meet the threshold are classified as incidents and routed to your incident response process
- Events that do not meet the threshold are documented as closed non-incidents
What auditors look for: An incident response policy that defines incident classification criteria, and an incident log showing events were evaluated during the audit period. Even if you had no significant incidents, you need evidence that monitoring alerts were reviewed and dispositioned.
Common gap
No documented triage of monitoring alerts. Companies that run Datadog or CloudWatch but have no process for reviewing and closing alerts that turn out to be non-incidents have a gap here. The absence of incidents is not the same as evidence that you are evaluating for incidents.
CC7.4: Incident Response and Communication
CC7.4 requires that identified incidents are responded to according to a defined process.
What this means in practice:
- A documented incident response procedure exists
- The procedure defines roles, escalation paths, and communication requirements
- Incidents are tracked with a timeline of actions taken
What auditors look for: An incident response procedure document and an incident log showing that any incidents in the audit period were handled according to the procedure. The log should show time-to-detection, time-to-containment, and actions taken.
Common gap
Incident response procedure exists on paper but no incidents were logged during the audit period, even minor ones. Auditors find this implausible for most companies. If you genuinely had no incidents, document the near-misses, the false positives, and the alert investigations that resolved as non-incidents.
CC7.5: Post-Incident Review
CC7.5 requires that lessons learned from incidents are captured and used to improve the program.
What this means in practice:
- After any significant incident, a post-mortem or root cause analysis is conducted
- Findings from the post-mortem are documented
- Identified improvements are tracked to completion
What auditors look for: A post-mortem document from any incident in the audit period, or evidence that your incident review process was followed even for minor incidents.
Common gap
Post-mortems exist for large incidents but not for smaller ones. The expectation is that the process is applied consistently, not selectively.
CC7 Evidence Summary
| Sub-criterion | Primary tool | Evidence type |
|---|---|---|
| CC7.1 | Tenable, Snyk, AWS Inspector | Scan reports with remediation log |
| CC7.2 | Datadog, CloudWatch, PagerDuty | Monitor config, alert routing, alert history |
| CC7.3 | Incident tracker (Jira, Linear) | Alert triage log, incident classification records |
| CC7.4 | Incident tracker + runbooks | Incident log with timeline of response |
| CC7.5 | Post-mortem documents | RCA per incident, action item tracking |
Pulling CC7 evidence from your monitoring and incident tools and catching controls with no evidence in the current audit period, before your auditor does, is exactly the work a fractional CISO owns for you. Book a call to review your monitoring controls.
Related reading
- Datadog SOC 2 Compliance Guide
- SOC 2 Evidence Collection: What Auditors Actually Want
- SOC 2 Readiness Assessment Checklist
Want a security leader to run this?
Xorabyte is a fractional CISO for startups who can review your cloud for the gaps found first, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.