Why the BIA provides the foundation stone for business continuity
In the fourth instalment of this series in which Resilience professionals take an in-depth look at the Good Practice Guidelines, Sarah Armstrong-Smith MBCI discusses the practical value of a BIA to an organization.
In this blog, I talk to you about why I think the Business Impact Analysis (BIA) is the foundation stone for business continuity and how I’ve put the BCI Good Practice Guidelines (GPG) to practical use. This not a lesson in how to do a BIA as the GPG provides excellent guidance in that regards, but rather how the BIA can be used to extract real value from the organisation. When determining the criticality and priority for recovery, it’s not about who shouts loudest, or having preconceived ideas about what we think is important; it’s about really listening to the business and enabling them to tell you what’s critical and why.
Focus on inside out, and outside in
It never fails to amaze me the labyrinth of intricate parts that goes into making up an organisation, and it can often be difficult for individual teams to understand how they contribute to the success and vision of the business. I liken it to a delicate ecosystem where everything needs to work in balance and harmony to work efficiently and effectively. When you start changing or removing parts of the organisation, whether that is through structural change or an incident, that ecosystem becomes out of balance and therefore we need to understand the impact. Obviously the bigger the change, the bigger the impact; hence the need for appropriate strategies and plans to counteract this.
It’s important to take a holistic viewpoint and to understand how a major change or incident can affect not just the operation of your business, but also your customers, and potentially their customers, etc. In a world of digital transformation, where so many companies are interconnected and dependent on each other, it’s important that the BIA looks outward, not just inward.
For that reason, consider having BIA criteria that measures the societal and environmental impact, not just the operational impact of the incident. It’s really useful to focus the BIA participants on how they contribute to that. In particular, 99% of the UK private sector are small and medium enterprises and can often be completely reliant on the availability and continuity of larger organisations.
This is where the BIA adds value beyond traditional business continuity. When performed properly, the BIA provides a holistic overview of the organisation and its dependencies as part of a ‘value-chain’, which enables the organisation to be more strategic and proactive. This is an important factor when moving towards a resilient culture.
A resilient organisation is one that can pre-empt and adapt to change, irrespective of whether it’s a planned change or a sudden change. With change, also comes opportunities, so it’s about understanding the wider benefits that a BIA can provide to the organisation.
Establishing a consistent data set
To do that effectively, the BIA needs to be an ongoing reiterative process and done in the right way to get real value from it. As the old adage goes ‘garbage in, garbage out’. If the underpinning data is flawed or incomplete, then the strategy and plans that follow may also be flawed or incomplete.
To do a BIA well requires a degree of preparatory work, as the BIA relies on having a consistent data-set and naming conventions for resources such as people, IT systems, suppliers, buildings, specialist equipment etc as users may know them by different names. Let’s take email for example; it can often be referred to as ‘Email’ ‘Outlook, ‘Exchange’, ‘Messaging’ or some other platform, so we need to know the correct name known by the IT department otherwise we are at risk of identifying RTO’s for different resources, or double-counting which provides confusion.
It’s also a good idea to consider whether software can be used to aide in the BIA process. Spreadsheets may be OK for smaller organisations, but trying to do analysis over a large volume of data can be cumbersome and may not yield the required results, as it may be difficult to amalgamate and filter the information. I have found that software not only speeds up the process, but provides the ability to model different ‘what if’ scenarios.
Simply having impact statements of high, medium or low doesn’t provide any sense of urgency or consequence. It’s important to have a predefined and agreed business impact criteria and risk appetite using a range from ‘no impact’ up to ‘catastrophic’ in a range of categories such as:
- Human safety and welfare
- Society and environment
- Legal and regulatory
This criteria can be used to establish the Maximum Unacceptable Outage (MUO). The MUO is defined as the point where failure to deliver an activity may cause a ‘major’ impact, and hence the activity must be recovered before it reaches this point. This is a slight variation on the GPG, which describes this as the Maximum Acceptable Outage (MAO). However, by stating this as MUO, it gives a clearer indication of when the impact breaches the risk appetite, and cannot go above this.
It follows therefore that the target Recovery Time Objective (RTO) must be a timeframe that is less than the MUO, and is perhaps a more accurate description of what is an acceptable outage.
As the GPG states, this is not a measure of importance, as everything has an intrinsic value, but not everything is high priority or urgent.
Building on the Result
Whilst deploying software can help to standardize completion of BIAs in a consistent manner, this can also provide a holistic view of the BC requirements and dependencies in one place. This enables ‘fault analysis’ modelling and ‘what if scenarios’. For example, ‘what activities would be impacted in the event of building, ICT service or supplier failure?’ By understanding the dependency and criticality of resources, this enables investment to be made in accordance with business need.
The adoption of proven BC techniques such as the BIA enables a more effective and strategic enterprise response across all business functions.
About the author