Operational Resilience vs Business Continuity: The Regulatory Shift You Need to Understand

Your business continuity plan was built to answer the question: how fast can we recover? Regulators in the UK, EU, and globally are now asking a different question: what level of disruption can your customers tolerate?

That’s not a minor rephrasing. It changes what you’re responsible for, how you measure success, what your board approves, and what an examiner checks. Three major regulatory frameworks — the Basel Committee’s Principles for Operational Resilience (March 2021), the UK PRA/FCA’s PS6/21 and PS21/3 (effective March 2022, full implementation March 2025), and the EU’s Digital Operational Resilience Act (DORA, effective January 2025) — have codified operational resilience as a distinct discipline.

Traditional BCP still matters. It’s still required. But it’s now one component inside a larger framework that asks whether your firm can stay functional for customers, not just whether your systems come back online.

TL;DR

• Operational resilience is not an upgrade to BCP — it’s a different frame: BCP asks “how fast do we recover?”, OR asks “what harm do we prevent customers from experiencing?”
• Three binding global frameworks have now codified OR: BCBS 2021 (principles), UK PS6/21/PS21/3 (rules effective 2022–2025), EU DORA (effective January 2025)
• The vocabulary shift matters: “important business services” and “impact tolerances” are compliance terms, not just concepts — and they mean something specific
• US regulators haven’t issued a formal OR framework, but exam findings and supervisory language are moving in this direction — firms regulated internationally need to comply now

BCP Isn’t Broken. It’s Just Not Enough Anymore.

A standard business continuity plan assumes you can identify the disruption, activate the plan, and measure success by whether systems are restored within the RTO. That model works for a fire in a data center. It doesn’t work for a supply chain failure that degrades service for three months. It doesn’t work for a third-party vendor outage that cascades across dozens of critical functions. It doesn’t work for a cyberattack where systems are technically “available” but data integrity is compromised.

The practitioner pain point is real: you built a solid BCP, you test it annually, your last examination didn’t flag anything. And now regulators are asking about impact tolerances and important business services, and those terms don’t appear anywhere in your documentation.

That gap is what this shift is about.

Four Ways Operational Resilience Differs from BCP

The conceptual differences matter because they drive entirely different compliance requirements.

The RTO vs. impact tolerance distinction is the critical nuance. A firm can restore systems within its 4-hour RTO and still breach its impact tolerance if customers experienced disruption to critical financial services during that window. Impact tolerance is defined from the outside — what harm did customers experience? — not from the inside — are systems operational again?

Consider: a payment processor whose systems fail for 3 hours meets its RTO if it restores functionality within 4 hours. But if its impact tolerance for its retail payment processing service specifies that customer harm becomes intolerable after 2 hours of disruption, it has breached its impact tolerance even while meeting its RTO. These are different questions with different answers.

The Regulatory Landscape

BCBS Principles for Operational Resilience (March 2021)

The Basel Committee published its Principles for Operational Resilience on March 31, 2021. These are principles-based and not self-executing regulations — but they inform supervisory expectations for internationally active banks globally.

The seven principles cover: governance, operational risk management, business continuity planning (as one component, not the whole), mapping of interconnections and dependencies, third-party dependency management, incident management, and resilient ICT and cybersecurity.

Three elements of the BCBS framework represent the clearest departure from traditional BCP:

“Tolerance for disruption” is the BCBS equivalent of impact tolerance — defined as “the level of disruption from any type of operational risk a bank is willing to accept given a range of severe but plausible scenarios.” Unlike RTO, this is explicitly framed as a risk appetite decision that the board owns, not a technical recovery target that IT manages.

Mapping of interconnections and dependencies requires banks to identify their critical operations and then map the internal and external dependencies — including third-party vendors — that support delivery of those operations. Most BCP programs map their own systems. OR mapping extends to the entire supply chain of critical service delivery.

Third-party resilience parity: Third parties must demonstrate “at least equivalent level of operational resilience” to safeguard the bank’s critical operations. A third-party vendor with weaker resilience than you require for your own operations creates an unacceptable dependency — a standard that goes significantly beyond most third-party risk management frameworks that focus on uptime SLAs and security reviews.

UK PRA/FCA Operational Resilience Rules (PS6/21 / PS21/3)

The UK has gone furthest in codifying operational resilience as binding regulation. The PRA’s PS6/21 and the FCA’s PS21/3 established enforceable rules with a two-phase implementation:

• 31 March 2022: Firms must identify important business services, set impact tolerances, and begin mapping and testing
• 31 March 2025: Firms must be able to actually remain within impact tolerances during severe disruption — not just have completed the mapping exercise on paper

