ISO27001:2022 – A5.25 Assessment and decision on information security events
Introduction to ISO 27001 – A5.25
It’s important not to lose sight of the fact that this control is part of a number of controls related to Incident Management. For clarity and the total picture, you should also review the following controls:
- A5.24 – Information security incident management planning and preparation
- A5.26 – Response to information security incidents
- A5.27 – Learning from information security incidents
- A5.28 – Collection of evidence
- A5.29 – Information security during disruption
- A5.30 – ICT Readiness for Business Continuity
This control is specifically concerned with understanding an aspect of Business Continuity which is often ignored or forgotten — yet it’s arguably one of the most important parts of incident management.
What does the standard require?
“The organisation shall assess information security events and decide if they are to be categorised as information security incidents.”
(ISO 27001 – A5.25 – Assessment and Decision on Information Security Events)
This control distinguishes between events and incidents. Events are things that happen and may lead to a security incident — but not always. This control ensures there’s a consistent, systematic approach to evaluate and categorise events.
Why is ISO 27001 – A5.25 required?
You can’t respond to an incident if you haven’t decided that it’s an incident in the first place. A structured approach ensures that assessment and decisions are made consistently — reducing uncertainty and potential delays in response.
What the auditor is looking for
For ISO 27001 – A5.25, the auditor will expect to see:
- A defined process for assessing events and categorising them as incidents
- This process documented in your Incident Response Plan or Business Continuity Plan
What do you need to do?
If you already use a ticketing system or IT helpdesk, you likely already have “priority levels” such as P1–P5. Extend that logic into your security event assessment framework.
Here’s a simple structure to begin with:
| Priority | Response Time | Considered an Incident If… |
|---|---|---|
| P1 | 0 – 4 hrs |
|
This ensures that you’re categorising and responding to security incidents in a consistent, structured way.
Q & A
How can we differentiate between an event and an incident?
An event is anything that happens. An incident is an event that negatively affects confidentiality, integrity, or availability (CIA). If it causes a business impact and needs remediation — it’s an incident.
Are there criteria we should use to evaluate the impact?
Yes. Suggested criteria include:
- Impact on confidentiality, integrity, and availability
- Type of information involved (e.g., personal data)
- Legal or contractual breach implications
- Disruption to operations (e.g., finance, customer service)
Who needs to know about the categorisation?
This should be documented in your Incident Response Plan. All stakeholders involved in incident management should understand how the assessment works — especially those who raise or log incidents. Of course it would be helpful to educate the rest of your business as to the distinction, because it’s still important for them to inform you of an incident and an event.
Difficulty Rating
1 out of 5 – This control requires low technical complexity. You just need to define the assessment criteria and make sure it’s consistently applied and communicated.
More Questions?
As with all ISO27001 controls, A5.25 should not be treated in isolation. Be sure to cross-reference related controls in your incident management framework.
For more help implementing ISO27001 or defining your incident management process, feel free to contact us.
We are ISO 27001 Consultants who provide ‘Compliance without Complexity’® and we know we can help you… we even wrote a book about it. For more information on how to implement ISO 27001, written by ISO 27001 consultants like us, you should buy our book… “The Real Easy Guide to ISO27001”, available on Amazon.
