ISO 27001 Annex A guide

ISO 27001 Annex A 8.16: Monitoring activities

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.

Control
8.16
Category
Technological controls
Primary outcome
Actively monitor relevant systems, networks, applications and identities so unusual behaviour is detected, investigated and escalated.

What Control 8.16 means in practice

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.

Implementation steps

  1. Step 1. Define ownership, scope and operating criteria for monitoring activities.
  2. Step 2. Implement monitoring standard that fits the organization’s risks, services and working practices.
  3. Step 3. Integrate the activity with relevant change, exception and review processes.
  4. Step 4. Review performance and improve the arrangement when risks, technology or obligations change.

What good implementation looks like

  • recent alerts with attributable investigation and closure
  • missing-log-source reports and recovery action
  • rule tuning based on false positives, incidents and environmental change
  • response-time evidence and escalations for high-severity alerts

Implementation evidence and effectiveness evidence

Evidence the control is implemented

  • approved monitoring standard
  • logs and review records
  • assigned ownership and approval evidence
  • sample implementation, review and exception records

Evidence the control is effective

  • recent alerts with attributable investigation and closure
  • missing-log-source reports and recovery action
  • rule tuning based on false positives, incidents and environmental change
  • response-time evidence and escalations for high-severity alerts

How an auditor may test Control 8.16

  1. Select a representative in-scope service, asset or process.
  2. Confirm the accountable owner and expected operation.
  3. Trace a recent example: Repeated failed logins followed by success from an unusual location.
  4. Inspect the operating record and corroborating technical evidence.
  5. Compare the design with evidence that the control operated effectively.
  6. Follow an exception or adverse result through decision and closure.
  7. Review trends, metrics and improvement decisions.

Questions to prepare for

  • How is monitoring activities implemented in practice?
  • Who owns the activity and how are decisions approved?
  • Show me a recent example from operation through review.
  • How are exceptions, changes or overdue actions handled?

Practical examples

Example 1

Repeated failed logins followed by success from an unusual location.

Example 2

A privileged group membership change outside an approved request.

Example 3

MFA disabled for a sensitive user.

Example 4

A security agent stopped or logging source became silent.

Example 5

An unusual administrative cloud API action or firewall rule creation.

Example 6

A suspicious outbound data transfer from a critical workload.

Illustrative decision and evidence record

Control outcomeActively monitor relevant systems, networks, applications and identities so unusual behaviour is detected, investigated and escalated.
Illustrative activityRepeated failed logins followed by success from an unusual location.
Evidence sampleapproved monitoring standard
Effectiveness signalrecent alerts with attributable investigation and closure
Auditor questionHow is monitoring activities implemented in practice?
Failure to challengedocumenting 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.

Monitoring scope and detection lifecycle

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.

  1. Identify relevant threat and failure scenarios.
  2. Select trustworthy telemetry with time, identity and asset context.
  3. Design and test detection logic, severity and ownership.
  4. Triage, investigate and preserve a decision record.
  5. Escalate, contain or close with a reviewable reason.
  6. Tune using incidents, false positives, change and missed detections.

Logging, monitoring and SIEM are not interchangeable

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.

Useful performance and coverage measures

  • critical systems with active monitoring
  • alert acknowledgement and investigation time
  • log sources silent beyond threshold
  • high-fidelity rules reviewed and tuned
  • repeat alerts closed without corrective action

Approach for smaller and mature organizations

Smaller organization

Start with identity, endpoint, email, cloud-administration and critical-service alerts. Assign named reviewers, define severity and keep a simple investigation record.

Mature or complex organization

Use governed detection engineering, source-health monitoring, tiered analysis, case management, threat-informed scenarios and measured tuning across SOC and platform teams.

Practical implementation checklist

  • □ Define ownership, scope and operating criteria for monitoring activities.
  • □ Implement monitoring standard that fits the organization’s risks, services and working practices.
  • □ Integrate the activity with relevant change, exception and review processes.
  • □ Review performance and improve the arrangement when risks, technology or obligations change.
  • □ Sample evidence has been checked for operation and effectiveness.
  • □ Exceptions have owners, rationale, review dates and closure evidence.

Common implementation mistakes

  • documenting monitoring activities without consistent operation
  • unclear ownership or review frequency
  • evidence that does not cover the full ISMS scope
  • exceptions accepted without risk-based approval or follow-up

Frequently asked questions

Do we need a SIEM for ISO 27001 8.16?

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.

How does 8.16 differ from 8.15 logging?

Logging creates and protects useful event records. Monitoring applies detection, review and investigation to relevant activity.

Do all systems need continuous monitoring?

Coverage and timeliness should reflect risk, criticality and feasible detection scenarios; not every asset needs identical monitoring.

Can Microsoft 365, Azure or AWS native monitoring be used?

Yes. Native services can provide strong signals when configured, owned, tested and connected to a workable investigation process.

What will an auditor sample?

Expect a trace from a critical system and detection rule to a recent alert, investigation, escalation or closure, plus evidence of coverage review.

How often should rules be reviewed?

Choose risk-based triggers and cadence, including changes to systems, threats, incidents, false-positive patterns and missing coverage.

Use the interactive control lookup

Open Control 8.16 in the free tool to browse connected controls and practical evidence alongside the complete reference set.

Open Control 8.16 in the Annex A lookup →