How to Get People to Speak Up Quickly When Something Looks Wrong
ISO 27001 Control 6.8 Information security event reporting is all about making sure people know:
“If you see anything that doesn’t look right, you report it quickly, through the right channel – and you won’t be punished for doing so.”
You can have brilliant technical controls, but if staff notice weird activity and don’t know what to do – or are too nervous to say anything – you’ll find out about issues far too late.
This control expects you to:
- Define what an information security event is (and isn’t)
- Provide simple, clear reporting channels
- Make sure staff know what to report, how to report it, and what not to do
- Treat event reporting as part of a wider incident management process, not a box-ticking exercise
This guide walks through how to implement ISO 27001 Control 6.8 in a way that actually works in day-to-day operations.
What ISO 27001 Control 6.8 Is Really Asking For
In plain language, ISO 27001 Control 6.8 – Information security event reporting requires you to:
- Ensure all personnel and relevant interested parties (e.g. contractors, temps, key suppliers) can promptly report:
- Information security events
- Suspected weaknesses in controls
- Provide defined reporting channels and make them visible and easy to use
- Make it clear that people must not investigate or exploit suspected weaknesses themselves
- Ensure reported events are captured, logged, and passed to the right people for assessment (this links directly to Control 6.9)
Think of 6.8 as the “front door” to your incident management process. If that door is hard to find or people are afraid to use it, your whole response capability suffers.
Step 1 – Define What Counts as an Information Security Event
If you want good reporting, you need to remove the guesswork. People should not be sat at their desk wondering:
“Is this serious enough to bother someone with?”
Under ISO 27001 Control 6.8, you should:
Explain the difference between:
- Information security event
Something that might indicate a security issue or weakness, but hasn’t yet been confirmed as an incident. - Information security incident
An event (or series of events) that has compromised – or is very likely to compromise – the confidentiality, integrity, or availability of information or services.
Control 6.8 is focused on events and weaknesses – the things staff notice and report. Control 6.9 deals with how you then assess them.
Give concrete examples of what to report
Make it very specific. For example:
- Suspicious emails or messages
– Phishing, odd requests for credentials, links that don’t look right. - Access issues and odd behaviour
– Unexpected MFA prompts.
– Logins from unfamiliar locations.
– Accounts locked out repeatedly. - Data handling problems
– Sending confidential data to the wrong recipient.
– Seeing data you shouldn’t be able to see.
– Files suddenly encrypted or renamed. - Technology behaviour
– Systems behaving unusually slow or crashing.
– New software appearing unexpectedly.
– Pop-ups, warnings, or anti-malware alerts. - Control weaknesses
– Shared passwords.
– Unlocked screens in sensitive areas.
– Security doors propped open.
– Obvious gaps in process (e.g. no review before granting admin access). - Physical and environmental issues
– Unauthorised people in restricted areas.
– Lost or stolen laptops, phones, or USB drives.
The simpler the rule, the better. A good default is:
“If you’re not sure whether to report something – report it.”
Step 2 – Design Simple, Clear Reporting Channels
ISO 27001 Control 6.8 doesn’t prescribe how people report events, but it does expect the mechanism to be clear, accessible and reliable.
In practice, you might provide:
- A dedicated security or “infosec” email address (e.g. security@…, infosec@…)
- A ticketing / service desk portal category for “Security event / incident”
- A telephone contact for urgent issues (especially out of hours)
- An internal form for reporting suspected vulnerabilities or control weaknesses
For higher-risk environments, you might also offer:
- An anonymous reporting channel (especially helpful for reporting policy breaches or unethical behaviour)
Whatever you choose, make sure:
- It’s easy to remember (and advertised in induction, training, intranet, policies).
- It’s not buried in a 40-page policy – people should be able to find it in seconds.
- It’s monitored – there’s no point having an inbox no-one reads.
A simple, concise “What to do if you think there’s a security issue” page on the intranet, poster, or quick-reference guide works very well here.
Step 3 – Tell People Exactly What to Do – and What Not to Do
One of the important points in your original text is spot on:
Don’t test, report.
Under ISO 27001 Control 6.8 you should explicitly tell staff:
What to do
When they notice something suspicious, they should:
- Stop and stabilise
- If they’re in the middle of doing something that might make it worse (e.g. repeatedly clicking a suspicious link), stop.
- Capture basic facts
- Time and date
- System or application affected
- What they were doing just before it happened
- Any error messages, screenshots or suspicious content (e.g. email headers)
- Use the official reporting channel
- Submit the information via the agreed route (service desk, email, form, phone etc.).
- If the impact looks serious or urgent (e.g. ransomware or widespread outage), follow your major incident / urgent path.
- Be available for follow-up
- They don’t need to solve the problem – but they should be ready to answer clarification questions if needed.
What not to do
- Do not attempt to exploit or “test” a suspected vulnerability.
- Do not run unapproved tools to “see how bad it is”.
- Do not delete evidence (e.g. wiping emails, clearing logs, reinstalling software) unless specifically told to by the security or IT team.
- Do not share details of the issue widely (internally or externally) unless authorised.
Make this guidance simple and explicit in your event reporting procedure and in staff training.
Step 4 – Build Event Reporting into Culture and Training
ISO 27001 Control 6.8 only works if people are:
- Aware of their responsibility to report
- Confident that reporting is expected and appreciated, not punished
Practical steps:
- Induction
– Include information security event reporting in onboarding for all new starters.
– Show them the actual channels and walk through an example. - Regular awareness training
– Remind people what to report, how to report, and the “don’t test, report” message.
– Use simple examples and short scenarios – phishing, misplaced devices, misdirected emails. - Reinforce non-blame principle
– Be clear: honest mistakes that are reported promptly will be handled constructively.
– Focus on learning and improvement, not blame. - Feedback loop
– Where appropriate, give general feedback such as “Thanks to prompt reporting from staff, we were able to contain X” (without naming individuals or sharing sensitive details).
– This builds trust that reporting is taken seriously and leads to action.
All of this helps turn ISO 27001 Control 6.8 from a dry requirement into part of your everyday security culture.
Step 5 – Connect Event Reporting to Your Incident Process
Control 6.8 does not stand alone. Once an event is reported:
- Someone needs to receive and log it
- Someone needs to decide whether it is:
- A minor issue that can be closed or tracked as a near miss
- An information security incident requiring full response (this is where Control 6.9 – Assessment and decision on information security events comes in)
To make this work:
- Define ownership
– Typically your information security team, service desk, or a named role (e.g. Information Security Manager) owns first-line triage. - Standardise recording
– Use a consistent template or workflow to capture reported events (date, time, reporter, system, description, initial impact). - Document the handoff
– Show clearly how a reported event flows from:- Reporter →
- Service desk / security queue →
- Assessment (6.9) →
- Incident management process (where applicable)
This gives you a traceable, auditable chain from “I saw something odd” to “We assessed and acted”.
Step 6 – Review, Learn and Improve the Reporting Mechanism
Control 6.8 is not a one-time setup. Over time, you should:
- Review volumes and types of reports
– Are people reporting at all?
– Are there recurring themes (e.g. same type of misconfiguration, same phishing vector)? - Check usability
– Ask staff whether they know how to report and whether it feels easy.
– If they don’t, your communication needs work. - Tune guidance and training
– If people aren’t reporting certain types of events, add examples into training.
– If you’re flooded with very low-risk noise, clarify what’s expected and refine your messaging. - Capture lessons learned
– After significant incidents, ask: did someone notice earlier and not report?
– Use those insights to tweak the event reporting process.
These improvements are valuable evidence that ISO 27001 Control 6.8 is properly embedded and part of continual improvement.
Quick Implementation Checklist for ISO 27001 Control 6.8
You’re in a good place for ISO 27001 Control 6.8 – Information security event reporting if you can say yes to most of these:
- We have a documented procedure for information security event reporting.
- We have defined and communicated what counts as an information security event (with clear examples).
- All personnel and relevant interested parties have simple, well-publicised channels to report events and weaknesses.
- Our guidance clearly says “don’t test, report” and tells people what not to do.
- Reported events are logged and routed to the right people for assessment (linking to Control 6.9 and our incident response process).
- Event reporting is covered in induction and regular awareness training.
- There is a non-blame culture around honest mistakes that are reported promptly.
- We periodically review event reports to identify trends and improve controls, training and processes.
- We can provide evidence (records, examples, training materials) to an auditor that Control 6.8 is consistently applied.
Bringing It All Together
ISO 27001 Control 6.8 – Information security event reporting – is less about tools and more about behaviour.
If you:
- Define clearly what should be reported
- Provide simple, trusted reporting channels
- Make it easy and safe for people to speak up
- Link reports into a structured assessment and incident response process
you’ll dramatically improve your chances of catching issues early – and you’ll have strong, practical evidence that you’re meeting the intent of ISO 27001 Control 6.8 in a way that genuinely strengthens your security posture.
Explore the ISO 27001 Control Group Purposes