What is an “Important Business Service” (IBS)? A service provided by the firm (directly or via another party) to clients that, if disrupted, could cause intolerable harm to any client, pose a risk to the soundness or stability of the UK financial system, or threaten market integrity. The IBS is the fundamental unit of UK operational resilience — not your systems, not your processes, but the service your customer receives.

What is an “impact tolerance”? The maximum tolerable level of disruption to an important business service, measured primarily as a length of time, beyond which further disruption would cause intolerable harm or systemic risk. Setting impact tolerances requires the firm to ask: at what point does disruption to this service become unacceptable for the people who depend on it? That’s a fundamentally different question than “when do we want systems back online?”

Governance requirements under the PRA’s Supervisory Statement SS1/21 are specific: the board must approve the identification of IBSs, the impact tolerances, and the annual self-assessment. SMF 24 (Chief Operations function) holds primary responsibility where it exists. This is a board accountability framework, not just a management exercise.

The FCA’s post-2025 findings are instructive. In observations published after the March 2025 full-implementation deadline, the FCA found poor practice including: firms claiming there is no scenario they wouldn’t recover from — without evidence to support that claim; self-assessments that didn’t describe how third-party vulnerability remediation would be tracked; mapping that focused only on technology while ignoring people, facilities, and processes. These findings reveal where the gaps tend to be for firms attempting compliance.

EU Digital Operational Resilience Act (DORA)

DORA (Regulation (EU) 2022/2554) became applicable on 17 January 2025. It applies to 20 types of financial entities in the EU — banks, insurers, investment firms, payment institutions, crypto-asset service providers, and financial market infrastructure — as well as ICT third-party service providers.

DORA is built on five pillars:

1. ICT Risk Management Framework — Mandatory continuous framework covering identification of critical functions, protection and prevention measures, backup and recovery, and annual review.

2. ICT-Related Incident Reporting — Major ICT incidents must be reported to national competent authorities within 24 hours of classification (initial notification), with a full report submitted within one month. This is significantly more prescriptive than most existing reporting obligations.

3. Digital Operational Resilience Testing — Annual testing required for all in-scope entities; significant institutions must conduct advanced threat-led penetration testing (TLPT) every three years, coordinated with authorities.

4. ICT Third-Party Risk Management — All third-party ICT service providers must be registered and subject to enhanced due diligence. Contracts with critical ICT third-party providers must include specific resilience and audit provisions. Critical third-party providers are subject to direct oversight by EU supervisory authorities.

5. Information Sharing — Entities are encouraged (and in some cases required) to share cyber threat intelligence within the financial sector.

How DORA differs from traditional BCP: A standard BCP covers your own organization’s recovery from disruption. DORA creates obligations that extend to your entire ICT supply chain, requires continuous testing (not just annual exercises), mandates specific incident reporting timelines that most firms haven’t built into their incident response processes, and establishes direct regulatory oversight of critical third-party providers. BCP remains required as one element of the DORA ICT risk management pillar — but it’s now one component of a significantly larger program.

The US Position: Emerging but Not Yet Formalized

The US has not issued a single operational resilience regulation equivalent to UK PS6/21 or DORA. Existing US frameworks that incorporate resilience concepts include:

• The FFIEC Business Continuity Management booklet (2019) — moved toward “business continuity management” as a program concept rather than plan-centric documentation
• OCC Heightened Standards (12 CFR 30, Appendix D) — require large banks to maintain a risk governance framework addressing operational risk, including recovery and resilience
• SR letters from the Federal Reserve addressing operational risk management expectations

The OCC recently rescinded its recovery planning guidelines (12 CFR 30 Appendix E) for banks over $100 billion effective May 2026 — moving in a direction that may seem counterintuitive, but reflects the OCC’s view that existing supervisory tools are sufficient rather than a reduction in resilience expectations.

For US institutions regulated internationally — any firm with UK entities subject to PS6/21, EU entities subject to DORA, or internationally active banks subject to BCBS review — the question isn’t whether operational resilience applies. It already does.

The Vocabulary Shift That Signals Compliance Requirements

Terminology differences aren’t academic. They signal what regulators will look for in examinations.

If your BCP documentation uses only the left column, you may be building the right program but documenting it in a way that won’t satisfy an examiner working from the right column.

What This Means for Your BCP Program Practically

For most organizations, operational resilience doesn’t require tearing down the existing BCP program. It requires extending and reframing it:

Step 1: Define your important business services. Start with your core products and services from the customer’s perspective. Which services, if disrupted, would cause intolerable harm to customers? Which are systemically important? This is different from listing your critical systems or critical processes — it starts with customer impact and works backward.

