Skip to main content
Control Institute
Category: Incident Management

Reporting Information Security Events

Also known as: Information Security Event Reporting, Security Event Reporting, Cybersecurity Incident Reporting
Simply put

Reporting information security events is the process of promptly notifying the appropriate people when something suspicious or harmful happens to an organization's information or systems, such as a suspected breach, phishing attempt, malware, or a failure of a security safeguard. The goal is to make sure that potential problems are documented and escalated quickly so they can be assessed and, if needed, responded to. Reporting an event is not the same as confirming an incident occurred; it is the step that gets a potential issue in front of the right people for evaluation.

Formal definition

Information security event reporting is the documented process by which identified occurrences indicating a potential breach of security policy or a failure of safeguards are communicated to designated personnel or channels for assessment. In practice it typically covers events such as suspected incidents, breaches, phishing, malware, and vulnerabilities, and it often specifies reporting mechanisms and timeframes (which vary by organization and policy). In the context of ISO/IEC 27002:2022, this activity aligns with reference control 6.8, Information Security Event Reporting, which may be selected via the Statement of Applicability when implementing an ISO/IEC 27001 ISMS; the specific requirements, reporting thresholds, and escalation timelines depend on the organization's scope, risk assessment, and applicable policies rather than a single fixed rule. This control addresses the reporting of events; it is distinct from, though closely related to, subsequent incident assessment and response activities.

Why it matters

The speed and clarity of event reporting often determines how much damage a security problem ultimately causes. When a suspected phishing message, malware infection, or failed safeguard is reported promptly to the right people, the organization gains the opportunity to assess and, if warranted, contain the issue before it escalates. Without a reliable reporting channel, potential problems can sit undetected in the hands of individual employees who are unsure whether what they observed is significant or who to tell. Because reporting an event is not the same as confirming an incident, encouraging people to report early and often, even when they are uncertain, helps ensure that genuine issues reach evaluation rather than being quietly dismissed.

Event reporting also underpins the broader incident management process. An organization cannot assess, respond to, or learn from something it never becomes aware of, so reporting is effectively the entry point into detection and response workflows. Guidance from some organizations reflects how time-sensitive this can be; for example, the University of Virginia's information security guidance directs users to report incidents within one hour, reflecting the principle that time is critical during an active incident. Reporting timeframes and thresholds like this vary by organization and are set by internal policy rather than by a single universal rule.

For compliance purposes, having a documented and functioning reporting mechanism supports controls within an ISO/IEC 27001 ISMS and aligns with reference control 6.8 in ISO/IEC 27002:2022. External bodies such as CISA also provide secure channels for reporting incidents, phishing, malware, and vulnerabilities, which organizations may use in addition to their internal processes. It is worth emphasizing that reporting a security event does not by itself guarantee that an incident occurred, that it will be resolved, or that an organization is protected from breaches; it is one necessary step within a larger, scope-dependent incident management program.

Who it's relevant to

Compliance and GRC Managers
Those managing an ISO/IEC 27001 ISMS need to decide, via the Statement of Applicability and informed by risk assessment, whether and how to implement reference control 6.8. They are typically responsible for documenting reporting mechanisms, thresholds, and escalation paths, and for demonstrating that the process functions. Reporting also supports incident management expectations that may be relevant when a SOC 2 examination covers the Security (Common Criteria) category, though the specific controls and how they are evaluated depend on scope and the auditor.
Security Engineers and Incident Responders
These practitioners rely on event reports as the entry point into detection, assessment, and response workflows. Because reporting an event is not the same as confirming an incident, they are often responsible for triaging reported events, such as suspected phishing, malware, or safeguard failures, and determining which require formal incident response. Clear, timely reporting channels directly affect how quickly they can act.
General Employees and System Users
In many organizations, the people most likely to first observe a suspicious event are ordinary users. They benefit from knowing what to report, how to report it, and within what timeframe, some guidance calls for reporting within a short window such as one hour. Encouraging users to report early, even when uncertain, helps ensure potential issues reach evaluation rather than going unnoticed.
Auditors and Assessors
Auditors reviewing an ISMS or performing a SOC 2 examination may examine whether an event reporting process exists, is documented, and operates as intended over the period or point in time under review. Their evaluation depends on the defined scope and applicable criteria, and evidence of a functioning reporting process supports, but does not by itself prove, effective incident management.

Inside Reporting Information Security Events

Event Reporting Channels
Defined mechanisms through which personnel and, where relevant, external parties can report observed or suspected information security events. Channels are typically documented so that reporters know where and how to raise concerns.
Reporting Criteria and Guidance
Guidance describing what constitutes a reportable event, helping personnel distinguish security-relevant occurrences from routine issues. The specifics depend on organizational scope and risk decisions rather than a universal threshold.
Timeliness Expectations
Expectations regarding how promptly events should be reported after being observed. In most environments the aim is to enable timely triage, though exact timeframes are set by the organization based on its risk appetite and applicable requirements.
Roles and Responsibilities
Assignment of who receives, records, and acts on reported events, and who is responsible for onward escalation. Clear ownership supports consistent handling.
Relationship to Incident Management
Event reporting typically feeds an assessment and decision process that determines whether an event is classified as an incident. Reporting is an input to broader incident management rather than the response process itself.
Framework Context
In ISO/IEC 27001, event reporting is addressed as an Annex A reference control selected via the Statement of Applicability and informed by risk assessment; the specific control designation and count depend on the standard edition (for example, the 2013 version differs from the restructured 2022 version). In a SOC 2 examination, related activities may be evaluated under the Security Common Criteria, depending on the controls the organization defines and the scope of the engagement.

