ISO 27001 A.8.16 - Monitoring Activities

Requirement

“Networks, systems and applications shall be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents.”

Plain-language meaning

The organization should actively watch important technology environments for signs that something abnormal or suspicious is happening. Monitoring should help detect possible attacks, misuse, compromise, lateral movement, service abuse, and unusual system behaviour early enough for people to investigate and respond.

This is not the same as simply collecting logs. A.8.15 Logging is about producing, storing, protecting, and analysing log records. A.8.16 is about turning available signals into risk-based detection, alerting, triage, escalation, and incident evaluation.

Why this matters

Attackers rarely announce themselves clearly. They create patterns: failed logons, unexpected successful logons, unusual data transfers, privilege changes, endpoint alerts, strange process behaviour, new connections, or activity outside normal hours.

Monitoring helps the organization detect those patterns before they become major incidents. Poor monitoring creates blind spots. Excessive noisy monitoring creates alert fatigue, where real attacks are missed because the team is overwhelmed.

Implementation guidance

1. Define what must be monitored

Identify monitoring scope from Risk Assessment, asset criticality, business impact, interested-party requirements, and the Statement of Applicability. Typical scope includes:

• networks and internet-facing services;
• identity systems and privileged access paths;
• endpoint and server security events;
• cloud control planes and SaaS administration;
• business-critical applications and databases;
• security tools such as EDR, IDS, IPS, WAF, and DLP;
• backup, logging, and monitoring infrastructure itself.

2. Convert risks into detection use cases

Each significant threat scenario should lead to one or more detection use cases.

3. Map use cases to data sources

For each detection use case, identify the log, alert, telemetry, or sensor source that can prove it. Do not assume a monitoring tool covers everything. Some systems may not generate the needed telemetry, may require configuration changes, or may need indirect detection through network, identity, or application logs.

4. Tune rules and thresholds

Monitoring should use thresholds that reflect risk appetite and operational context. One failed login may be normal. Ten failed logins in five seconds followed by a success from the same source is more suspicious.

Thresholds should be reviewed after false positives, missed detections, incidents, system changes, and threat intelligence updates.

5. Define triage, escalation, and out-of-hours response

Monitoring only works if alerts lead somewhere. Define:

• who reviews alerts;
• how potential incidents are assessed;
• when events become incidents under A.5.25 Assessment and Decision on Information Security Events;
• how response starts under A.5.26 Response to Information Security Incidents;
• who is contacted outside working hours;
• how evidence is preserved under A.5.28 Collection of Evidence.

6. Review effectiveness

Monitor the monitoring process itself. Track alert volume, false positives, missed detections, stale rules, source coverage, escalation time, and lessons learned from incidents.

Audit guidance

Auditors should verify:

• monitoring scope is based on risk and critical assets;
• detection use cases are defined for relevant threats;
• alerts are traceable to configured rules and data sources;
• monitoring covers required networks, systems, applications, cloud services, and security tools;
• blind spots are known, justified, and risk-treated;
• thresholds are tuned and reviewed;
• alerts are triaged and escalated consistently;
• detected incidents are handled through the incident management process;
• alert fatigue is monitored and managed;
• out-of-hours alert handling is defined and tested where relevant;
• monitoring performance is reviewed and improved.

Auditors should sample detected alerts and ask what happened next. A closed alert should have a reason. A true positive should link to an event decision, incident response record, corrective action, or lessons learned.

Evidence examples

Strong evidence

• Detection use cases trace to risk scenarios and critical services.
• Monitoring sources cover identity, endpoints, servers, networks, cloud, applications, and security tools where relevant.
• Alert thresholds are tuned and periodically reviewed.
• Alerts show triage decisions and escalation where needed.
• True positives link to incident records and corrective actions.
• Blind spots are documented with compensating controls or risk acceptance.
• Out-of-hours escalation has named contacts and test evidence.

Weak evidence

• A SIEM exists but default rules are not reviewed.
• Alerts are generated but no one owns triage.
• Monitoring covers perimeter devices only and misses identity, cloud, or endpoints.
• Thresholds create constant noise and ignored alerts.
• No one can explain what an alert means or what action follows.
• Out-of-hours alerts depend on informal personal contact.
• Monitoring rules are not updated after incidents or environment changes.

Common failures

Exam traps

Related controls and concepts

• A.8 Technological Controls MOC
• A.8.15 Logging
• A.8.7 Protection Against Malware
• A.8.8 Management of Technical Vulnerabilities
• A.8.12 Data Leakage Prevention
• A.5.24 Information Security Incident Management Planning and Preparation
• A.5.25 Assessment and Decision on Information Security Events
• A.5.26 Response to Information Security Incidents
• A.5.27 Learning from Information Security Incidents
• A.5.28 Collection of Evidence
• Risk Assessment
• Statement of Applicability
• Logging and Monitoring Standard
• Monitoring Detection Use Case Register
• Monitoring Coverage and Data Source Map
• Monitoring Alert Threshold Review
• Out-of-Hours Monitoring Escalation Checklist
• A.8.16 Audit Evidence Pack
• A.8.16 Audit Checklist

KB-ready summary

• Define monitoring from risk and critical assets.
• Map each detection use case to a data source.
• Tune alert thresholds to reduce noise and missed detections.
• Connect alerts to event assessment and incident response.
• Review blind spots, false positives, out-of-hours response, and monitoring effectiveness.

Templates and checklists

• Monitoring Detection Use Case Register
• Monitoring Coverage and Data Source Map
• Monitoring Alert Threshold Review
• Out-of-Hours Monitoring Escalation Checklist
• A.8.16 Audit Checklist