ISO 27001 A.8.16: Monitoring Activities

ISO 27001 A.8.16 requires that networks, systems, and applications are monitored for anomalous behavior and that potential security incidents are evaluated as they surface. It is a Technological control (A.8), new in the 2022 revision, and the action teams often get flagged on is documenting what happened after an alert fired, rather than deploying the monitoring tooling itself. A dashboard full of cleared alerts with no triage record behind them is a common A.8.16 gap.

What is ISO 27001 A.8.16?

ISO 27001 A.8.16 Monitoring activities governs the active watching of networks, systems, and applications for behavior that signals a potential security incident. Paraphrasing the intent attributed to ISO/IEC 27001:2022, Annex A: the organization monitors its environment for anomalous behavior, establishes what normal looks like so deviations stand out, and evaluates the events that monitoring produces to decide whether they represent an incident. A.8.16 is one of the controls introduced in the 2022 revision. It did not exist as a standalone control in the 2013 standard, where monitoring was implied inside the logging and network controls rather than named on its own.

A.8.16 is the watching-and-alerting control, and it is deliberately separated from A.8.15 Logging in the 2022 structure. Logging records what happened. Monitoring watches the recorded signal in near-real time, raises an alert when something looks wrong, and puts a human decision behind that alert. A.8.16 is also upstream of the incident controls in the Organizational theme: the alerts it produces feed the assessment and response process defined in A.5.24, A.5.25, and A.5.26. Monitoring generates the signal; the incident controls decide and act on it.

How do you implement A.8.16?

Implementing ISO 27001 A.8.16 is a sequence a team can follow to turn raw telemetry into a monitored, evidenced control. Each step produces an artifact an auditor can later sample.

1. Baseline normal behavior. Establish what typical looks like for the environment: normal authentication patterns, expected network flows, standard process and API activity, and routine administrative actions. Anomaly detection is only meaningful against a defined baseline, and the baseline is what lets a deviation stand out instead of drowning in noise.
2. Define what to monitor. Decide the systems, networks, and applications in scope and the specific behaviors worth watching: failed and impossible-travel logins, privilege escalation, unexpected outbound connections, malware detections, configuration changes, and data movement out of the environment. A monitoring scope that is not written down is a monitoring scope an auditor cannot confirm.
3. Set alerting thresholds. Translate the monitored behaviors into alert rules with thresholds that fire on real signal without burying the team. Thresholds are the tuning knob that separates a monitoring program from a noise generator, and they are set deliberately rather than left at tool defaults.
4. Integrate detection tooling. Wire the detection sources into a single destination for alerts: a SIEM, a managed detection service, or a monitoring console. Every source, cloud provider logs, IDS, EDR, and application telemetry, needs a path into one queue. A source that drops alerts into a mailbox nobody watches is not integrated.
5. Triage and document alert dispositions. Every alert that warrants investigation gets a case with a timestamp, the triggering alert, the observables reviewed, and the conclusion, even when the conclusion is no action needed. Documented disposition is what converts monitoring into an operating control, and it is the evidence A.8.16 turns on.
6. Tune to reduce noise. Review alert volume on a cadence, suppress the false positives, and adjust thresholds so the signal that reaches a human is worth the human's time. A program that is not tuned drifts into alert fatigue, and alert fatigue is how a real detection gets cleared without a look.

Steps 4 and 5 depend on where the detection signal comes from, and that differs between cloud and on-prem environments. The two subsections below cover each.

In cloud environments

Cloud environments implement A.8.16 through provider-native detection services feeding a managed or cloud-hosted SIEM:

• Managed threat detection such as AWS GuardDuty, Microsoft Defender for Cloud, or Google Cloud IDS analyzes provider telemetry and raises findings without a self-run collection stack.
• Cloud-native log analytics and SIEM, whether a managed service or a hosted platform, aggregate provider logs and application telemetry into one place where alert rules run.
• Provider anomaly detection on identity and API activity flags impossible-travel logins, unusual privilege use, and anomalous API call patterns against a provider-maintained baseline.
• Native alerting and notification pipelines route findings into the triage queue and a ticketing system, so a cloud finding becomes a documented case rather than a dashboard entry.

On-prem / self-hosted

On-prem environments reach the same monitoring outcomes through tooling the team runs and evidences itself. The SOC 2 incident response for on-prem environments guide covers the self-hosted detection stack in depth; the shape is:

• A self-run SIEM such as Splunk or Wazuh aggregates host, network, and application logs and runs the correlation and alert rules the team defines.
• A self-operated IDS or network monitoring platform such as Security Onion running Zeek and Suricata watches critical traffic paths for anomalous behavior.
• A network operations center or on-call rotation provides the human watch that reviews alerts and starts triage, since there is no managed service doing it in the background.
• Endpoint detection tooling feeds process and host telemetry into the same queue, closing the gap self-run SIEMs handle less cleanly on their own.

