The ultimate audit guide to ISO 27001 Annex A 6.8 Information security event reporting
Table of contents
- 1. Incident Reporting Policy Formalisation Verified
- 2. Centralised Reporting Channel Accessibility Confirmed
- 3. Reporting Anonymity and “No-Blame” Culture Evidence Identified
- 4. Third-Party and Contractor Reporting Integration Validated
- 5. Personnel Reporting Awareness and Competency Verified
- 6. Timeliness of Initial Event Logging Confirmed
- 7. Automated Technical Event Trigger Integration Verified
- 8. Reporting Criteria for “Suspected” Events Validated
- 9. Feedback Loop to Reporters Confirmed
- 10. Periodic Review of Reporting Efficacy Verified
1. Incident Reporting Policy Formalisation Verified
Verification Criteria: A documented policy exists that mandates the reporting of all observed or suspected information security events through identified channels.
Required Evidence: Approved Information Security Policy or Incident Management Policy containing explicit “Duty to Report” clauses.
Pass/Fail Test: If the organisation lacks a formalised requirement for personnel to report security anomalies, mark as Non-Compliant.
2. Centralised Reporting Channel Accessibility Confirmed
Verification Criteria: A singular, well-defined point of contact (e.g. SOC email, helpdesk portal, or telephone hotline) is active and accessible to all personnel.
Required Evidence: Screenshots of the intranet, internal posters, or helpdesk configuration showing a dedicated security event intake channel.
Pass/Fail Test: If reporting channels are fragmented (e.g. “tell your manager”) without a centralised logging mechanism, mark as Non-Compliant.
3. Reporting Anonymity and “No-Blame” Culture Evidence Identified
Verification Criteria: Reporting mechanisms allow for confidential or anonymous reporting where appropriate to encourage transparency without fear of reprisal.
Required Evidence: Whistleblowing policy or anonymous reporting portal logs; absence of disciplinary actions for self-reported accidental breaches.
Pass/Fail Test: If the reporting process is perceived as a disciplinary trigger rather than a risk-reduction tool, mark as Non-Compliant.
4. Third-Party and Contractor Reporting Integration Validated
Verification Criteria: External parties with access to organisational assets are contractually mandated to report security events within specified timeframes.
Required Evidence: Master Service Agreements (MSAs) or Supplier Security Annexes containing specific event reporting SLAs.
Pass/Fail Test: If contractor agreements do not specify a mandatory window (e.g. 24 hours) for reporting suspected events, mark as Non-Compliant.
5. Personnel Reporting Awareness and Competency Verified
Verification Criteria: Employees demonstrate the ability to identify a security “event” versus a standard technical “issue” and know the correct escalation path.
Required Evidence: Security awareness training completion logs and results of “Spot Check” interviews with random staff members.
Pass/Fail Test: If a sampled employee cannot identify how to report a lost corporate device or a suspicious email, mark as Non-Compliant.
6. Timeliness of Initial Event Logging Confirmed
Verification Criteria: Reported events are logged with an initial timestamp immediately upon receipt to ensure the audit trail for statutory reporting (e.g. GDPR) is accurate.
Required Evidence: Ticketing system export showing the delta between “Event Observed” and “Event Logged” timestamps.
Pass/Fail Test: If there is a consistent lag of >24 hours between observation and logging without technical justification, mark as Non-Compliant.
7. Automated Technical Event Trigger Integration Verified
Verification Criteria: Reporting is not solely dependent on humans; technical systems (SIEM/EDR) are configured to report events automatically to the centralised intake.
Required Evidence: SIEM correlation rules or EDR alert configurations showing automated ticket generation in the ITSM tool.
Pass/Fail Test: If the security team only receives reports via email and lacks automated system alerts for critical anomalies, mark as Non-Compliant.
8. Reporting Criteria for “Suspected” Events Validated
Verification Criteria: Documentation exists defining what constitutes a reportable “suspected” event, reducing ambiguity for non-technical staff.
Required Evidence: Employee handbook or “Quick Reference Guide” listing examples like “unusual system slowdown,” “missing hardware,” or “unlocked doors.”
Pass/Fail Test: If the organisation only requires reporting of confirmed breaches, ignoring suspected events, mark as Non-Compliant.
9. Feedback Loop to Reporters Confirmed
Verification Criteria: A mechanism exists to provide feedback to the reporter on the outcome of their report, reinforcing the value of the reporting process.
Required Evidence: Sampled ticket communications showing “Resolution” notifications sent back to the original reporter.
Pass/Fail Test: If reports enter a “black hole” where the reporter never receives confirmation or closure, mark as Non-Compliant.
10. Periodic Review of Reporting Efficacy Verified
Verification Criteria: Management reviews the volume and quality of reports to identify areas where awareness training may be failing or reporting is being suppressed.
Required Evidence: Management Review Meeting (MRM) minutes showing analysis of incident reporting trends and “False Positive” rates.
Pass/Fail Test: If reporting volumes are suspiciously low (e.g. zero reports in 6 months for 100+ staff), and no management review has investigated this, mark as Non-Compliant.
About the author
