Pierluigi Paganini
December 18, 2013
At first sight, business continuity may not have a direct relationship with information security, but this is not so – business continuity is essential for information security because it ensures that IT systems become available quickly, even in the case of natural disasters or any other kind of disruptions (e.g., hacker attacks, inside attack, malfunction, etc.).
First impressions
In any case, business continuity is not my specialty, so I didn’t know what to expect from this book. But what really surprised me was that it was written in such a way that it is very easy to read for people who are not experts in business continuity – Dejan avoided using jargon or abbreviations, so even those people without much knowledge about IT or business continuity will be able to read it.
Also, the book seems very practical – it includes plenty of diagrams and figures – let me give just a few examples:
So, you’ll find plenty of examples that seem very usable in real-life business continuity implementation.
Risk assessment
What I like the most is that the book gives very detailed guidelines on particular topics like business impact analysis or risk assessment. Since risk assessment is something I’m quite familiar with, let me go into more details about this section of the book – with Dejan’s permission I’ve quoted a section of the book that explains which options exist for performing the risk assessment:
“1) Activity-based or asset-based risk identification. In activity-based risk assessment you assess the risks of disruptive incidents for your whole activity, whereas in asset-based you have to assess risk of disruptive incident for each and every asset in the activity (assets range from employees, hardware, software, data, to equipment, infrastructure, etc.). Of course, activity-based risk assessment is much quicker, because in each activity you may have a few dozen to a few hundred assets. However, if you choose the asset-based risk assessment, you will identify all the assets that are important to you, which you would need to do anyway during the business impact analysis, so sooner or later it makes no difference.
2) Assessing only the threats, or vulnerabilities also. Threat is what could potentially happen to your activity/asset and do harm – e.g., a fire; vulnerability is the characteristic of your activity/asset that could be exploited by a threat – e.g., lack of a fire-suppression system. You can choose to identify only the threats for each of your activities or assets (which would be sufficient according to ISO 22301); however, if you want to be more precise you could also identify vulnerabilities, because this is how you will find out the cause of the problem – this cause is what you will have to address in the treatment phase, so identifying vulnerabilities will help you be more effective with the treatment later on.
3) Determining the level of risk directly, or through consequences and likelihood. Once you identify the risks, you need to know how high they are – for example, you can use the scale of 1 to 5, where 1 would be very low, 2 low, 3 medium, etc.; alternatively, you can choose to assess consequences and likelihood – e.g., using the same scale of 1 to 5, the likelihood of fire is low (2); however, the consequences would be very high (5) – in such approach the level of risk would be a calculated result of consequences and likelihood (see below “Method of risk calculation”). Again, assessing risk directly is quicker, but assessing consequences and likelihood will give a more precise result and it will be compliant with the information security risk assessment if you choose to do it afterwards.
4) Which assessment scales to use. You are completely free to use whichever scales you like – e.g., Low-Medium-High, or 1 to 5, or 1 to 10, whatever suits you best. Of course, if you want to make it simple, go for Low-Medium-High. In case you assess the level of risk directly, you can even use a simpler scale: risk is acceptable Yes/No.
5) Method of risk calculation. If you use assessment through consequences and likelihood, you have to calculate the level of risk – this is usually done through addition (e.g., 2 + 5 = 7) or through multiplication (e.g., 2 x 5 = 10). If you use scales Low-Medium-High, then this is the same as using scale 1-2-3, so you have numbers again for calculation.
6) Decision on which risks need treatment. If your method of risk calculation produces values from 2 to 10, then you can decide that an acceptable level of risk is, e.g., 7 – this would mean that only the risks of value 8, 9 and 10 need treatment. Alternatively, you can examine each individual risk and decide which should be treated or not based on your insight and experience, using no pre-defined values; assessing the risks directly with a scale of Yes/No is basically the simplest way of using this alternative.
7) Use of risk assessment tools. If you are a larger organization you will find performing the risk assessment much easier with the tool; however, if you are really small it will take you much longer to figure out how the tool works then to do it using Excel sheets. One word of caution here – you should aim at adapting the tool to your methodology, not the other way around.
8) Measurement. You must measure whether your risk management process is effective by evaluating whether the safeguards and other treatment options have produced desirable results; however, if no incidents have occurred it will be difficult to make this measurement, so you can also decide to measure the residual risk, i.e., the risk that is left after the treatment has been performed.”
And, in a similar way, the book explains options for every other business continuity element – business continuity policy, business impact analysis, business continuity strategy, exercising and testing, etc.
Conclusion
On the negative side, for my taste the book touches too little on the technologies that can be used for disaster recovery, alternative locations for data centers and backup systems – the author probably could have spent a chapter on these subjects, but I understand his effort for keeping this book readable even for non-technical people.
But if you don’t expect this book to teach you the technology side of business continuity, and you want an easy and comprehensive guideline to start (and finish) your business continuity implementation, this is certainly a very good book to start with.
You can find the book here: Becoming Resilient: The Definitive Guide to ISO 22301 Implementation.
Pierluigi Paganini
