Attackers don’t announce themselves. When monitoring is absent or poorly configured, adversaries dwell inside networks for weeks — sometimes months — before anyone notices. ISO 27001 control 8.16 exists to close the gap between “we log things” and “we actually catch things.” Without active monitoring, your ISMS is flying blind.
What 8.16 Requires
Control 8.16 requires organizations to continuously monitor networks, systems, and applications for anomalous behavior — and take timely action when something looks wrong. That means detecting indicators of compromise, evaluating them against defined baselines, and triggering response processes when thresholds are crossed. The control is part of the technological controls domain in ISO/IEC 27001:2022, and it applies to any organization pursuing or maintaining ISO 27001 certification.
This is active monitoring, not passive logging. The distinction matters. Logging records events. Monitoring watches for patterns that indicate something has gone wrong or is about to. You need baselines that define what normal looks like, alerting rules that fire when behavior deviates, and people or processes that respond when alerts trigger.
The scope covers the full stack: network traffic flows, system-level events, application behavior, and user activity. The requirement exists because logs sitting in storage don’t prevent breaches. Someone — or something — has to watch. The standard explicitly requires that monitoring results feed into incident evaluation and response, connecting 8.16 directly to your broader incident management process.
Why 8.16 Matters
Consider an organization that checks every compliance box for logging. Firewall logs, endpoint logs, authentication logs — all collected, all retained. But nobody is watching them in real time. An attacker compromises a single endpoint through a phishing email, moves laterally to a domain controller over three weeks, and exfiltrates sensitive data for another two weeks before an external party notifies the organization.
This isn’t hypothetical. According to Mandiant’s M-Trends 2025 report, the global median dwell time for attackers worsened from 11 days to 14 days in the latest measurement period — and when organizations relied on external notification rather than internal detection, that figure jumped to 26 days. Every additional day of dwell time expands the blast radius: more systems compromised, more data exfiltrated, more expensive to remediate.
Control 8.16 is classified as both a detective and corrective control. It modifies risk by catching attacks in progress, not just recording that they happened. The difference between an organization that detects lateral movement on day one versus day twenty-six is often the difference between a contained incident and a reportable breach — and between passing and failing a certification audit.
What Attackers Exploit
Monitoring failures create predictable attack opportunities:
- Unmonitored network segments where lateral movement goes undetected — attackers deliberately pivot through segments they know aren’t watched
- Missing baselines that prevent anomaly detection — if you haven’t defined “normal,” you can’t identify “abnormal”
- Alert fatigue from over-broad monitoring — too many alerts, all ignored, creating a perfect environment for real threats to hide in the noise
- Gaps between logging and monitoring — logs exist but nobody reviews them, giving organizations a false sense of security
- No after-hours monitoring — attacks deliberately launched when SOC coverage is offline or reduced
- Unmonitored application-layer activity — API abuse, privilege escalation within applications, and business logic attacks that network-level monitoring misses entirely
How to Implement 8.16
For Your Organization (First-Party)
Implementation starts with knowing what to monitor and works outward from there.
1. Define monitoring scope. Inventory your critical systems, networks, and applications. Not everything needs the same level of monitoring. Prioritize based on risk: internet-facing systems, systems processing sensitive data, and identity infrastructure should be at the top of the list.
2. Establish behavioral baselines. Before you can detect anomalies, you need a documented definition of normal. What does typical authentication traffic look like? What’s the normal volume of outbound data from your file servers? Baselines should be specific, measurable, and reviewed periodically as your environment changes.
3. Deploy monitoring tooling. The technology stack depends on your environment, but typically includes a SIEM platform (Splunk, Microsoft Sentinel, or similar) for log aggregation and correlation, IDS/IPS for network-level detection, EDR for endpoint visibility, and cloud-native monitoring tools (AWS CloudWatch, Azure Monitor) for cloud workloads.
4. Configure alert thresholds and escalation procedures. Define what triggers an alert, who receives it, and what happens next. Thresholds should be tuned to minimize false positives without missing real threats. Document escalation paths from initial triage through incident response.
5. Assign monitoring responsibilities. Someone needs to own this. Define who watches, who responds, and what the SLA is for each alert severity level. Monitoring without assigned ownership is monitoring that nobody does.
6. Integrate with incident response. Monitoring outputs must feed directly into your incident management process (controls 5.24 and 5.25). An alert that doesn’t trigger investigation is a wasted alert.
7. Document and review. Write down your monitoring procedures and review them at defined intervals. As your environment evolves, your monitoring must evolve with it.
8. Address privacy and legal requirements. Employee and user monitoring has legal implications under GDPR and local employment laws. Ensure your monitoring program has been reviewed for data protection compliance.
Common mistakes:
- Monitoring everything at the same priority — drowning in noise while critical alerts get buried
- Not defining what “anomalous” means before deploying tools — leading to either too many or too few alerts
- No documented escalation path from alert to investigation — alerts fire into a void
- Treating monitoring as a technology project instead of an operational process — tools deployed but never tuned or maintained
- Failing to update baselines as the environment changes — what was normal six months ago may not be normal today
For Your Vendors (Third-Party Assessment)
Your vendors’ third-party monitoring capabilities directly affect your risk. When assessing third-party monitoring, ask pointed questions and look for specific evidence.
Key questions to ask:
- “Describe your monitoring architecture and coverage scope.”
- “What is your mean time to detect (MTTD)?”
- “How do you define and update behavioral baselines?”
- “What are your SOC coverage hours?”
Evidence to request: Monitoring policy, sample alert configuration (redacted as needed), incident detection metrics over time, and documented SOC coverage hours.
Red flags: A vendor that says “we use logging” without distinguishing monitoring from log collection. No defined MTTD metric. 24/5 coverage only — attackers don’t take weekends off. No documented escalation path from alerts to incident investigation.
Verification: Request the relevant section of a SOC 2 Type II report covering monitoring controls. Ask for evidence of a recent alert investigation, including timeline from detection to resolution.
Audit Evidence for 8.16
Auditors assess whether monitoring is operational, not just documented. Prepare the following artifacts:
| Evidence Type | Example Artifact |
|---|---|
| Policy | Monitoring and Alerting Policy defining scope, responsibilities, and review cadence |
| Baseline documentation | Documented behavioral baselines for critical systems with review dates |
| Tooling configuration | SIEM/IDS deployment records showing monitored assets and alert rules |
| Alert samples | Sample alerts from the past 90 days with investigation records |
| Escalation procedures | Documented escalation matrix from alert triage to incident response |
| Coverage metrics | Dashboard or report showing monitoring coverage across in-scope systems |
| Review records | Meeting minutes or tickets from periodic monitoring effectiveness reviews |
| Privacy impact | DPIA or legal review confirming monitoring complies with data protection requirements |
The key detail auditors focus on: evidence that monitoring is active and investigated, not just configured. Showing that alerts were generated, triaged, and resolved demonstrates that the control is operating effectively.
Cross-Framework Mapping
Control 8.16 maps to monitoring requirements across major compliance frameworks. If you’re managing multiple certifications, these mappings help you demonstrate overlapping coverage.
| Framework | Control ID | Coverage |
|---|---|---|
| NIST 800-53 | AC-02(12) Account Management — Account Monitoring | Full |
| NIST 800-53 | AC-17(01) Remote Access — Monitoring/Control | Full |
| NIST 800-53 | AU-13 Monitoring for Information Disclosure | Full |
| NIST 800-53 | IR-04(13) Incident Handling — Behavior Analysis | Full |
| NIST 800-53 | MA-04(01) Nonlocal Maintenance — Logging & Review | Partial |
| NIST 800-53 | PE-06 Monitoring Physical Access | Partial |
| NIST 800-53 | PE-06(03) Monitoring Physical Access — Video Surveillance | Partial |
| NIST 800-53 | SC-07 Boundary Protection | Partial |
| NIST 800-53 | SI-04 System Monitoring | Full |
| NIST 800-53 | SI-04(04) System Monitoring — Inbound & Outbound | Full |
| NIST 800-53 | SI-04(13) System Monitoring — Analyze Traffic/Event Patterns | Full |
| NIST 800-53 | SI-04(16) System Monitoring — Correlate Monitoring Information | Full |
| SOC 2 | CC7.2 Monitoring | Full |
| CIS Controls v8.1 | Control 8 — Audit Log Management | Full |
| CIS Controls v8.1 | Control 13 — Network Monitoring and Defense | Full |
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | Full |
| DORA | Article 10 — ICT-Related Incident Detection | Full |
Related ISO 27001 Controls
Control 8.16 doesn’t operate in isolation. These controls form the monitoring ecosystem:
| Control ID | Control Name | Relationship |
|---|---|---|
| 8.15 | Logging | Monitoring depends on log data; 8.15 provides the raw input 8.16 acts on |
| 8.17 | Clock synchronization | Accurate timestamps are essential for correlating monitoring events across systems |
| 5.24 | Information security incident management planning | Monitoring feeds directly into incident detection and escalation workflows |
| 5.25 | Assessment and decision on information security events | Alerts from monitoring require triage and decision-making per 5.25 |
| 8.7 | Protection against malware | Malware detection is a primary monitoring use case |
| 8.20 | Networks security | Network monitoring is a core scope area for 8.16 |
| 8.9 | Configuration management | Configuration drift detection is a monitoring function that supports change control |
| 5.28 | Collection of evidence | Monitoring data supports forensic evidence collection during and after incidents |
Frequently Asked Questions
What is ISO 27001 8.16?
ISO 27001 8.16 is a technological control requiring organizations to continuously monitor networks, systems, and applications for anomalous behavior and respond to potential security incidents. It goes beyond passive logging by requiring active detection, defined baselines, alerting, and documented response processes.
What happens if 8.16 is not implemented?
Without monitoring activities, attackers can operate inside your network undetected for extended periods. This increases dwell time, expands the blast radius of incidents, and significantly raises the likelihood of failing an ISO 27001 certification audit.
How do you audit 8.16?
Auditors verify that monitoring tools are deployed, behavioral baselines are defined, alerts are configured and actively investigated, and monitoring coverage aligns with the organization’s risk profile. They typically request sample alerts with investigation records from the past 90 days to confirm the process is operational, not just documented.
How UpGuard Helps
Your internal monitoring program addresses what happens inside the perimeter. But what about the exposures attackers find from the outside? UpGuard’s Breach Risk product continuously monitors your external attack surface for the same class of visibility gaps that 8.16 addresses internally — misconfigured services, exposed credentials, and unpatched vulnerabilities visible to anyone scanning the internet.