A.8.16 Audit Evidence Pack

What the auditor wants to verify

Audit objective

Verify that networks, systems, and applications are monitored for anomalous behaviour and that potential information security incidents are evaluated and escalated appropriately.

Evidence to request

Evidence	Purpose
Monitoring strategy or standard	Shows monitoring scope, ownership, and expected operation
Risk assessment and detection mapping	Shows monitoring is risk-based
Detection use case register	Shows defined anomalous behaviour and alert logic
Monitoring coverage/source map	Shows relevant systems and data sources are covered
SIEM/IDS/IPS/EDR rule configuration	Shows alert rules are implemented
Alert threshold reviews	Shows tuning and fatigue management
Alert triage records	Shows alerts are evaluated
Incident response records	Shows true positives are escalated
Out-of-hours escalation procedure/test	Shows alerts can be handled outside business hours
Monitoring metrics and review records	Shows effectiveness is reviewed and improved

Strong evidence

Detection use cases trace to risk scenarios, assets, and critical services.
Monitoring source coverage includes relevant identity, endpoint, server, network, cloud, application, and security tooling events.
Alert thresholds are tuned and reviewed after false positives, incidents, and system changes.
Alerts have triage decisions, owners, timestamps, and escalation outcomes.
True positives link to event assessment, incident response, evidence preservation, and corrective action.
Known blind spots are documented and risk-treated.
Out-of-hours escalation has named roles, contact paths, and test evidence.

Weak evidence

A SIEM exists but only uses generic default rules.
Alerts are visible on a dashboard but not assigned or reviewed.
Monitoring covers network perimeter only and ignores identity, endpoint, cloud, or applications.
Alert volume is high and no one tracks false positives or fatigue.
True positives are handled informally with no event or incident record.
Out-of-hours response depends on personal availability rather than a documented process.

Sample interview questions

Which risks drove the monitoring rules?
Which systems and applications are monitored?
Which critical systems are not monitored, and why?
How are alert thresholds defined and tuned?
What happens when an alert may indicate compromise?
How are false positives reviewed?
How are out-of-hours alerts escalated?
Can you show a recent alert from detection through closure or incident response?

Common nonconformities

Monitoring scope is not risk-based.
Detection use cases are missing or not mapped to data sources.
Critical systems are not monitored.
Alerts are not triaged or escalated.
Event fatigue is evident and unmanaged.
Monitoring rules are not reviewed after incidents or changes.
Out-of-hours escalation is undefined.

Audit
Evidence
A8 16
Iso27001

Note Metadata

Aliases: A.8.16 Evidence

Source: 04 Audit Evidence Packs/A.8.16 Audit Evidence Pack.md

Graph-sourced resources

Templates and evidence

Implementer templates

Working artifacts for control owners and operators.

Monitoring Coverage and Data Source Map

Auditor evidence packs

Evidence collections and audit-facing verification material.

A.8.16 Audit Checklist