Annex A Controls Explained
ISO 27001 Control 6.8: Information Security Event Reporting
ISO 27001 Control 6.8 asks for a simple way for people to report security events. When an organisation says nothing has happened, it usually means nothing has been reported.
Last Updated: 4 November 2026
Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →
ISO 27001 Control 6.8: Information Security Event Reporting
https://www.iso.org/standard/27001
The organization shall provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner.
Key Takeaways
- Control 6.8 asks for a timely, appropriate way for people to report observed or suspected security events.
- Security events happen constantly. “Nothing to report” usually means nobody reported.
- People mostly do not report because it feels bureaucratic and not worth their time.
- Make reporting take seconds: a report button, a short form, a named person.
- Thank people for reporting, and never punish honest mistakes reported promptly.
- Automated alerts from tools you already have reduce how much depends on people noticing.
- An empty event log is a warning sign, not a good result.
Table of Contents
Introduction
In short: ISO 27001 control 6.8, information security event reporting, requires a simple, well-known way for anyone to report a suspected security event quickly. In practice that means one reporting route, a no-blame culture so people use it, and a log showing reports were received and assessed.
When I ask an organisation whether it has had any security events or incidents in the past few months, the answer is very often “No, nothing.” Frankly, I do not believe it.
Security events happen constantly. Phishing emails arrive every day. People mistype email addresses. Sign-in attempts fail. Laptops get left on trains. Most of these are minor, and most turn out to be nothing, but they need looking at, because now and then one is the early sign of something larger. “Nothing reported” almost never means nothing happened. It means nobody reported it.
Control 6.8 asks for a way for people to report what they see, quickly and through the right channel. This page covers why people do not report, how to make reporting easy enough that they will, and where automated tools take some of the load. The free incident log further down is the place to record what comes in.
What control 6.8 actually asks for
The control requires the organisation to provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner. In practice:
- A reporting route. Simple, well known and available to everyone, including contractors.
- Clarity about what to report. Including suspected events and weaknesses, not just confirmed incidents.
- Speed. People report straight away, not at the end of the week.
- Someone receiving it. Reports go to a person who looks at them and decides what happens next.
- No penalty for honest reporting. Otherwise people will not do it.
In the 2013 edition this was split across A.16.1.2, reporting events, and A.16.1.3, reporting weaknesses. The 2022 version combines them.
Why people do not report
In my experience the main reason is not fear, though fear plays a part. It is that reporting feels bureaucratic and not worth the time. A suspicious email? Delete it. A wrong attachment? Send a quick apology. A strange pop-up? Close it and carry on. Filling in a form or finding the right person feels like more trouble than the thing itself.
The result is that low-level events are not reported at all, and only the major incidents get reported, usually because they cannot be ignored. Everything that might have warned you earlier is lost.
The other reasons are real too. Some people do not recognise an event when they see one. And some fear blame, especially for their own mistakes, which is why the disciplinary approach under control 6.4 matters so much.
Make reporting easy
If reporting takes more than a minute, it will not happen. The aim is to make it the easiest thing to do:
- A report button in email. One click sends a suspicious message to whoever reviews it. Microsoft 365 and Google Workspace both support this.
- One place for everything else. A dedicated email address, a chat channel or a short form. Not a ten-field ticket.
- A named person, for anyone who would rather just tell someone.
- Clear examples of what to report, in the induction and in awareness training: suspicious emails, lost devices, mis-sent information, unusual behaviour from systems, anything that looks wrong.
- A thank-you. Every report gets acknowledged, and people who report are thanked publicly when appropriate. What gets rewarded gets repeated.
- An explicit no-blame message for honest mistakes reported promptly.
Let the tools do some of the work
People are not the only source of events, and they should not have to be. Automated event handling and alerting tools can make life much easier, because they reduce how much depends on a human noticing something and deciding to report it. Most small businesses already have more of this than they use:
| Source | Examples | How they reach you |
|---|---|---|
| People | Suspicious emails, odd calls, a lost phone, a mis-sent email, a door left open, something that “just looks wrong”. | A reporting route staff actually use: report button, short form, chat channel, a named person. |
| Systems | Blocked sign-ins, impossible travel alerts, malware detections, unusual file activity, failed backups. | Automated alerts from the tools you already have, routed to someone who looks at them. |
| Suppliers | Your IT provider or a SaaS vendor tells you about something affecting you. | Contractual notification, received by a named contact. |
Microsoft 365 and Google Workspace both generate alerts for risky sign-ins, malware, mass downloads and suspicious forwarding rules. Endpoint protection raises its own alerts. Backup tools report failures. The gap is usually not the alerts but who receives them. Make sure each one goes to someone who will look, and that what they find is logged in the same place as staff reports, so you get one picture.
Where reports go next
A report is the start, not the end. Each one should be logged and assessed under control 5.25: is this just an event, or is it an incident? Most will be closed quickly. The few that are incidents move into your response process under control 5.26, and some have external reporting duties of their own: personal data breaches to the ICO within 72 hours where required, significant cyber incidents to the NCSC, and crimes to Report Fraud (England, Wales and Northern Ireland) or, in Scotland, Police Scotland.
The log of reported events is also your evidence for this control. A steady stream of minor reports is a sign of a healthy reporting culture. An empty log, in an organisation that receives phishing emails every day, is a sign that something is not working.
Incident Log and Response Roles Download
For this control, the incident log is where every report goes, however small; a log of minor, closed reports is your evidence that reporting works.
What auditors will look for
I look at the reporting log first; an empty one tells me as much as a full one.
- The reporting mechanism. What is it, and is it easy to use?
- Awareness. I will ask staff how they would report a suspicious email or a lost laptop. Hesitation tells me a lot.
- The log. What has been reported in the last few months? If the answer is nothing, I will ask why.
- Automated sources. Which alerts do your systems raise, and who receives them?
- Follow-through. Pick a report: was it acknowledged, assessed and closed or escalated?
Common issues
- An empty event log, in a business that receives phishing emails every day.
- A reporting process so formal nobody uses it.
- Staff who do not know how to report, or think only serious incidents count.
- Alerts from cloud platforms going to an unmonitored mailbox.
- Reports never acknowledged, so people stop making them.
- Honest mistakes punished, so people hide them.
The self-check
If something odd happened today, would anyone tell you?
- How many security events were reported last month?
- How long does it take a member of staff to report a suspicious email?
- Who receives the security alerts from your email and cloud platforms?
- Would someone who sent client data to the wrong person report it straight away?
- What happened to the last thing that was reported?
The first is the one to sit with. If the answer is zero, the question is not whether events happened, but why nobody told you.
The branch office that kept it to itself
During my years running support at an education charity, we had a hub-and-spoke network, with small offices around the UK connecting back to head office. One branch office picked up a virus. Staff there were seeing the warnings, but rather than calling the helpdesk they tried to deal with it themselves. By the time we found out, it had spread far enough that we had to cut that office off from the network and send someone to site to clean it up before it could be reconnected.
Nobody did anything malicious; they thought they were helping. What was missing was a simple, well-known expectation: if you see something odd, tell the helpdesk straight away, and you will not be blamed for it. An early call would have cost minutes. The silence cost that office its connection and a site visit.
The pattern I see most is not an organisation with no events; everyone has event logs, whether they look at them or not. It is an organisation with no recorded incidents. Of the roughly 30 organisations I have audited or implemented ISO 27001 for since 2024, only around one in five was actually recording security incidents (see my findings). The rest tell me “Oh, we haven’t had any”, and I think: really? Over a whole year, not one phishing click, lost phone or email sent to the wrong person?
Usually the problem is that nobody has said what counts. Here are the kinds of events I would expect staff to report, and how often they turn out to be incidents. Put something like this in your reporting guidance, and you will start seeing reports.
| What happened | Report it? | Likely to be an incident? |
|---|---|---|
| A phishing email arrives and nobody clicks | Yes | Usually not; log it and warn others |
| Someone clicks a phishing link or enters their password | Yes, immediately | Often; reset credentials and check sign-ins |
| A laptop or phone is lost or stolen | Yes, immediately | Often; depends on encryption and what was on it |
| An email or file goes to the wrong person | Yes | Often, if it holds personal or confidential data |
| An unexpected MFA prompt or sign-in alert | Yes | Possibly; someone may have your password |
| A malware or antivirus alert | Yes | Possibly; check whether it was blocked |
| A stranger following staff through a secure door | Yes | Usually not, unless something is missing |
| A supplier tells you it has had a breach | Yes | Possibly; depends on what data it holds of yours |
| A password shared or written down where others can see it | Yes | Usually not; change it and log it |
| Personal data found somewhere it should not be | Yes | Possibly; may need assessing under UK GDPR |
Every report gets logged and assessed under control 5.25. Most will be closed quickly. That is fine; the log of small, closed reports is your evidence that the reporting route works.
How control 6.8 links to other clauses and controls
- Control 5.24, Information security incident management planning and preparation. The plan that reporting feeds.
- Control 5.25, Assessment and decision on information security events. Every report is assessed here.
- Control 5.26, Response to information security incidents. What happens when a report turns out to be an incident.
- Control 6.3, Information security awareness, education and training. How people learn what and how to report.
- Control 6.4, Disciplinary process. Used carefully, so it does not stop people reporting.
- Control 8.16, Monitoring activities. The automated side of spotting events.
Frequently asked questions
What counts as an information security event?
Anything that might indicate a breach of security or a failure of controls: suspicious emails, lost devices, mis-sent information, unusual system behaviour, failed backups, or something that simply looks wrong. Most turn out to be minor, which is fine.
Should staff report events that turn out to be nothing?
Yes. Reports that turn out to be nothing are part of a healthy reporting culture. Thank people for them; the alternative is that they stop reporting the ones that matter.
Do automated alerts count for control 6.8?
Control 6.8 is about people reporting, but automated alerts complement it and reduce the load. Make sure alerts reach someone, and log them alongside staff reports.
What if we have had no events at all?
It is very unlikely you have had none. More likely they were not reported or not recorded. An auditor will see an empty log as a sign the reporting mechanism is not working.
Sources and further reading
Official legislation, standards and guidance referred to on this page.
- ISO/IEC 27002:2022. The implementation guidance that accompanies the controls.
- Incident management. NCSC guidance on preparing for and responding to incidents, including encouraging reporting.
- Report a cyber incident. The NCSC reporting service for significant cyber incidents.
- Report a breach. ICO guidance on assessing and reporting personal data breaches.
- Report Fraud. The national service for reporting cyber crime and fraud, which replaced Action Fraud.
- ISO/IEC 27001:2022, Information security management systems. The standard itself, published by ISO.
Internal Audit Service
Get an independent view of your ISO 27001 ISMS before you go into an audit.
“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“
– Quartile.
✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement
✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price
