Author

Saul Midler FBCI

The Draft International Business Continuity (BC) Standard ISO22301 “Societal security — Preparedness and Continuity Management Systems – Requirements” focuses on the requirements for setting up and managing an effective Business Continuity Management System (BCMS).

The ISO Committee developing the Standard has input from 46 countries and uses their standards and guidelines as a basis, including BS25999 (particularly Part 2 – UK), HB221:2004 (Australia/New Zealand) and documents from USA, Israel, Japan and Singapore.

ISO22301 focuses on Business Continuity Management, with more emphasis on:

• Structure and Leadership;
• Tangible, auditable evidence.

It applies the Plan-Do-Check-Act (PDCA) cycle to planning, establishing, implementing, operating, monitoring, reviewing, exercising, maintaining and continually improving the effectiveness of an organisation’s BCMS.

In this Draft Standard, BCM is definitively separated from Risk Management (RM), unlike some existing Standards and Guidelines (notably AS/NZS5050 “Business continuity – Managing Disruption-related Risk”).

This Think Piece explores 10 reasons why ISO22301 will change BCM, for the better.

1. Business Impact Analysis is BCM, Not RM

Section 3.3 defines the Business Impact Analysis (BIA) as the

“…process of analysing Business Functions and the effect that the business disruption may have on them.”

ISO 22301 defines what a BIA is and how you do it, focusing on the business functions and the effect of business disruption on those business functions. There is no reference to likelihood, as in some existing Standards and Guidelines, and the emphasis is on analysing what happens when the business disruption occurs, not if it occurs.

2. Events, Not Disasters

Section 3.12 defines an event as the occurrence or change of a particular set of circumstances, which can sometimes be referred to as an “incident” or “accident”.

There is no reference to a ‘disaster’, which recognises that a disaster may be the result or outcome if we are not prepared to deal with a significant disruption event.

3. Flexible Procedures, Not Plans

Section 3.30 defines procedures, not plans. Procedures are defined as a specified way to carry out an activity or process, and a BC plan is a suite of procedures which are implemented to respond to and recover from an event. This gives BCM the granularity and detail required to actually perform its function – responding to and recovering from an event. A BC Plan shows what to do, but the procedures show how to do it.

Section 8.5.1 defines a BC Response as documented procedures (including necessary arrangements). Procedures must ensure continuity of activities and management of a disruptive event, and must also be flexible to respond to unanticipated threat scenarios and changing internal and external conditions.

Section 8.5.5 defines BC plans as implementation procedures. This confirms that BC plans are a collection of procedures used to restore functions and resources following a disruption.

4. Procedures must be Prioritised

Section 3.32 states that activities must be prioritised following an incident in order to mitigate impacts. Prioritising tells the organisation which procedures must be invoked in which order to ensure that the impact of an event is minimised. Traditional BC plans do not contain prioritisation lists, so time and resources can be wasted in trying to clarify the requirements for business recovery.

5. BCM must be led by Top Management

In Section 5 – Leadership, ISO 22301 states that top management shall demonstrate leadership by:

• visibly directing and controlling its overall direction and operation;
• motivating persons to ensure the BCMS supports the business continuity performance of the organisation.

Further, Section 5.2 – Management Commitment states that Top management shall demonstrate its commitment:

• Integrating the BCMS into the organisation’s business processes;
• Providing the resources for the PDCA cycle;
• Communicating importance for conforming to the BCMS process.

Top-down support for BCM is mandated. The importance of BCM is to be recognised by the organisation and support for the process is required. This gives BCM traction and leverage in the organisation to ensure that the BCM Life Cycle is followed in the normal course of business. Top Management are being told to walk the talk, in the process making the BC Professional’s job easier.

6. BCM Documentation Must be Controlled

Section 7.5.3 – Control of Documented Information – states that

“…documented information required by the BCMS shall be controlled.”

Controls for documented information shall include as applicable:

