What is ISO 27001 Annex A 6.8 – Information Security Event Reporting?
ISO 27001 Annex A 6.8 requires organizations to provide a mechanism for personnel to report observed or suspected information security events through appropriate channels.
The objective is simple:
People should know what to report, when to report it, and how to report it.
An information security event may be something that appears unusual, suspicious, or potentially harmful, even if it has not yet been confirmed as a security incident.
Examples include:
- Suspected phishing email
- Suspicious login notification
- Lost or stolen laptop
- Lost security key
- Malware alert
- Accidental disclosure of information
- Unexpected access to a system
- Misdelivery of an email containing confidential information
- Unusual system behavior
- Suspected credential compromise
- Unauthorized software installation
- Suspicious phone call or social-engineering attempt
- Possible data leakage
Simple Explanation
Employees do not need to determine whether something is a security incident. They need to recognize and report something suspicious.
The security team can then assess the event and determine what action is required.
Why is Annex A 6.8 Important?
Employees are often the first people to notice unusual activity.
For example:
An employee receives:
“Your Microsoft 365 password has expired. Click here immediately.”
The employee notices that the sender looks suspicious.
The employee should not need to determine whether this is:
- Phishing
- Credential theft
- Malware
- Social engineering
- A security incident
The employee’s responsibility is to report it.
The security team can investigate.
Without effective reporting
An organization may experience:
- Delayed incident detection
- Lost investigation time
- Unreported phishing
- Delayed containment
- Missed evidence
- Increased data exposure
- Repeated security events
- Poor security awareness
Simple Principle
Report early. Let the security team decide how serious the event is.
Information Security Event vs. Information Security Incident
This distinction is extremely important for ISO 27001.
Information Security Event
An observable occurrence that may be relevant to information security.
Examples:
- Suspicious email
- Multiple failed login attempts
- Unexpected password-reset notification
- Lost laptop
- Antivirus alert
- Unusual application behavior
An event does not automatically mean that a security incident has occurred.
Information Security Incident
An event or series of events that has been assessed as having an actual or potentially significant information security impact and requires incident response.
For example:
Employee receives phishing email
↓
Employee reports it
↓
Security team investigates
↓
Determines credentials were entered
↓
Security incident identified
This is why A.6.8 is primarily about reporting, while Annex A 5.25 and 5.26 address assessment and response.
What Does Annex A 6.8 Require?
The organization should establish an appropriate reporting mechanism that enables personnel to report information security events.
The reporting process should be:
- Easy to understand
- Accessible
- Known to personnel
- Appropriate to the organization’s size
- Available through suitable channels
- Connected to incident/event assessment
- Supported by appropriate responsibilities
- Protected against unnecessary disclosure
The organization should make clear:
What should be reported?
Who should receive the report?
How should it be reported?
How quickly should it be reported?
What information should be included?
What happens after reporting?
Employees should not be expected to perform technical investigation themselves.
What Should Employees Report?
A practical reporting policy can include categories such as:
1. Phishing and Social Engineering
Report:
- Suspicious emails
- Suspicious links
- Fake login pages
- Unexpected MFA requests
- Suspicious phone calls
- Impersonation attempts
2. Account Security
Report:
- Unexpected password-reset notifications
- Unknown login alerts
- MFA prompts that were not initiated
- Suspicious account activity
- Suspected credential compromise
3. Device Security
Report:
- Lost laptop
- Stolen laptop
- Lost mobile device
- Malware alerts
- Suspicious software
- Unexpected system behavior
4. Information and Data
Report:
- Information sent to the wrong person
- Confidential information accidentally exposed
- Unauthorized access
- Lost documents
- Unauthorized sharing
- Suspected data leakage
5. Physical Security
Report:
- Unauthorized person in restricted areas
- Lost access card
- Lost security key
- Suspicious activity around offices or equipment
6. System and Application Events
Report:
- Unexpected system behavior
- Unusual access
- Security alerts
- Configuration changes that were not expected
- Suspected compromise
Activities Required to Implement Annex A 6.8
Step 1: Define What Constitutes a Reportable Event
Create a simple list of examples.
For example:
“If you are unsure whether something is a security event, report it.”
This is particularly useful for startups because employees may not have security expertise.
Step 2: Define Reporting Channels
Employees should have an easy way to report events.
Possible channels include:
- Security email
- Security ticketing system
- Helpdesk
- Incident management platform
- Dedicated Slack/Teams channel
- Phone number for urgent events
- Security reporting form
- Manager escalation
A startup could use:
for normal reporting and:
Security Hotline / Phone
for urgent events.
The organization should define which channel should be used for different situations.
Step 3: Define Urgency
Not every event needs the same response time.
A simple model could be:
| Event | Reporting Expectation |
|---|---|
| Suspicious email | As soon as practical |
| Suspicious login | Immediately |
| Lost laptop | Immediately |
| Suspected account compromise | Immediately |
| Accidental confidential disclosure | Immediately |
| Security software warning | Promptly |
| Minor security policy question | Normal support channel |
The exact timelines should reflect the organization’s risk and incident response arrangements.
Step 4: Make Reporting Easy
A complicated reporting process discourages reporting.
Avoid requiring an employee to complete a 15-page security form before reporting a phishing email.
A practical approach:
See Something Suspicious
↓
Report
↓
Security Team Assesses
↓
Security Team Responds
↓
Employee Provides Additional Information if Required
Step 5: Train Employees
Employees should know:
- What to report
- Where to report
- When to report
- What information to provide
- What not to do
- Who to contact for urgent situations
Training should emphasize:
When in doubt, report.
This connects directly with Annex A 6.3.
Step 6: Define Information to Include
A reporting form may ask for:
- Date/time
- Person reporting
- Description
- System involved
- Device involved
- What happened
- Suspicious email/message
- Screenshot where appropriate
- Attachment or evidence
- Actions already taken
- Urgency
Do not make the reporting form unnecessarily complicated.
The security team can gather additional information during investigation.
Step 7: Connect Reporting to Event Assessment
Once a report is received:
Report
↓
Initial Triage
↓
Event Assessment
↓
Security Event or Incident?
↓
Classify
↓
Escalate / Respond / Close
This connects A.6.8 with Annex A 5.25.
Step 8: Protect Reporting Information
Security reports may contain sensitive information.
For example:
- Employee information
- Customer information
- Screenshots
- Security logs
- Credentials
- IP addresses
- Incident details
Access to reports should therefore be appropriately restricted.
A phishing report should never become a new source of information leakage.
Step 9: Learn From Reports
Reported events can identify recurring problems.
For example:
If employees report 40 phishing emails in one month, the organization may identify a need for:
- Additional awareness training
- Email filtering
- MFA improvements
- Phishing simulations
- Technical controls
- Supplier investigation
This connects A.6.8 with A.5.27 – Learning from Information Security Incidents.
Startup Example
Consider a 40-person SaaS startup.
The organization has:
- Google Workspace
- GitHub
- AWS
- Slack
- Customer support platform
- HR system
An employee receives an unexpected MFA notification.
They did not attempt to log in.
The employee reports it through the company’s security reporting channel.
Workflow
Unexpected MFA Notification
↓
Employee Reports Event
↓
Security Team Reviews
↓
Check Authentication Logs
↓
Identify Suspicious Login Attempt
↓
Assess Risk
↓
Reset Credentials / Revoke Sessions if Required
↓
Investigate
↓
Determine Whether Incident Criteria Are Met
↓
Document
↓
Lessons Learned
The employee did not need to investigate the attack themselves.
That is the purpose of the reporting mechanism.
Startup-Focused Quick Summary
A startup can implement A.6.8 with a simple system.
1. Define
Tell employees what security events should be reported.
2. Provide
Create one or more simple reporting channels.
3. Train
Teach employees how and when to report.
4. Encourage
Make it clear that reporting suspicious activity is expected.
5. Triage
Security personnel assess reported events.
6. Escalate
Potential incidents are transferred into the incident-management process.
7. Record
Maintain appropriate records.
8. Learn
Use recurring reports to improve security controls.
Simple Startup Rule
See → Stop if appropriate → Report → Let Security Assess
Information Security Event Reporting Workflow
A practical workflow can look like this:
Security Event Observed
↓
Employee Recognizes Something Suspicious
↓
Report Through Approved Channel
↓
Initial Triage
↓
Event Assessment
↓
Is It a Security Incident?
/ \
No Yes
↓ ↓
Record/Close Incident Response
↓
Containment
↓
Investigation
↓
Recovery
↓
Lessons Learned
The important point is that reporting comes before classification.
Employees should not be discouraged from reporting because they are unsure whether something qualifies as an “incident.”
Example Information Security Event Reporting Matrix
| Event | Report? | Urgency |
|---|---|---|
| Suspicious phishing email | Yes | Promptly |
| Unexpected MFA request | Yes | Immediately |
| Lost company laptop | Yes | Immediately |
| Stolen phone used for work | Yes | Immediately |
| Accidental customer data disclosure | Yes | Immediately |
| Suspicious login notification | Yes | Immediately |
| Malware alert | Yes | Promptly |
| Unauthorized software | Yes | Promptly |
| Suspicious physical visitor | Yes | Promptly |
| Minor security question | Usually through normal support process | Normal |
| Known planned maintenance | No, unless unusual | N/A |
The exact reporting criteria and urgency should be defined according to the organization’s environment.
Security Event Reporting Form
A simple reporting form could contain:
| Field | Example |
|---|---|
| Reporter | Employee name |
| Date/time | 27 September 2026, 10:30 |
| Event type | Phishing |
| System/device | Company laptop |
| Description | Suspicious Microsoft 365 email |
| Action taken | Did not click link |
| Evidence | Screenshot/email |
| Customer information involved? | No/Unknown |
| Urgency | Normal/High/Critical |
| Additional comments | Any useful context |
The form should be simple enough that employees will actually use it.
Anonymous Reporting
Some organizations may provide anonymous or confidential reporting mechanisms where appropriate.
This may be useful for situations such as:
- Suspected insider misuse
- Deliberate policy violations
- Sensitive security concerns
- Conflicts of interest
- Concerns involving management
However, anonymous reporting is not necessarily required for every organization.
The reporting mechanism should reflect the organization’s:
- Size
- Risk
- Culture
- Legal requirements
- Governance model
Reporting Security Events From Remote Work
A.6.8 is particularly important for remote-working organizations.
Remote employees may encounter:
- Lost devices
- Suspicious home-network activity
- Phishing
- Fake MFA prompts
- Account compromise
- Accidental screen sharing
- Unauthorized access
- Lost security keys
Employees should know how to report these events even when they are not physically present in the office.
This connects directly with A.6.7 – Remote Working.
Reporting Security Events to Customers or Regulators
Employees should normally report security events internally through the organization’s established channels.
The organization should then determine whether an event requires:
- Customer notification
- Regulatory notification
- Law-enforcement contact
- Contractual notification
- Data protection notification
Employees should not independently notify customers or regulators unless the organization has authorized them to do so.
This connects A.6.8 with:
- A.5.5 Contact with Authorities
- A.5.24 Incident Management Planning
- A.5.25 Event Assessment
- A.5.26 Incident Response
- A.5.31 Legal and Contractual Requirements
- A.5.34 Privacy and Protection of PII
Audit Evidence for Annex A 6.8
An auditor may request:
Policies
- Information Security Policy
- Security Incident Management Policy
- Information Security Event Reporting Policy
- Acceptable Use Policy
- Remote Working Policy
Procedures
- Security Event Reporting Procedure
- Incident Reporting Procedure
- Incident Response Procedure
- Phishing Reporting Procedure
- Lost Device Reporting Procedure
- Security Escalation Procedure
Reporting Channels
- Security email
- Ticketing system
- Incident platform
- Reporting form
- Helpdesk process
- Emergency contact information
Operational Evidence
- Security event reports
- Phishing reports
- Lost device reports
- Suspicious login reports
- Incident tickets
- Event triage records
- Escalation records
- Security investigation records
- Training records
- Awareness communications
Supporting Evidence
- Incident classification matrix
- Incident response plan
- Security contact list
- Incident response exercises
- Lessons-learned records
- Security metrics
Audit Checklist for Annex A 6.8
| Audit Question | Evidence |
|---|---|
| Is security event reporting formally defined? | Policy |
| Do employees know what to report? | Training / awareness |
| Are reporting channels available? | Email / ticket / form |
| Are urgent events identified? | Reporting procedure |
| Can remote employees report events? | Remote reporting mechanism |
| Are employees trained? | Training records |
| Is reporting easy to use? | Reporting workflow |
| Are reported events recorded? | Event/ticket records |
| Are events assessed after reporting? | Triage records |
| Are potential incidents escalated? | Incident records |
| Is sensitive reporting information protected? | Access controls |
| Are reporting responsibilities defined? | Roles and responsibilities |
| Are recurring events analyzed? | Metrics / review |
| Are lessons incorporated into security improvements? | Improvement records |
| Are legal/customer notification requirements considered? | Incident procedure |
Common Mistakes
1. Telling Employees to “Contact IT” Without Defining the Process
“Contact IT” may be too vague.
Employees should know:
- Who to contact
- How to contact them
- What constitutes an event
- How quickly to report it
2. Asking Employees to Decide Whether Something Is an Incident
This can delay reporting.
A better approach is:
Report suspicious events. Security personnel determine their classification.
3. Having a Reporting Email But No Monitoring
An email address such as security@company.com is not enough if nobody monitors it.
The organization should define ownership and escalation.
4. Making Reporting Too Complicated
A long form can discourage employees from reporting.
The first report should be easy.
Additional information can be collected later.
5. No Evidence of Actual Reporting
A policy alone does not demonstrate that the process works.
Auditors may ask:
“Show me an example of a security event that was reported and handled.”
Actual records are useful evidence.
6. Employees Fear Getting Into Trouble
If employees believe reporting mistakes will automatically result in punishment, they may hide events.
The organization should encourage timely reporting and distinguish between:
- Honest mistakes
- Lack of awareness
- Negligence
- Deliberate violations
This connects with A.6.4 – Disciplinary Process.
7. Ignoring Remote Workers
Remote employees need the same ability to report events as office-based employees.
8. No Feedback or Awareness
If employees report events but never hear anything afterward, reporting culture can weaken.
Organizations can use anonymized examples in security awareness training to demonstrate why reporting matters.
Practical Startup Implementation Model
A startup can implement A.6.8 using:
Define
Define reportable security events.
Provide
Create simple reporting channels.
Communicate
Tell employees exactly where to report.
Train
Teach employees what and when to report.
Receive
Monitor reporting channels.
Triage
Perform initial assessment.
Escalate
Move significant events into incident response.
Record
Maintain appropriate evidence.
Analyze
Identify recurring events and trends.
Improve
Use the information to strengthen controls and awareness.
Simple Model
Recognize → Report → Assess → Respond → Learn
Policy vs. Process vs. Evidence
| Layer | Example |
|---|---|
| Policy | Personnel must report suspected security events |
| Procedure | Employee submits an event through security email/ticket |
| Reporting Channel | security@company.com |
| Process | Security team triages the event |
| Incident Process | Confirmed incidents enter incident response |
| Evidence | Security ticket |
| Evidence | Phishing report |
| Evidence | Triage record |
| Evidence | Incident investigation |
| Improvement | Awareness/control update |
This distinction is important for ISO 27001.
Having a Security Incident Policy does not prove that employees actually know how to report events.
Relationship With Other ISO 27001 Controls
A.5.24 – Information Security Incident Management Planning and Preparation
Defines how the organization prepares for incidents.
A.5.25 – Assessment and Decision on Information Security Events
Determines whether a reported event becomes an information security incident.
A.5.26 – Response to Information Security Incidents
Defines the response once an incident is identified.
A.5.27 – Learning From Information Security Incidents
Uses incident experience to improve security.
A.5.28 – Collection of Evidence
Supports appropriate evidence collection during investigations.
A.6.3 – Security Awareness, Education and Training
Teaches employees what and how to report.
A.6.4 – Disciplinary Process
Addresses deliberate or repeated violations where appropriate.
A.6.7 – Remote Working
Ensures remote workers can identify and report security events.
A.5.5 – Contact With Authorities
Supports escalation when external authorities need to be contacted.
A.6.8 vs. A.5.25 vs. A.5.26
These controls can be understood as a sequence:
| Control | Main Question |
|---|---|
| A.6.8 | Did personnel report the suspicious event? |
| A.5.25 | What is the event, and does it qualify as an incident? |
| A.5.26 | How should the confirmed incident be handled? |
Example
Employee receives suspicious email
→ A.6.8: Employee reports it
→ A.5.25: Security team assesses it
→ A.5.26: If it is an incident, response begins
→ A.5.27: Lessons are identified afterward
This makes the relationship between the controls much easier to understand.
Questions an Auditor May Ask
“How do employees report a security event?”
Show the documented reporting channel.
“What types of events should employees report?”
Show examples from the policy or training.
“How quickly should serious events be reported?”
Show the defined escalation requirements.
“How are employees trained?”
Provide training records.
“Show me an actual reported event.”
Provide an appropriately redacted event/ticket record.
“Who monitors the reporting channel?”
Identify the responsible person/team.
“What happens after an employee reports an event?”
Demonstrate the triage and incident assessment workflow.
“How do you distinguish an event from an incident?”
Show the organization’s event assessment/classification process.
“Can remote employees report incidents?”
Demonstrate the remote-accessible reporting mechanism.
“What happens when an employee reports a mistake?”
Explain the organization’s incident assessment, corrective action and personnel processes.
Useful Documents and Resources
A startup implementing A.6.8 may maintain:
- Information Security Event Reporting Policy
[Insert Draft Document Link] - Information Security Event Reporting Procedure
[Insert Draft Document Link] - Security Event Reporting Form
[Insert Draft Document Link] - Security Incident Reporting Procedure
[Insert Draft Document Link] - Security Event Classification Matrix
[Insert Draft Document Link] - Security Incident Escalation Matrix
[Insert Draft Document Link] - Phishing Reporting Procedure
[Insert Draft Document Link] - Lost/Stolen Device Reporting Procedure
[Insert Draft Document Link] - Security Incident Contact List
[Insert Draft Document Link] - Security Event Register
[Insert Draft Document Link] - Security Incident Register
[Insert Draft Document Link] - Security Event Triage Checklist
[Insert Draft Document Link] - Security Incident Reporting Training Material
[Insert Draft Document Link] - Information Security Event Reporting Audit Checklist
[Insert Draft Document Link]
Startup-Focused Final Takeaway
Annex A 6.8 is about creating a culture and process where security concerns are reported early rather than discovered late.
A practical startup implementation is:
Define what should be reported
↓
Provide a simple reporting channel
↓
Train employees
↓
Encourage early reporting
↓
Triage reported events
↓
Escalate potential incidents
↓
Respond appropriately
↓
Record evidence
↓
Learn and improve
The key audit question is:
Can every relevant person quickly report a suspected information security event, and can we demonstrate what happens after that report is received?
For a startup, the goal is not to build a complicated SOC before it has the need for one.
The goal is to make security reporting simple, accessible, fast, and connected to a defined assessment and incident-response process.
If employees know something is wrong but do not know where or how to report it, the security control is incomplete.