ISO 27001 Annex A 6.8 information security event reporting

The due-diligence questionnaire asks how your staff report security events. Your honest answer is a Slack message pinned in March and an incident log with nothing in it. Annex A 6.8 information security event reporting is the control an auditor tests by stopping a random employee in the corridor and asking how they would raise the alarm.

This guide shows what the control asks for, how to build two or three channels into one audited log, the no-blame culture most guides skip, and what a Stage 2 auditor samples. It is written for security and compliance leads at UK firms of 25–250 staff who want an audit-ready process without a SIEM or an enterprise bureaucracy.

What does ISO 27001 Annex A 6.8 require?

ISO 27001 Annex A 6.8 requires an organisation to give everyone a fast, well-known route for reporting observed or suspected information security events. Sitting in the People Controls theme, it is the front door to incident handling: staff report, someone responds, and the report is logged for triage under the wider incident process.

Your people see trouble before your tooling does: the odd email, the propped door, a system behaving strangely, their own mistake. The control asks for three things: a channel everyone knows, a contact that responds, and reporting fast enough for the response to matter.

The reportable set is deliberately broad, because at the moment of observation nobody knows which reports are serious:

• Suspected breaches and policy violations
• Human error, including your own
• Physical security lapses
• Changes made outside change control
• Malfunctions and access anomalies
• Suspected weaknesses and possible malware

Annex A 6.8 works as a detective control: it surfaces events that have already begun, using people instead of sensors. It protects confidentiality, integrity and availability alike, because early sight limits damage of every kind.

Three neighbours sit around it. Incident planning under Annex A 5.24 and the assessment and decision on information security events under Annex A 5.25 consume what staff report, while Annex A 6.3 awareness training is how everyone learns the route exists. Most of this is good practice you already want; the control asks you to make it findable and evidenced.

What is the difference between a security event and a security incident?

A security event is anything observed that looks suspicious: an odd email, a misbehaving control, a mistake. A security incident is an event that triage confirms has real impact on your information. Staff report events; the triage step, owned by a named person, decides which events become incidents.

Define both terms once, in your incident management procedure, and use them identically in training. The definitions matter because they tell staff what not to decide. Nobody reporting a strange email should have to judge whether it is serious.

Take a reported phishing email. Triage might find it was blocked and never opened, which stays an event. If someone entered their password, the same report becomes an incident.

A triage decision usually lands in one of three places:

• Closed as an event: no impact found, with the reason recorded in the log.
• Escalated as an incident: impact confirmed and the report handed to the incident process.
• Held for information: the reporter is asked a follow-up question before a decision.

Muddled terms create two failure modes. Staff who think they must be sure before reporting self-filter, and breaches go unlogged. Staff who think every report is an incident, or that judging severity is their job, freeze, and over-reporting paralysis sets in. A named triage owner removes both: reporters describe what they saw, and one accountable person decides.

Should employees test a suspected vulnerability before reporting it?

No. Staff report suspected weaknesses; they never probe them to see whether they are real. Well-meaning verification can take systems down, destroy forensic evidence and amount to unauthorised access, leaving the individual legally exposed. Report first, then let the named owner investigate under a controlled process.

Each harm is concrete. A well-meaning scan or password guess against a production system can lock accounts or take a service down. Poking at a compromised machine overwrites the logs and timestamps an investigator needs. And testing a weakness you were never authorised to test exposes the individual personally, not just the company.

Say this explicitly, in both the procedure and the training. The helpful engineer who "just checks" before reporting is the likeliest offender, which makes the rule protection for them as much as for your systems.

A good report contains what the person already knows, with no further action:

• What they saw, and where.
• When they saw it.
• Any screenshot or message they already hold.
• What they did, if anything, including clicks.

How do you set up Annex A 6.8 information security event reporting channels?

Offer two or three channels everyone knows — a #security chat channel in Slack or Teams, a security@ alias, and a phone route for out-of-hours and lost devices — all feeding one ticketing log. Fewer, well-publicised channels beat an exhaustive menu nobody remembers, and contractors need the same route.

