ISO 27001 Annex A 8.16: monitoring activities that pass audit

The enterprise questionnaire asks how you would know if you had been breached, and how fast. Your honest answer is "we'd check the logs if something seemed off". That answer fails the question, and it fails ISO 27001 Annex A 8.16 as well.

This guide is for security leads, heads of IT and compliance managers at UK firms of 25 to 250 staff. It shows what the control requires, how to meet it with tooling you already own, where UK GDPR limits what you may watch, and which evidence auditors sample.

What do ISO 27001 Annex A 8.16 monitoring activities require?

ISO 27001 Annex A 8.16 requires you to watch networks, systems and applications for unusual behaviour, evaluate what you see, and respond when something looks wrong. It is the active half of detection: knowing what normal looks like, spotting departures from it, and routing them to an incident decision. Retaining logs alone does not satisfy it.

The control exists because preventive layers fail. The NCSC guidance on building a Security Operations Centre describes the purpose of monitoring as detecting and responding to attacks that successfully bypass preventive controls. An intruder who goes unnoticed for weeks exfiltrates more, spreads further and leaves a harder clean-up.

The commercial stake is just as direct. Cyber insurance proposals ask the same question as the enterprise questionnaire, in near-identical words, and a vague answer fails there too.

Scope is wider than any single tool. Networks, systems, applications, admin actions and the outputs of your security tooling all fall inside what you decide to watch.

The control is detective first, because it surfaces hostile activity that preventive layers missed. It is also corrective, because the requirement does not stop at the alert: evaluating, escalating and responding to what fires are part of the control.

It protects confidentiality, integrity and availability, because the activity you watch for spans data leaving, data being altered and systems being degraded.

How does A.8.15 logging differ from A.8.16 monitoring?

A.8.15 covers capturing and retaining event records; A.8.16 covers someone, or something, reading them. Logs sitting in storage with no alerting fail A.8.16 because nothing detects an attack as it happens. The NCSC calls logging the foundation on which security monitoring is built, and auditors test the two separately.

The NCSC guidance on logging for security purposes treats the next step after logging as searching what you have collected for known threats. It is candid that this takes further investment in people, skills and business processes. That is the cost A.8.16 adds, so plan for it when you scope the control.

ISO 27001 A.8.16 sits directly on top of A.8.15, so logging coverage comes first. If a source never reaches your log platform, no rule can fire on it, and no later tuning recovers the missing visibility.

Two mistakes follow when teams treat the pair as one control:

• Hoarding telemetry with no alerting on top. Storage cost is at its maximum, detection is zero, and the capacity bill arrives before the security benefit does.
• Pointing at the logging stack when asked about monitoring. A.8.15 evidence, such as retention settings and log source lists, does not answer an A.8.16 question.

Answer the monitoring question with the rule that fired, the person who picked it up and what they decided. That shows detection, which a retention screenshot cannot.

What lawful basis do you need before monitoring staff under UK GDPR?

Before enabling monitoring of staff endpoints, traffic or communications, you must identify a UK GDPR lawful basis, such as legitimate interests, and tell workers what is observed. The ICO expects workers to be told about any monitoring, apart from rare, justified covert cases. Document the decision with your data protection lead and keep it as audit evidence.

The ICO guidance on monitoring workers is direct: there are six lawful bases to choose from, and you must identify at least one. Legitimate interests is the most flexible, but the ICO warns it may not fit monitoring that workers would not understand or reasonably expect. It also needs a three-part test: a real purpose, processing that is necessary for it, and a balance against workers' rights.

A monitoring control built without a lawful basis swaps a security finding for a privacy breach.

Work through these steps before enabling any rule:

1. Define what you observe. Name the endpoints, traffic, communications and admin actions in scope.
2. Choose the basis. Select at least one of the six and record why it fits your purpose.
3. Write the notice. Tell workers in the privacy notice what is observed, why, and for how long records are kept.

Settle the legal boundary at the same moment as scope, not after a complaint. If the answer lives in someone's head, the first audit question about it is already lost.

Do you need a SIEM to meet A.8.16 at 25–250 staff?

No. At 25–250 staff, detection features already in your stack (Microsoft Defender, Google Workspace alerting, AWS GuardDuty, a small Microsoft Sentinel deployment, EDR consoles) cover most of A.8.16. The standard cares that watching happens and leads somewhere, not which product does it. A dedicated SIEM earns its place only when telemetry volume outgrows native tools.

Start from what you already pay for. The work is switching on the right detections, pointing them at an owned destination and writing down what you watch. The table below shows what each option catches and the evidence it leaves.

A SIEM is a scaling decision, not a compliance one. Buy it when telemetry volume and team size outgrow the native consoles. At that point, correlating many sources in one place saves more time than it costs to run.

Whichever route you take, lock down the monitoring platform itself:

• Least-privilege access, so only the people who run detection can change rules.
• MFA on every account that can reach the console.
• Log storage the watched cannot edit, kept apart from the systems and users it records.

If the people being watched can edit the records, the findings prove nothing.

Broad admin access is the same weakness from another angle, because anyone holding it can disable a rule without anyone noticing.

How do you baseline normal activity without drowning in alerts?

Build a baseline from typical working hours, sign-in locations and volumes, and expected traffic at quiet and busy periods. Anomaly detection without a baseline only generates noise, so responders stop looking and the one real alert drowns. Encode the baseline in detection rules, then aim them at authentication attacks, privilege changes and outbound data spikes.

