%20PNG.png)
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 aspects of incident management there is.
What does the standard require?
The standard states that “The organisations shall assess information security events and decide if they are to be categorised as information security incidents.” (A5.25 - Assessment and decision on information security events).
You should note that there are two things discussed here; events and incidents. They are not the same thing. Events are things which happen, and may lead to becoming a security incident. But this may not always happen. Therefore, the point of this control is that you have a systematic way of evaluating ‘things which happen’ (aka events), that you may determine (aka categorise) to be a security incident.
Why is this required?
To ensure you can effectively respond to an incident, you need to decide if it’s an incident at all. For example, if your Cloud service fails, is that a security incident? The simply answer is, it depends how long the Cloud service is down for. But who decides?
A lack of a simple structure in the decision-making process makes it uncertain if incidents will be consistently responded to, and thereby reduce the impact that an incident may have.
What the auditor is looking for
The auditor is looking for a process which ensures that incidents can be identified and assessed in a consistent manner. They will expect to see this detailed within your Incident Response Plan, or Business Continuity Plan, which you began to develop in A5.24 - Information security incident management planning and preparation.
The way you assess the security event is down to you.
What do you need to do?
Your assessment framework can be based on something already in place. Quite often, the IT function will have ‘priority levels’ already assigned, such as “P1” to “P5”, with P1 being the highest priority. If this isn’t something you already have in place, then use this as a basis and build upon it because it will already be part of the fabric of your business, and people will understand the language you’re using.
We suggest using this structure and building upon it for the assessment of security events, so start with a simple table in your Incident Response Plan, and develop it as follows.
Priority | Response time | This is a security incident if there is a… |
1 | 0 – 4hrs | · Loss of mission critical systems · Loss of mission critical services · Significant impact on Data Protection · Significant client impact · Significant financial losses (including fines or legal costs)
|
Now consider the same for a P2, P3 and so on. This simple structure will ensure that you are correctly and consistently assessing if an event (something that happened) is deemed to be an incident.
Q & A
How can we differentiate between an event and an incident?
It’s not as difficult as it may sound, as long as you keep in mind that they are different. Keep in mind that a security incident is something which has a negative impact upon Confidentiality, Integrity or Availability and do you need to take any action to remediate the incident?
Are there any criteria we should be using to evaluate the impact?
There’s nothing set in stone here, and it should simply make sense to you. We would suggest however that you evaluate an event based on the impact on;
Confidentiality, Integrity, and Availability.
The type of information involved (i.e. is personal data involved?)
Legal or contractual implications (i.e. is there a breach of contract or legal requirements?)
Impact on day-to-day operations (e.g. impact on financial reporting)
Who needs to know about the categorisation?
This should be written into your Incident Response Plans, so everyone listed in that plan should be made aware. However, it is important that those who are raising incidents understand what the different levels are, so they can raise incidents in a consistent manner.
Difficulty rating
We rate this a 1 out of 5 difficulty rating. This means that it requires little to no technical skill to understand the requirement. You simply need to decide what the criteria for the assessment, and then ensure this is communicated to those who will need it.
More questions?
Remember that nothing in ISO27001 sits in isolation, so you should review our FAQ to gain answers to other aspects of the standard. Follow the links in this control to see the relationship in other controls, but if you’re still confused about this control, then please get in touch.
For information on how to implement ISO27001, you might like to consider buying our book “The Real Easy Guide to ISO27001” which is available on Amazon.
Comments