Common questions

Answers to the questions practitioners most commonly ask about Reporting Information Security Events.

Is reporting information security events a mandatory Annex A control that every ISO 27001-certified organization must implement?
Not automatically. Annex A controls, including those addressing the reporting of information security events, are reference controls selected through a Statement of Applicability and informed by the organization's risk assessment. An organization determines applicability based on its scope and identified risks rather than treating every Annex A control as universally mandatory. That said, event reporting is commonly retained in most ISMS implementations because timely event detection typically supports the incident management and continual improvement expectations found in the clause 4-10 requirements. The specific control reference and grouping depend on the ISO 27001 edition, so the applicable version should be cited when discussing where this control sits.
Does having a documented event-reporting process mean the organization is protected from or free of security breaches?
No. A reporting process establishes a mechanism for personnel and, where relevant, external parties to raise observed or suspected information security events so they can be assessed and, where appropriate, treated as incidents. It does not guarantee freedom from breaches. Like the boundaries of a SOC 2 report, which attests only to the controls and period covered, an event-reporting control demonstrates that a defined process exists and, depending on the assessment, operates as intended; it does not certify that no breach will occur. Its value lies in reducing detection and response delays, not in eliminating risk.
Who should be able to report information security events, and through what channels?
In most implementations, the reporting mechanism is made available to all personnel and, depending on scope, to relevant external parties such as contractors, suppliers, or users. Organizations typically define one or more accessible channels, for example a dedicated contact point, ticketing system, or hotline, and communicate them so that reporters know where and how to raise an event. The exact channels and audience depend on the organization's scope and risk assessment; the underlying aim is that anyone likely to observe an event has a clear, low-friction route to report it promptly.
What information should personnel be asked to include when reporting a suspected event?
Organizations generally define what a useful report contains so that the receiving team can assess it. This typically includes what was observed, when and where it occurred, any systems or data potentially involved, and how to contact the reporter for follow-up. The precise fields depend on the organization's process design and scope. Keeping the required detail proportionate is common practice, since overly burdensome reporting requirements can discourage prompt reporting.
How does event reporting connect to incident management within an ISMS?
Reporting is typically the front end of a broader flow: an event is reported, then assessed to determine whether it qualifies as an information security incident, and, if so, handled through the organization's incident management process. Not every reported event becomes an incident. Defining the assessment step and the criteria used to classify events is usually part of an ISMS implementation, and the outcomes can feed the continual improvement expectations in the ISO 27001 clause requirements. The specific procedures and thresholds vary by organization and scope.
How might an assessor evaluate whether event reporting is designed and operating effectively?
The evidence sought depends on the framework and engagement. Under ISO 27001, a certification body's assessment of an applicable control typically considers whether the reporting mechanism is defined, communicated, and used, and whether reported events are assessed and actioned. In a SOC 2 examination, a Type I engagement addresses suitability of design at a point in time, while a Type II engagement addresses both design and operating effectiveness over a defined review period whose length is set by scoping decisions. In practice, an assessor may look for documented procedures, evidence that channels were communicated, and records of events actually reported and handled during the relevant period.

Common misconceptions

Reporting a security event is the same as responding to a security incident.
Reporting is typically the initial step of raising awareness of an observed or suspected event. A subsequent assessment usually determines whether the event qualifies as an incident, which then triggers response and management activities. The two are related but distinct.
Every security event will always result in a formal incident and remediation.
Many reported events are assessed and found to be non-events, false positives, or minor issues that do not meet the organization's incident criteria. Whether an event becomes an incident depends on the organization's defined criteria and its assessment process.
Having an event reporting control demonstrated in a SOC 2 report or covered by an ISO 27001 certificate guarantees breaches will be detected or prevented.
A SOC 2 report attests only to the controls and the period covered and does not guarantee freedom from breaches, and an ISO 27001 certificate covers only the defined ISMS scope. Effective reporting improves the chance that events are surfaced, but it does not assure detection or prevention of all incidents.

Best practices

Document clear, accessible reporting channels and communicate them so personnel and relevant external parties know where and how to report suspected events.
Provide practical guidance and examples of what constitutes a reportable event to reduce ambiguity, recognizing that criteria depend on your scope and risk decisions.
Define timeliness expectations that suit your risk appetite and any applicable requirements, and set them explicitly rather than assuming a universal timeframe.
Assign and record clear roles for receiving, logging, assessing, and escalating reported events so handling is consistent and traceable.
Connect the reporting process to your broader incident assessment and management process, keeping the distinction between raising an event and classifying an incident.
Retain records of reported events and their disposition to support internal review and to provide evidence during a SOC 2 examination or an ISO 27001 certification audit, mapping the control to your Statement of Applicability or Common Criteria as applicable.