The short answer is that business continuity and operational resilience are asking genuinely different questions. Business continuity asks how quickly the organisation can recover after a disruption. Operational resilience asks whether the organisation can keep delivering its most important services to customers throughout a disruption, not just after it has ended.
That distinction sounds subtle but has significant practical consequences for how each discipline is designed, tested, governed, and reported. This article explains both disciplines clearly, identifies the five most important differences between them, and sets out how they fit together as complementary rather than competing approaches.
Business continuity planning is the discipline of ensuring an organisation can continue or restore its operations after a disruptive event. It addresses the fundamental question: if something significant goes wrong, how will we get back to functioning?
The core metrics of business continuity are the Recovery Time Objective and the Recovery Point Objective. The Recovery Time Objective defines the maximum acceptable time before a business function must be restored to operation. The Recovery Point Objective defines the maximum acceptable amount of data loss, measured in time, that the organisation could sustain and still recover effectively. These objectives are typically set for each significant business function and are used to determine what backup and recovery capabilities need to be in place.
Business continuity plans are typically structured around the internal building blocks that the organisation needs to restore: systems, processes, people, locations, and data. A business continuity plan for a payment processing function might specify that the primary processing system must be restored within four hours, that a secondary site can take over processing within two hours, and that backup data is available at no more than one hour's latency.
Business continuity planning is well suited to events with a clear disruption-and-recovery profile: a system outage, a fire destroying a facility, a cyber incident that takes critical infrastructure offline. These events have a beginning, a period of disruption, and a recovery phase. Business continuity planning addresses the recovery phase comprehensively.
Business continuity is also well suited to events that primarily affect internal capabilities rather than the organisation's ability to deliver services to external parties. If a building becomes unavailable, the business continuity plan addresses how the people who work there continue doing their jobs from another location. The question of whether customers can tell the difference during the disruption is addressed only incidentally.
Operational resilience, as framed by the FCA and PRA in their policy statement PS21/3 and by equivalent frameworks in other jurisdictions, takes a fundamentally different starting point. It does not start with the organisation's internal systems and processes and ask how they can be restored. It starts with the services the organisation delivers to customers and asks whether those services can continue to be delivered even while a disruption is occurring.
The central concept is the important business service: a service that, if severely disrupted, would cause intolerable harm to customers, to market integrity, or to the organisation's own viability. Identifying which services are important business services is the foundational analytical exercise of operational resilience, and it is done from the customer's perspective rather than from the organisation's internal structure.
The impact tolerance is the maximum level of disruption to an important business service that the organisation and its regulator consider acceptable before harm becomes intolerable. It is expressed in terms of time, for example, this service cannot be unavailable for more than four hours continuously, and sometimes in terms of data integrity or service degradation thresholds.
Critically, the impact tolerance is set based on what is tolerable from a customer and market perspective, not based on what recovery capability the organisation currently has. If the organisation's current capabilities mean it could not restore a service within four hours, the answer is not to set the impact tolerance at six hours. The answer is to invest in the capabilities needed to meet a tolerance defined by what constitutes intolerable harm.
This is where the FCA and PRA framework places the most significant demand. The Bank of England's supervisory statement SS1/20 requires firms to set impact tolerances, map the dependencies that support each important business service, and demonstrate through scenario testing that they can remain within those tolerances under a range of severe but plausible disruption scenarios.
Business continuity is about restoring operations after disruption. Operational resilience is about maintaining service delivery throughout disruption. The Recovery Time Objective asks how long recovery will take. The impact tolerance asks whether the service can keep running while recovery is happening.
Business continuity plans are built around internal building blocks: systems, locations, teams. Important business services, the organising concept of operational resilience, are defined from the customer perspective. A bank might run its payment processing through three internal systems, two sites, and five teams. From the customer perspective, all of this produces one service: the ability to make a payment. Resilience is assessed at the service level, not the building block level.
Operational resilience requires mapping the full chain of people, technology, data, facilities, and third parties that support each important business service, because a weakness anywhere in that chain can cause an impact tolerance to be breached. Business continuity plans typically address the most obvious internal dependencies without mapping the complete chain including third-party and fourth-party dependencies.
This depth of mapping is where many organisations find the most significant gaps when they begin resilience work in earnest. Services that appeared to have adequate recovery capability are found to depend on third-party providers, technology components, or data sources that have not been included in continuity planning and that could not be replaced within the impact tolerance if they failed.
Business continuity testing typically confirms that a known plan can be executed: the secondary site can be activated, the backup system can take over, the recovery procedures work. It rarely probes what happens if the plan itself fails or if the disruption is more severe than the plan anticipated.
Operational resilience testing uses severe scenarios specifically designed to find the conditions under which impact tolerances would be breached. Rather than testing that the plan works in normal scenarios, resilience testing identifies the point at which resilience fails, so that the organisation understands where its genuine limits are.
Business continuity has been a regulatory expectation in many sectors for some years but typically without the specific board accountability and evidential requirements that operational resilience now carries. The FCA requires boards to approve important business services and impact tolerances, to receive evidence that testing has been conducted, and to sign off on annual self-assessments of compliance with the policy statement's requirements.
Business continuity and operational resilience are not alternatives. They address different dimensions of the same fundamental challenge, and a mature approach requires both.
Business continuity planning provides the practical detail that gets activated when a disruption occurs: the specific recovery procedures, the escalation paths, the communication protocols, the alternative sites and systems. Without this level of operational detail, the aspiration to remain within an impact tolerance is not backed by the capability to deliver it.
Recovery Time Objectives inform impact tolerances. If a business continuity plan specifies a four-hour Recovery Time Objective for a critical system, that objective should be tested against the impact tolerance for the service it supports. If the impact tolerance is two hours and the Recovery Time Objective is four hours, there is a gap that resilience governance must address.
Operational resilience provides the service-level governance, the customer-outcome focus, and the depth of dependency mapping that business continuity planning alone does not provide. It asks whether the customer experience remains acceptable during a disruption, not only whether internal systems eventually recover. And it provides the regulatory framework and board-level accountability structure that business continuity planning has typically lacked.