Charlie revisits his bulletin on the Minimum Business Continuity Objective (MBCO) and provides some useful scenarios when developing your MBCO.

I seem to be on a roll with writing about different parts of the BIA, so this week I thought I would update a blog I wrote years ago on the MBCO. I wanted to consider whether the concept needs updating or, as often happens in business continuity, the underlying concept has not changed and nobody has invented anything better.

There is a second reason for writing this blog. As people, especially our Databarracks consultants, increasingly use AI to help deliver their assignments, they need clear definitions and guidance on how to conduct different activities. This bulletin could provide the basis for guidance on identifying and using MBCOs.

The MBCO is, in my opinion, an extremely important component of the business impact analysis (BIA). I have always thought that it is the poor cousin of the maximum tolerable period of disruption (MTPD): it is not used very often and is not really understood by many people.

The MBCO is the minimum capacity or level of products and services that is acceptable to the organisation during a disruption. The MBCO sits alongside the recovery time objective (RTO). The RTO defines how quickly we want an activity to be recovered, but, equally importantly, the MBCO defines the level at which that activity should be recovered.

An example would be a call centre with 1,000 people operating from a single site. During the BIA, the RTO for the call centre is set at 24 hours. Setting the MBCO is now key. If the MBCO is set at 1% of normal activity, we have to recover 10 call centre agents to deliver the service at this level. In terms of devising a recovery solution, this is not too difficult. Alternatively, if the MBCO is set at 80% of the normal level of calls taken, we have to develop a solution that can recover 800 agents within 24 hours. This is much more complex and probably a lot more expensive. The level at which the MBCO is set may therefore define the recovery solution as much as, or perhaps more than, the RTO.

The GPG states that an MBCO can be more than 100% of normal activity. For example, the MBCO for a staffed customer helpline could be set at 130% of normal activity because, during an incident, it is likely to receive more calls than on a normal day. In the same way, IT technical staff may have more work during an incident.

In setting an MBCO, we are defining the level at which the activity must be recovered. I have often asked people to show me their MBCO, and what they have shown me is a list of the resources required to achieve their stated RTO. This is not technically the same thing. You should first state the level at which the activity needs to be recovered and then identify the resources needed to achieve that level of recovery. The reason this is important is that there may be several different ways to achieve the stated MBCO, each requiring different levels or combinations of resources. You should always state the level of recovery required by the activity first and then consider the solution and resources required to achieve the stated MBCO. It should also be noted that you could have several different MBCOs and RTOs over time as the activity is progressively recovered. For example, you could require 25% of an activity within 24 hours, 60% within three days, and 100% within seven days.

I think we can learn something here from the operational resilience requirements applying to financial organisations. As part of this process, organisations must identify their important business services and set impact tolerances for them. They must then map the people, systems, premises, suppliers, and other resources required to deliver those services and remain within their impact tolerances during a severe but plausible disruption.

What I like about this approach is that it forces the organisation to start by considering the service delivered to the customer and the level at which that service must be delivered. Further planning then flows from this customer-focused requirement.

When teaching the MBCO, I say that there are several ways of stating it, and I give the following examples:

• Activity carried out at 75%, 50% or 25% of its normal level.
• Only emergency repairs will be completed. All other repairs will be recorded and returned to at a later date.
• We will check the generators every three months rather than monthly.
• Customer correspondence will use standard templates during the disruption and will not include the normal level of personalisation.
• Priority customers will receive a response within 4 days rather than the normal 2 days.
• All invoices will be processed within 20 days, rather than our normal target of 10 days.
• Our emergency call-handling capacity will meet the forecast incident demand, which may be 130% of normal volumes.

When developing the MBCO for an activity, I first consider whether the activity can be carried out at less than its normal level. If it can, I then ask the following questions:

• Do I need to change the volume of activity carried out?
• Do I need to change the time taken to carry out the activity?
• Do I need to change the quality at which the activity is carried out?

Asking activity owners to consider how they could reduce or change their activities gets them thinking about what a reduced level of service would look like. This is much more useful than making a random decision, such as “I will reduce my activity by 50%”, without really understanding what that means in practice.

A useful MBCO should be sufficiently precise to support solutions design and subsequent exercising. It may specify volume, time, quality, customer group, product rangem, service delivery, or a combination of these.

Once the required level of service has been decided, the people, systems, premises, suppliers, and procedures needed to meet the objective should be identified separately as part of solutions design.

If you have not considered MBCOs as part of your BIA, or if you have defined them only as a list of resources, I suggest that you revisit them during your next review. Start with the minimum acceptable level of service, make sure it can be measured, and then determine the solutions and resources needed to deliver it.