Each channel has its own job:

• Chat channel: a #security channel in Slack or Teams, for the quick "is this odd?" report from someone already at their desk.
• Email alias: security@ for forwarded phishing, attachments and anyone outside your chat workspace.
• Phone route: for out-of-hours events and lost devices, when the laptop holding the chat app is the thing that has gone missing.

Test the phone route before you need it. Ring the number at an odd hour, confirm who answers, and check that the call produces a ticket in the same log as the chat reports.

Extend the route to contractors, temporary staff and supplier staff who touch your systems. Put it into onboarding packs and supplier contracts, so the people with the least context on your organisation still know whom to tell.

We would treat the build as a few days' work once the incident procedure exists, and build the two together, because the reporting route is that procedure's front door.

The usual failure is quieter than a missing channel. The route was mentioned once, at induction, three years ago, and now neither staff nor contractors can name it. Pin it where people work, repeat it in annual awareness training, and use phishing-simulation results to test whether people really know it.

A reporting channel nobody has used is a policy, not a control.

Why does a no-blame culture and a closed feedback loop matter for event reporting?

Blame switches off your early-warning system: people who fear consequences hide the clicked link until it becomes a compromise. A no-blame stance stated by leadership, plus acknowledging every report, telling the reporter the outcome and thanking them, keeps reports arriving. Technical alerting alone cannot replace this human layer.

The arithmetic is simple. A clicked phishing link reported in five minutes is a password reset. The same link never reported is a quarter-long compromise discovered by a customer. Sensors see what sensors see; people see the rest, and they share it only when sharing feels safe.

Blame doesn't prevent mistakes. It only delays the news of them.

The blame reflex rarely looks dramatic. It is a raised eyebrow, a mention in a team meeting, mandatory retraining after a self-report. One such episode is remembered for years, and it guarantees the next mistake goes unreported.

So the stance has to come from the top and be honoured in practice. Leadership says, in writing and aloud, that admitting a mistake will not be punished, then behaves that way the first time someone confesses to a lost phone.

No-blame is not no-accountability. The mistake happens either way; the only variable is whether you hear about it in minutes from the employee or in months from a stranger.

Closing the loop takes three actions every time:

1. Acknowledge every report, false alarms included, so the reporter knows it arrived.
2. Tell the reporter the outcome once triage decides: closed as harmless, or escalated.
3. Thank them, publicly where the reporter is comfortable with that.

A report that vanishes into a void teaches people not to bother next time, and the log empties without anyone deciding it should. The acknowledgement and outcome messages also become the feedback evidence an auditor asks for.

What information should be documented in an incident log?

Each log entry should carry a timestamp, a unique reference, the reporter, a description of what was observed, the triage decision and who made it, the escalation or closure outcome, and when the reporter was informed. One log, ideally your existing ticketing system, makes every report traceable end to end.

The NCSC incident management guidance advises keeping a careful record of the response, the decisions made, the actions taken and the data captured or missing, because it proves useful in post-exercise reviews. A log that records the triage decision and its owner gives you that record from the very first report.

Each field answers a question someone will eventually ask. The timestamp and reference let an auditor trace one report from start to finish. The triage decision and its owner show that a named person made the call. The reporter-informed date proves the loop closed.

The common pitfall is no central log. Reports scattered across DMs, memory and inboxes cannot be reconstructed at audit and are useless for trends. Screenshots of Slack threads are not an audit trail.

Alongside the log, keep this evidence set ready:

• The incident management procedure, showing channels, definitions, severity tiers and escalation path.
• The event log itself, with timestamps, references and triage outcomes.
• Onboarding and training material showing staff and contractors are told the route, plus phishing-simulation reporting rates.
• The escalation matrix with named roles, and proof that an out-of-hours path exists.
• Records of reporter feedback, and of periodic log reviews feeding the risk register.

Start the log the day the channels go live. History takes months to accumulate, and you cannot backfill it credibly.

An empty incident log isn't proof of a secure company. It's proof of a silent one.

How should triage and out-of-hours escalation work against the 72-hour ICO clock?

Name a triage owner with a deputy, set simple severity tiers and define who is woken, and for what, at 2 a.m. UK GDPR requires notifying the ICO within 72 hours of becoming aware of a notifiable personal data breach, so intake that waits until Monday puts the deadline at risk.

The ICO personal data breach reporting guidance sets the standard as without undue delay and, where feasible, within 72 hours of becoming aware. The same guidance expects robust internal reporting procedures and an investigation treated as urgent. A report left unread in a queue over a weekend meets neither expectation.

Four decisions make the pathway work:

• Triage owner and deputy: a security lead or managed provider, with named cover for leave.
• Severity tiers: keep to three, such as log and review next working day, respond today, and wake someone now.
• Out-of-hours path: state who is woken, by what means and for which tier.
• Authority to act: the person who answers can lock a lost device or isolate an account without waiting for approval.

The pitfall is a procedure that is current while the escalation contacts are two reorganisations out of date. The rota names someone who left, the deputy changed teams, and the first real call goes unanswered. Tie a contact check to every reorganisation and every joiner, mover and leaver event.

What do auditors sample for A.6.8 at a Stage 2 audit?

Auditors trace log entries end to end — report received, triage decision, escalation or closure, reporter informed — and interview random staff about the channel. An empty log is read against headcount and phishing-simulation volume. Most certification bodies grade a missing mechanism, or staff who cannot name it, as a major nonconformity, and patchy records as minor.

Expect questions like these, some put to you and some to whoever the auditor meets in the corridor:

• "How would anyone here report something suspicious?"
• "Show me your event log for the last six months, and walk me through how these three were triaged."
• "What is the difference between an event and an incident in your process, and who decides?"
• "Someone loses a laptop at 11 p.m. on Friday. What happens?"
• "What does a reporter hear back, and when?"

The Friday question tests your out-of-hours path. A good answer names the phone route, the person it reaches, the device-lock step and the ticket that records it, all in under a minute.

Zero reports in a year from fifty people means the channel isn't known or isn't safe, not that nothing happened. A handful of trivial entries beats a pristine blank.

The logic is that a missing mechanism means the requirement is not met at all. Missing timestamps, patchy feedback to reporters or an undocumented out-of-hours path are minor on their own, but several minors in the same area can add up to a major.

Before the audit, run the sample yourself. Pick three entries, walk each from report to feedback, and ask two colleagues outside security how they would report something. If either hesitates, your awareness push has not landed.

How can GRC engineering automate event reporting?

Engineered intake puts reporting where people already work: a Slack or Teams shortcut or mail-client report button files the event with evidence attached in two clicks. Every channel auto-logs to the ticketing system, severity tags drive escalation, reporter notifications fire from the workflow, and trend telemetry flags a channel going quiet.

Two clicks is not a nicety. Friction suppresses reporting, and removing steps is what moves reporting rates. The design is also self-evidencing: the ticket, timestamp, attachment and notifications are the audit trail, produced as a by-product.

A build order that works at 25–250 staff:

1. Wire the entry points (chat shortcut, mail-client report button, security@ alias) to one ticket queue.
2. Generate timestamp and reference automatically, so no one types them.
3. Map severity tags to the out-of-hours page, so escalation needs no human dispatcher.
4. Fire acknowledgement and outcome messages from the ticket workflow.
5. Chart reporting rate, time-to-triage and category mix monthly, and feed the chart into management review.

Because every step is a workflow event, the Stage 2 sample becomes a query rather than an archaeology exercise. Pull ten tickets, show the timestamps, the triage owner and the notification sent. A 30-person firm can do this with a chat shortcut, a ticketing form and two automation rules; a 250-person firm adds the mail-client button and a rota integration.

The human layer stays human. Designing the reporting and escalation model, setting the no-blame tone from leadership and owning triage judgement belong with a fractional CISO, while the buttons, auto-logging, closed loops and telemetry are what GRC engineering builds.

At this scale, a self-evidencing channel satisfies both auditors and enterprise customers reading your questionnaire answers.

Frequently asked questions