A.8.16

Objective

Monitor networks, systems, and applications for anomalous behaviour and take appropriate action.

Points of focus

• Detections cover authentication anomalies, privilege escalation, and bulk data access/export
• Cloud-native threat detection (GuardDuty, Security Command Center, Defender for Cloud) is enabled and tuned
• Alerts route to an on-call rotation with a defined response SLA, not just a Slack channel
• Alert thresholds are tuned periodically to reduce fatigue without silencing real signal
• Monitoring scope keeps pace with new services and infrastructure as the product grows

Implementation notes

Start from a short list of detections that matter most for a SaaS platform handling customer data: anomalous authentication (impossible travel, new-device admin login, repeated MFA failures), privilege escalation (a user or role gaining admin rights outside a change ticket), and bulk or unusual data access (a service account suddenly reading far more records than its normal pattern, or a large export from the customer database). Layer cloud-native detection services on top of infrastructure you don't fully control at the network layer — GuardDuty, Microsoft Defender for Cloud, or Security Command Center catch a wide range of infrastructure-level threats with minimal setup. Route everything above an agreed severity threshold into the same on-call system used for production incidents, with a documented acknowledgement SLA (e.g. 15 minutes for critical, 4 hours for medium), because an alert with no response SLA is really just a log entry with extra steps. Revisit detection coverage every time you add a major new service, data store, or environment — monitoring that was comprehensive at 10 engineers is often full of blind spots at 50. Finally, budget time for tuning: track false-positive rate per rule and adjust thresholds or add suppression logic, since an over-alerting system trains responders to ignore it, which is functionally the same as having no monitoring at all.

Audit tip: Ask for the most recent high- or medium-severity alert that actually fired — not a hypothetical — and walk through who was notified, how fast they acknowledged it, and what they concluded. A single real alert trace with timestamps demonstrates the control far better than a list of configured rule names.

Common gaps

• GuardDuty or an equivalent service is enabled but findings route to an email inbox nobody triages, so real detections sit unread for weeks
• Detection rules were written at launch and never updated as the architecture changed, so they no longer cover the services that now hold customer data
• Alert volume is so high that the on-call engineer mutes the channel, defeating the purpose of having monitoring in the first place

Related

Primary sources

• ISO/IEC 27001:2022 Annex A: ISO/IEC 27001:2022 Annex A (A.8.16)