Is the Risk Register a red herring for Business Continuity Planning?

Risk Register

It feels that a logical starting point for the Business Continuity Planning process would be the major risks that the business faces and, therefore, the Risks identified in the Risk Register. But when building Resilience, the Risk Register can be a red herring.

Let's first state the obvious that (commercial) organisations exist to generate income, profit and a return for shareholders by delivering their products and services, that is the reason for existing. They do this by utilising their Assets and Resources, and anything that disrupts this capability, whether an internal or external factor, is a risk to the business and needs to be addressed.


Let’s consider the purpose of the Risk Register

A Risk Register is a document that records your organisation's identified risks, the likelihood and consequences of a risk occurring, the actions you take to reduce those risks and who is responsible for managing them.

It enables you to store your risk information in one easily accessible location. Its simple, consistent format makes it easier for people to understand the presented information and provide feedback.

A Risk Register is also an important mechanism for the Board to demonstrate good governance to stakeholders.

Importantly, a Risk Register specifies the ways your team commits to managing the identified risks and who is responsible for doing so. The Risk Register is event-based.

17th March 2000, Albuqurque, New Mexico*. 

A power line was struck by lightning in an electrical storm, causing a power surge which in turn started a small fire in Philips' chip manufacturing plant, which supplied both Ericsson and Nokia, 40% of its production capacity.

The sprinkler system put out the fire in 10 minutes with slight building damage. However, in the process of the incident, thousands of chips being manufactured were destroyed. The sprinkler activation and smoke contamination rendered millions of chips obsolete.

Ericsson, at the time Sweden's largest company with an annual revenue of $30 billion, had been moving to single sourcing as a means of controlling cost and efficiency and used this plant as the sole supplier of radio frequency chips. Even though this wasn't a major fire, it still took 6 months for production levels to reach 50% of the pre-incident volume. Ericsson reported that the total fire cost was more than $400 million (approx $700 million: 2022), which contributed to a $1.7bn (approx $3bn: 2022) loss in the mobile phone division for the year. Ericsson subsequently withdrew from handset production and outsourced manufacturing to Flextronics International.

Nokia, another telecoms leader with annual revenues of $20 billion, had implemented a multiple supplier strategy as part of their supply chain strategy, having experienced sole supplier issues previously. Their rapid response to the incident allowed them to leverage supply of chips from other partners in USA and Japan within 5 days and from other Philip's production sites, some 10 million chips. Nokia experienced hardly any disruption to production.

Given the far-reaching consequences of this event, where did this figure in the Ericsson Risk Register, or was this such an unforeseen event that it didn't register?

In many ways, this highlights why the Risk Register and Business Continuity Planning need to be kept separate

The Risk Register focuses on the major organisational risks and assesses the Likelihood and Consequence of the risk. It then defines risk management and mitigation measures. But it can miss the unknown risks, the so-called Black Swans and lower-level operational risks, as in the example above.

If we think about the Covid Pandemic, most organisations hadn’t planned for it and didn't list Global Pandemic on their Risk Register.

Many office-based businesses had the infrastructure in place (Microsoft Office 365, Teams etc) so that they could flip the operations to a virtual set-up. They had planned, perhaps inadvertently, for the loss of the working environment, regardless of the cause, in this case, "Lock-down".

It also highlights the difference between the Disaster Recovery Plan (DRP) - for dealing with major events and the Business Continuity Plan - the ability to continue delivering your products and services regardless of what the business experiences.

The DRP reacts should a major event occur.

The Business Continuity Plan (BCP) should minimise disruption in the first place, in the example above, by utilising a dual-, multi-supplier policy or Just-in-Case supply chain strategies as Nokia had and allow the business to recover its operations within its Tolerance for Disruption.

A key element to this is the Analysis phase of the Business Continuity process, particularly Business Impact Analysis, which will help identify where the programme design needs to be targeted. In many respects, a robust BCP effectively ignores "Likelihood" and focuses on Consequence – “it doesn’t matter why the supplier isn’t able to supply, we have a plan b”.


Black swan event

Ignoring Likelihood

In some recent planning work with a business, a key part of the process, distribution of product, was outsourced to a national company. Whilst there can be an assumption that larger organisations will have robust Disaster Recovery and Business Continuity in place, again, as highlighted above, this is not always the case. So, as part of their Programme Design, they started to address the "Loss of Distribution Capability" and within 6 weeks, their distribution partner served notice on them. A non-event-specific approach meant they were already able to deal with this.

With another business that we worked with, one of their Business Continuity Objectives was to put in place a dual-supplier strategy to remove the risk of a critical component in their product; a new supplier would take upwards of 20 weeks to bring on board, they had a Minumum Tolerable Period of Disruption (MTPD) of 12 weeks. Within 6 months of the new supplier coming online, they had to invoke this business continuity measure as their original supplier came close to financial collapse.

And unlike the DRP, the BCP is constantly operating, using readily deployable arrangements and resources to reinstate its business functionality, regardless of the severity of the incident. 

So how should the Risk Register interact with the Business Continuity Plan?

One way is quite simply that Business Continuity or Resilience (i.e. the ability to continue delivering product/service......) should be one of the risks identified on the Risk Register, the treatment for which is the Business Continuity Plans. The plans should be how the organisation deals with unknown or unforeseen risks.

The second is to use the Risk Register to validate the outcomes of the BCP – does it deal with our major risks?

It is important to understand that they are separate risk tools.

More information on Business Continuity Planning

If you’d like more advice on Business Continuity Planning, download our 9 Steps to Business Continuity Guide, which can help fast-track and focus your BC Planning with the minimum of jargon and practical tips on how to keep the process effective and productive.   Or get in touch for a chat about how we may be able to help you move your business continuity planning forwards. 

If you found this article useful, you may also be interested in our related insights such as:-

* Case Study Reference - Supply Chain Risk Management by Donald Waters 

Free e-book: 9 Steps to Business Continuity

Fast-track and focus your Business Continuity Planning with the minimum of jargon and practical tips on how to keep the process effective and productive.

Download Now


Download to save, print or share this insight.


How can we help you?

Our friendly expert team are here to help. If you have a specific question about one of our solutions or need our help assessing your company needs contact us. If you would like a meeting to understand the benefits of BCarm, schedule a time and date convenient for you here.

Arrange a meeting

Initialising form...

If this text doesn't change, this form has crashed. We apologise for the inconvenience.

Wave shape Wave shape