Information security event reporting
Purpose
Enable staff to report security events they notice in a timely, consistent and effective way.
How to meet this control
In short: Provide a mechanism for personnel to report security events promptly.
- Step 01Provide a single, well-known reporting channel such as a security@ mailbox, a Slack or Teams command, or an intranet form that reaches the security team fast
- Step 02Communicate a no-blame, report-early culture so staff raise suspected events without fear of punishment
- Step 03Train staff on what to report, including phishing, lost devices, suspected malware, policy breaches, near-misses and observed control weaknesses
- Step 04Instruct staff not to investigate or test a suspected vulnerability themselves but to report and leave it to the security team
- Step 05Feed every report into the incident triage process and give the reporter acknowledgement and feedback to reinforce the behaviour
- Step 06Track reporting volumes as a positive metric and surface trends in awareness communications
Tip: A single, well-known channel (email/Slack/form) plus "report, don’t fear blame" messaging.
What ISO 27002 says to cover
Reference points from the ISO/IEC 27002:2022 guidance for this control. Use them to check the steps above cover everything relevant to you.
- ›Give staff a mechanism to report observed or suspected security events promptly
- ›Make all personnel aware it is their duty to report events fast to limit incident impact
- ›Tell people the reporting procedure and point of contact, and keep it easy and accessible
- ›Have staff report ineffective controls and breaches of confidentiality, integrity or availability
- ›Include reporting of human errors, policy non-compliance and physical security breaches
- ›Include reporting of unauthorised changes, malfunctions, anomalous behaviour and access violations
- ›Include reporting of vulnerabilities and suspected malware infections
- ›Instruct staff not to try to prove suspected vulnerabilities themselves
Audit evidence to keep
- - Documentation of the reporting channel and procedure shared with staff
- - A log or ticket trail of reported security events
- - Awareness materials promoting the report-early, no-blame message
- - Evidence reports feed into incident triage, such as linked tickets
- - Metrics showing reporting volume and feedback given to reporters
Common mistakes
- - Having an incident plan that staff cannot find
- - Closing incidents without root cause or lessons learned
- - Not preserving evidence before systems are changed
Owner, cadence, and proof
Assign one accountable owner for A.6.8. Review this control at least annually, after related incidents, and whenever the underlying process, supplier, system, office, or legal obligation changes. The control is audit-ready when the owner can show the policy or procedure, the latest operating evidence, the latest review, and any open exceptions with due dates.
Policy templates for this control
Use these starting documents to turn the control into evidence. Adapt each template to your scope, systems, legal obligations and actual operating process.