In mid-September, a new technical specification, ISO/TS 22317 Societal security — Business continuity management systems — Guidelines for Business Impact Analysis (BIA), was issued which is poised to significantly improve the way organisations approach their BIA processes.

So, what does this actually mean for you as a BC professional? What is ISO/TS 22317 and why is it a positive step for BC?

Maybe it’s easier to first describe what ISO/TS 22317 is NOT. It’s not about BCM program scope, it’s not about Risk, it’s not about Strategy, and it’s not about Plans. In fact, it’s not about threats, or likelihood, or scenarios, or RTO, or the cost of a recovery capability.

When you peel away these components of the broader BCM process you’re left with a tight focus on what Business Impact Analysis means as defined in ISO 22301 clause 8.2.2. In summary, it focuses on the use of impact over time to determine how quickly products and services (hence Business Activities and Resources) need to be made available after a disruption. It is about defining the business requirements for continuity. How you deliver to those requirements, how much it will cost, how much can you afford, who will manage the recovery process etc. are all beyond the BIA.

Business Impact Analysis (BIA)

It’s this aspect of ISO/TS 22317 that I really like because I’ve seen too many organisations manipulate BIA results to suit a capability spend limit. This is wrong[1] because it masks the true business requirement for continuity and creates an unknown exposure for the organisation.

I see too many people blur BIA and Risk Assessment, even though they are separate activities within ISO 22301. By definition, Risk includes the attribute of likelihood (or probability) for the purpose of considering controls (i.e. treatments) to stop or limit a threat. BIA assumes that a disruption does strike – it’s not an issue of probability. The philosophy of BIA is to determine Maximum Tolerable Period of Disruption (MTPD) solely on magnitude of impact over time regardless of the cause. That’s why the word ‘threat’ doesn’t appear in the body of the standard. To me, this reaffirms that you shouldn’t use scenarios (i.e. a range of threats) to determine how quickly products and services should be restored. Scenarios are a tool which should be used exclusively for Exercising.

A common complaint is that the BIA process is long, complex and time-consuming. This is the case when the BC Analyst rolls risk assessment, scenario considerations, risk appetite, strategy considerations and spend appetite etc. into the BIA.  This will not be the case when the BIA is focused solely on Impact over time, as stated in the standard.

Recovery Time Objective (RTO)

RTO is not included in this standard as it is considered to be a Strategy stage discussion point. Why? The answer lies in its name: Recovery Time OBJECTIVE.

Being an Objective means you have flexibility and choice which comes from a variety of decision attributes such as stakeholder tolerance, risk appetite, spend limits etc., all part of the strategy for dealing with the disruption. I can certainly understand why people feel that RTO belongs to the BIA process and I think there is a balance that needs to be found. There is opportunity to combine various BC lifecycle steps to reduce the overhead of hitting managers more times than necessary. For example; even though RTO is a strategy stage discussion point, I do include it in the BIA discussion AFTER I have defined the MTPD. For the sake of a few extra minutes it makes sense to continue the discussion of time-frames to estimate the target time-frame for recovery. This will then form a basis for discussion (and potential amendment) during the strategy phase of the BC lifecycle.

So, why is ISO/TS 22317 great for the Business Continuity community?

1. Puts the onus of Product and Service prioritisation on Top Management

If they don’t know, then the organisation has a bigger problem than poorly-defined BC requirements.

2. States that the process mapping step is optional.

Personally, I find this a complex task requiring a specialist and lots of time to map the flow. Unless you’re in heavy industry e.g. mining, I think it’s an unnecessary step especially if you’re going to define Business Activities anyway.

3.Binds the concept of prioritisation with time i.e. prioritized time-frames.

Prioritisation without a time attribute does not protect the organisation from failure.

4. Presents the BIA as a process, requiring management/facilitation, planning, maintaining, improving and reporting.

It’s not just about running a few workshops.

5. Does not refer to the words Threat, Likelihood or Scenario within the main body of the document.

It confirms that BIA and RM are two different management disciplines.

6. Contains a clause (the very last section; D.6) that highlights to the reader that BIA undertaken via a risk-based standard is inappropriate as a method to determine recovery requirements.

It highlights the irony that you place the organisation at Risk if you undertake the BIA based on a Risk Management philosophy as per my 5th point.

7. Of course there will always be opportunity for improvement. I’d like to see:

  • More depth to the definition of Impact Categories

Specifically, how and why they are different to Consequence categories (from the Risk Management Framework) and how to define a tiered structure (e.g. 5 levels) of impact levels using objective references or definitions. Ask five managers what “Significant” means and you’ll get five different responses.

  • A better definition of MTPD

The use of the term unacceptable in the definition of MTPD is, in my mind, unacceptable. It’s too subjective. I always use the so what test to see if someone’s MTPD is just really, really bad, or so catastrophic it will cause the organisation to fail (politically or go out of business).

Is ISO/TS 22317 perfect? NO – no standard is, but it’s a very solid platform to help explain what seven sentences in the parent standard ISO 22301 means. The success of this Technical Standard will hopefully pave the way for sister Technical Standards for BC such as; Strategy, Procedure development, Integration of Emergency Response and Team structures.

Still unsure how you can drive value from ISO/TS 22317 to improve your organisation’s BIA processes? Contact me directly on 03 9017 2119 or via our contact form, and I will happily answer any specific questions you have.

[1] I’m not one for using the word wrong in such black and white terms but in this case I have to.