SOC 223 April 2026 7 min read

SOC 2 Monitoring Requirements: CC7 Explained

CC7 requires continuous monitoring of your systems for security anomalies. Learn what monitoring controls SOC 2 auditors expect and how to implement them.

Key Takeaways

CC7.1 requires implementing detection tools to identify threats and vulnerabilities in your environment on an ongoing basis.
CC7.2 requires monitoring for anomalies and deviations from expected baselines, not just known attack signatures.
CC7.3 through CC7.5 cover incident detection, response, and post-incident review — the operational half of the CC7 cluster.
Infrastructure monitoring (CloudWatch, Datadog), security monitoring (GuardDuty, CloudTrail), and log management (centralized logging) each satisfy different aspects of CC7.
Alert fatigue is a monitoring anti-pattern: if alerts are ignored because they fire too frequently, the monitoring control is not operating effectively.

In this guide

CC7 Structure Overview
CC7.1: Detection Tools
CC7.2: Anomaly Monitoring
Log Management Requirements
Vulnerability Scanning
Alert Management and Triage
Evidence Auditors Collect

CC7 Structure Overview

The CC7 cluster contains five criteria that together address the system operations and monitoring lifecycle. CC7.1 requires ongoing monitoring using tools to detect threats, vulnerabilities, and indicators of compromise. CC7.2 requires monitoring for anomalies — deviations from normal behavior that may indicate a security issue even if they don't match a known attack pattern. CC7.3 requires evaluation of security events to identify incidents. CC7.4 addresses incident response and containment. CC7.5 addresses post-incident review and disclosure.

CC7 is the operational execution layer of your security program. Where CC6 establishes who can access what, and CC8 governs how changes are made, CC7 asks: how do you know when something is wrong, and what do you do about it? Companies that have strong access controls and change management but no monitoring infrastructure have a significant gap in their SOC 2 posture.

Most SOC 2 auditors spend significant time on CC7.1 and CC7.2 because they are the most variable criteria: the acceptable approaches range from a few cloud-native tools to a full SIEM implementation, and auditors must assess whether what you have is proportionate to your risk profile and system scope.

CC7.1: Detection Tools

CC7.1 requires that you implement controls to detect known threats and vulnerabilities. For cloud-hosted SaaS companies, the minimum detection toolkit typically includes: AWS GuardDuty (or equivalent on GCP/Azure) for cloud-native threat detection — identifying unusual API activity, compromised credentials, cryptomining, and network-level threats; CloudTrail (or equivalent) for API-level audit logging of all actions in your cloud environment; and endpoint detection and response (EDR) on developer laptops — CrowdStrike, SentinelOne, or Jamf Protect are commonly used.

Vulnerability scanning is also part of CC7.1. This includes: automated dependency scanning in your CI pipeline (Snyk, GitHub Dependabot) to detect vulnerable open-source packages before they reach production; container image scanning if you use Docker; and network vulnerability scanning if you have public-facing infrastructure beyond your application load balancer. Penetration testing (annually) supplements automated scanning with human-led adversarial testing.

The detection tools must actually be configured to alert on events. GuardDuty enabled but with no alert routing to a human (no SNS notifications, no SIEM integration, no on-call escalation path) does not satisfy CC7.1. Document the alert routing configuration for each detection tool and verify that alerts are routed to someone who triages them.

CC7.2: Anomaly Monitoring

CC7.2 addresses monitoring for deviations from expected baselines — detecting when something unusual is happening even if it doesn't match a known attack signature. Examples of anomaly-based detection: an alert when an IAM user makes more than 100 API calls in 5 minutes (potential credential stuffing or automated enumeration); an alert when CloudTrail logging is disabled (an attacker covering their tracks); an alert when a production database query volume exceeds 3× the normal baseline; and an alert when a developer logs into the production AWS console from a new country.

Establishing baselines requires operating your systems for a period and observing normal behavior patterns. CloudWatch metric alarms, AWS Config rules, and GuardDuty anomaly detection handles much of this automatically for cloud infrastructure. For application-level anomaly detection, APM tools (Datadog, New Relic, Dynatrace) with anomaly detection alerts are the standard approach.

Auditors testing CC7.2 will ask to see examples of anomaly alerts and how they were investigated. If your monitoring tools generate anomaly alerts but they route to a Slack channel that nobody monitors, the control is not operating. Show the auditor an example of an anomaly alert, the investigation record, and the disposition — this walkthrough demonstrates CC7.2 operating in practice.

Log Management Requirements

Centralized log management is foundational to both CC7.1 and CC7.2. Without centralized logs, you cannot correlate events across systems, investigate incidents effectively, or demonstrate to an auditor that your detection controls have coverage across your environment. All log sources — cloud API logs, application logs, authentication logs, network flow logs — should flow to a central aggregation point.

Common log management architectures for SOC 2: CloudTrail → S3 → CloudWatch Logs → SIEM (Splunk, Elastic, Datadog SIEM) for comprehensive coverage; CloudTrail → S3 with GuardDuty consuming the same logs for cloud-native threat detection; or a managed SIEM-as-a-service solution (Sumo Logic, Devo, Securonix) for teams without dedicated security engineering resources.

