Dashboards and Impacts Over Time
In part two of this series I looked at how the BIA can be undertaken and add value, the potential of starting with a lower order BIA, and a manufacturing focused example. Now let’s turn attention to impacts over time and how they are visualised.
The phrase ‘impacts over time’ has been present in the guidance for as long as I can remember and whenever we try to show this in a diagram, it is always shown as adverse impacts growing over the time of the incident, until they reach a time and magnitude that is deemed unacceptable (MTPD)
These are always depicted as a graph, which seems to suggest that the data for that graph emanates from the analysis of impacts over time.
So, it therefore follows that for each impact category, a true analysis would indicate the way these impacts manifest themselves over time.
Let us assume the organisation breaks down time frames into 4-hour slots across a BIA, to create that graph, you would need to quantify how these impacts adversely increase over time.
Each time period and quantified adverse impact would be plotted to develop the graph. This to me at least would be true analysis.
This means that adverse impacts must be quantified to deliver true analysis, common sense?
Ask yourselves, if a solution must not cost more than the impact and if to know this you must undertake a cost benefit analysis, then without quantified impacts how is that ever possible?
Quantified impacts then facilitate understanding the acceptable magnitude of adverse impacts and in what timeframe they will manifest themselves.
This then becomes the recovery time objective which has no value unless a minimum service target is also stated in the form of the MBCO.
Now we understand through quantified analysis what magnitude of adverse impact is unacceptable and what is acceptable, including when these time objectives and tolerances are reached.
An incident manager now has stated objectives in terms of priorities, timeframes and service levels. These will be finalised in the designing of strategies and solutions and once these are enabled, via projects and validation, they will be considered operationalised and fit-for-purpose, this will be covered in part three.
Traffic lights, dashboards, and so-called metrics
Anyone who has met me, knows what comes next: Red, Amber, Green (or any other colour combinations) are not adverse impacts, they are an attempt to codify impacts which leads to simply colouring in the BIA. (N.B. Burgundy is a wine and plum is a fruit).
High, Medium, and Low are not adverse impacts but descriptors that can be subjective. But fear not, I hear you say, we have a look up table which offers descriptive metrics, such as important or essential or some adverse publicity and substantial adverse publicity.
As if part one was not complex enough, now let us use colours, scores, and subjective metrics to justify our decisions. I will discuss my version of how the analysis should be undertaken (in my opinion) in part three.
So, part two in summary, the BIA is an analysis - a detailed examination of the elements or structure of something.
Colour coding and using designations that are incredibly open to interpretation (even in a descriptor table) serves extraordinarily little purpose and attempts to simplify the analysis to provide a compliant methodology.
This is why the perception of undertaking a BIA is often as a tick box procedure adding little if any value.
As mentioned in part one, whilst the role of AI could and should be to bring the BIA to life by providing genuine analysis, it is not a “silver bullet” either - as will be discussed in part four.
Doing it for real
It begins as a top-down analysis, which makes criticality a redundant term and priority the objective - priority suggests time and impacts are analysed over time.
Tolerances and service levels are proposed by top management and there need not be several levels of a BIA, simply ask the right knowledgeable people to undertake them.
This could include process owners, activity owners and resource owners, and do not forget to collaborate with procurement for externally provided products, services, processes, activities, and resources.
If you do not use MTPD or MBCO, do not work top down, still use criticality not priority, never quantify adverse impacts in terms of their growing magnitude over a timeframe. Are you really undertaking true analysis or simply complying or purporting to be aligned to a standard?
If you do not have a final report offering the consolidated business continuity requirements, you will not be able to effectively and efficiently design strategies and solutions.
This in practice means that the so-called analysis is simply transferred to a business continuity plan. All of which reinforces the contention that BIAs and BC plans are simply documented box ticking functions.
If your BIAs are regularly undertaken (some organisations do them every three to five years) and never change, are they true analysis? If most of your organisation believes and states that it will recover in less than a day, is the analysis truly indicative?
Look out for part four, which will look at a practical, top-down BIA implementation model, challenge superficial compliance practices, and look at where AI can be useful.
More on
About the author
David Window
Director
