ISO 27001 Control A.6.8: Information Security Event Reporting

Control A.6.8 is the last of the eight people controls, and in many ways the one that makes the others pay off. Your staff are the largest sensor network you have - they notice the phishing email, the misdirected file, the tailgater, the odd system behaviour - but only if they have an easy way to report it and a reason to believe reporting is worthwhile. A.6.8 requires a mechanism for personnel to report observed or suspected information security events, through appropriate channels, in a timely manner. It is the human front end to your whole incident management process. This is the eighth control in our walk through Annex A, completing the People theme.

What the control requires

Annex A control 6.8 of ISO 27001:2022 states that the organization shall provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner.

The key elements:

• A mechanism - a defined, known way to report, not “email someone if you think of it”
• Observed or suspected - people report suspicions too, not only confirmed incidents; you would rather investigate a false alarm than miss a real one
• Appropriate channels - reporting routes suited to the situation and audience
• Timely - fast reporting matters, because early detection limits damage

A.6.8 is a detective control - it is how events come to light. Annex A states the control; ISO 27002 gives guidance, and your Statement of Applicability records how you apply it. Note the control is about reporting events; assessing and responding to them belongs to the incident management controls in the organizational theme.

How to implement event reporting

Make reporting effortless

The single biggest factor in whether people report is how easy it is. Provide an obvious, low-friction channel - a dedicated email address, a chat command or button, a simple form, or a help-desk option - and make it memorable. If reporting a suspicious email takes five steps and a login, most people will just delete it. Aim for one obvious action.

Tell people what to report and when

People cannot report what they do not recognise. Through awareness training, give concrete examples: phishing emails, lost or stolen devices, suspected malware, misdirected information, unauthorized access, tailgating, weak or exposed credentials. Emphasise “when in doubt, report it,” and that speed matters more than certainty.

Build a no-blame culture - this control lives or dies on it

The fastest way to kill reporting is to punish the reporter. If a person who clicks a phishing link and reports it gets disciplined, the next person will stay quiet - and silence is far more dangerous. Make explicit the distinction between honest reporting (encouraged and protected) and deliberate or concealed violations (which the disciplinary process covers). A strong security culture treats a report of one’s own mistake as a good outcome.

Close the loop with reporters

People keep reporting when they see it matters. Acknowledge reports, and where appropriate tell the reporter what happened. A short “thanks, we looked into it, here is what we did” does more for future reporting than any poster.

Connect reporting to incident management and measure it

Reports must flow into your incident assessment and response process quickly, so nothing sits in an unwatched inbox. Track reporting metrics - volume, type, time to report - as part of your monitoring and measurement under Clause 9.1. A healthy, rising report count usually signals a maturing culture, not a worsening threat.

Related controls and clauses

A.6.3 connection. Awareness and training is what teaches people to recognise events and reminds them how to report - without it, the reporting mechanism goes unused.

A.6.4 connection. The disciplinary process must be balanced against reporting, so fear of punishment does not suppress honest reports.

A.5.24 to A.5.27 connection. Incident management planning, assessment, response, and learning are where reported events are triaged, handled, and turned into improvement - reporting is the trigger for that chain.

A.5.25 connection. Assessment and decision on information security events determines which reported events become incidents.

Clause 9.1 connection. Reporting volumes and response times are useful metrics for judging whether the control - and the culture - is working.

What auditors check

A defined, known mechanism. Auditors expect a clear reporting channel that personnel can actually name, not a vague notion that people would “tell IT.”

Awareness of it. They check, often by asking staff, whether people know how to report an event and what to report.

Timeliness. Auditors look for evidence that reports are made and acted on promptly, and that the channel is monitored.

The link to incident management. They trace how a reported event flows into assessment and response, confirming reports do not vanish.

Culture. Mature auditors probe whether the reporting culture is healthy - whether people feel safe reporting their own mistakes.

Common mistakes to avoid

No obvious channel. If there is no single, well-known way to report, people improvise or stay silent. Provide one clear route.

A blame culture. Punishing honest reporters is the surest way to stop reporting. Protect good-faith reports explicitly.

Reports into a void. A reporting address nobody monitors, or reports that never get acknowledged, quickly train people to stop bothering.

Only counting confirmed incidents. The control covers suspected events too. Encourage reporting of suspicions, not just certainties.

No awareness link. A reporting mechanism that is never taught goes unused. Tie it to training and reinforce it.

Ignoring the metric. Not tracking reporting means you miss an early signal of both threats and cultural health.

How 27kay can help

We help organizations build event reporting that people actually use - easy channels, a no-blame culture, and a clean handoff into incident response. As part of ISO 27001 implementation, we set up the reporting mechanism, weave it into your awareness programme and incident process, and put reporting metrics in front of management. For the full picture, see our ISO 27001 knowledge hub.

Are your people reporting the events they see, or quietly deleting them? Get in touch - we will help you build a reporting culture that surfaces problems while they are still small.