A developer notices that a staging server is responding with unfamiliar error messages and unusual latency. They mention it casually to a colleague at lunch but do not report it formally. Two weeks later, the incident response team discovers that the server was compromised — the attacker used it as a pivot point to reach the production database. The developer’s early observation could have stopped the attack in its tracks. A.6.8 ensures that every observation reaches the right people through the right channel — quickly.
The control requires organizations to provide a mechanism for all personnel to report observed or suspected security events in a timely, consistent and effective manner.
What does the standard require?
The core requirements focus on four areas:
- Reporting mechanism. The organization must provide clear, accessible channels for reporting security events — email, ticketing system, hotline, web form or a combination.
- Universal responsibility. All personnel and users must understand that reporting observed or suspected events is their responsibility.
- Timeliness. Reports must be made as soon as possible. Delays reduce the organization’s ability to contain damage.
- No self-investigation. Personnel should report what they observed and leave the investigation to the incident-response team. Attempting to verify or test a suspected vulnerability can damage evidence or cause further harm.
In practice
Set up a reporting channel. At minimum: a dedicated email address and a short web form. For larger organizations: integrate with your ticketing system so that reports are automatically triaged. Publish the channel prominently — intranet home page, email signature, posters in the break room.
Define what to report. Give concrete examples: phishing emails, suspicious phone calls, unfamiliar devices on the network, lost laptops, tailgating at the entrance, unusual system behavior, suspected data leaks. Concrete examples lower the threshold for reporting.
Promote a no-blame culture. Explicitly communicate that reporting a false alarm is always welcome and will never have negative consequences. If employees fear being blamed for mistakes, they will stay silent — and real incidents will go undetected.
Acknowledge every report. Respond to the reporter within a defined timeframe (e.g. 4 hours during business hours). Acknowledging the report shows that the system works and encourages future reporting.
Measure and improve. Track the number of reports, the average response time and the ratio of substantiated incidents to total reports. Feed these metrics into the management review.
Typical audit evidence
Auditors typically expect the following evidence for A.6.8:
- Incident-reporting procedure — documented description of the reporting mechanism (link to Security Operations Policy in the Starter Kit)
- Communication materials — evidence the reporting channel was promoted (intranet pages, posters, training slides)
- Report log — list of received security-event reports with timestamps and status
- Response records — evidence that reports were acknowledged and triaged
- Awareness training materials — sections covering event reporting
- Phishing simulation results — reporting rates from simulated campaigns
KPI
% of employees who know how to report an IS event
Measured through surveys or awareness quizzes: what percentage of your personnel can correctly identify the reporting channel? Target: above 90%. Most organizations start at 40–60% and improve rapidly once the channel is promoted in awareness training and phishing simulations.
Supplementary KPIs:
- Number of security events reported per quarter (trending upward in the first year is positive — it means awareness is growing)
- Average time from event observation to report submission
- Phishing-simulation reporting rate (% of employees who report the simulated phishing email rather than ignoring or clicking it)
- Average time from report submission to first acknowledgement
BSI IT-Grundschutz
A.6.8 maps to BSI’s detection and response modules:
- DER.1.A3 (Defining reporting channels for security events) — requires that clear channels for reporting security events are established and communicated to all personnel.
- DER.1.A4 (Awareness of security events among employees) — requires that all employees are trained to recognize and report security events.
- DER.2.1.A9 (Reporting of security events) — requires that the reporting process is documented, tested and integrated into the incident-management workflow.
- DER.2.1.A20 (Timely reporting to top management) — requires that critical events are escalated to top management without delay.
Related controls
A.6.8 is the people-facing entry point to the incident-management chain:
- A.6.6 — Confidentiality or non-disclosure agreements: Suspected NDA breaches should be reported through this channel.
- A.6.7 — Remote working: Remote workers must have access to the reporting channel from any location.
Further connections: 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) and A.5.27 (Learning from incidents).
Sources
- ISO/IEC 27001:2022 Annex A, Control A.6.8 — Information security event reporting
- ISO/IEC 27002:2022 Section 6.8 — Implementation guidance for event reporting
- BSI IT-Grundschutz, DER.1 — Detection of security-relevant events