Collecting logs is the easy half. The control an auditor tests is whether anyone notices when something in those logs matters, and what they do about it. A log store full of perfect events that nobody reviews satisfies the logging requirement and fails the monitoring one.
Monitoring also fails in the opposite direction. A team wires up hundreds of alerts, most of them noisy, and within a month the alert channel is muted. That leaves the same gap as no alerts, with more configuration to maintain.
This article covers what the frameworks require, which detections to build first, how to route alerts to owners, what triage records to keep, how to tune without losing coverage, and what evidence shows monitoring operated across the period.
What the frameworks require
SOC 2 CC7.2 asks you to monitor system components for anomalies that indicate malicious acts, natural disasters, and errors, and to analyze them to determine whether they are security events. CC7.3 asks you to evaluate security events to decide whether they are incidents.
ISO 27001:2022 Annex A 8.16 requires networks, systems, and applications to be monitored for anomalous behavior, with appropriate action taken to evaluate potential incidents.
PCI DSS v4.0 Requirement 10.4.1 requires security event logs and logs of critical components to be reviewed at least once daily, and 10.4.1.1 requires automated mechanisms for those reviews. Requirement 10.7 requires failures of critical security control systems to be detected, alerted, and addressed promptly.
The HIPAA Security Rule requires information system activity review at 45 CFR 164.308(a)(1)(ii)(D), and lists log-in monitoring as an addressable specification at 164.308(a)(5)(ii)(C).
NIST SP 800-53 Rev. 5 SI-4 covers system monitoring, and AU-6 covers review, analysis, and reporting of audit records.
PCI DSS is worth reading closely here, because "reviewed daily" is easy to misread as a person reading logs every morning. Requirement 10.4.1.1 expects automated mechanisms to do that review. In practice, the automated detections are the daily review, and people review what they raise. Your evidence then has two parts: that the detections ran every day across the period, and that the alerts they produced were triaged. A gap in either, such as a week where the log pipeline was broken and nothing fired, is a gap in the control.
All of these assume the logs exist. If you have not settled sources, content, retention, and protection, centralized logging for compliance comes first.
Start with detections that protect your controls
A useful first set of detections is not a catalog of every possible attack. It is a short list of events that would mean a key control has been bypassed or a privileged account misused. Each one should be specific enough that an alert means something.
| Detection | What it protects |
|---|---|
| MFA policy changed or a user excluded from it | Authentication |
| New administrator in the identity provider or cloud platform | Privileged access |
| Cloud root or break-glass account sign-in | Emergency access |
| Audit logging disabled or a log forwarder stopped | Logging itself |
| New long-lived access key for a privileged identity | Credentials |
| Storage or database made publicly accessible | Data exposure |
| Bulk export or download of customer data | Data access |
| Protection removed from a production branch | Change management |
| Malware detection on an endpoint | Endpoint protection |
| Repeated failed sign-ins followed by a success | Account compromise |
Write each detection down with an owner, the log source, the logic, the severity, and the expected response. That inventory is the first thing to show an auditor, and it makes gaps obvious when you add a new system.
Every alert needs an owner and a destination
An alert posted to a shared chat channel with no owner is a notification, not a control. For each severity, define:
Who receives it. A named on-call rotation or a named person, not a channel.
Where it is recorded. A ticketing or case system where the alert becomes a record with a status, not only a message.
How fast it is acknowledged. Set targets you can meet, for business hours and out of hours. As with any service level, the auditor will test you against what you wrote.
What happens when nobody responds. Escalation to a second person after a defined interval.
Small teams often cannot staff a round-the-clock rotation. That is a real constraint, and it is acceptable to define out-of-hours coverage for the highest-severity alerts only, as long as the policy says so.
Triage, and the record it leaves
Each alert ends in one of a few outcomes: a false positive, expected activity, or a security event that needs investigation. A security event may become an incident, at which point your incident response plan takes over.
The triage record is the evidence for SOC 2 CC7.3 and ISO 27001 Annex A 8.16. For each alert it should show:
When the alert fired and when it was acknowledged
Who triaged it
The conclusion, with a short reason
Any follow-up action, linked to a ticket
Whether it was escalated as an incident
"Closed, false positive" with no reason is weak. "Closed: new admin was added by the platform lead under change ticket 482, verified with requester" is strong, and takes the same minute to write.
Tuning without losing coverage
Noisy alerts get ignored. Tuning is necessary, and it is also the easiest way to quietly switch off a control.
Treat changes to detections like changes to code:
Suppress narrowly. Exclude a specific known-good source, not the whole detection.
Record why. Each suppression or threshold change carries a reason and an approver.
Review noisy rules on a schedule. A monthly look at the alerts that fired most often, and the ones that never fired, keeps the set honest.
Test detections. Trigger a harmless test event for key detections periodically, and keep the result. A detection that has never fired may be broken rather than quiet.
Monitoring your controls as well as your attackers
Security monitoring looks for adversary behavior. A second kind of monitoring looks for control drift: a new user without MFA, an unencrypted laptop, a storage bucket without logging. These are not attacks, but they are the gaps attackers use, and they are exactly what an auditor will sample.
Both kinds belong in the same operating rhythm: an owner, a destination, a record. They are distinct from a formal continuous monitoring program under federal frameworks, which is about ongoing authorization and risk; continuous monitoring under NIST 800-53 covers that meaning of the term.
What evidence shows monitoring operated
For a Type II report the auditor will want evidence across the period, not a demonstration on the day. Prepare:
- Not done:
The detection inventory, with owners and severities
- Not done:
Alert routing configuration and the on-call schedule
- Not done:
A population of alerts from the period, with triage records
- Not done:
Records of detection changes and suppressions, with reasons
- Not done:
Results of periodic detection tests
- Not done:
Escalations to incident response, where any occurred
The auditor may sample alerts from the population and follow each one to its conclusion. For SOC 2, this population is the core of the CC7.2 and CC7.3 evidence.
How TrustLynce helps
TrustLynce continuous monitoring runs control checks against the systems you connect and routes each failure to an owner, which covers the control-drift side of monitoring and leaves a dated record of every failure and its resolution.