Monitoring under A.8.16 means watching networks, systems and applications for anomalous behaviour — and taking appropriate action to evaluate potential security incidents. Storing logs isn’t enough: A.8.15 records history, A.8.16 analyses the present. The auditor wants detection running, and a traceable path from alert to evaluated incident.
A.8.16 Monitoring Activities is a Technological control in ISO 27001:2022, and it’s one of the few whose wording you can hold the whole implementation against. 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.
The useful way to place it: A.8.15 records history; A.8.16 analyses the present. Logging gives you the material to reconstruct what happened. Monitoring is the discipline of noticing while it’s still happening. An organisation can hold years of immaculate logs and still fail A.8.16, because nothing and nobody is reading them for trouble.
“Anomalous” does real work in that sentence. The control doesn’t ask you to watch for a fixed list of bad events — it asks you to notice deviation from normal, which means you need a working picture of normal first. What that looks like differs by scope:
| Scope | Normal looks like | Anomalous might look like |
|---|---|---|
| Networks | Known traffic patterns between known endpoints | Traffic to destinations you’ve never sent data to, volumes that don’t match the hour |
| Systems | Expected logins, scheduled jobs, stable privilege sets | Sign-ins at odd hours or from odd places, privilege changes nobody requested |
| Applications | Steady error rates, familiar usage patterns | Authentication failure spikes, query volumes far outside the usual range |
Those are illustrations, not the control’s list — the control doesn’t carry one. The obligation is that deviation gets noticed across all three scopes, however your environment defines it.
The second obligation is the one that turns a tool into a control: appropriate actions taken to evaluate potential incidents. Detection has to connect to a person or process that looks at the alert, decides whether it’s a potential incident, and records the decision. Monitoring that ends at a dashboard satisfies half the sentence.
“We keep all our logs. Isn’t that monitoring?” It’s the most common objection, and the answer is no — that’s A.8.15. The auditor testing A.8.16 at Stage 2 is after something live, and the request usually comes in three parts.
Show me the monitoring running. Not the procurement record or the architecture diagram — the thing itself, watching your environment today, with your networks, systems and applications in scope. Gaps here are usually scope gaps: the network is watched, the SaaS applications aren’t.
Show me a recent alert. A monitoring setup that has never raised an alert invites a hard question: is your environment that quiet, or are the thresholds set so nothing ever fires? Either answer needs evidence.
Show me what happened next. This is where most nonconformities live. An alert fired six weeks ago; who looked at it, what did they conclude, where is that written down? If the honest answer is “nobody, nothing, nowhere”, the control isn’t operating — whatever the tooling cost. The trail you want is short and boring: alert, evaluation, decision — incident raised or reason it wasn’t — each step timestamped and attributable.
That trail also feeds the rest of your ISMS. Evaluated alerts are inputs to incident management, to management review, and to the internal audit that happens before the external one. Build the record once and it evidences four things at once.
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.”
Read it as two halves joined by “and”. The first half is detection — the three scopes, watched for deviation. The second half is response to what detection finds — evaluation, not 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 | Folds 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 |
The mistake is treating A.8.16 as a purchase. A monitoring platform gets bought, connected to some log sources, and the control is marked implemented — while alerts accumulate in a queue nobody owns.
The control’s grammar catches this. It doesn’t say monitoring shall be installed; it says monitored, and actions taken to evaluate. An unwatched dashboard takes no actions. When the auditor pulls a sample alert and asks for its evaluation, the tooling investment is irrelevant — what’s being audited is the operating loop around it. The correction is organisational, not technical: name who triages alerts, define what an evaluation records, and check the loop monthly the way you’d check a backup restore. A modest tool that’s genuinely operated passes; an expensive one on autopilot doesn’t.
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 your auditor asks for already exists. Already have Splunk, CrowdStrike or Defender? We layer over it and unify the data — one monitored stream instead of four consoles, and one set of evidence. You keep the accountability the standard puts on you; we do the watching and hand you the record.
What's the difference between A.8.15 and A.8.16?
A.8.15 is about producing and keeping event logs — the record. A.8.16 is about analysing what’s happening now — monitoring for anomalous behaviour and evaluating potential incidents. You can satisfy A.8.15 with storage; A.8.16 needs someone, or something, watching.
Does A.8.16 require a SIEM?
No control names a product. You need monitoring across networks, systems and applications and a way to evaluate what it finds. A SIEM is the usual way to do that at any scale, not the mandated one.
What counts as anomalous behaviour?
Behaviour that deviates from what’s normal in your environment — which means you need a working idea of normal first. A login pattern, a traffic destination or an error rate that’s unremarkable in one organisation can be the anomaly in another.
What evidence will the auditor ask for?
Three things, usually in this order: show me the monitoring running, show me a recent alert, show me what happened next. The third is where audits go wrong — an alert with no recorded evaluation reads as monitoring that nobody acts on.
Can we outsource the monitoring?
Yes. The control requires that monitoring happens and that potential incidents get evaluated — not that your own staff do it. You stay accountable for the outcome, so make sure the provider’s evaluations produce evidence you can hand to your auditor.
