Monitoring activities

What the requirement asks

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. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.

What the guidance adds

Monitoring turns logs into decisions. The guidance asks for the rule, the threshold, the alert, the triage and the record.

What good looks like

Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep A documented monitoring scope covering network traffic, system access, configuration files, security tool logs, code integrity and resource use, with retention periods and one live sample together.

Evidence an assessor asks for

• Security monitoringA documented monitoring scope covering network traffic, system access, configuration files, security tool logs, code integrity and resource use, with retention periods
• Security monitoringBaselines of normal behaviour for systems and user groups, and the detection rules built on them
• Security monitoringAlerting configuration with thresholds and evidence of tuning to reduce false positives
• Security monitoringMonitoring team rota or SOC arrangement with trained staff and redundant alert channels
• Security monitoringAlert triage and response records showing timely handling and escalation to incident management
• Security monitoringRecords of false positive analysis and resulting rule tuning

The question an assessor will ask

An assessor will ask for A documented monitoring scope covering network traffic, system access, configuration files, security tool logs, code integrity and resource use, with retention periods, then trace it to the system it protects. For A.8.16 the test is whether that record ties to a live sample, not whether the control is named in a policy.

Common gaps

• Monitoring tools are deployed but no baseline was set, so anomalies are not recognized
• Alerts go to an unmonitored mailbox outside business hours
• Outbound traffic to known malicious domains is not monitored
• Alert fatigue from untuned rules causes real incidents to be missed

Before the next audit

Before the next audit, check one live sample for this gap: monitoring tools are deployed but no baseline was set, so anomalies are not recognized.