John Robinson, FBCI, reviews ISO’s Technical Specification for conducting BIAs which was published on September 15th 2015.
To my mind, in the world of business continuity, the new ISO/TS 22317 guidance represents a significant step forward. It offers the chance for a reliable recipe and the ingredients for completing a perfect business impact analysis (BIA), a Holy Grail for many in the industry, and with good reason. Few find it easy to do well.
Having just read the Technical Specification, cover-to-cover, I liken its adoption to taking part in the BBC’s Great British Bake-Off Technical Challenge, currently cult viewing for many in the UK. For those who don’t know, in The Bake-Off contestants are provided with a hidden list of ingredients and a depleted recipe for completing a technically difficult task. They are then expected to use their knowledge and skill to fill in the gaps, baking a ‘perfect cake’ first time under stringent time pressure.
With this in mind, some of my observations below are simply nice touches. Others however, relate to potent alternative ingredients and technical steps. Worth considering, since you won’t know if your BIA will win ‘Star Baker’ until your plan is activated.
The Technical Specification has a useful two-page introduction followed by 27 pages of well-written substance. It doesn’t re-iterate any aspect of ISO 22301 (the business continuity management standard), which is refreshing. Working out at around $5.50 or £3.60 per page, it is good value and worth buying. It has three main sections: Pre-requisites; Performing the BIA; and Review and Monitoring; taking you through the BIA process a step at a time.
As you read it, your first impression is one of intensity, concise expression and the need to satisfy the very largest of organizations. It also generalises every point, maximising applicability and scope. Consequently, there is a strong onus on the reader to interpret every statement in their own context. Unsurprising, as the Technical Specification is aimed at all organizations, expect to work quite hard to make it fit. Nonetheless, as the de facto International guidance, should we reasonably expect detailed best-practice coverage of every generic aspect of the discipline?
Here are some points I noted as I read through the Technical Specification for the first time:
1. The Introduction shows BIA paired with risk assessment, in keeping with ISO 22301, but this is the last mention that the risk assessment or risk in general receives. This omission could result in divergence between related disciplines. It would help to add a brief section or line point on managing continuity risks. In practical terms, this can be done simply, linking to a risk register to drive scenarios and strategies using BIA-aligned responses. This ensures that every risk with high impact potential is assessed and, where necessary, accommodated by the business continuity plan.
2. The list of whole BIA outcomes in the Introduction seems to miss an important one: arming the organization with decision-making information to shape its response dynamically in a non-standard incident (sic). If you don’t present your BIA flexibly in the business continuity plan, then the rigid deadlines that it sets risk being ignored as soon as management sees a better plan of action. More on this in a later point.
3. The Technical Specification doesn’t make clear the strong adaptive relationship between strategy selection, cost, impact tolerance and timeframe (section 5.8 mentions strategy but only as a postscript titled ‘After the BIA’). Say you set an activity deadline requiring a vital IT application to be recovered in 24 hours and that this implies a £0.5M spend on replication. When this spend is rejected, you have to decide how to respond and either make an exception or reflect this hardening of risk appetite across the business (we’d rather take the hit than spend the money). It turns the tables, with budget now setting acceptable timeframes and placing a new implied value on impact tolerance. This introduces a feedback loop into the process, requiring potential iteration after the BIA is signed off. Strategy and BIA are thus linked and the cycle should reflect this.
4. Not everyone has the budget or resources to complete a full-spec BIA as detailed in the Technical Specification. I think the guidance should make it clearer that the level of detail, certainty and accuracy required may be varied, depending on need and appetite (there is a specific concession, towards the end of 4.3.2). I have completed valid BIAs to good first draft in a day, or so, where budget is limited and the perceived importance of BCM is low. Others take months. The fact is that any BIA needs to be detailed enough to ensure that all critical ingredients for recovery can be obtained in an acceptable timeframe, and drive business continuity planning and strategy deadlines with reasonable certainty. In my experience you don’t need to complete every stage to this level to get a result, but you do need a scalable, reliable system that shapes to fit.
5. Section 5.3 is about Product and Service Prioritisation and lies at the heart of BIA, driving the process. However, as is the way with standards, the Technical Specification provides the bones but no body, giving tantalising clues but not really stating what must be done to achieve the expected outcomes. The impact chart at Figure 4, for example, would be better shown per product since the aggregated picture tells us little. A good part of what’s missing is, to my mind, generic material: this should be present in a document that seeks to guide its readers to success.
6. Section 5.3 also seems to rely on top management to pluck priority and timeframe values from the air. I understand priorities to be based on governance, estimated loss rate and stakeholder tolerance (policy). The Technical Specification seems to jump in after the fact and assumes that top management will instinctively know what is tolerable without knowing why or referring to policy. Is there a step missing or did I overlook it? Generally, I would analyse the impact profile for all stakeholder groups and discuss with management the point where they pass the tolerance threshold.
7. Love them or hate them, the conscious omission of ISO 22301-consistent terminology (RTO, RPO) seems an unnecessary source of potential confusion, error or delay. The definitions are present in Annex B but are not used in the body of the Technical Specification so you can’t see where they come from or are used. People now use these acronyms and ultimately, we need to be able to use the guidance to set 22301-compliant recovery paths and deadlines for any blend of affected products under different disruption conditions. As a new practitioner using the Technical Specification with a view to 22301 accreditation, has it made it easier for me? Probably not.
8. Section 5.6 provides guidance on Analysis and Consolidation and as the name suggests, is potentially the core activity we engage in. BIA sets recovery intensity across the whole business continuity plan and errors get transmitted and potentially amplified via dependencies. Consequently, half-baked analysis can result in capability that ranges from over-specified; over-priced; unnecessary; burdensome to weak; ineffective; wasteful; and over-confident: with governance implications. Yet the Technical Specification holds back; it itemises techniques that may be adapted for this purpose, but it doesn’t offer a framework to conduct the analysis. Whilst understandable in one respect – professionals use different methods - as a practitioner faced with deploying best-practice BIA I would feel a little short-changed and in need of a more practical, decisive roadmap.
9. Annex C is helpful and identifies a number of good ways to collect information. Through its proposed use of scenarios, it highlights an important point affecting how we think about BIA.
Consider the breadth of scenarios that most of us might want to plan against. In a ‘no fault’ highly visible catastrophe, such as a chemical explosion, we might buy extra time; whereas an IT failure attracts little sympathy. A pandemic has yet more and different implications. In each situation we are potentially faced with different strategies and different acceptable resumption timeframes. In each situation, our BIA should be able to advise us how to recover optimally, although the interpretation may be substantially different. Add to this the need to respond acceptably to ‘Black Swan’ events and you can see that there are at least two possible approaches – static / wasteful / simplistic with hard, fixed RTOs; versus adaptive / efficient / considered.
Using scenarios in this way allows different situations to yield different response times and priorities. A mechanistic approach can look detailed and have great content, but risks abandonment as soon as a non-standard situation arises.
10. Finally, a round-up of questions the Technical Specification could help us with:
- What if the strategies required to support the BIA requirements are too expensive?
- Are the deadlines the same under all scenarios?
- Will this model be over-complicated for smaller firms?
- How do we perform timeframe analysis?
- How fast do we need to restore failed assets?
- How do we ensure the data we collect is consistent?
- How can the crisis team reason reliably in an incident using the mass of data we have acquired?
- How does the BIA relate to risk?
Overall, whilst a great step forward, I confess I find the Technical Specification a little data-based and mechanical, rather than explanatory, practical and helpful; particularly in some areas where practitioners might struggle. However, taking ISO’s point of view, in addition to the necessity of providing universal truths about performing acceptable BIA, it also needs to leave a layer of flexibility to allow the process to fit any organization and this may be why gaps appear to be present. Nonetheless the Technical Specification is a useful purposeful document and will benefit many businesses and practitioners.
ISO/TS 22317 can be obtained directly from ISO: click here for more details.
The author
John Robinson FBCI is managing director of Inoni Limited, a business continuity software supplier and consultancy company. Contact him at info@inoni.co.uk
John is the chair of the joint Continuity Central / Total Business Metrics BIA Special Interest Group. This takes place online every month and is open to all business continuity professionals around the world. The next BIA Special Interest Group takes place at 15.00 British Summer Time / 10.00 Eastern Time on October 20th and will consist of a question and answer session about the ISO/TS 22317 guidance. To take part sign up at https://bc.formstack.com/forms/biasig
