Operational Resilience vs Business Continuity: Services, Tolerances and Plans Compared

Many organisations believe a certified business continuity programme makes them operationally resilient, then find in their first severe scenario test that every plan worked and the customer-facing service still failed. Business continuity management (BCM) is plan-based: it asks how each process or site recovers after a disruption. Operational resilience is service-based: it asks how much harm the organisation will tolerate to the services its customers and markets depend on, and whether it can stay inside that limit when, not if, something breaks. This guide compares the two ways of thinking, shows where impact tolerances differ from recovery time objectives, and explains how to run both without duplicating effort. It is written for resilience leads, BCM managers, CISOs and risk teams. Regime detail sits in the regulatory guides linked below, such as the UK Financial Operational Resilience Guide and the DORA Guide; this page focuses on the operating model choice.

Key takeaways

• The unit of analysis differs. BCM plans around processes, sites and systems; operational resilience starts from the end-to-end service an external user receives.
• Impact tolerance is not an RTO. An RTO is an internal recovery target for a resource; an impact tolerance is the maximum harm to a service, set from the customer's and market's point of view, and every supporting RTO must sit inside it.
• Resilience assumes failure. Scenario testing asks whether you stay within tolerance in severe but plausible events, including ones where the plan itself cannot run.
• Third parties are inside the service. Plans that stop at the organisation's boundary miss the supplier and cloud dependencies that most often break a service.
• Build one programme, not two. Use the BIA, plans and exercises of BCM as the engine and the service map, tolerances and self-assessment of operational resilience as the steering.

Short answer

Business continuity is a necessary component of operational resilience, not a substitute for it. If you are a regulated financial firm under the UK, EU, Swiss, Canadian or Australian regimes, you need the operational resilience model, with business continuity plans as one of its tools. If you are not regulated this way, a mature BCM programme aligned to ISO 22301 is a sound baseline, and borrowing two operational resilience ideas (service mapping across third parties and tolerance-based severe scenario testing) closes its most common blind spots.

Side-by-side comparison

Business continuity management in depth

Threat model

BCM grew from planning for physical loss: a building, a data centre, a pandemic absence or a key supplier. It assumes the organisation can identify scenarios in advance and write a plan for each. That still works well for many events, and ISO 22301 gives it a management system wrapper with policy, objectives, internal audit and continual improvement. See the ISO 22301 Business Continuity Guide.

Architecture in words

A BIA ranks activities by the impact of losing them over time and sets recovery objectives. NIST SP 800-34 Rev. 1 frames this for information systems, with a BIA template and contingency plan templates for low, moderate and high impact systems. Continuity strategies (alternative sites, manual workarounds, DR replication) are chosen to meet those objectives, plans document who does what, and an exercise programme tests them. The Business Continuity and Disaster Recovery Guide covers this machinery.

Failure modes

• Silo recovery: each process recovers to its own RTO, but nobody checks whether the customer journey that strings them together works.
• Plan dependency: plans assume email, identity, collaboration tools and the plan repository survive. Destructive cyber attacks remove exactly those.
• Internal targets: RTOs set by what IT can deliver rather than by the harm a customer suffers.
• Boundary blindness: supplier continuity reduced to an annual questionnaire, with no mapping of fourth parties or shared cloud regions.

Controls

BIA refresh at least annually and after change, documented plans with alternates, exercise programme from walkthrough to full interruption, and post-exercise improvement tracking.

Operational resilience in depth

Threat model

The FCA describes operational resilience as the ability to prevent, adapt and respond to, and recover and learn from operational disruption. The model assumes disruption will happen and that its cause, cyber attack, supplier failure, change gone wrong, is less predictable than its effect. The Basel Committee's Principles for operational resilience (March 2021) set the same direction for banks internationally, building on earlier business continuity, outsourcing and operational risk guidance.

Architecture in words

