A.6.8
Information security event reporting
People controlsCheckpoints 6Evidence 7Cases 6
Control objective
This control establishes formal procedures and channels for personnel, external parties, and users to promptly report observed or suspected information security events. Human observations complement automated detection, so explain what, when, and how to report and connect reports to assessment and response. Protecting good-faith reporters also helps reduce concealment and reluctance to report.
Key checkpoints
- Are formal reporting channels (hotline, email, ticket, portal) and a reporting procedure defined for information security events, and are employees/external parties aware of them?
- Is guidance provided on what should be reported as an event, including types, examples, and decision criteria?
- Are reporting deadlines (for example, immediately on becoming aware, or within a set time) and the information to include (time of occurrence, affected asset, symptoms, actions taken) specified?
- Are confidentiality and protection from retaliation for good-faith reporters guaranteed by policy?
- Are received events routed to incident assessment/classification/response (A.5.24 onward), with feedback to reporters appropriate to confidentiality and investigation needs?
- Are reporting channels and methods also provided for parties outside the organization, such as external parties, partners, and users?
Implementation guidance
- Explain reportable events with examples, including suspected compromise, malware, loss, phishing, access errors, disclosure, and vulnerabilities. Ask reporters to relay observations without reproducing vulnerabilities or accessing further information without authorization.
- Provide an easy-to-reach single reporting point (hotline, dedicated mailbox, intranet portal, ticketing system) and maintain a contact route for out-of-hours and emergency situations.
- Supply a minimum set of fields and a standard form so anyone can report simply and quickly.
- Establish a policy that protects good-faith reporters (confidentiality, no retaliation, anonymous reporting where needed) and make it known to all members.
- Route reports into incident assessment/classification/response (A.5.24, A.5.25, A.5.26) and acknowledge receipt. Limit outcome feedback to information that can be shared considering privacy, confidentiality, and investigation impact.
- Include reporting methods and examples in awareness training (A.6.3), and use exercises (such as phishing simulations) to verify that reporting actually works.
- State the reporting obligation and channels in external-party/partner contracts and user guidance, so reporting is not limited to internal staff.
Evidence
- Information security event reporting procedure/guidance and reporting form
- Configuration of reporting channels (hotline, dedicated mailbox, portal, ticketing system) and the notice announcing them
- Event intake/handling log, ticket history, and records of routing into the incident management procedure
- Reporter-protection policy documents (confidentiality/no retaliation/anonymous reporting)
- Training materials on reporting methods for employees/external parties and completion records
- Results and improvement records of reporting exercises such as phishing simulations
- Acknowledgement and outcome feedback records sent to reporters
Nonconformity examples
- Reporting channels exist but are not communicated to employees/external parties, so people do not actually know where or how to report.
- There are no event types, criteria, or examples for what should be reported, so the decision to report is left entirely to individual judgment.
- Even when events are reported, they are not routed into the assessment/classification/response procedure and are left unattended after intake.
- No reporter-protection policy exists, so fear of adverse consequences leads to concealment and under-reporting.
- No reporting channel is offered to external parties/partners/users, so events noticed outside the organization cannot be received.
- Reporting deadlines and required fields are not defined, so intake time and content are not recorded and the response is delayed.