• Distribution;
• Access;
• Storage and preservation;
• Retrieval and use;
• Identification of version and changes;
• Preservation of legibility (i.e. clear enough to read);
• Prevention of the unintended use of obsolete information;
• Retention and disposition.

How can you ensure that a paper BC Plan is not obsolete? By its very nature, it becomes obsolete as soon as it is issued. Paper BC Plans are printed and then dispatched and delivered to each area of the Organisation, where they are filed away until an event strikes.

What if an event doesn’t occur for six (6) months? Will the responsible person be able to find the Plan? Will it reflect the fact that the organisation has changed in this time, such as staff loss, retired and new IT systems, new business functions etc?

BCMS Software ensures that the changing needs of an event can be taken into account when producing the BC Plan to recover from that event, at the time it occurs. Changes such as:

• Changing RTOs due to seasonality;
• Geographic Impact, where only part of the organisation is affected;
• New Teams Required;
• Recovery location unavailable.

BCMS Software should cascade changes through your data so that Plans reflect the new circumstances. Plans can be produced on your screen instead of printed, and then distributed to laptops, phones, tablets or other portable devices using mobile delivery technology, removing the need for paper plans entirely and ensuring that plans are always legible and accessible.

7. Likelihood is Irrelevant

Section 8.4.3 – BIA and RA – excludes likelihood from BIA. Since BCM assumes a disruption event will strike, the likelihood of a type of disruption occurring is irrelevant. Likelihood should only come into play when devising exercise scenarios or considering strategies.

Section 8.4.3 also sequences Risk Assessment (RA) after the BIA and outsources it to ISO31000 – Risk Management Principles and guidelines. This approach separates Enterprise Risk Management from Operational Risk Management. The BIA identifies Time Critical functions which need to be assessed for Risk. This allows you to focus the RA on areas with increased impact, decreasing effort and expense.

8. Multiple Strategies Means Flexibility

Section 8.4.4.1 – Determination and Selection, states that the determination and selection of options shall be based on the outputs from the BIA and RA.

‘Options’ infers multiple strategies. It is good business management practice to consider options instead of only one strategy in case the preferred strategy cannot be implemented when the event occurs. Options also offer a different balance of advantages, disadvantages and costs.

For example, a recovery location or vendor may be unavailable, or all of your company locations may be affected by an event at the same time (it can, and did happen in January 2011 in the Queensland floods).

9. Exercising or Checking is Imperative

Section 8.6 – Checking – places a strong emphasis on Checking/Exercising, reinforcing the key principles of Exercising.

An Organisation cannot feel protected against an event until recovery procedures have actually been tested and team members understand what they need to do. An organisation is not automatically covered just because procedures and BCM capabilities exist. They must also work!

10. Programme Management = Continual Improvement

Section 10 – Improvement deals with nonconformity and corrective action (Section 10.1) and Continual Improvement (Section 10.2).

Programme Management, driven by PDCA, reinforces the notion that organisations change. A BCMS must reflect the current situation in an Organisation, so must be continually updated through the BCM Lifecycle.

BCMS Software should reflect the BCM Lifecycle and provide tools to ensure the BCMS is always up-to-date, for example, reminder and escalation emails and dashboard reports.

BCMS Software will help you align your Organisation to the requirements of ISO22301, by allowing you to:

• Define flexible procedures;
• Produce prioritised Procedure lists (Plans) for event response and recovery;
• Control your BCM Documentation, including ensuring that it is up-to-date and always accessible;
• Define multiple, flexible Strategies;
• Manage your Exercising Program;
• Implement Programme Management to manage your BCM Lifecycle

Terra Firma Revive BCMS’ provides all of this functionality, and will always dynamically reflect any changes made to any data at any time, on any platform. For more information about the dynamic update, read our Think Piece “4 Reasons you need Elastic Plans – How Flexible BC Plans Enhance your Ability to Recover.”

If you ensure that your Organisation aligns to ISO22301 – Societal security – Preparedness and Continuity Management Systems – you can be confident that you are following BCM best practice, and thereby improving your organisation’s ability to respond to any type of disruption event.