A one-page note is enough at this scale, provided it names an owner. Where the values live in the detection rules instead, the rule settings are the note.

Aim detections at the events that matter most for a firm your size:

• Authentication attacks and impossible-travel sign-ins.
• Privilege changes.
• Traffic to known-bad destinations.
• Unexpected outbound data volumes.
• Tampering with configurations or security tooling.
• Resource spikes that suggest cryptomining or denial of service.

Tune on a cycle. Review what fired, retire or adjust the rules producing false positives, and keep a short record of each change. That record is proof the capability is alive.

New offices, new SaaS tools and new hires all move normal, so revisit the baseline when they arrive rather than waiting for a yearly review.

A dashboard that stays green for a year is not proof of detection. It is proof nobody has revisited a threshold.

Who owns alerts, and how do they reach incident response?

Route every alert to a tracked queue or channel with a named responder, a stated response window and a fallback for absences. Each alert is triaged, and anything credible flows into A.5.25 event assessment and A.5.26 incident response. An alert nobody is accountable for is in effect an alert that never fired.

Auditors test A.8.16, A.5.25 and A.5.26 as one pipeline, and they check the handoff from both ends. An incident in the log with no matching detection invites questions, and so does a detection that never reached an incident decision. If you arrived looking for ISO 27001 Annex A.16 incident handling, this detection-to-incident handoff is where A.8.16 connects to it.

A routing design needs four decisions:

• Destination. A tracked queue or channel, never a shared inbox.
• Named responder. Typically the head of IT or the security lead.
• Response window. Written down, so "quickly" has a number attached.
• Fallback. A deputy, so a lone responder on holiday does not mean nobody is watching.

From there the path is short:

1. The alert fires and opens a ticket with a timestamp.
2. The responder triages it as a false positive, a tuning candidate or a credible event.
3. Anything credible goes to A.5.25 for the decision on whether it is an incident.
4. A confirmed incident follows the A.5.26 response route.
5. The ticket closes with the outcome recorded.

Ownerless alerting is the failure we see most often, and an undocumented route is its twin. With no written triage or escalation path, response quality depends on who happens to be online, and the first sampled alert exposes it. A one-page runbook that names the steps above removes the dependence on individuals.

Can an MDR service cover out-of-hours monitoring for A.8.16?

Yes. A managed detection and response (MDR) service is a legitimate way to cover out-of-hours monitoring, and auditors accept it. You must still show the handoff: escalation from the provider lands in your own incident process, with named internal owners and records. For small firms it is usually cheaper than a second security hire.

Evidence the handoff with these items:

• The service description, showing the hours covered and what the provider will act on.
• The escalation path from provider to your named owners, written into your incident process.
• A few provider escalations traced to your own tickets and decisions.
• A record of who can see and change the detection rules the provider runs.

Buying the eyes does not buy the accountability. You still own the scope, the lawful basis for watching staff and the decision on whether an event is an incident. The provider's report feeds your A.5.25 process; it does not replace it.

Run one out-of-hours test escalation and keep the ticket. It is the strongest exhibit of a working handoff.

What audit evidence do ISO 27001 monitoring activities need to produce?

Auditors expect these artefacts: the documented monitoring scope, exports of configured detection rules and thresholds, baseline notes, real alerts traced through triage tickets to closure, and tuning records. They sample alerts from recent months, ask to see the console live, and probe who can change rules and who watches the watchers.

Assemble the full evidence set:

• Monitoring scope and rules of engagement, including privacy and retention decisions.
• Baseline notes, or the configuration that encodes them.
• Exports of detection rules and thresholds, with their notification wiring.
• Real alerts traced through triage to closure or escalation: tickets, timestamps and responder.
• Tuning records showing what changed, when and why, ideally with false positives falling.
• Access control and MFA evidence for the monitoring platform.
• The privacy assessment or legal review behind any observation of staff activity.

Tracing a sampled alert to its investigation record is the fastest way to expose a channel nobody reads. The control is sometimes searched as "sixteen point asset and information audit". It is a detection control, though, so expect questions about alerts and response, not an asset audit.

Prepare answers to these questions:

• How would you know if someone was inside your network right now?
• What does normal look like for you, and how did you establish it?
• Show me a recent alert: who picked it up, how quickly, and what happened next?
• Who can change the detection rules, and who watches the watchers?
• What is your lawful basis for observing staff activity, and where are they told about it?

How can you automate A.8.16 evidence with compliance engineering?

Treat A.8.16 as an engineered system whose evidence falls out of running it. A scheduled job checks your asset inventory against the sources actually sending logs. Alert-to-ticket automation opens a timestamped ticket for every alert. Detection rules live in version control, so the git log becomes the tuning evidence auditors request.

Four mechanisms do the work:

• Coverage as code. The reconciliation job flags silent sources, so "are we watching everything we think we are" is answered continuously instead of arriving as an annual surprise.
• Alert-to-ticket automation. Responder assignment, time-to-triage and closure evidence accumulate as a by-product of responding.
• Tuning as change history. Every threshold change carries an author, a date and a reason.
• Metrics on tap. False-positive rates and time-to-respond trends export straight from the ticketing data, which turns the capability review into a query rather than a retrospective.

At this scale, a ticket queue, a scheduled job and a git repository are enough. They let you answer a questionnaire or an insurer's proposal from live data, and walk an auditor through the evidence without a scramble. This is the pattern GRCMANA's GRC Engineering work builds.

Frequently asked questions