Monitoring under A.8.16 means watching networks, systems and applications for anomalous behaviour, and taking appropriate action to evaluate potential security incidents. Log storage does not satisfy it: A.8.15 records history, A.8.16 analyses the present. The auditor examines detection in operation, and a traceable path from alert to evaluated incident.
A.8.16 Monitoring Activities is a Technological control in ISO 27001:2022, and its wording defines the implementation closely. It names three scopes — networks, systems and applications — and sets two obligations: monitor them for anomalous behaviour, and take appropriate actions to evaluate potential information security incidents.
A.8.15 records history; A.8.16 analyses the present. Logging supplies the material to reconstruct what happened, and monitoring identifies it while it is happening. An organisation holding years of complete logs can still fail A.8.16, where nothing and nobody reads them for indicators.
The word anomalous sets the requirement. The control does not specify a fixed list of bad events; it requires deviation from normal to be noticed, which depends on having a defined picture of normal. What that involves differs by scope.
| Scope | Normal looks like | Anomalous might look like |
|---|---|---|
| Networks | Known traffic patterns between known endpoints | Traffic to destinations never previously used, volumes inconsistent with the hour |
| Systems | Expected logins, scheduled jobs, stable privilege sets | Sign-ins at unusual hours or from unusual locations, privilege changes nobody requested |
| Applications | Steady error rates, familiar usage patterns | Authentication failure spikes, query volumes far outside the usual range |
Those are illustrations rather than the control’s list, since the control carries none. The obligation is that deviation is noticed across all three scopes, as your environment defines deviation.
The second obligation converts a tool into a control: appropriate actions taken to evaluate potential incidents. Detection has to connect to a person or process that reviews the alert, determines whether it is a potential incident, and records the decision. Monitoring that ends at a dashboard satisfies the first half of the requirement only.
Log retention satisfies A.8.15 rather than A.8.16. The Stage 2 test for A.8.16 examines operating capability, in three parts.
The monitoring in operation. Not the procurement record or the architecture diagram, but the system itself, watching your environment today, with networks, systems and applications in scope. Gaps here are usually scope gaps: the network is watched and the SaaS applications are not.
A recent alert. A monitoring configuration that has never raised an alert prompts a question about whether the environment is that quiet or the thresholds are set so nothing fires. Either answer requires evidence.
What happened next. Most nonconformities sit here. For an alert that fired six weeks ago: who reviewed it, what they concluded, and where that is recorded. Without those three, the control is not operating, irrespective of the tooling. The required trail is short: alert, evaluation, decision — incident raised or the reason it was not — each step timestamped and attributable.
That trail also feeds the rest of the ISMS. Evaluated alerts are inputs to incident management, to management review, and to the internal audit that precedes the external one.
ISO/IEC 27001:2022, Annex A 8.16 states that “networks, systems and applications shall be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents.”
The two halves are joined by “and”. The first is detection across the three scopes. The second is response to what detection finds — evaluation, rather than necessarily escalation. Both halves are auditable, and the second fails more often.
| Framework | Control | How it compares |
|---|---|---|
| PCI DSS v4.0.1 | Requirement 10 — logging you can prove, every day | Combines logging and monitoring into one requirement and sets the cadence explicitly — automated log review daily, mandatory since 31 March 2025 |
| ISO 27001:2022 | Annex A 8.15 — Logging | The companion control that produces the record A.8.16 analyses |
A monitoring platform bought, connected to some log sources and marked implemented leaves alerts accumulating in an unowned queue.
The control’s wording covers this. It requires that systems are monitored and that actions are taken to evaluate, which an unattended dashboard does not do. Where the auditor selects a sample alert and asks for its evaluation, the subject of the audit is the operating loop rather than the tooling. The correction is organisational: name who triages alerts, define what an evaluation records, and verify the loop monthly as you would a backup restore. A modest tool that is operated satisfies the control.
Our SIEM capability runs as an operated loop: we monitor your networks, systems and applications for anomalous behaviour, triage what fires, and record every evaluation, so the alert-to-decision trail an auditor asks for already exists. Where Splunk, CrowdStrike or Defender is already in place, we layer over it and unify the data into one monitored stream and one set of evidence. Accountability stays where the standard places it, with you, and we perform the monitoring and supply the record.
What's the difference between A.8.15 and A.8.16?
A.8.15 covers producing and keeping event logs, which is the record. A.8.16 covers analysing what is happening now: monitoring for anomalous behaviour and evaluating potential incidents. A.8.15 can be satisfied with storage; A.8.16 requires someone or something watching.
Does A.8.16 require a SIEM?
No control names a product. The requirement is monitoring across networks, systems and applications, plus a means of evaluating what it finds. A SIEM is the usual way to do that at scale rather than the mandated one.
What counts as anomalous behaviour?
Behaviour that deviates from what is normal in your environment, which requires a working definition of normal. A login pattern, a traffic destination or an error rate that is unremarkable in one organisation can be the anomaly in another.
What evidence will the auditor ask for?
Three things, usually in this order: the monitoring in operation, a recent alert, and what happened next. The third is where audits fail, because an alert with no recorded evaluation indicates monitoring that nobody acts on.
Can we outsource the monitoring?
Yes. The control requires that monitoring happens and that potential incidents are evaluated, rather than that your own staff perform it. Accountability for the outcome stays with you, so the provider’s evaluations have to produce evidence you can give your auditor.
