EvidenceSheet

8.16 Monitoring activities

Networks, systems and applications are to be monitored for anomalous behaviour, with appropriate steps taken to evaluate possible information security incidents. Purpose: spot abnormal behaviour and possible incidents. Guidance: decide the scope and depth of monitoring from business and security requirements and applicable law, and keep monitoring records for defined periods. Consider monitoring inbound and outbound network, system and application traffic; access to systems, servers, network equipment, the monitoring system itself and critical applications; critical or administrator-level configuration files; logs from security tools such as anti-virus, IDS, IPS, web filters, firewalls and DLP; system and network event logs; checks that running code is authorized and untampered, for example not recompiled with unwanted additions; and resource use and performance (CPU, disks, memory, bandwidth). Establish a baseline of normal behaviour, reviewing use at normal and peak times and each user's or group's usual access times, locations and frequency, and monitor for deviations such as unplanned termination of processes or applications; malware-like activity or traffic from known malicious addresses or domains, such as botnet controllers; known attack signatures like denial of service or buffer overflows; unusual system behaviour such as keystroke logging, process injection or non-standard protocol use; bottlenecks and overloads (queuing, latency, jitter); actual or attempted unauthorized access; unauthorized scanning of applications, systems and networks; successful and failed attempts on protected resources such as name servers, portals and file systems; and user or system behaviour that departs from expectations. Use continuous monitoring tools, in real time or at intervals as needs and capabilities allow, able to handle large data volumes, adapt to changing threats, notify in real time and recognize signatures and behaviour patterns. Configure automated alerts on predefined thresholds through consoles, email or messaging, tuned to the baseline to limit false positives; have dedicated, trained staff to interpret and respond to alerts, with redundant systems and processes for receiving them. Share abnormal events with relevant parties so that audit, security evaluation, vulnerability scanning and monitoring improve (5.25); respond to positive indicators promptly to limit harm (5.26); and identify and address false positives, tuning tools to reduce them. Other information: monitoring can be strengthened with threat intelligence (5.7), machine learning and AI, block and allow lists, technical assessments such as vulnerability assessments, penetration tests, attack simulations and response exercises that help set baselines, performance monitoring, and logs combined with monitoring; intrusion detection systems can be baselined to expected activity; watching for anomalous communications helps find botnet infections controlled from outside.

Source: ISO/IEC 27002:2022, 8.16. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.

ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.

6
artefacts
3
held by a system
1
at each review
easy
to go live
SIEM / log platform
where the evidence lives
teal = a system already holds it · olive = produced at each review. To go live: easy when half or more of the artefacts are already held by a system, moderate from a quarter to a half, hard below a quarter.

These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.

system holds itEvidence a system already holds

  • Baselines of normal behaviour for systems and user groups, and the detection rules built on them · SIEM / log platform
  • Alerting configuration with thresholds and evidence of tuning to reduce false positives · SIEM / log platform
  • Alert triage and response records showing timely handling and escalation to incident management · SIEM / log platform

periodic reviewEvidence produced at each review

  • Records of false positive analysis and resulting rule tuning · SIEM / log platform

governing documentDocuments that govern the control

  • A documented monitoring scope covering network traffic, system access, configuration files, security tool logs, code integrity and resource use, with retention periods · Policy repository / GRC workspace
  • Monitoring team rota or SOC arrangement with trained staff and redundant alert channels · Policy repository / GRC workspace

First move

Automate the pull from your SIEM / log platform. Retention and alert rules exported from the SIEM; review evidence is the closed-alert record with reviewer and time.

Common gaps auditors find

Do this for your whole sheet

Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.

Build my evidence sheet

8.15 Logging · 8.17 Clock synchronization