Skip to main content
Control Institute
Category: Incident Management

Assessment and Decision on Information Security Events

Also known as: Annex A 5.25, Control 5.25, Security Event Assessment, Assessment and Decision on Security Events
Simply put

This is an ISO 27001 reference control that describes how an organisation looks at security events as they arise and decides which ones are serious enough to be treated as security incidents. In practice, it means having a consistent way to review something unusual, categorise it, and determine what happens next. It helps ensure that events are handled by the right people and given the appropriate priority rather than being ignored or mishandled.

Formal definition

Assessment and Decision on Information Security Events is Annex A control 5.25 in the ISO/IEC 27001:2022 revision, where Annex A serves as a list of reference controls selected via the Statement of Applicability and informed by the organisation's risk assessment. The control requires that information security events be assessed systematically against defined criteria to determine whether they qualify as information security incidents, and that categorisation and prioritisation decisions route events to the relevant parties for handling. As an Annex A reference control, its inclusion and implementation depend on scope and the outcome of the risk assessment; it is typically related to broader incident response requirements rather than operating in isolation. Note that Annex A was restructured in the 2022 revision and that Annex A lists reference controls, distinct from the certifiable ISMS requirements in clauses 4 through 10 and from the guidance in ISO/IEC 27002; it is also separate from the SOC 2 Trust Services Criteria.

Why it matters

Not every unusual event on a network is a security incident, and not every genuine incident announces itself clearly. Without a consistent way to assess events and decide which ones warrant escalation, organisations risk two opposite failures: treating routine noise as emergencies and exhausting response resources, or dismissing early warning signs that later develop into serious breaches. Annex A 5.25 addresses this by requiring that events be assessed systematically against defined criteria and categorised so they reach the right people at the right priority.

The value of this control lies in bringing structure and repeatability to a decision that is often made under pressure. When an organisation has agreed criteria for what qualifies an event as an information security incident, decisions become defensible, consistent across shifts and staff, and less dependent on individual judgement in the moment. This consistency also supports the broader incident response process, since a reliable assessment and triage stage determines whether and how the rest of that process is invoked.

As an Annex A reference control, its inclusion and implementation depend on scope and the outcome of the organisation's risk assessment rather than being universally mandated in a fixed form. Its presence in an ISMS does not guarantee that every event will be correctly classified, and it operates in relation to broader incident response requirements rather than in isolation. It is best understood as the triage step that channels security events toward appropriate handling.

Who it's relevant to

Security operations and incident responders
Teams that monitor and triage events are the primary users of this control. Defined assessment criteria and categorisation give them a consistent basis for deciding which events qualify as incidents and how to prioritise handling, helping ensure that events reach the right parties rather than being ignored or mishandled.
Compliance managers and GRC professionals
Those maintaining an ISO 27001 ISMS need to determine whether 5.25 is applicable within scope, document that decision in the Statement of Applicability, and ensure the assessment and decision process aligns with the organisation's risk assessment and broader incident response requirements.
Internal and certification auditors
Auditors reviewing an ISMS will examine whether events are assessed systematically against defined criteria and whether categorisation and prioritisation route events appropriately. They should note that 5.25 is a reference control whose implementation depends on scope, and that it is distinct from the clause 4 to 10 requirements and from the SOC 2 Trust Services Criteria.
Organisations mapping across frameworks
Teams comparing ISO 27001 with SOC 2 should recognise that Annex A 5.25 sits within the ISO 27001 reference control set and is separate from the SOC 2 Trust Services Criteria. Any mapping between comparable event-assessment expectations across frameworks is partial, and satisfying one framework does not automatically satisfy the other.

Inside Assessment and Decision on Information Security Events

Event Detection and Recording
The initial identification and logging of a security event, capturing details such as source, time, affected assets, and observed symptoms so the event can be consistently evaluated. This step feeds the subsequent assessment activity.
Assessment Against Criteria
The evaluation of a recorded security event to determine whether it constitutes a security incident. This typically involves applying predefined classification and severity criteria, though the specific thresholds depend on the organization's scope and risk decisions.
Decision on Classification
The documented determination of whether an event is classified as a security incident, a false positive, or a non-incident event, along with its assigned severity or priority category, informing the response path taken.
Roles and Responsibilities
The designation of who is authorized to assess events and make classification decisions, which in most engagements is defined so that decisions are accountable and traceable rather than ad hoc.
Records and Evidence
The retained documentation of the assessment and the resulting decision, which serves as auditable evidence. Under SOC 2 this evidence supports testing of control operating effectiveness over the review period, and under ISO 27001 it supports demonstrating that the ISMS process operates as intended.

Common questions

Answers to the questions practitioners most commonly ask about Assessment and Decision on Information Security Events.

