Operational resilience vs business continuity: what actually changes

Operational resilience is an outcome-based discipline: the organisation's ability to keep its important business services within impact tolerance during disruption. The test is not whether each recovery plan worked — it is whether the service the customer depends on stayed inside the boundary of tolerable harm.

An outcome, not a thicker plan

Classic business continuity management grew up around processes and resources: identify the critical processes, analyse the impact of losing them, write recovery plans, exercise the plans. Operational resilience starts from the opposite end. It assumes disruption will happen — the data centre will fail, a key vendor will be breached, the payment switch will drop — and asks one question: will the important business services stay within tolerable harm while it happens? The two views can disagree. A process can be down while the service is still delivered through a workaround; equally, every process can recover "on time" while customers, counterparties and the regulator absorb damage nobody agreed to accept. So the unit of management shifts from the process inside the organisation to the service as the customer and the market experience it — end to end, across departments, systems and third parties.

Where the term comes from, and why it is now law

The vocabulary was written by regulators, not consultants. The Bank of England, the PRA and the FCA built the UK regime on three terms — important business services, impact tolerance, and severe but plausible scenarios — and required firms to be able to remain within their tolerances by March 2025. The European Union encoded the same logic for the financial sector in DORA, applicable since January 2025, with digital services and ICT third parties at its centre. In the Gulf, the Central Bank of the UAE has set operational resilience expectations for licensed financial institutions on the same three concepts; the specifics for UAE banks — scope, timelines and what supervisors ask about first — are covered on our CBUAE operational resilience page. Three jurisdictions, one shared language. When supervisors on three continents independently converge on the same words, the shift is structural, not a fashion.

Diagram of risk capacity, risk appetite and impact tolerance as nested boundaries — Impact tolerance belongs to the same nested logic as capacity and appetite: it is the boundary of harm the board accepts for a single service.

What actually changes compared with classic BCM

The differences are few, but each one bites.

	Classic BCM	Operational resilience
Unit of analysis	Critical processes and the resources behind them	Important business services, end to end, third parties included
Core metric	RTO and RPO per process	Impact tolerance per service — a harm boundary, not a recovery target
Testing	Plan walkthroughs and scheduled exercises	Severe but plausible scenarios, run to the point of failure
Governance	Delegated to the continuity manager	Board accountability built into the regime

The sharpest change is the metric. An RTO is a target for restoring one process, and meeting every RTO proves only that the plans work in isolation — the mechanics of RTO, RPO and MTPD are set out in our recovery objectives guide. An impact tolerance is a judgement about harm: the point beyond which disruption of a service hurts customers, the market or the firm's own viability in a way the board refuses to accept. A firm can meet every RTO on the schedule and still breach a tolerance, because harm accumulates along the whole chain. Testing changes with the metric: a walkthrough asks whether the plan runs; a severe but plausible scenario asks at what point the service breaks, and expects the honest answer to be uncomfortable. Accountability moves up in the same motion — the board approves the list of services and their tolerances and answers for them to the supervisor. What a board pack for that duty should contain is a separate guide on board reporting.

Diagram of the boundary beyond which disruption becomes intolerable harm — The tolerance boundary: before it, disruption is damage to be managed; beyond it, harm the board has declared unacceptable.

The bridge from an existing BCM system: four steps

None of this discards BCM. The business impact analysis, the plans and the exercising habit become the engine room; what resilience adds is the outcome layer above them. Four steps carry an existing system across.

Map important business services. List what the organisation delivers to customers and the market, not what departments do. Keep the list short — a mid-sized bank typically names eight to twelve. For each service, chart the full chain that delivers it: people, sites, systems, data, third parties.
Set impact tolerances. For each service the board approves a boundary — maximum hours of disruption, transactions lost or customers affected — derived from the harm done, not from what current recovery arrangements happen to achieve.
Test to the breaking point. Design severe but plausible scenarios and run each service against them until the tolerance is breached. The output is not a pass mark; it is a map of vulnerabilities, each with an owner and a remediation date.
Report to the board. Services, tolerances, test results and remediation progress become a standing board agenda item rather than an annual annex.

Impact tolerance, the regulatory layer behind it and the mechanics of this transition are taught step by step in the ERGP programme.

This topic is part of the working language of ERGP — the first resilience governance certification fully available in Arabic, also in English. 94 chapters, six modules, a verifiable certificate.

Explore the ERGP programme