CC7 — System Operations — is where security operations and SOC 2 compliance converge. The controls required for CC7 — continuous monitoring, vulnerability management, and incident response — are the controls that protect the organization in practice, not just on paper. Organizations that build genuine operational security practices satisfy CC7 as a natural byproduct; those that implement controls purely for audit purposes find that the evidence trail is thin and unconvincing.
SIEM Architecture for SOC 2
A SIEM (Security Information and Event Management) platform is the centerpiece of CC7 monitoring. SOC 2 does not mandate a specific SIEM, but requires that logs from in-scope systems are collected, that alert rules are defined for relevant security events, that alerts are reviewed and acted upon, and that the disposition of each alert is documented.
| Log Source | Why It Is In Scope for CC7 | Key Events to Alert On |
|---|---|---|
| Identity provider / SSO | Authentication events are the primary indicator of unauthorized access attempts | Failed MFA, successful login from new location/device, account lockout, privilege escalation |
| Cloud infrastructure (AWS CloudTrail, Azure Activity Log, GCP Audit Logs) | Infrastructure API calls reveal unauthorized configuration changes, resource creation/deletion, and IAM modifications | Root account login, IAM policy changes, security group modifications, S3 bucket policy changes |
| Production application logs | Application-layer events that may indicate account compromise, data exfiltration, or injection attacks | High-volume data exports, admin function access, error rate spikes, authentication failures |
| Endpoint protection / EDR | Malware detection, suspicious process execution, and lateral movement indicators on in-scope endpoints | Malware detection, blocked execution, process injection, credential dumping |
| Network monitoring | Unusual traffic patterns that may indicate data exfiltration or command-and-control communication | Anomalous outbound traffic, large data transfers, connections to known malicious IPs |
Alert Rules and Response Playbooks
Effective security monitoring requires not just a SIEM with log ingestion, but well-tuned alert rules and defined response playbooks. Alert rules that fire too broadly generate alert fatigue — a common situation where the volume of alerts is so high that individual alerts are not investigated. Alert rules that are too narrow miss real incidents. Building and maintaining effective alert rules requires ongoing tuning based on the organization’s specific environment and threat profile.
For each alert rule, a corresponding response playbook defines what action should be taken when the alert fires: who is notified, what initial investigation steps are required, what criteria distinguish a false positive from a real incident, and what actions are taken in each case. Response playbooks convert alert rules into actionable, auditable processes.
| KEY IDEA | Auditors will pull a sample of alerts from the observation period and ask: what happened after this alert fired? If the answer is “the alert went to an inbox and no action was recorded,” that is a CC7 exception. The evidence auditors look for: alert notification, investigation action (even if it concludes the alert was a false positive), and disposition record with timestamp and analyst name. |
Incident Classification and Register
Every security event that rises above the threshold of “alert” to “incident” must be formally recorded in the incident register. The incident register is one of the most important evidence artifacts in a Type II audit — auditors will review the entire register for the observation period and sample individual incidents for detailed testing.
The incident register should capture: incident ID, date/time of detection, date/time of reporting, severity classification, brief description, affected systems, root cause (where determined), response actions taken, resolution date/time, and post-incident review reference. GRC platforms and ticketing systems (Jira, ServiceNow, PagerDuty) can serve as incident registers if configured with the required fields.
| IMPORTANT | Every security alert that was escalated to incident status must appear in the incident register. Auditors will compare the SIEM alert history to the incident register. If they find alerts that appear to have been incidents — extended response, multiple team members involved, system changes made — but are not in the incident register, they will question the completeness of incident management controls. |
Post-Incident Review
CC7 requires that after incidents are resolved, a post-incident review is conducted to identify root cause, lessons learned, and any control improvements. For significant incidents (Severity 1 and 2), a formal post-mortem document with root cause analysis, timeline, contributing factors, and action items is expected. For lower-severity incidents, a brief documented review noting root cause and any follow-up actions may suffice.
Post-incident reviews are frequently skipped for incidents that were resolved quickly or are perceived as minor. Auditors will sample post-incident review completion rates and note if the pattern suggests selective review (only for major incidents). The discipline of completing a brief review for every incident — even a one-paragraph root cause note — demonstrates systematic incident management.
Incident Response Timeframes
| Severity Level | Definition | Response Time SLA | Resolution SLA |
|---|---|---|---|
| Critical (P1) | Active compromise, data breach, or system unavailability affecting clients | Immediate — on-call response within 15 minutes | Containment within 4 hours; full resolution within 24 hours |
| High (P2) | Confirmed threat actor activity, significant vulnerability exploited, or service degradation | Response within 1 hour | Containment within 8 hours; resolution within 48 hours |
| Medium (P3) | Suspicious activity requiring investigation, vulnerability with active exploit, or minor service impact | Response within 4 business hours | Resolution within 7 days |
| Low (P4) | Informational security events, low-risk vulnerabilities, policy violations without data impact | Acknowledgment within 1 business day | Resolution within 30 days |