Cloud vs on-prem at a glance

What evidence demonstrates A.8.16?

Evidence for ISO 27001 A.8.16 is paired: a configuration artifact showing monitoring is set up, plus a triage record showing alerts are evaluated and dispositioned. Teams that wire triage cases and tooling configuration exports into their evidence store automatically, rather than assembling screenshots each audit, spend far less time here; that evidence-automation approach is what GRC engineering covers.

How does A.8.16 map to SOC 2?

ISO 27001 A.8.16 is a Full overlap with SOC 2 CC7.2. Organizations with an existing SOC 2 program can reuse the same monitoring and triage evidence for the ISO 27001 certification audit with no adaptation.

CC7.2 is the anomaly-monitoring criterion, and it maps to the same trio of ISO controls that separate recording from watching: A.8.15 Logging, A.8.16 Monitoring activities, and A.8.17 Clock synchronization. A team that has built its SOC 2 monitoring evidence for CC7.2 has already produced the A.8.16 artifacts. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across every criterion.

Related controls

ISO 27001 A.8.16 stands between the logging control that feeds it and the incident controls it feeds. A.8.15 Logging records the events that monitoring watches: A.8.15 produces the log, A.8.16 raises the alert. On the incident side, the alerts A.8.16 generates flow into A.5.24 incident management planning and preparation, which defines the plan and triage queue, then into A.5.25 assessment and decision on security events and A.5.26 response to information security incidents. The ISO 27001 certification guide is the hub for how these controls fit into a full ISMS.

Part of Truvo's control-by-control ISO 27001 Annex A reference series. Start from the ISO 27001 certification guide for the full picture. If you are implementing A.8.16 as part of an effective security program and want a second set of eyes on the design, Truvo offers scoping calls.

Frequently Asked Questions

What is ISO 27001 A.8.16?

ISO 27001 A.8.16 Monitoring activities is a Technological control in Annex A of ISO/IEC 27001:2022. It requires that networks, systems, and applications are monitored for anomalous behavior and that potential security incidents are evaluated as they arise. It covers baselining normal behavior, defining what to monitor, setting alert thresholds, integrating detection tooling, and triaging alerts with documented dispositions. It was introduced in the 2022 revision as a control in its own right.

Is A.8.16 new in ISO 27001:2022?

Yes. A.8.16 Monitoring activities is one of the controls introduced in the 2022 revision of ISO 27001. It did not exist as a standalone control in the 2013 version, where monitoring expectations were implied inside the logging and network security controls. The 2022 revision named monitoring as its own Technological control to separate active watching and alerting from the passive recording that logging covers.

How is A.8.16 different from A.8.15 logging?

A.8.15 Logging records what happened; A.8.16 Monitoring activities watches that recorded signal and alerts on anomalies. Logging produces the log data, the audit trail an investigator reads after the fact. Monitoring runs detection rules against that data in near-real time, raises an alert when behavior deviates from the baseline, and puts a documented human decision behind the alert. A team needs both: logging without monitoring is a record nobody watches, and monitoring without logging has nothing to watch.

What evidence satisfies A.8.16?

A.8.16 evidence is paired: a configuration artifact plus a triage record. Auditors expect monitoring scope documentation, alert rule and threshold configuration, detection tooling configuration for the SIEM, IDS, or managed detection service, an alert triage case log covering the observation period, tuning and false-positive review records, and escalation records for confirmed incidents. The triage case log is what demonstrates the control operates over time rather than existing only as deployed tooling.

How do you implement A.8.16 in the cloud versus on-prem?

Cloud implementations use provider-native detection: managed threat detection such as GuardDuty, Defender for Cloud, or Cloud IDS, a cloud-native or managed SIEM for aggregation, provider anomaly detection on identity and API activity, and native alert routing into the triage queue. On-prem implementations reach the same outcomes with a self-run SIEM such as Splunk or Wazuh, a self-operated IDS such as Security Onion, a NOC or on-call rotation providing the human watch, and endpoint tooling feeding the same queue. The detection sources differ; the triage discipline and evidence are the same.

How does A.8.16 map to SOC 2 CC7.2?

A.8.16 maps to SOC 2 CC7.2 as a Full overlap. Both address monitoring system components for anomalous behavior and evaluating the events monitoring produces. Evidence generated for CC7.2, including SIEM alert evidence, infrastructure monitoring dashboards, alerting configuration, and the alert triage case log, is reusable for the ISO 27001 A.8.16 requirement without adaptation. CC7.2 maps to A.8.15, A.8.16, and A.8.17 together.