Log retention is also addressed — auditors will ask how long logs are retained. Best practice for SOC 2 is to retain security-relevant logs (CloudTrail, authentication logs, application access logs) for a minimum of 12 months, with 90 days in hot storage for rapid investigation access and the remainder in cold storage (S3 Glacier, similar). Your retention policy should be documented and the configured retention settings should match the policy.

Vulnerability Scanning

Vulnerability scanning is part of CC7.1 — identifying vulnerabilities before attackers can exploit them. The SOC 2 expectation is that you scan your systems for vulnerabilities on a regular basis and remediate findings within defined timeframes. Typical remediation SLAs: critical vulnerabilities within 30 days, high within 60 days, medium within 90 days.

For SaaS companies on AWS, Amazon Inspector provides continuous host and container vulnerability scanning. For application dependencies, Snyk and GitHub Dependabot provide automated CVE scanning on every commit and weekly full scans. For web application vulnerabilities, a DAST tool (Burp Suite, OWASP ZAP) or a dedicated application security scanner is used in addition to or instead of an annual penetration test for continuous coverage.

Document your vulnerability management process: how vulnerabilities are triaged, who owns remediation, what the SLA thresholds are, and how exceptions (accepted risks) are documented. Auditors will ask for the current open vulnerability count by severity and the average remediation time for closed vulnerabilities during the observation period. If your critical CVE remediation average is 90 days when your policy says 30 days, that gap will be noted.

Alert Management and Triage

An alert that nobody sees is not a control — it is a noise generator. Effective alert management requires: (1) routing alerts to the right people through the right channels; (2) triage processes for evaluating and prioritizing alerts; (3) documentation of alert dispositions (true positive / false positive / inconclusive); and (4) tuning processes to reduce false positive rates over time.

SOC 2 auditors assess alert management by asking to see the alert triage log for the observation period. If no alerts were triaged (either because none fired or because they were silenced), the monitoring control may be found to be operating but untested. A healthy alert log shows alerts being received, evaluated, and closed with documented rationale.

Alert fatigue — when so many low-quality alerts fire that the team stops investigating them — is a monitoring anti-pattern with direct SOC 2 implications. If your alert management log shows hundreds of ignored alerts followed by a security incident that should have been detected, auditors will have questions. Tune your alert thresholds regularly to maintain a signal-to-noise ratio where every fired alert receives human attention.

Evidence Auditors Collect

For CC7.1 and CC7.2, auditors typically request: (1) a list of monitoring tools in use with screenshots showing they are enabled and configured; (2) alert routing configuration (who receives alerts and through what channel); (3) examples of security alerts triaged during the observation period with investigation records; (4) vulnerability scan results from the observation period with remediation status; and (5) your log retention policy and configuration screenshots showing retention settings match the policy.

For the incident response criteria (CC7.3–CC7.5), auditors request incident records, post-mortem documents, and corrective action completion evidence — discussed in the incident response article. The two halves of CC7 are tested separately even though they are logically connected.

Monitoring evidence is one of the areas where compliance automation platforms add the most value. Platforms that integrate with GuardDuty, CloudTrail, and your SIEM can automatically capture alert configurations, pull periodic alert samples, and maintain a continuous monitoring log — eliminating the need to manually compile this evidence at audit time.

Frequently Asked Questions

Does SOC 2 require a SIEM?

SOC 2 does not require a dedicated SIEM (Security Information and Event Management) platform. It requires detection and monitoring capabilities proportionate to your risk profile. For small SaaS companies, cloud-native tools (GuardDuty, CloudTrail, CloudWatch, Okta System Log alerts) can satisfy CC7.1 and CC7.2 without a SIEM. As companies scale, a SIEM provides better correlation, search, and alert management capabilities that become increasingly important.

What is the minimum monitoring stack for a first SOC 2 audit?

A practical minimum stack for a cloud-hosted SaaS company: AWS GuardDuty enabled in all regions with alerts routed to a security-team Slack channel or PagerDuty; CloudTrail enabled with logs stored in S3 with 12-month retention; Okta System Log alerts for suspicious authentication events (multiple failed logins, impossible travel, new device); EDR on developer laptops; and Snyk or Dependabot for dependency vulnerability scanning. This stack, with documented alert routing and triage records, satisfies CC7.1 and CC7.2 for most first-time audits.

How long do logs need to be retained for SOC 2?

SOC 2 does not specify a mandatory log retention period. Industry standard for security-relevant logs is 12 months, with 90 days in hot storage. Your log retention policy should document the retention period for each log type and the technical configuration should match the policy. For regulated industries (healthcare, finance), longer retention may be required by other applicable regulations.

Does SOC 2 require a penetration test?

SOC 2 does not explicitly require a penetration test, but annual penetration testing is expected by most enterprise customers and auditors view it as strong evidence of CC7.1 operating. A penetration test report from a recognized security firm, along with documented remediation of findings, is one of the most compelling pieces of monitoring evidence you can present. Most SOC 2-certified companies conduct an annual penetration test as part of their security program.

We had a false-positive alert storm that we silenced. Is that a CC7 finding?

Silencing an alert without documenting the reason and implementing a proper fix is a monitoring gap. The correct process: document that the alert was identified as a false positive with a rationale, tune the alert threshold or filter to reduce false positives, and verify that the underlying condition being monitored is still covered by an alternative alert or detection mechanism. A blanket silence with no documentation suggests the monitoring control is not being actively managed.