Noticing, before someone else does.
CC7.2 is the SOC 2 criterion about monitoring: detecting anomalies and security events so you can respond to them. It sits on top of logging, a log records that something happened, monitoring is what notices and raises a hand. A control you cannot see operating is a control you cannot respond to, which is why detection has its own criterion.
The shapes the same control failure takes.
CC7.2 weakens when a change quietly shrinks what the system can notice. The recurring shapes:
An alert rule is deleted
A rule that fired on a security condition (a spike in failed logins, an unexpected privilege grant) is removed because it was noisy, taking the detection with it.
A threshold is loosened
An alert's threshold is raised so far that the anomaly it was meant to catch no longer trips it, leaving the rule present but effectively blind.
A metric stops being emitted
Instrumentation that fed a dashboard or alert is removed, so the thing being watched goes dark even though the alert still exists.
Coverage does not follow new surface
A new service, endpoint, or path ships with no monitoring, so a whole area of the system is unwatched by default.
A detection is disabled
Anomaly detection or a security monitor is turned off (a feature flag, a commented-out check) to cut noise, and never turned back on.
An alert on failed-login spikes, removed.
An alert that fires when failed logins spike has been paging people during load tests, so a change deletes it from the monitoring config. The noise stops, and so does the only automated way the team would notice a brute-force attempt in production.
groups:- - alert: FailedLoginSpike- expr: rate(auth_failures_total[5m]) > 20- for: 2m- labels: { severity: security }This removes the detection for a spike in failed logins, the signal you would want if someone were brute-forcing an account. CC7.2 expects the system to monitor for and detect anomalies like this. If it is too noisy, tune the threshold or route it away from paging, but keep the detection rather than deleting it.
Monitoring is checked as a capability, not a promise.
An auditor looks for evidence that you actually detect and respond to anomalies: the alerts that exist, that they fire, and that someone acts when they do. A change that deleted a security alert or quietly blinded a metric is the gap behind a claim that you monitor. It shows up in the diff to the monitoring config, which is the cheapest place to catch it.
A review, not your monitoring stack.
heygrc flags changes that touch CC7.2 and cites the criterion so the fix happens in the pull request. It does not run your alerting or your incident response. It catches the moment a detection is removed or blinded, at the diff. heygrc is in early access.