Step 2: Set impact tolerances for each. For each IBS, define the maximum tolerable disruption time (and any supplementary metrics like maximum transaction failure volume). This requires engaging the business — operations, product management, legal, and risk — not just IT. Impact tolerances are a business decision with a risk appetite component.

Step 3: Map the dependencies. For each IBS, map every internal and external dependency: systems, processes, people, facilities, and third-party vendors. This mapping reveals single points of failure that BCP may have missed because it focused on system-level recovery rather than service-level delivery.

Step 4: Test under severe but plausible scenarios. Go beyond annual tabletop exercises. Test whether the firm can actually remain within impact tolerances when the dependency map is stressed. What happens when the key vendor supporting this service goes down? When three dependencies fail simultaneously?

Step 5: Build the self-assessment. In UK-regulated contexts, the annual self-assessment is a board governance document. Even for non-UK firms, building this artifact — documenting your IBS identification methodology, impact tolerances, mapping completeness, scenario testing results, and identified vulnerabilities — is the output that demonstrates you have an operational resilience program, not just a BCP.

So What?

The March 2025 deadline for UK operational resilience full implementation has passed. DORA has been in effect since January 2025. If you have entities regulated in the UK or EU and haven’t completed the transition from BCP to operational resilience, you’re already past the deadline.

For US-only institutions, the formal requirement isn’t there yet. But exam findings increasingly use resilience language. The FFIEC BCM booklet moved in this direction in 2019. And given the pattern in UK and EU rulemaking, the gap between “supervisory expectation” and “formal regulation” tends to close.

The underlying logic of operational resilience is sound regardless of the regulatory calendar: disruption will happen in forms you didn’t plan for. The question is whether your critical services keep working for customers when it does.

If you’re building or refreshing your BCP program, the Business Continuity & Disaster Recovery Kit provides structured templates that align with both traditional BCP requirements and the operational resilience frameworks increasingly expected by regulators.

Related Reading

• Business Continuity Plan Template: The Complete Guide
• FFIEC Business Continuity Management Requirements: A Practitioner’s Guide
• AI Operational Resilience: Making Sure AI Systems Don’t Break the Business

Frequently Asked Questions

What is the difference between operational resilience and business continuity planning? BCP is reactive and scenario-specific — it activates a pre-planned response when a named disruption occurs and measures success by whether systems are restored within RTO targets. Operational resilience is proactive and outcome-oriented — it asks whether the firm can keep delivering important business services to customers regardless of what disrupts it, measuring success by whether customers experience intolerable harm. BCP is one component inside an OR framework, not a substitute for it.

What are impact tolerances and how do they differ from RTOs? An RTO measures how fast internal systems are restored. An impact tolerance measures the maximum disruption that customers of an important business service can tolerate before experiencing intolerable harm. A firm can meet its RTO while still breaching its impact tolerance if the service was unavailable to customers longer than acceptable — the metrics answer different questions. Impact tolerances are defined from the outside in; RTOs from the inside out.

Does DORA replace BCP requirements for EU financial institutions? No — DORA supplements BCP. ICT business continuity policy remains one of five DORA pillars, so traditional BCP is still required. What DORA adds: continuous ICT risk management framework, mandatory incident reporting within 24 hours of classification, advanced testing requirements including threat-led penetration testing, and direct regulatory oversight of critical ICT third-party providers. DORA is significantly broader than a BCP requirement.

Did the UK’s March 2025 deadline apply to all firms? The March 31, 2025 deadline applied to all PRA and FCA-regulated firms in scope of PS6/21/PS21/3: banks, building societies, designated investment firms, insurers, and FCA-regulated financial services firms. By that date, firms had to be able to demonstrate they could actually remain within their impact tolerances during severe disruption — not just complete mapping exercises on paper.

What is the US regulatory position on operational resilience? The US has no single OR regulation equivalent to UK PS6/21 or DORA. The FFIEC Business Continuity Management booklet (2019) incorporated resilience program concepts, and SR letters and exam findings increasingly reference resilience language. US institutions with UK or EU entities must comply with those jurisdictions’ rules regardless of US regulatory timing.

What were the FCA’s main findings after the March 2025 implementation deadline? The FCA observed good practice including clear IBS identification methodology and scenario testing expanded to cyber threats. Poor practice included: firms claiming they could survive any scenario without evidence; self-assessments that didn’t describe third-party vulnerability remediation processes; dependency mapping focused only on technology while ignoring people, facilities, and processes. These findings reveal where firms most commonly fall short under formal scrutiny.