1. Identify services: the FCA requires firms to identify important business services whose disruption could cause intolerable harm to consumers and markets. DORA works from critical or important functions, defined in Article 3, point (22), around functions whose disruption would materially impair the entity's financial performance, among other criteria.
2. Set impact tolerances: the FCA describes these as the maximum tolerable disruption to each important business service.
3. Map the service: people, processes, technology, facilities, information and third parties that deliver it.
4. Test against severe but plausible scenarios and find vulnerabilities where the service would breach tolerance.
5. Remediate and invest until the service can remain within tolerance. Under PS21/3 that was required no later than 31 March 2025.
6. Self-assess and govern: document the evidence and have the board approve it.

Failure modes

• Too many or too few services: listing every product dilutes effort; listing only internal systems misses the point that services face the customer.
• Tolerances reverse-engineered from current RTOs: this hides the gaps the exercise exists to find.
• Mapping as a one-off spreadsheet: it goes stale with the first major change.
• Testing only the comfortable scenarios: data centre failover passes while identity provider compromise and supplier loss are never tested.

Controls

Service register with owners, tolerance statements with metrics, maintained dependency maps, a scenario testing plan, a vulnerability and remediation log, and a dated self-assessment. Regime specifics are in the FINMA Circular 2023/1, OSFI E-21 and B-10 and APRA CPS 230 Operational Risk Management Guide pages.

Impact tolerance, MTD and RTO: how the numbers relate

The rule that joins them: every RTO on the critical path of a service, plus detection and decision time, must fit inside the service's impact tolerance with margin. In the example, a 2 hour platform RTO looks fine against a 4 hour tolerance until you add an hour to detect and declare, and a dependency on an identity platform whose own recovery takes longer. The example figures are illustrative, not regulatory values.

Service mapping versus the BIA

The BIA and the service map overlap but answer different questions. Treat the BIA as the input and the map as the cross-check.

• Direction: the BIA works bottom up, activity by activity. The map works top down from the service to everything it needs.
• Shared resources: mapping exposes resources that support many services at once (identity, network, a core platform, a cloud region, one outsourcer). These single points of failure rarely show as high priority in a per-activity BIA.
• Third and fourth parties: maps follow the chain into suppliers and their critical suppliers; see the Third-Party Risk Management Guide and the Cloud Concentration Risk and Exit Strategy Guide.
• Granularity: map to the level needed to find vulnerabilities, not to an asset inventory. The FCA expected mapping and testing to the level of sophistication needed to set tolerances.

Testing: exercising plans versus testing tolerances

A scenario test that ends "the plan could not be invoked because the identity platform was down" is a success: it found the vulnerability. DORA Article 12 adds backup policies and periodic testing of backup and restoration, which underpins any recovery claim.

Choosing your model: decision criteria

• Regulatory regime: UK dual-regulated and FCA solo-regulated firms in scope of SYSC 15A, EU financial entities under DORA (applying from 17 January 2025), and Swiss, Canadian and Australian financial institutions need the operational resilience model. Others may face it indirectly through customers or supervisors.
• Customer harm potential: if a disruption harms external users quickly (payments, healthcare, utilities, critical SaaS), tolerance-based thinking pays off even without a mandate.
• Dependency concentration: heavy reliance on a few cloud or outsourcing providers favours service mapping.
• Organisation size: a small firm can run one integrated programme with a short service list, simple maps and an annual severe scenario tabletop; a large group needs a central service register, tooling and federated owners.
• Existing BCM maturity: a certified ISO 22301 programme is a strong base; extend it rather than building a parallel function.

Worked scenario: same outage, two lenses

A building society's core banking platform runs in one cloud region with a managed database service, and staff authenticate through a single identity provider. Ransomware encrypts on-premises servers, including the identity infrastructure.

