6.8 Information security event reporting
A mechanism is to be provided so personnel can report information security events they notice or suspect, promptly and through the right channels. Purpose: support reporting of events that personnel can spot in a timely, consistent and effective way. Guidance: all personnel and users should know they must report events as fast as possible so incidents can be prevented or their effects limited, and should know the reporting procedure and the contact point. The mechanism should be as simple, accessible and available as possible. Events include incidents, breaches and vulnerabilities, and situations worth reporting include controls that do not work, breaches of expected confidentiality, integrity or availability, human error, non-compliance with policies or standards, physical security breaches, system changes that bypassed change management, software or hardware malfunctions and anomalous behaviour, access violations, vulnerabilities and suspected malware. People should be told not to try to prove a suspected vulnerability, because testing it can look like misuse, can damage systems or services, can spoil or hide digital evidence and can expose the tester to legal liability. See the ISO/IEC 27035 series.
Source: ISO/IEC 27002:2022, 6.8. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open ISO/IEC 27002:2022 in the compliance library.
ISO/IEC 27002 is guidance on the Annex A controls; certification is against ISO/IEC 27001. Use this set when your sheet follows the 27002 numbering.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
none for this control
periodic reviewEvidence produced at each review
- Records of events reported by personnel, with time from observation to report · Document repository
- Evidence the reporting channel is available outside working hours where needed · Document repository
- Metrics or reviews showing reports are received across the range of event types · Policy repository / GRC workspace
governing documentDocuments that govern the control
- A documented reporting procedure naming the point of contact and the channels available, such as a portal, hotline or mailbox · Policy repository / GRC workspace
- Awareness material telling personnel and users what to report, how quickly and where · HR system / LMS
- Guidance instructing people not to test suspected vulnerabilities themselves · Policy repository / GRC workspace
First move
Common gaps auditors find
- Staff do not know where or how to report, so events surface late
- The channel is a single person's inbox with no cover
- Users try to verify suspected vulnerabilities themselves
- Human errors and near misses go unreported because reporting is seen as blame
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheet