Annex A Controls

A.6.8 Information Security Event Reporting — Building a Culture That Reports

Alex Fuerst

01 Oct 2025 — 7 min read

The Reality Gap Between Procedures and Practice

I've certified organizations with pristine incident response procedures, elegant escalation matrices, and comprehensive security playbooks that collect digital dust because nobody reports anything meaningful. The infrastructure exists. The technology exists. But the cultural foundation doesn't. Here's what I consistently discover during Clause 9.2 internal audit reviews: you can deploy the most sophisticated SIEM solution available, but if your receptionist doesn't know they should report that suspicious phone call asking about your CEO's travel schedule, you've got a critical detection gap that no amount of technology will bridge.

Control A.6.8 Information Security Event Reporting isn't about creating another digital form or adding steps to an already complex procedure. It's about fundamentally rewiring how your organization thinks about security awareness at the operational level. This is human-centric security implementation at its core—and it represents one of the controls where I observe the widest disconnect between documented procedures and day-to-day operational reality.

What Control A.6.8 Actually Mandates

ISO/IEC 27002:2022 specifies that organizations must provide a mechanism for personnel to report observed or suspected information security events through appropriate channels in a timely manner. The control objective sounds deceptively straightforward. Implementation reality proves otherwise.

The standard explicitly distinguishes between events, incidents, breaches, and vulnerabilities. This distinction creates the foundation for effective early detection. An event is any occurrence that might indicate a potential security issue—unusual system behavior, suspicious emails, unfamiliar personnel in restricted areas. An incident represents a confirmed security violation or breach. By the time you've verified something constitutes an actual incident, you've frequently lost critical response time and forensic opportunities.

The control requires clarity on ten specific categories of reportable situations, from ineffective security controls to suspected malware infections. But here's where most implementations stumble: Clause 7.4 on communication requires you to determine what needs to be communicated, when, to whom, and how. Applied to security event reporting, this translates to documented clarity on:

Precise definitions of what constitutes a reportable event versus routine system behavior
Primary and backup reporting channels with specific contact information
Expected response timeframes differentiated by event severity levels
Required information elements for initial reports
Clear follow-up procedures and feedback mechanisms

Cross-referencing ISO/IEC 27035 incident management requirements, the reporting mechanism must integrate seamlessly with your broader incident response capability while maintaining accessibility for non-technical personnel.

Why Reporting Programs Systematically Fail

During a recent certification audit of a mid-sized professional services firm, I encountered a textbook example of this implementation gap. They had invested substantially in security awareness training—interactive modules, simulated phishing exercises, quarterly security briefings. Their compliance metrics appeared excellent: 97% training completion rates, phishing simulation click-through rates reduced from 38% to 12%.

However, my Clause 9.2.2 interviews with operational staff revealed a different reality. A database administrator mentioned noticing unusual query patterns two weeks earlier but "assumed it was related to the quarterly reporting cycle." A facilities coordinator had observed someone tailgating through a badge-controlled entrance but "didn't want to seem unwelcoming to what appeared to be a new employee." An executive assistant received a suspicious vendor invoice modification request but only mentioned it casually to a colleague, never formally escalating it.

None of these potentially significant events appeared in any security log or report. The organization had zero visibility into these occurrences. Their sophisticated reporting procedure existed primarily on paper—it hadn't penetrated operational culture.

This pattern repeats consistently across industries. The underlying causes follow predictable patterns:

Fear of False Positive Consequences

Nobody wants to be the person who escalated a "security incident" that turned out to be legitimate vendor maintenance. Organizations that respond to false positives with visible frustration, procedural criticism, or subtle social penalties systematically destroy their reporting culture. I consistently advise clients: every false positive represents a cultural success. Someone observed unusual activity and took appropriate action. This behavior should be reinforced, not discouraged.

Fear of Accountability and Blame

If your initial response when someone reports clicking a suspicious link is "why did you click on that?" you've effectively guaranteed that future similar events will go unreported. The next person who experiences a potential compromise will quietly hope it wasn't malicious and remain silent. This dynamic is how significant breaches remain undetected for extended periods.

Ambiguous Reporting Channels

During audit interviews, when I ask operational staff how they would report a security concern, typical responses include: "I suppose I'd email IT?" "Probably mention it to my supervisor?" "There's some kind of form on our intranet portal, I think?" If your personnel are guessing about reporting procedures, your mechanism has fundamentally failed. The reporting path must be as instinctive and accessible as emergency services contact procedures.

Communication Void After Reporting

Reports disappear into organizational silence. Personnel never receive acknowledgment, outcome information, or feedback about the value of their report. After experiencing several instances of reporting into apparent void, rational individuals stop investing effort in the process.

Implementing a Functional Reporting Culture

The technical infrastructure components of Control A.6.8 are relatively straightforward—reporting mechanisms, handling procedures, documentation systems. Cultural transformation represents the real implementation challenge. Organizations that achieve effective security event reporting operate with fundamentally different approaches:

Eliminate Reporting Friction

The reporting barrier must be minimal. Your mechanism should be accessible through multiple channels—dedicated email address, internal phone extension, web portal, mobile application, or even physical suggestion boxes in high-security environments. I've seen organizations implement simple solutions like security@company.com with guaranteed four-hour response times that dramatically outperform complex ticketing systems.

Consider implementing supplier relationship management protocols that extend reporting expectations to third parties accessing your systems or facilities.

Establish Positive Reinforcement Cycles

Every report—regardless of outcome—should receive prompt acknowledgment and appreciation. Organizations with mature reporting cultures actively celebrate false positives during security meetings. "Sarah reported suspicious email activity that turned out to be a legitimate vendor notification, but her vigilance demonstrates exactly the awareness we need throughout the organization."

Implement feedback loops that close the communication circle. When someone reports a potential security event, provide follow-up information about the investigation outcome and any protective actions taken.

Integrate with Broader Risk Management

Security event reporting should connect directly with your Clause 6.1 risk management processes. Events that don't constitute immediate security incidents often reveal emerging risks, control effectiveness gaps, or changing threat landscapes that require strategic attention.

Cross-reference with organizational context analysis requirements—external trends, regulatory changes, and business environment shifts often surface first through informal observations that become formal security event reports.

What Auditors Examine for Control A.6.8

During certification and surveillance audits, I evaluate Control A.6.8 effectiveness through multiple evidence streams:

Documentation Evidence

Documented reporting procedure with specific contact information and escalation pathways
Event classification criteria with examples for different organizational roles
Integration documentation connecting event reporting to incident management processes
Communication records showing how reporting expectations are disseminated to personnel

Operational Evidence

Sample security event reports demonstrating the mechanism's practical use
Evidence of timely acknowledgment and investigation of reported events
Records showing feedback provided to reporting individuals
Demonstration that false positives are handled constructively rather than punitively

Cultural Evidence

Interview responses indicating personnel understand what to report and how
Examples of events reported by non-technical staff demonstrating broad organizational engagement
Evidence that management visibly supports and reinforces reporting behavior
Integration between security awareness training and practical reporting expectations

I specifically look for evidence that the reporting mechanism functions during stress conditions. Organizations with mature implementations can demonstrate that their reporting culture remains effective during high-pressure situations, system outages, or other operational disruptions.

Integration with Related Standards and Controls

Control A.6.8 doesn't operate in isolation. Effective implementation requires coordination with multiple related standards and controls:

ISO/IEC 27035 incident management requirements provide the procedural framework for handling reported events. Your A.6.8 mechanism serves as the primary input stream for your broader incident response capability.

Control A.8.16 Monitoring activities should include metrics on reporting volume, response times, and cultural indicators like voluntary reporting rates versus mandatory compliance reporting.

For organizations processing personal data, ISO/IEC 27018 privacy protection requirements may mandate specific reporting procedures for potential personal data breaches with defined timelines and notification requirements.

Cloud service environments require particular attention to reporting procedures that span organizational boundaries, potentially invoking ISO/IEC 27017 cloud security guidance for shared responsibility models.

Common Implementation Mistakes

Through hundreds of certification audits, I've identified recurring implementation failures:

Over-engineering the reporting mechanism. Complex ticketing systems with multiple required fields and approval workflows create barriers that discourage reporting. Simple, accessible mechanisms consistently outperform sophisticated systems.

Focusing exclusively on technical events. Physical security observations, social engineering attempts, and human behavioral anomalies often provide earlier threat detection than automated systems. Your reporting culture must encompass the full spectrum of potential security events.

Treating reporting as compliance theater. Organizations that implement A.6.8 solely to satisfy audit requirements typically achieve minimal operational value. Effective reporting programs are designed to provide genuine security value, with audit compliance as a beneficial side effect.

Inadequate management engagement. Clause 5.1 leadership requirements extend to security event reporting. If management doesn't visibly value and reinforce reporting behavior, the cultural transformation fails regardless of procedural sophistication.

Practical tip: Implement a monthly "security awareness spotlight" that highlights (with appropriate anonymization) a recent security event report and the protective actions it enabled. This reinforces the value of reporting while maintaining individual privacy.

Control A.6.8 represents a fundamental shift from reactive security posture to proactive threat detection through human intelligence networks. Organizations that successfully implement this control create early warning systems that complement technical monitoring with human awareness and observation.

The investment in cultural transformation pays dividends through faster threat detection, reduced incident impact, and enhanced organizational resilience. But it requires sustained management commitment and systematic attention to the human factors that make security procedures effective in operational reality.

For personalized guidance on implementing Control A.6.8 within your specific organizational context, or to discuss integration with your broader ISMS implementation, consider connecting with experienced practitioners through the IX ISO 27001 Info Hub community.

Need personalized guidance? Reach our team at ix@isegrim-x.com.