%20PNG.png)
The purpose of this ISO27001 control is to ensure that we respond swiftly, effectively, and consistently to information security incidents, and carry out any actions in an orderly manner.
The first thing to say about this control is that although this control is not talking about Business Continuity Management specifically, incident management is a big part of business continuity. This control should not be taken in isolation and there is a lot we will also talk about incident management when we discuss Annex A controls;
A5.24 - Information security incident management planning and preparation.
A5.25 - Assessment and decision on information security events.
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.
Before we get into specifics we will say that Business Continuity can be a complex topic, which we think is illustrated by the number of controls which are related to the topic (listed above). Business Continuity Management is a full time role for some people, and there is a whole standard (ISO22301) which outlines requirements for organisations to implement robust processes.
We say this here because we don’t want you to panic(!) if you start going down a path and find yourself getting lost and confused. Don’t worry! We’ve got your back!
Stick with us and keep on track through this control and the ones listed above and you won’t go far wrong.
What does the standard require?
The standard states that “The organisation shall plan and prepare for managing information security incidents by defining, establishing, and communicating information security incident management processes, roles and responsibilities.” (A5.24 Information security incident management planning and preparation).
This control requires that you plan and prepare for the way you handle an information security incident by doing three things;
Defining what resources you need
Establishing (i.e. writing) a process that explains what to do and who is doing it
Communicate these plans to the interested parties
Why is this required?
Let’s face it; Security incidents are inevitable. This is not to say that you are going to be hacked! We don’t prescribe to the idea that everyone is going to be a victim of crime, but we all live with the risk and therefore we need a plan to deal with it if it happens.
So what do we mean that it’s inevitable? Well consider that information Security, and therefore ISO27001, are primarily concerned with three things;
Confidentiality
Integrity
Availability
If there is an incident that affects any, or all three, of these then it can be classified as a security incident. For example;
Accidentally emailed the wrong client with customer data?
Laptop, mobile device or important paper file lost or stolen?
Systems outage meaning no one can access their data?
Be honest… these have happened to most of us (especially the first one!). The severity of the incident depends on many factors, which we will discuss in A5.25 - Assessment and decision on information security events.
A5.24 expects you to have planned for the above eventualities so that you can respond without delay, and bring the situation back under control as quickly and effectively as possible.
What the auditor is looking for
Ultimately the auditor will be looking for some form of Incident Management Process or Business Continuity Plan. Without trying to overly complicate things, we would suggest you need the following documents and processed;
Incident Response Plan
Business Continuity Processes
Post incident review process
To get to these three documents and evidence, you are going to have to address the requirements of the controls listed above. However, the auditor will expect to see a documented plan which outlines key roles and responsibilities. This will be part of your plan, but may also be listed within job descriptions or within the document you created when you developed controls for A5.2 – Information security roles and responsibilities.
The auditor will expect to see some form of Business Impact Analysis (BIA) has been completed, and that the plan has also been tested or exercised.
What do you need to do?
Specifically in this control the auditor will want to know how you planned for information security incidents, so you will need to have this conversation with your business. Your Management Review Team (MRT) might be able to assist in this, but what you are looking to complete is a Business Impact Analysis (BIA).
This can be achieved using a simple spreadsheet within which you collect the following information;
What are our most important functions?
What resources (human and technology) do we need?
How long can we survive without X? (where X is the function, system or people)
What roles will people take during an incident?
Again, BIA’s can become quite technical and complex, but at the most basic level if you capture and present this information to the auditor, your plans will be better for it.
You also need to demonstrate that your plans have been tested or exercised. A test is different from an exercise, because a test is generally focused on technical recovery, whereas an exercise if focused on people and teams.
If you are new to this topic, consider running an exercise for your leadership whereby you present a fictional scenario, such as “We have lost access to our CRM and won’t have access for the next week. What do we do?” If you wish to go further, then work with your IT teams to test the recovery of a critical piece of infrastructure. In either case, you will need to evidence that the exercise took place, including actions and decisions taken during the exercise.
Q & A
We already have a BC Plan, so is that ok?
Possibly. If the plan satisfies the points outlined above, in that it defines what you need, roles and responsibilities, has been communicated and has been tested. If it works for you, and it meets these requirements then don’t change it.
How detailed does the BIA need to be?
Again, please don’t over complicate things here. The BIA doesn’t have to be complicated. Look at the details stated above, and collect that information. You’re establishing what is important to you, and what the impact would be over time. There is a lot to consider within a full BIA process, such as recovery time objectives (RTO), recovery point objectives (RPO) and maximum tolerable periods of disruption (MTPoD), but don’t try and boil the ocean! Start simple, create a plan and then communicate it.
How often should we test our plans?
We would suggest that you should look at an annual exercise for the people listed within the plan, and an annual test of some technical aspect of your plans. You can use this as an awareness tool, which will also go some way to help satisfy Annex A control A6.3 - Information security awareness, education and training.
Difficulty rating
We rate this a 2 out of 5 difficulty rating. This means that it requires a little technical skill to understand the requirement. This is because there is quite a lot to think about, especially when considering the BIA process.
You will need to be quite organised in how you pull this together, but it is just about pulling information together from across your business. How you then display this within you plan is down to you. Just keep in mind that this is a plan that will need to be read and understood when everything is going wrong! Stress levels will be high and the desire to read a lengthy document that they’re not familiar with is likely to result in the plan not being read or referred to.
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