Is assessment and decision on security events something required only by SOC 2?
No. The activity of assessing security events and deciding whether they constitute incidents is relevant to both frameworks, though they approach it differently. Under SOC 2, event assessment and response typically fall within the Common Criteria (Security) and any in-scope categories, and the auditor evaluates whether the described controls are suitably designed and, in a Type II engagement, operating effectively over the review period. Under ISO 27001, the requirement to assess events and decide whether they are classified as information security incidents is addressed through the ISMS requirements in clauses 4 through 10 and the relevant reference controls selected via the Statement of Applicability. Neither framework treats this activity as unique to itself, and the specific expectations depend on scope, applicable criteria, and the risk assessment.
Does having an assessment and decision process guarantee that security incidents will be prevented or that no breaches will occur?
No. A defined process for assessing events and deciding whether they are incidents governs how an organization triages and responds; it does not guarantee freedom from breaches. In a SOC 2 context, the report attests only to the controls and the period covered and does not assure that no incident will occur. In an ISO 27001 context, the certificate covers only the defined scope of the ISMS and reflects that a management system exists and was evaluated, not that incidents are impossible. Both frameworks focus on whether processes are designed and, where assessed, operating as described, rather than on eliminating risk entirely.
How do we distinguish an event from an incident when defining our assessment process?
The distinction is typically made through predefined classification criteria that your organization sets during scoping and risk assessment. An event is generally an observed occurrence within systems or networks, while an incident is an event, or series of events, determined through assessment to have adverse implications warranting a defined response. Documenting the criteria used to make this determination helps demonstrate consistency to a SOC 2 auditor or an ISO 27001 certification body. The specific thresholds and categories vary depending on scope, applicable criteria, and the organization's risk profile.
What documentation typically supports this activity during a SOC 2 Type II engagement or ISO 27001 assessment?
In most engagements, supporting documentation includes a written procedure describing how events are assessed and decisions are made, records of events that were evaluated, and evidence of the resulting decisions and any escalation. For a SOC 2 Type II, the auditor generally seeks evidence that these controls operated over the defined review period, so retained records across that period are important. For ISO 27001, evidence typically demonstrates that the process aligns with the ISMS requirements and the controls identified in the Statement of Applicability. The exact evidence expected depends on the auditor, certification body, and scope.
Who should be responsible for making the assessment and decision on security events?
Responsibility is usually assigned to defined roles within the incident response or security function, with clear points of authority for classifying and escalating events. Both frameworks generally expect that responsibilities are documented and understood, but neither prescribes a single organizational structure. In practice, the assignment depends on the organization's size, scope, and operating model, so smaller organizations may consolidate roles while larger ones distribute them. Documenting who holds decision authority helps demonstrate that the process operates consistently.
Can we use one assessment and decision process to satisfy both SOC 2 and ISO 27001?
A single well-designed process can often support evidence for both frameworks, since mapping between SOC 2 and ISO 27001 is possible, but that mapping is partial and satisfying one does not automatically satisfy the other. The way the process is evaluated differs: SOC 2 assesses suitability of design and, in a Type II, operating effectiveness over a period, while ISO 27001 evaluates conformance to the ISMS requirements and the applicability of selected reference controls. Depending on scope, you may need to align the process with the distinct expectations of each and maintain evidence appropriate to each engagement.

Common misconceptions

Every recorded security event must be treated as a security incident.
The purpose of the assessment and decision step is precisely to distinguish events that are incidents from those that are not. Depending on scope and criteria, many events are classified as false positives or non-incidents and do not trigger the full incident response process.
Having a documented assessment and decision process guarantees the organization will not experience a breach.
This process addresses how events are evaluated and classified; it does not eliminate risk. A SOC 2 report attests only to the controls and period covered, and an ISO 27001 certificate covers only the defined ISMS scope, so neither guarantees freedom from breaches.
The assessment and decision requirements are identical under SOC 2 and ISO 27001.
Both frameworks expect events to be assessed and classified, but they express this differently. SOC 2 evaluates it against the applicable Trust Services Criteria (with Security as the required Common Criteria), while ISO 27001 addresses it through its ISMS requirements and reference controls selected via the Statement of Applicability. Mapping between them is partial, and satisfying one does not automatically satisfy the other.

Best practices

Define documented, consistent criteria for classifying events and assigning severity so that assessment decisions are repeatable rather than dependent on individual judgment.
Clearly assign roles and authority for who assesses events and who makes and approves the classification decision, ensuring accountability and traceability.
Retain records of both the assessment and the resulting decision, since this documentation typically serves as the evidence auditors test for operating effectiveness over a SOC 2 Type II review period and supports the ISO 27001 ISMS.
Ensure the classification path connects to the broader incident response process, so that events determined to be incidents are escalated and handled while non-incidents and false positives are appropriately closed out.
Align the criteria and process with the applicable scope and criteria of your framework, recognizing that specific thresholds and requirements depend on the auditor, certification body, and defined scope rather than a fixed universal rule.
Periodically review and refine the assessment criteria based on observed events to reduce misclassification, while documenting any changes to support both audit and certification objectives.