Example 1
Repeated failed logins followed by success from an unusual location.
ISO 27001 Annex A guide
Review systems, networks and user activity for anomalies and indicators requiring investigation or response. This independent guide turns that purpose into practical ownership, operating evidence and auditor-ready testing.
Actively monitor relevant systems, networks, applications and identities so unusual behaviour is detected, investigated and escalated. Test the control through the organisation's actual scope, decisions, ownership and operating records rather than relying on a policy reference alone.
For monitoring activities, proportional design depends on the affected services, information, people and dependencies. The evidence below should be adapted to that real boundary.
Repeated failed logins followed by success from an unusual location.
A privileged group membership change outside an approved request.
MFA disabled for a sensitive user.
A security agent stopped or logging source became silent.
An unusual administrative cloud API action or firewall rule creation.
A suspicious outbound data transfer from a critical workload.
| Control outcome | Actively monitor relevant systems, networks, applications and identities so unusual behaviour is detected, investigated and escalated. |
|---|---|
| Illustrative activity | Repeated failed logins followed by success from an unusual location. |
| Evidence sample | approved monitoring standard |
| Effectiveness signal | recent alerts with attributable investigation and closure |
| Auditor question | How is monitoring activities implemented in practice? |
| Failure to challenge | documenting monitoring activities without consistent operation |
Reviewer note: Test monitoring activities with a recent real example; a current operating record normally reveals more than policy wording alone.
Define which identities, endpoints, networks, cloud services, applications and critical processes need monitoring. Connect each important scenario to a signal, rule, severity, owner and response path. Coverage includes source health: a silent agent or missing log stream can be as important as an alert.
A large volume of stored logs is not proof of monitoring. The differentiator is that relevant signals are reviewed, investigated and used to drive action. A SIEM can centralize analysis and workflow, but is not mandatory. Microsoft 365, Azure, AWS and other native services can support effective monitoring when signals are deliberately selected, assigned and tested.
Start with identity, endpoint, email, cloud-administration and critical-service alerts. Assign named reviewers, define severity and keep a simple investigation record.
Use governed detection engineering, source-health monitoring, tiered analysis, case management, threat-informed scenarios and measured tuning across SOC and platform teams.
No. A SIEM is one implementation approach. Smaller environments may combine cloud-native alerts, endpoint tooling and documented review, provided coverage and response are effective.
Logging creates and protects useful event records. Monitoring applies detection, review and investigation to relevant activity.
Coverage and timeliness should reflect risk, criticality and feasible detection scenarios; not every asset needs identical monitoring.
Yes. Native services can provide strong signals when configured, owned, tested and connected to a workable investigation process.
Expect a trace from a critical system and detection rule to a recent alert, investigation, escalation or closure, plus evidence of coverage review.
Choose risk-based triggers and cadence, including changes to systems, threats, incidents, false-positive patterns and missing coverage.
Open Control 8.16 in the free tool to browse connected controls and practical evidence alongside the complete reference set.