ISO 27001 A.6.8 - Information Security Event Reporting

Requirement

“The organization shall provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner.”

Plain-language meaning

People need to know what might be a security event, how to report it, who to report it to, and what not to do. Reporting should be fast, simple, and no-blame enough that people do not hide mistakes.

Events are not only IT problems. An open safe, lost paper record, misdirected salary slip, suspicious visitor, strange system behavior, lost phone, or attempted social engineering can all matter.

Why this matters

Unreported events cause damage to grow. They also distort risk assessment because the organization thinks fewer events are happening than reality.

Minor events can reveal weak controls. If staff quietly fix or ignore them, the organization loses the chance to correct root causes before a major incident occurs.

Implementation guidance

1. Define what should be reported

Personnel should understand examples of reportable events and weaknesses.

Examples:

• lost or stolen device, document, badge, or media;
• misdirected email, file, or paper record;
• suspected phishing or social engineering;
• malware alert or unusual system behavior;
• unauthorized access attempt;
• open safe, unlocked cabinet, or exposed sensitive paper;
• wrong recipient receiving personal or confidential information;
• unavailable critical service;
• suspected policy violation;
• discovered vulnerability or weakness.

The definition should include physical, human, paper-based, verbal, supplier, and technical events.

2. Provide clear reporting channels

Channels may include:

• service desk;
• security mailbox;
• hotline or phone number;
• ticketing system;
• line manager route;
• incident portal;
• supplier/service-provider route where appropriate.

Contact points should be documented, available, and included in awareness training.

3. Use standard forms and minimum information

Reporting forms should be easy to find and easy to complete.

They should capture:

• reporter and contact details where appropriate;
• date and time observed;
• what happened;
• systems, locations, information, or assets involved;
• whether information may be exposed;
• immediate action taken;
• screenshots or evidence references where safe;
• urgency or impact indicators.

The form should also tell users what not to do, such as exploiting a weakness, probing further, deleting evidence, or sharing sensitive details in the wrong channel.

4. Promote no-blame reporting

People hide mistakes when reporting is punished by default. A no-blame reporting culture does not remove accountability for deliberate misuse, but it encourages early reporting of mistakes, weaknesses, and near misses.

This links to A.6.4 Disciplinary Process. Discipline should not discourage legitimate reporting.

5. Connect reporting to incident management

Reported events should be recorded, assessed, and investigated.

This links directly to:

• A.5.24 Information Security Incident Management Planning and Preparation;
• A.5.25 Assessment and Decision on Information Security Events;
• A.5.26 Response to Information Security Incidents;
• A.5.27 Learning from Information Security Incidents.

Reporting is not complete when the form is submitted. The event needs triage, response, root-cause analysis where appropriate, closure, and feedback where suitable.

6. Define external notification triggers

Some events may trigger legal, contractual, customer, regulator, or public notification obligations. The organization should define when escalation is needed and who decides.

Timescales matter. Some obligations start when the organization becomes aware of an incident, so late internal reporting can create external compliance failure.

Audit guidance

Auditors should verify that event reporting procedures, channels, forms, awareness, and response linkage exist and operate.

Audit testing should include:

• event reporting procedure;
• reporting channels and contact points;
• event report form or ticket template;
• training and awareness material;
• sampled personnel interviews;
• event/incident register;
• triage and response records;
• root-cause and corrective-action records;
• evidence that reporters receive feedback where appropriate;
• procedures preventing users from exploiting identified weaknesses;
• external notification criteria and escalation paths.

If the organization claims there were no events, the auditor should interview staff and test examples. “No reports” is suspicious unless the environment is tiny and the organization can explain why.

Evidence examples

Strong evidence

• Personnel can explain what an event is and how to report it.
• Reporting channels are easy to find and use.
• Report forms capture information useful for incident management.
• Reports cover physical, paper, human, supplier, and technical events.
• Events are recorded, triaged, investigated, and closed.
• Root causes and corrective actions are tracked.
• Training emphasizes timely reporting and not exploiting weaknesses.
• External notification criteria are linked to legal and contractual obligations.

Weak evidence

• Security events are only reported informally to IT.
• Staff think only cyberattacks count as security events.
• No reports exist and no evidence of awareness testing exists.
• Forms are hard to find or do not capture useful information.
• Reported events are not triaged or closed.
• Users are encouraged to prove weaknesses by exploiting them.
• No external notification criteria or timelines.

Common failures

Exam traps

Related controls and concepts

• A.6 People Controls MOC
• A.6.3 Information Security Awareness Education and Training
• A.6.4 Disciplinary Process
• A.5.24 Information Security Incident Management Planning and Preparation
• A.5.25 Assessment and Decision on Information Security Events
• A.5.26 Response to Information Security Incidents
• A.5.27 Learning from Information Security Incidents
• A.5.31 Legal, Statutory, Regulatory and Contractual Requirements
• A.5.34 Privacy and Protection of PII
• Information Security Event Report Form
• Information Security Event Reporting Channel Register
• A.6.8 Audit Evidence Pack
• A.6.8 Audit Checklist

KB-ready summary

• A.6.8 requires a timely reporting mechanism for observed or suspected information security events.
• Personnel need clear examples, channels, contact points, and reporting forms.
• Reporting should cover physical, paper, human, supplier, and technical events.
• No-blame reporting encourages early disclosure of mistakes and weaknesses.
• Reports should feed triage, incident response, root-cause review, and corrective action.
• Users should not exploit weaknesses to prove them.
• External notification triggers and timelines should be predefined.

Templates and checklists

• Information Security Event Report Form
• Information Security Event Reporting Channel Register
• A.6.8 Audit Checklist