Skip to content
AuditFront
A.6.8 ISO 27001

ISO 27001 A.6.8: Information security event reporting

What This Control Requires

The organization shall provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner.

In Plain Language

Many security incidents are spotted by regular users long before automated monitoring picks them up. A phishing email that looks wrong, a laptop left on a train, a stranger tailgating through a secure door - if your people do not know how or where to report these, you are flying blind.

The reporting mechanism needs to be easy, well-publicised, and always available. People should know what to report, how to report it, and who receives it. Multiple channels help - email, phone, web form, chat - because different situations call for different approaches.

The biggest barrier to timely reporting is fear. If people think they will get blamed for clicking a dodgy link or calling a false alarm, they will stay quiet. Building a culture where reporting is actively encouraged and rewarded - even for false alarms - is the most important thing you can do for this control.

How to Implement

Set up multiple reporting channels: a dedicated security incident email address, a security hotline or phone number, a web-based reporting form, integration with your IT service desk, an instant messaging channel or chatbot, and a physical option for when electronic channels are not available.

Give people clear guidance with concrete examples of what to report: suspected phishing emails, unauthorised access attempts, lost or stolen devices, suspicious behaviour by colleagues or visitors, unusual system behaviour, potential data breaches or exposures, physical security concerns, social engineering attempts, malware suspicions, and anything that just feels off from a security perspective.

Keep the reporting process simple and fast. The initial report should need minimal information: what happened, when, where, and who is reporting. Do not ask reporters to do technical analysis. The security team follows up for details. Acknowledge every report promptly so people know it was received and is being looked at.

Publicise the reporting mechanism everywhere and keep reminding people. Cover it in security awareness training. Put reporting contact details on the intranet and in common areas. Add them to email signatures or login screens. Include reporting in new joiner induction. Send periodic reminders.

Build a positive reporting culture. Never punish or blame anyone for a good-faith report, even if it turns out to be nothing. Thank people who report. Share anonymised examples of how reports helped prevent or contain real incidents. Make it clear that early reporting is valued and helps the whole organisation.

Track reporting activity. Monitor volume, types of reports, response times, and outcomes. Low volumes probably mean people do not know about the mechanism or do not feel safe using it. Growing volumes are usually a sign of a healthy security culture.

Evidence Your Auditor Will Request

  • Documented security event reporting mechanisms and channels
  • Guidance provided to personnel on what and how to report
  • Records of reported security events showing the reporting mechanism is used
  • Communication records showing reporting mechanism has been publicized
  • Metrics on reporting volumes, response times, and outcomes

Common Mistakes

  • No clear or well-publicized mechanism for reporting security events
  • Personnel do not know what constitutes a reportable security event
  • Reporting process is too complex or bureaucratic discouraging timely reports
  • Culture of blame discourages personnel from reporting incidents and near-misses
  • Reports are received but not acknowledged or followed up in a timely manner

Related Controls Across Frameworks

Framework Control ID Relationship
SOC 2 CC7.2 Related
SOC 2 CC2.2 Partial overlap
GDPR Art.33 Partial overlap
NIS2 Art.23 Partial overlap

Frequently Asked Questions

Should we encourage reporting of false alarms?
Yes, always. It is far better to investigate ten false alarms than to miss one real incident because someone was afraid to speak up. A high rate of reporting, including false positives, is actually a sign of a healthy security culture. Never criticise someone for a good-faith report that turns out to be nothing. Instead, use false alarms as learning opportunities to help people refine their judgement about what constitutes a real threat.
Should reporting be anonymous?
Offer both options. Anonymous reporting is especially valuable for reporting suspected insider threats or policy violations by colleagues or managers - situations where people understandably feel exposed. The downside is that anonymous reports are harder to investigate because you cannot go back for details. Identified reports should be handled confidentially, and you need to make it genuinely clear that there are no negative consequences for reporting in good faith. If people trust the process, most will be happy to identify themselves.

Track ISO 27001 compliance in one place

AuditFront helps you manage every ISO 27001 control, collect evidence, and stay audit-ready.

Start Free Assessment