• BCM lens: the IT DR plan fails over core banking to the secondary region within its 2 hour RTO. The plan reports success. But branch and contact centre staff cannot sign in, payments operations cannot approve releases, and the mortgage service relies on a document provider whose integration credentials sat on an encrypted server.
• Operational resilience lens: the important business service "make a payment" has a tolerance of 4 hours. The map shows identity as a shared dependency for every service and the document provider as part of the mortgage service. The test reveals both as tolerance breaches, so remediation funds out-of-band administrative access, an isolated identity recovery capability and credential escrow for critical integrations.

The same event, the same plans: only the service lens shows the customer impact.

Where identity fits

Identity is the shared dependency most often missing from both BIAs and service maps. Every important service needs people and machines to authenticate, so the identity provider, privileged access, certificates and the service accounts and API keys that link systems to suppliers belong on the map with their own recovery targets inside the tightest tolerance they support. See the Identity Recovery Guide.

Implementation roadmap

1. Baseline: collect existing BIAs, plans, exercise results and supplier records; confirm which regime, if any, applies and its dates.
2. Identify services: agree a short list with business owners, using customer harm, market impact and firm viability as criteria.
3. Set tolerances: agree metrics for each, approved by senior management; record the rationale.
4. Map: start with one pilot service; map people, process, technology, facilities, information and third parties; reuse BIA data.
5. Reconcile numbers: check each critical path RTO plus detection time against tolerance; log gaps as vulnerabilities.
6. Test: run a severe but plausible tabletop for the pilot, then extend to all services; include at least one cyber and one third-party scenario.
7. Remediate and govern: track remediation with owners and dates; produce the self-assessment; review annually and after material change.

Testing safety and rollback: live failover tests need an agreed abort criterion, a tested failback path and change approval; start with tabletop and component tests before any live interruption.

Detection and measurement

• Tolerance coverage: share of important services with an approved tolerance, a current map and a test in the last 12 months.
• Tolerance headroom: tested end-to-end recovery time as a share of tolerance, per service.
• Open vulnerabilities: number and age of tolerance breaches found in testing that remain unremediated.
• Third-party mapping depth: share of critical suppliers with documented exit or substitution options.
• Real incident performance: actual disruption duration against tolerance for live incidents.

The Operational Resilience Executive Briefing covers board reporting.

Common failure patterns

• Relabelling BCM as resilience: renaming processes "services" and RTOs "tolerances" without changing the perspective.
• Plans that miss third parties: continuity plans stop at the contract, so a supplier or cloud outage is discovered, not planned for.
• Plans that need the systems they recover: runbooks stored on the network that has just been encrypted, call trees in the email system.
• Tolerances nobody tests: numbers approved by the board but never exercised against a cyber scenario.
• Two teams, two registers: BCM and resilience functions keeping separate inventories that disagree.
• Static maps: service maps not updated after migrations, mergers or supplier changes.

Framework mapping

Practitioner checklist

• Confirm which operational resilience regime applies and record its current status and dates.
• Agree a short list of important services from the customer and market point of view.
• Set an impact tolerance with a clear metric for each service and record the rationale.
• Map each service end to end, including identity, shared platforms and third and fourth parties.
• Check that critical path RTOs plus detection and decision time fit inside each tolerance.
• Test at least one severe but plausible cyber scenario and one supplier loss per year.
• Store plans and contact lists where they survive loss of the corporate network and identity.
• Run one integrated register for BCM and resilience, with one owner per service.
• Track vulnerabilities found in testing to remediation and report them to the board.

Standards and references

• FCA: PS21/3 Building operational resilience
• Bank of England PRA: SS1/21 Operational resilience, impact tolerances for important business services
• FCA: Operational resilience
• EUR-Lex: Regulation (EU) 2022/2554 (DORA)
• Basel Committee on Banking Supervision: Principles for operational resilience
• NIST: SP 800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems

Related NHI Mgmt Group resources: UK Financial Operational Resilience Guide · ISO 22301 Business Continuity Guide · FINMA Circular 2023/1 · OSFI E-21 and B-10 · Business Continuity and Disaster Recovery Guide