In this guide, I will show you exactly how to implement ISO 27001 Annex A 6.8 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.
I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.
Key Takeaways: ISO 27001 Annex A 6.8 Information Security Event Reporting
ISO 27001 Annex A 6.8 requires organizations to provide a clear and timely mechanism for employees and contractors to report observed or suspected information security events. The goal is to catch potential threats early before they escalate into full-blown incidents. This is a critical “detective” control that relies on a culture of transparency: if an employee clicks a suspicious link or loses their ID badge, they must know how and who to tell immediately without fear of retribution.
Core requirements for compliance include:
- Timely Reporting: Events must be reported as soon as possible. Some regulations, like GDPR, have strict 72-hour windows for data breach reporting, making internal speed essential.
- Multiple Reporting Channels: You should provide accessible ways to report, such as a dedicated email (e.g., security@company.com), an anonymous online form, or a direct helpdesk phone number.
- Clear Definitions: Staff must be educated on what constitutes an “event” versus an “incident.” An event is a suspicious occurrence (like a phishing email); an incident is a confirmed security failure (like a ransomware attack).
- Assigned Responsibility: There must be a designated “Information Security Manager” or team responsible for triaging these reports and determining if they require a formal response.
- Audit Trail: Every report must be recorded, including the time it was received, the nature of the event, and the initial decision made by the security team.
Audit Focus: Auditors will look for “The Reporting Culture”:
- Staff Awareness: They will interview random employees and ask: “If you lost your laptop right now, who would you tell and how?”
- The Event Log: “Show me your log of reported events from the last six months. How many were classified as ‘incidents’?”
- Third-Party Access: They will check if contractors and temporary staff have been trained on your reporting procedures.
Event Classification Matrix (Audit Cheat Sheet):
| Security Scenario | Triage Classification | Required ISO 27001 Compliance Action | ISO 27001:2022 Control |
|---|---|---|---|
| Phishing Email Received | Event | Report to IT Security; block sender; initiate staff awareness alert. | 5.24 (Incident Management) |
| Laptop Left on a Train | Incident | Provision Remote Wipe; notify Legal/DPO; log in Incident Register. | 5.24 (Incident Management) |
| Suspected Data Leak | Incident | Invoke Incident Response Team; conduct GDPR/Regulatory assessment. | 5.24 (Incident Management) |
| Slow System Performance | Event | Triage for anomalies: investigate potential DDoS or resource breach. | 8.16 (Monitoring Activities) |
| Lost ID Badge / Key | Event | Revoke physical access immediately; issue replacement with new ID. | 7.2 (Physical Entry) |
Table of contents
- Benefits of implementing Information Security Event Reporting
- Watch the ISO 27001 Annex A 6.8 Tutorial
- ISO 27001 Annex A 6.8 Explainer Video
- ISO 27001 Annex A 6.8 Podcast
- ISO 27001 Annex A 6.8 Implementation Guidance
- How to implement ISO 27001 Annex A 6.8
- Event Classification Matrix
- How to pass the audit of ISO 27001 Annex A 6.8
- What the auditor will check
- Top 3 Mistakes People Make
- Applicability of ISO 27001 Annex A 6.8 across different business models.
- Fast Track ISO 27001 Annex A 6.8 Compliance with the ISO 27001 Toolkit
- ISO 27001 Annex A 6.8 FAQ
- Related ISO 27001 Controls
- Further Reading
- External Links
- ISO 27001 Annex A 6.8 Attribute Table
Benefits of implementing Information Security Event Reporting
The benefits of implementing ISO 27001 Information Security Event Reporting include:
- Reducing the risk of data breaches by catching events early
- Reduced cost of incidents by catching and managing events early
- Mitigating legal liability by acting and responding
- You cannot get ISO 27001 certification without it
- Protection of confidential information
- Building trust with employees and third parties
- Reputation Protection
Watch the ISO 27001 Annex A 6.8 Tutorial
In the video ISO 27001 Information Security Event Reporting Explained – ISO27001:2022 Annex A 6.8 show you how to implement it and how to pass the audit.
ISO 27001 Annex A 6.8 Explainer Video
In this beginner’s guide to ISO 27001 Annex A 6.8 Information Security Event Reporting, ISO 27001 Lead Auditor Stuart Barker and his team talk you through what it is, how to implement in and how to pass the audit. Free ISO 27001 training.
ISO 27001 Annex A 6.8 Podcast
In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001 Annex A 6.8 Information Security Event Reporting. The podcast explores what it is, why it is important and the path to compliance.
ISO 27001 Annex A 6.8 Implementation Guidance
You are going to have to
- implement a process for reporting information security events
- educate people how to report events
- assign responsibility for managing information security events
- educate people who to report events to
Reporting Mechanisms
How security events should be reported?
The process for reporting incidents and events can take many forms and you may choose one, some or all of them. Examples of appropriate channels include reporting via:
- an on line form
- a telephone number
- messenger / chat
Reporting Timeframe
How quickly should you report suspected or actual events?
People should report suspected or actual information security events as soon as possible / at the first opportunity. Significantly, there are some laws and regulations that have very specific timelines for reporting and what needs to happen, such as the GDPR so the guidance is to tell people report as soon as they can. This includes out of hours and at weekends.
Event Reporting
Who are security events are reported to?
Internal Reporting
Typically incidents will get reported to the information security manager. While in a larger organisation or mature organisation the first point of call is usually a unified help desk or support function that acts as the coordinator and gatekeeper and then allocates that ticket to the information security manager.
Reporting includes:
- IT Service Desk: The central point for incident reporting and management
- Chief Information Security Officer (CISO): Oversee incidents and incident response
- information security manager: Management of security incidents and usually the first point of contact
- Legal: Management of any legal implications of security incidents
External Reporting
External reporting is done under the guidance and direction of the legal department or representative and often includes:
- Law enforcement
- Regulators
- Customers
- Suppliers
Event Definition
What types of events should be reported?
The guidance should be that if in doubt, report it. Better to air on the side of caution. That said, the kind of information security events that should be reported include but are not limited to:
- Actual or suspect data breach
- Information Security Controls that are not working
- Loss of device
- Emailing the wrong person
- Physical security breach
- Virus infection
- Malware infection
- Systems not working as intended
- Ransomware
- Phishing email / clicking a link
Event Investigation
Who is responsible for investigating security events?
The responsibility for investigating security events will depend on the organisation’s specific structure and processes. However, it is typically assigned to a designated security team or individual.
How to implement ISO 27001 Annex A 6.8
Implementing ISO 27001 Annex A 6.8 ensures that security anomalies and suspected weaknesses are communicated through formal channels without delay. This proactive approach allows the Information Security Management System (ISMS) to mitigate threats and vulnerabilities before they escalate into significant data breaches or system outages.
1. Formalise the Information Security Event Reporting Policy
Establish a documented procedure that defines what constitutes a security event or weakness and provides clear instructions on how to report them.
- Draft a policy that distinguishes between observed security events (e.g., a door left propped open) and suspected weaknesses (e.g., an unpatched server).
- Define mandatory reporting channels such as a dedicated security email alias, a web portal, or an internal telephone line.
- Incorporate a “no-blame” culture statement to encourage staff to report accidental security breaches without fear of immediate reprisal.
2. Provision a Centralised Reporting Portal and Logging Tool
Deploy a technical infrastructure to capture, track, and archive all security event reports for auditability and rapid triage.
- Utilise a ticketing system or an Incident Management System (IMS) to assign unique tracking IDs to every report.
- Configure Role-Based Access Control (RBAC) or specific IAM roles to ensure that only authorised security personnel can view sensitive report data.
- Enable automated timestamping and logging to create an immutable audit trail for external certification auditors.
3. Define Technical Categorisation and Escalation Criteria
Create a structured matrix to prioritise reported events based on their potential impact on the Confidentiality, Integrity, and Availability of data.
- Establish severity levels (e.g., Low, Medium, High, Critical) to guide the speed of the required response.
- Formalise escalation paths that link specific event categories to the appropriate responders, such as the CISO, IT Operations, or the Legal department.
- Document out-of-hours contact procedures to ensure that critical events reported during weekends or holidays are addressed immediately.
4. Execute Mandatory Staff Training and Awareness Programs
Regularise training sessions to ensure that all employees and contractors understand their reporting obligations and can recognise security anomalies.
- Deliver security inductions for new starters that include a walkthrough of the reporting tools and escalation contacts.
- Conduct phishing simulations and social engineering tests to validate that staff follow the reporting chain when faced with a threat.
- Distribute physical or digital assets, such as intranet guides, to keep reporting procedures top-of-mind for the entire workforce.
5. Implement a Feedback Loop and Continual Improvement Process
Establish a process for reviewing reported events to identify systemic weaknesses and provide closure to the individuals who reported them.
- Formalise a feedback mechanism to notify the reporter once their submission has been triaged or resolved.
- Conduct monthly reviews of the event logs to identify trends that may require new technical controls or updated risk assessments.
- Update the ISMS risk register based on the findings from reported weaknesses to ensure the organisation remains resilient against evolving threats.
Event Classification Matrix
| Scenario | Classification | Why? |
| Phishing Email Received | Event | It happened, but no one clicked. |
| Laptop Left on Train | Incident | Data is potentially compromised. |
| Slow Internet | Event | Could be a glitch, or a DDoS (needs checking). |
| Ransomware Screen | Incident | Confirmed attack; activate Incident Response. |
| Lost ID Badge | Event | Potential risk, needs deactivating. |
How to pass the audit of ISO 27001 Annex A 6.8
To comply with ISO 27001 Annex A 6.8 and pass the audit you are going to implement the ‘how’ to the ‘what’ the control is expecting. You are going to:
- Implement your information security event reporting process
- Have the process approved by management
- Assign ownership of the process to competent resource
- Tell people about the process
- Include different channels for people to be able to report events
- Plan to review your process at least annually or if significant changes occur
- Keep records of your reported events
What the auditor will check
The audit is going to check a number of areas for compliance with ISO 27001 Annex A 6.8. Lets go through them
1. That you have documented your process for event reporting
What this means is that you will have a document that sets out what the process for event reporting is and includes the roles and responsibilities are that are involved. It will cover the different ways in which events can be reported taking into account the culture and set up of the organisation. It will set out what needs doing and what will be done.
2. That you have allocated your roles and responsibilities
For the roles and responsible that you have defined and documented you are going to allocate people to them to do the work. Has each defined role been allocated to someone and can you say who if asked? In addition it will check that those people are competent to perform the roles.
3. That events were responded to in a timely manner
The definition of a timely manner will come down to your own circumstances but you are going to consider any legal or regulatory constraints that may be imposed. For example consider requirements for reporting data breaches under GDPR in 72 hours. The audit will check the reporting and response to incidents and that any time requirements were met.
Top 3 Mistakes People Make
In my experience, the top 3 mistakes people make for ISO 27001 Annex A 6.8 are
1. You have no evidence that anything actually happened
There needs to be records and minutes of everything. For evidence, you are need a paper trail to show it was done. Make sure you have updated communication plans, records of events, records of how you responded to events and in what timeframe. If it isn’t written down it didn’t happen.
2. One or more members of your team haven’t done what they should have done
Before the audit check that all members of the team have done what they should have. For example, do they know where the process documents are? Have events been recorded and do you know where that record it. If events led to risks or continual improvement can you show the link and evidence it. Check!
3. Your document and version control is wrong
The following are good document mark up best practice
- Keeping your document version control up to date
- making sure that version numbers match where used
- having a review evidenced in the last 12 months
- having documents that have no comments in
Applicability of ISO 27001 Annex A 6.8 across different business models.
| Business Type | Applicability | Examples of Control Implementation |
|---|---|---|
| Small Businesses | Focuses on building a simple, no-blame culture where staff feel comfortable reporting basic security mistakes. The goal is to catch issues like lost keys or phishing clicks before they escalate into major data breaches. |
|
| Tech Startups | Critical for managing fast-moving cloud environments and remote teams. Compliance requires a more structured reporting mechanism that can handle technical anomalies and suspected software vulnerabilities. |
|
| AI Companies | Vital for protecting proprietary model IP and massive training datasets. Focus is on reporting sophisticated anomalies in data pipelines or unauthorized access attempts to GPU clusters. |
|
Fast Track ISO 27001 Annex A 6.8 Compliance with the ISO 27001 Toolkit
For ISO 27001 Annex A 6.8 (Information security event reporting), the requirement is for organizations to provide a mechanism for employees and third parties to report suspected or actual information security events in a timely manner. This is a critical detective control, if you don’t know an event has happened, you cannot manage the resulting incident.
| Compliance Factor | SaaS Compliance Platforms | High Table ISO 27001 Toolkit | Audit Evidence Example |
|---|---|---|---|
| Process Ownership | Rents access to event logs; if you cancel the subscription, your documented reporting history and standards vanish. | Permanent Assets: Fully editable Word/Excel Event Reporting Processes that you own forever. | A localized “Event Reporting Procedure” stored on your secure server defining how staff report PII leaks. |
| Technical Implementation | Mandates proprietary portals that often duplicate the functionality of your existing email, Slack, or helpdesk. | Governance-First: Formalizes your existing tools (Teams, Forms, Email) into an auditor-ready reporting framework. | An Event Classification Matrix showing how suspected phishing is triaged versus a lost laptop. |
| Cost Efficiency | Charges an “Incident Volume Tax” based on the number of reported events or portal users. | One-Off Fee: A single payment covers your reporting governance for 1 report a year or 1,000. | Allocating budget to security awareness training rather than a monthly software subscription for a “ticketing” portal. |
| Communication Freedom | Forces users into a specific SaaS interface, creating barriers to timely “in-the-moment” reporting. | 100% Agnostic: Procedures adapt to your stack—Slack, Teams, or a dedicated security@ email address. | The ability to evolve your reporting intake methods without reconfiguring a rigid SaaS compliance module. |
Summary: For Annex A 6.8, the auditor wants to see that you have a formal process for reporting events and proof that people know how to use it. The High Table ISO 27001 Toolkit provides the governance framework to satisfy this requirement immediately. It is the most direct, cost-effective way to achieve compliance using permanent documentation that you own and control.
ISO 27001 Annex A 6.8 FAQ
What is ISO 27001 Annex A 6.8?
ISO 27001 Annex A 6.8 is an operational control that mandates organisations establish formal procedures for personnel to report information security events through appropriate management channels as quickly as possible.
- It ensures that security anomalies are identified and communicated promptly.
- It requires that all employees, contractors, and third parties are aware of their reporting responsibilities.
- It acts as the primary “trigger” for the organisation’s incident response and management process.
- It covers both observed security events and suspected security weaknesses.
What is the difference between a security event and a security incident?
A security event is an identified occurrence that indicates a possible breach of security policy, whereas a security incident is a confirmed event (or series of events) that has a significant probability of compromising business operations.
- Event: A system log showing a failed login attempt or a door left propped open.
- Incident: A successful unauthorised database exfiltration or a total system outage caused by malware.
- Annex A 6.8 focuses on the reporting of the “event” so that the security team can determine if it constitutes an “incident.”
How quickly should security events be reported?
Under ISO 27001, security events must be reported “as quickly as possible,” which usually implies an immediate notification to the designated security contact upon discovery.
- Delays in reporting can allow a minor event to escalate into a catastrophic data breach.
- Immediate reporting preserves volatile evidence needed for forensic investigation.
- Most organisations define a specific “Golden Hour” or 24-hour window within their internal policies.
What should be included in an information security event report?
An effective security event report should provide enough technical context to allow the security team to triage the threat without over-complicating the initial notification.
- Description of the event or observed weakness.
- Date, time, and physical or digital location of the occurrence.
- Identification of the person reporting the event.
- Initial assessment of the potential impact (if known).
Do security weaknesses need to be reported under Annex A 6.8?
Yes, ISO 27001 specifically requires that personnel report suspected security weaknesses in systems or services in addition to actual observed events.
- Reporting weaknesses allows for proactive patching before a vulnerability is exploited.
- Examples include unencrypted sensitive files, outdated software, or lack of physical access controls.
- Personnel should be encouraged to report these without fear of reprisal to foster a strong security culture.
Can employees be penalised for reporting security events?
No, an effective ISO 27001 compliant ISMS should encourage a “no-blame” culture where reporting events is seen as a positive contribution to organisational security.
- Fear of punishment leads to non-reporting, which increases long-term business risk.
- Policies should clearly state that reporting an accidental error will not lead to automatic disciplinary action.
- Employee awareness training should reinforce that reporting is a mandatory contractual obligation.
Related ISO 27001 Controls
ISO 27001 Annex A 8.15 Logging
ISO 27001 Annex A 5.24 Information security incident management planning and preparation
ISO 27001 Annex A 5.25 Assessment and decision on information security events
ISO 27001 Annex A 5.26 Response to information security incidents
ISO 27001 Annex A 5.27 Learning from information security incidents
ISO 27001 Annex A 5.28 Collection of evidence
ISO 27001 Annex A 5.29 Information security during disruption
ISO 27001 Annex A 5.30 ICT readiness for business continuity
Further Reading
The complete guide to ISO/IEC 27002:2022
ISO 27001 Logging and Monitoring Policy Beginner’s Guide
External Links
Information Commissioners Office Incident reporting
ISO 27001 Annex A 6.8 Attribute Table
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
| Detective | Availability Confidentiality Integrity | Detect | Information security event management | Defence |
