CC7 — System Operations — covers the day-to-day operational security activities that keep the system secure and responsive to emerging threats. Where CC6 focuses on who can access the system, CC7 focuses on what happens within it: are threats detected? Are vulnerabilities identified and remediated? When incidents occur, are they handled systematically and documented? The operational discipline required for CC7 is the foundation of continuous compliance — and the evidence it generates is the raw material of a Type II audit.
Vulnerability Management (CC7.1)
CC7.1 requires that the organization identifies and addresses vulnerabilities in its systems on an ongoing basis. This means: a defined vulnerability scanning cadence (most organizations run weekly or bi-weekly automated scans), a vulnerability classification methodology (typically aligned to CVSS severity ratings), and remediation SLAs by severity (critical: 24–48 hours; high: 7–14 days; medium: 30 days; low: 90 days are common benchmarks).
| Severity | Typical Remediation SLA | Auditor Testing Approach |
|---|---|---|
| Critical (CVSS 9.0–10.0) | 24–48 hours | Auditors will sample critical findings and verify remediation within SLA; unpatched critical findings are automatic exceptions |
| High (CVSS 7.0–8.9) | 7–14 days | Sampled for remediation timeliness; compensating controls (e.g., WAF rules, network isolation) may be acceptable if documented |
| Medium (CVSS 4.0–6.9) | 30 days | Sampled statistically; pattern of consistently exceeding SLA generates finding |
| Low (CVSS 0.1–3.9) | 90 days (or accepted risk with documentation) | Low scrutiny; accepted risk documentation satisfies control requirement |
| Exceptions / accepted risks | Risk acceptance requires documented business justification, approver name, and review date | Auditors verify risk acceptance is formal, not just informal deferral |
Security Monitoring / SIEM (CC7.2)
CC7.2 requires the organization to monitor system components for anomalies and evaluate those anomalies to identify potential security incidents. In practice, this means having a SIEM or log management platform with defined alert rules, a process for reviewing and responding to alerts, and documentation showing that alerts were investigated and either resolved or escalated to incident management.
The evidence for CC7.2 is operational: alert configurations, sample alert notifications, and the disposition records showing how each alert was handled. Auditors will pull a sample of alerts from the observation period and trace the response. An alert that fired but was never investigated — or was acknowledged without documented disposition — is a finding.
| KEY IDEA | The key CC7.2 question is not “do you have a SIEM?” but “do you actually respond to what it tells you?” Many organizations have SIEM tooling that generates alerts into an inbox nobody reviews systematically. Auditors detect this pattern quickly when they see alert volume with no corresponding investigation records. |
Incident Management (CC7.3 – CC7.5)
Incident management is the most operationally visible component of CC7. SOC 2 requires that the organization has a defined incident response process — from initial detection through classification, response, notification, recovery, and post-incident review — and that this process is actually followed and documented when incidents occur.
The incident register is the central evidence artifact for this requirement. Every security event that rises to the level of an incident — confirmed unauthorized access, data exposure, system outage, phishing attack with credential compromise — should be documented in the incident register with: incident date and time, classification/severity, description, response actions, resolution, and post-incident review outcome.
| IMPORTANT | SOC 2 does not require zero incidents — it requires that incidents are handled and documented. A company that had five security incidents during the observation period but handled each systematically and documented them thoroughly will receive a cleaner audit opinion than a company that had no documented incidents but also no evidence of an active incident management process. Evidence of process is what auditors test. |
| Incident Lifecycle Stage | Required Documentation | Common Gap |
|---|---|---|
| Detection | Alert, user report, or external notification triggering the incident record | Incidents detected but not formally recorded until severity is confirmed — leaving a documentation gap |
| Classification | Severity assignment with rationale; escalation decision | Severity assigned inconsistently; no documented classification criteria |
| Response | Actions taken, by whom, at what time | Response actions logged in the incident ticket; chain of custody clear |
| Notification | Client/regulatory notification decision and execution | Notification decision not documented; “we decided not to notify” not recorded |
| Recovery | System restoration confirmation; evidence that the incident is resolved | Ticket closed without documented resolution verification |
| Post-incident review | Root cause analysis; lessons learned; control improvements identified | Post-incident review skipped for lower-severity incidents; only performed for “major” events |
Malware Protection and Environmental Controls
CC7 also covers malware protection (endpoint detection and response, email security, browser protection) and environmental controls for physical infrastructure (temperature monitoring, power redundancy, water detection). For cloud-native organizations, most environmental controls are inherited from the cloud provider — but you must document that dependency and review your cloud provider’s SOC 2 report to confirm coverage.