Control Definition
The organization must provide a mechanism for personnel to report observed or suspected information security events through appropriate channels, and reports must be made in a timely manner.
Control Objective
To ensure that security events noticed by people are reported quickly and consistently enough for the organization to assess and act on them.
What This Really Means
Your monitoring stack watches systems. A.6.8 wires up the sensors no SIEM can replace: every employee, contractor, and visitor who notices something off — the email that almost fooled them, the laptop that vanished from a cafe table, the spreadsheet sent to the wrong client, the application behaving strangely on a Friday afternoon. People routinely see trouble before any dashboard does; this control decides whether what they see ever reaches someone who can act on it.
It is deliberately a people control, and a narrow one. The organizational machinery of incident management lives in A.5.24 through A.5.26 — plans, triage, response. A.6.8 cares about one thing: that an observation in someone's head travels to the security team fast. That takes three ingredients. First, one obvious channel — a button in the chat tool, a memorable email address, a helpdesk category — not a choice of five routes nobody remembers. Second, shared knowledge of what belongs in it: suspicious messages, lost or stolen devices, mis-sent information, unexpected system behavior, suspected malware, policy violations, weaknesses noticed in passing, even an unfamiliar person in the office. Third, a speed norm: report in minutes, even when unsure.
Two cultural rules make or break the control. The first is report first, diagnose never — personnel should not investigate a suspected event themselves, and emphatically should not probe a suspected weakness to confirm it is real, because the probing can cause damage and is indistinguishable from misuse in the logs. The second is no-blame handling: the person who clicked the link or mis-sent the file must believe, from observed behavior rather than posters, that reporting their own mistake is safer than hiding it. Organizations that punish honest error get silence, and silence is how small events grow into breaches.
When auditors test this control, documentation is the smallest part. The heart is whether a randomly chosen employee names the channel without hesitating, and whether the event register shows a living stream of reports from across the organization — false alarms and near-misses included — feeding triage under A.5.25. A register showing zero events for a quarter reads as a detection failure, not a clean bill of health.
Why It Matters
Most consequential incidents are noticed by a human before any tool raises an alert — a strange invoice, an unexpected MFA prompt, a colleague's oddly urgent request. The interval between that first human observation and the security team knowing about it is the cheapest place in the entire security program to buy speed, and speed determines blast radius: an attacker contained within the hour versus one with a weekend of dwell time.
The control also carries quiet legal weight: breach notification regimes around the world run on clocks measured in hours or days, and every one of those clocks silently assumes your internal reporting is near-instant. Where the reporting channel is weak, the failure pattern is consistent:
- •Detection stretches from minutes to weeks – early signals die in inboxes and hallway conversations while attacker dwell time accumulates
- •Small events compound into breaches – a mis-sent file recalled within the hour is an event; the same file discovered months later in a complaint is a notifiable incident with legal exposure
- •Regulatory clocks become unmeetable – external notification windows assume internal awareness is immediate; a report that sits in a helpdesk queue for two days has already spent the entire budget
- •Near-misses teach nothing – without no-blame reporting, the weakness that almost caused an incident stays in place until something exploits it
- •The sample test fails the audit – when interviewed staff cannot say where to report, no procedure document can save the control
Regional Compliance Context
India. The arithmetic here is unforgiving: CERT-In directions require specified categories of cyber incidents to be reported within 6 hours of noticing them — achievable only if internal event reporting happens in minutes, because an employee report that waits overnight in a general IT queue has already breached the window. Under the DPDP Act 2023, personal data breaches must be notified to the Data Protection Board of India and to affected data principals, and the mis-sent spreadsheet an employee reports may itself be the notifiable event — the internal channel feeds statutory duties directly.
Gulf. Saudi Arabia's PDPL and the UAE federal PDPL both impose breach notification duties on short regulator timelines; organizations in the region should treat employee event reporting as the first segment of those statutory clocks.
Implementation Guidance
Define What Counts as a Reportable Event — With Examples
Publish a one-page guide listing concrete situations: suspicious emails and messages, lost or stolen devices, information sent to the wrong recipient, unexpected system or account behavior, suspected malware, policy violations, weaknesses noticed in systems or processes, and unescorted strangers in work areas. Examples beat definitions — people recognize situations, not taxonomy.
Stand Up One Obvious, Low-Friction Channel
Create a single front door: a report button or workflow in your chat tool, a memorable address like security@yourcompany, or a dedicated helpdesk category — plus a phone path for urgent out-of-hours situations. Multiple equal channels dilute memory; one channel with several doors into it works. Reporting should take under a minute from any device.
Set the Speed Norm: Report First, Diagnose Never
Make the expectation explicit in policy and training: report immediately, even when unsure, and let the security team decide whether it matters. Be equally explicit about the inverse — personnel must not investigate suspected events themselves or probe a suspected weakness to confirm it, since probing can deepen the damage and looks identical to misuse in the logs.
Build the Receiving Side Before Promoting the Channel
Route every report into a ticketing queue or event register with timestamps, assign a triage owner, and define an acknowledgment SLA back to the reporter — within one business hour for urgent reports is a common norm. The handoff into formal assessment under A.5.25 should be a documented step, not an informal forward.
Anchor No-Blame Handling in Policy
State in writing that good-faith reports — including self-reporting one's own mistakes — will not trigger disciplinary action, and reserve the disciplinary process under A.6.4 for willful violations and concealment. Then prove it through behavior: one person quietly punished after self-reporting will silence a hundred future reports.
Embed the Channel in Training, Onboarding, and the Environment
Put the reporting channel in induction, annual awareness refreshers, and phishing simulation follow-ups — the moment after someone clicks a simulated phish is the best teaching moment the report button will ever get. Reinforce it ambiently: intranet homepage, posters, laptop stickers. Include contractors and on-site third parties, who see plenty and are told least.
Measure, Close the Loop, and Report Upward
Track report volume, time-from-event-to-report, and the share of near-misses; thank reporters and tell them what happened with what they raised. Publish anonymized good catches. Present the metrics in management review — rising report volume with falling time-to-report is what a healthy reporting culture looks like on paper.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.6.8:
Documentation
- Event reporting procedure naming the channel, what to report, and the expected timeframe
- Event register or ticket queue showing reported events with timestamps, acknowledgments, and triage outcomes
- Training and awareness materials teaching the reporting channel — onboarding deck, refresher content, posters or intranet page
- Good-faith / no-blame reporting statement in policy, with its communication record
- Reporting metrics presented in management review: volume, time-to-report, near-miss trends
Interviews
- Random employees across departments: you receive a suspicious email — what exactly do you do, and how fast?
- Security or triage owner on how reports are received, acknowledged, and escalated into incident assessment
- Service desk staff on how security reports are distinguished and routed differently from ordinary IT tickets
Observations
- An employee locates and uses the reporting channel end to end with a test message while the auditor watches
- The channel is visibly accessible — chat-tool button, intranet placement, posters in work areas
- Live review of the event queue: recency and spread of reports across the organization, not just from the IT team
Practitioner Insights
The audit test for this control is brutally simple: I ask three people in different departments what they would do with a suspicious email, and I watch how long they hesitate. Confident, instant answers mean the control is alive; pauses and guesses mean it exists only on paper. The counterintuitive maturity marker is volume — a healthy program shows a steady stream of reports, most of them false alarms and near-misses. When a management review proudly presents zero reported events for two quarters, I read that as a detection failure, not a security success.
A pattern I keep finding: security reports routed through the general IT helpdesk, where a possible account compromise sits in the same queue as printer tickets and gets a response in two days — long after any notification window has died. Give security reports a separate priority route and an acknowledgment the reporter can see within the hour, because silence trains people to stop reporting. And close the loop publicly: a short note saying someone reported this and here is what we did does more for reporting culture than any poster campaign.
Common Challenges & Solutions
Challenge
Employees stay silent because they fear blame, embarrassment, or simply looking paranoid.
Solution
Put a good-faith protection statement in the policy, have leadership repeat it, and visibly celebrate useful reports — including false alarms — as good catches. Separate honest error from willful violation explicitly in the disciplinary policy. Culture follows evidence: the first few well-handled self-reports do more than any awareness campaign.
Challenge
There are four different places to report — helpdesk, manager, IT email, security email — and reports die in the seams between them.
Solution
Collapse to one front door and turn the other routes into automatic forwards into it. Configure the helpdesk so any ticket tagged as security jumps the general queue. Then teach exactly one instruction in training: when in doubt, use the button.
Challenge
Reports vanish into a void — no acknowledgment, no outcome — so people conclude reporting is pointless.
Solution
Define an acknowledgment SLA the reporter can see (one business hour for the urgent channel is a workable norm) and close the loop with a short outcome note when triage finishes. Track acknowledgment times as a metric. People keep using channels that visibly respond.
Challenge
People sit on suspicious emails or lost devices for hours or days while they try to make sure it is a real problem.
Solution
Train speed over certainty relentlessly: the security team would rather close ten false alarms than learn about one real event a day late. Measure time-to-report in phishing simulations and publish the trend. Make the reporting flow faster than self-investigation — under a minute, from any device, with no ten-field mandatory form.
Challenge
During the audit, randomly sampled employees cannot name the reporting channel.
Solution
Drill the channel through every medium people actually see: onboarding, annual refreshers, posters, screen wallpapers, chat-tool pins. Run your own sample test quarterly — ask five random people what they would do with a suspicious email — and treat failures as a training metric. If your internal sample passes, the auditor's will too.
