SOC 2 · Trust Services Criteria · 2 min read

SOC 2 CC7.2: anomaly monitoring, explained for startups

What CC7.2 asks you to show about anomaly monitoring, and what proves it.

You watch your systems for signs of attack, failure or error. Logs are collected in one place, alerts fire on suspicious activity, and someone reviews them. An auditor wants to see an alert and what happened next.¹

CC7.2 is a common criterion, so it is part of every SOC 2 report.

What usually proves it

An auditor wants records from the period being examined, pulled from the systems that hold them rather than written up afterwards. Dates matter. A record with a date and a named owner carries more weight than a screenshot with neither. For CC7.2, the usual records are these.

Centralized logging configuration
Alert rules and examples of alerts that fired
Log review records

What Polara asks about it

The free readiness assessment asks 5 questions that bear on CC7.2. A yes becomes a task to show the proof. A no becomes a task to fix the gap, with the steps written out.

Centralized log collection for app and infrastructure? If yes, show it: Datadog log dashboard, CloudWatch Log Groups list, security information and event management (SIEM) ingest view, or log pipeline configuration screenshot. If no, the fix: route application and infrastructure logs to a central logging service and export the ingestion configuration.
Admin/operator activity logged and reviewed weekly? If no, the fix: schedule a weekly review of administrator activity logs and retain the review record.
Alerting configured for security events? If yes, show it: PagerDuty service with security alerts, Datadog monitor list, alert routing policy, or on-call schedule screenshot. If no, the fix: configure alerts for authentication failures, privilege changes, and other security events, and export the alert rules.
Capacity and uptime monitored? If yes, show it: Datadog infrastructure dashboard, CloudWatch alarms, capacity trend report, or uptime monitoring dashboard. If no, the fix: configure capacity and uptime monitoring with alert thresholds and export the dashboard or alert rules.
Security events logged with severity, date, and status? If yes, show it: incident ticket template, PagerDuty incident list, incident Slack channel log, or post-incident review record. If no, the fix: record every security event in a tracker with severity, date, and status fields.

Policies, templates and connected evidence

A policy states the rule, a template gives you the record to keep, and a connected system pulls the proof from the source. An auditor checks that the three agree: the cadence in the policy, the dates in the record and what the system shows.

In the policy pack, the Operations Security Policy and Information Security Policy cover CC7.2.

Free templates that help, printed in full with Word, PDF or Excel downloads:

Connected systems that pull evidence for it:

Amazon Web Services, CloudTrail trails: audit log configuration per region.
Amazon Web Services, CloudWatch alarms: security-relevant monitoring alarms per region.
Amazon Web Services, AWS Config recorders: whether AWS Config records configuration changes in each region.
GitHub, Organization audit log: audit log entries for organization admin actions, on Team and Enterprise plans.
Google Cloud, Audit logs configuration: cloud Audit Logs configuration per project, covering admin read and data access log types.
Google Cloud, Logging sinks: log sinks per project, with their export destinations and filters.
Google Workspace, Login audit: login activity over the last 30 days.
Google Workspace, Admin audit: admin console actions over the last 30 days.
Okta, System log summary: counts of system log events by type over the collection window, never the message bodies.

If you also run ISO 27001, the Annex A controls A.8.15, logging, A.8.16, monitoring for anomalies and A.8.17, clock synchronization ask for overlapping evidence. One record can serve both when it names what it proves.

Where it goes wrong

One gap a remediation playbook covers here is vulnerability Scanning. The fix: deploy a scanner and configure it to scan production assets. The proof: screenshot or export showing scanner configured with target assets and schedule.

An auditor asks two things about it. Is there a documented process for vulnerability scanning? Is a scanning tool deployed and configured to scan production?

Is it in your scope?

Yes, always. CC7.2 is one of the 33 common criteria, and the common criteria are in every SOC 2 report, Type 1 or Type 2. The common criteria. Every SOC 2 report covers them, whatever else you add: governance, risk, access, operations, change and vendors. Most of the work in any SOC 2 sits here.

Polara Labs is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

System operations: the criteria around it

CC7.2 is one of 5 criteria in system operations, CC7.1 to CC7.5. Reading a group together shows how its outcomes fit, and one record often serves more than one of them.

Before it: CC7.1, vulnerability monitoring. After it: CC7.3, incident triage. All the criteria are on the Trust Services Criteria page, grouped by category.

Questions

What does SOC 2 CC7.2 ask a startup to show?

What evidence proves CC7.2?

The usual evidence is centralized logging configuration, alert rules and examples of alerts that fired and log review records. An auditor tests it across the report period, so dated records matter more than a written promise.

Sources

TSP Section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy AICPA. The criteria themselves, including the common criteria every SOC 2 report covers.

Get audit-ready without a compliance team.

The readiness assessment is free, with no payment and no card. Star is $2,000 one time to get on the platform and close your gaps. Orbit is $7,800 a year, and your SOC 2 Type 2 audit is included in every contract year. You can be audit-ready starting at about a week.

Take the free assessment