We at Fox Red Risk are big fans of standards. Standards such as the recently updated Business Continuity Standard ISO 22301:2019. These standards help businesses plan for disruptive events but also allow businesses to talk to each other about their BCMS using a common language. If you use BC software to support your 22301 certification (or are thinking about using software) you should read on. There are some of the key things that have changed in the 2019 version of 22301 that could mean your current BC software is no longer be fit-for-purpose.
22301:2019 is simpler and concise
What is immediately noticeable about the 22301:2019 Business Continuity standard is how much shorter the standard has become. When doing a side-by-side comparison you can see how much of the 22301:2012 content has been taken out. Take policy, the 2012 version was a lot more prescriptive. The 2019 version is concise, simply stating you need to document a policy, tell people about it, and make it available to third parties. Ultimately, the content of the policy must reflect the requirements of the standard to be effective so all the fluff about commitment and appropriateness was unnecessary. This haircut is very much welcomed.
A number of definitions are no longer in the 2019 version. An example of one is ‘Risk Appetite’. Apparently (and I have no concrete source) this was due to the concept being ‘subjective’. I have seen good and bad examples of Risk Appetite but it’s a shame the concept has been taken out. Risk appetite definitely has a place in Business Continuity Management. What is positive however is that a lot of Business Continuity jargon has been removed from the standard. As a business continuity practitioner, I typically shield the business from this jargon. This is because it takes up too much time just explaining what the terminology actually means. This time could be used more productively. It’s great to see the standard reflecting this common practice. It’s also worth reviewing whether your business continuity software is aligned to the new terminology.
Significantly Improved Business Impact Analysis (BIA) section
Business Impact Analysis (BIA) is the foundation of good Business Continuity Management. If organisations don’t start from the point of first understanding what their business does, how it does it, the order in which things are done, and who relies on who, how on earth can it even begin to understand how to recover from a disruptive event? In 22301:2019 the BIA section is a lot clearer.
22301:2019 introduces into the standard the concept of ‘Impact Categories’ (although unhelpfully doesn’t define the term). An impact category though is fairly self-explanatory, it’s the different types of impact a business may face. These could be amongst other things: financial impacts, reputational impacts, safety impacts or legal impacts. Introducing impact categories aids the business in creating a taxonomy for assessing impacts. This should stop the far-too-common practice of just rating things High, Medium or Low with absolutely no context as to what High, Medium or Low actually means.
The rest of the BIA section clearly lays out the high-level requirements in a way the 2012 version did not. This clarity will be a great benefit for both internal practitioners and business continuity consultants alike. It will take a lot of the subjectivity out of what should and should not be in a BIA. It’s therefore critical to check whether your Business Continuity solution is capable of meeting the updated BIA requirements.
Still work to do in the Risk Assessment section
I have always had discomfort with how Risk is applied in Business Continuity Management Systems. The primary issue is Risk is a combination of Impact (identified in the BIA) and Likelihood (a probability the impact will happen between 0 – never happen and 1 – will definitely happen). In a Business Continuity situation likelihood is largely irrelevant because a BCMS is primarily focussed at preparing for, and recovering from, an event where the Impact has actually happened. The probability is always going to be one after an event has actually happened so assessing risk, to me at least, seems redundant insofar as the standard requires risk to be assessed.
That said, if an organisation wishes to be certified they must carry out a risk assessment so a risk assessment must be done. What is positive is the standard encourages an integrated risk management approach, recommending the use of ISO 31000:2018. If your organisation doesn’t adhere to 31000 integrating BCM risk assessment into your existing enterprise/operational risk management framework is still highly recommended…don’t create another risk register if you don’t have to! In terms of BC software, this is probably less of an issue but to restate…don’t create a new risk register if you don’t need to!
BCM strategies and solutions now must be resilience focussed
Another material change in 22301:2019 is in the Business Continuity Strategies and Solutions (formerly Business Continuity Strategy) section. In the 2012 version, the focus was very much on identifying strategies to deal with a disruptive event after it has happened (i.e. recovery). Whilst 22301:2019 still has this requirement, it now has the additional requirement to identify and implement strategies to incorporate resilience into the DNA of prioritised activities proactively. Promoting organisational resilience is a welcome addition to the standard as businesses spend too much time focussing on dealing with the potential aftermath of a disruptive event rather than focussing on engineering out the chances of a disruption occurring in the first place.
A good example of engineering in organisational resilience would be a call centre operating over two geographically separate locations with a high-availability cloud-based telephony system and each site having two smaller Internet connections running in a load-balanced configuration. If any of these components fail (including the people), there will still be at least some capacity to keep the call centre activities operational. Compare this to a call centre operating at one location with one telephone line and an internal PABX and it’s not hard to see how the latter is inherently more vulnerable to a wide range of potentially disruptive events.
Some BC software is weak on strategy development so this is another key area to check. If there is no strategy development component I would steer well clear.
A nod…but not an endorsement…to the All-Hazards Approach
The BC Strategies and Solutions section, in addition to discussing the strategic approaches, requires organisations to identify resource requirements to enable these intended strategies. In the resource requirements section, it states: “The organization shall determine the resource requirements to implement the selected business continuity solutions.” What I have always found frustrating is the associated list, is just a slightly expansive list of “All-Hazards” disruptive events. However, the standard does not directly incorporate the All-Hazards approach into the BIA or Risk Assessment. Such an approach could significantly improve adoption of 22301.
For those who are not familiar, the All-Hazards approach looks at disruptive events as impacting one of five business enablers: People, Locations, Assets, Technology, Suppliers (PLATS). Basically, a disruptive event is going to arise when a loss of one or more (or all) of the PLATS enablers occurs. Impacts arising from disrupted activities will be greater the longer these core business enablers remain unavailable. By adopting the All hazards approach, organisations no longer need to come up with endless scenarios or even more extravagant risks.
A little more on All-Hazards
If I were let loose to re-write the 22301:2019 standard, I would edit the BIA so that the requirement was to only assess impact arising from the loss of a list of predefined (e.g. PLATS) Business Enablers. I would then edit the Risk Assessment to only assess the risk of loss of each Business Enabler. In one fail swoop, every single scenario that could ever be conceived is covered. Not convinced, put something in the comments below and let’s test it out…
“If I were to be let loose to re-write the 22301:2019 standard.
As a slight aside, 22301:2019, in addition to the PLATS business enablers also highlights Finance and Transport as core business Enablers. Under the PLATS All-Hazards Approach, Finance is an Asset and Transport is an Asset or a Supplier depending on the situation. Under the PLATS system disruption to transport not controlled by the business (e.g. public transport) is a disruption to People as ultimately that is what is actually disrupting the business.
I am not aware of any BC software that guides businesses through an All-Hazards approach. If anyone reading this does know of software that does, leave a comment below.
Not a standalone business continuity standard
Moving back to the standard’s contents, what is a definite disappointment is poor cross-referencing. This is a practice I wish ISO would improve. 22301:2019 has a bibliography which completely omits the rest of the 223XX corpus. A lot of people are under the misapprehension that standards such as 22301:2019 and 27001:2013 are standalone documents – they’re not. 22301:2019 is part of a whole suite of documents that deal with resilience. A case in point is 22317:2015 which gives detailed guidance on how to implement a repeatable Business Impact Analysis process. Another is ISO 22318:2015 which gives guidance on supply chain continuity issues. My hope is that in future it becomes ‘standard’ for ISO to include in each document a list of the other documents in a standard’s family, or even better, a permanent weblink to an authoritative and updated list.
Whilst not a particular issue in terms of software, solutions that clearly show step-by-step how the software outputs meet the requirements of 22301:2019, and the wider guidance contained in documents such as 22317 and 22318, will be a clear benefit to those looking to achieve certification.
So do I need to change my Business Continuity Software?
The short answer really will depend on your approach. If you are certifying and your software does not meet the requirements of 22301:2019 then when it comes to transitioning (usually a maximum of three years after the new standard is introduced) you may run into challenges (so more effort augmenting the tool with workarounds in Excel and Word). A good place to start is with a systematic review of the new standard against your specific software solution to draw any deficiencies out. The next thing will be to work with the vendor to get your current solution aligned to 22301:2019. Where a vendor has no plans to update their software, organisations should weigh up the pros and cons of keeping with their current business continuity solution.
If you don’t already have a solution…ensuring that any new software will meet the requirements of 22301:2019 is a great starting point. But, if the solution doesn’t and you’re looking to certify then buyer beware! Personally, I would not rush into buying BC software at all until you have had a dry run in Word/PDF and Excel. Once you understand exactly what you need to achieve, only then upgrade to a formal software solution. Not all BC ‘solutions’ actually make your life better as anyone who has used LDRPS can attest!
I’m new to business continuity. Should my business adopt this 22301:2019?
If you’re a supplier of services to other organisations (e.g. B2B) then you are highly likely to undergo session after session of due-diligence. These audits can be incredibly resource-intensive. Adopting (and possibly getting certified) to standards such as 22301:2019 is likely to make your life so much easier. No matter who comes knocking you will know your BCMS covers most, if not all, of what your customer requires. 22301:2019 is now concise, and in plain English, so it’s entirely possible you could implement a 22301:2019 compliant BCMS without any business continuity software.
If you do want help with implementing a 22301:2019 BCMS, or a BCMS based on another framework or which BC software will best meet your businesses needs, get in touch – we can definitely help!
About The Author
About Fox Red Risk
Fox Red Risk is a boutique data protection and cybersecurity consultancy and Managed Security Service Provider which, amongst other things, helps client organisations with implementing control frameworks for resilience, data protection and information security risk management. Call us on 020 8242 6047 or contact us via the website to discuss your needs.
22301 22301:2019 article 28 awareness bcms BIA business continuity calculating risk change management ciso controller cybersecurity data breach data privacy Data Protection data protection by design data protection officer data protection service Data Subject Access Request DPO DSAR GDPR incident management information security leadership monitoring operational resilience Outsourced DPO Privacy processor risk risk appetite risk management ROI security security as a service small business strategic strategy Subject Access Request tools training transparency vciso virtual ciso
