Operational Resilience vs. BIA: The Regulatory Shift from RTOs to Impact Tolerances

TL;DR:

• Traditional BIA produces RTOs — internal recovery targets measured from the inside-out. Operational resilience requires impact tolerances — maximum customer harm thresholds measured from the outside-in.
• These are fundamentally different questions that require different methodology, different interview questions, and different outputs from your BIA process.
• UK regulators hit their March 2025 deadline. US examiners are using operational resilience language in findings, and FFIEC guidance incorporates resilience concepts. The directional shift is clear.
• The fix isn’t rebuilding from scratch — it’s adding a service-level mapping layer and consumer harm metrics on top of your existing BIA work.

Your BIA was designed to answer the wrong question.

Not completely wrong — traditional business impact analysis correctly identifies critical functions, maps dependencies, and outputs recovery time objectives your BCP is built around. That work matters, and examiners still expect it.

But there’s a second question that regulators are increasingly asking, and your current BIA probably can’t answer it: how much disruption can your customers actually tolerate before you’ve caused them harm?

That’s the operational resilience question. The methodology for answering it is different from what your BIA currently does — and if you’re a US financial institution watching how the UK’s March 2025 deadline played out, or reading FFIEC examination procedures that now include “impact tolerance” language, this gap is worth closing before it shows up as an exam finding.

What Your Traditional BIA Actually Measures

A standard BIA produces three core outputs:

• Maximum Tolerable Downtime (MTD): How long can this function be unavailable before the organization is critically impaired?
• Recovery Time Objective (RTO): The target time to restore normal operations
• Recovery Point Objective (RPO): The maximum acceptable data loss, measured in time

These are inside-out measurements. They start with your internal operational needs — what the organization can sustain — and define recovery targets from there.

The FFIEC Business Continuity Management IT Handbook defines BIA as “the process of identifying the potential impact of disruptive events to an entity’s functions and processes.” Functions and processes — your internal operations.

This framework serves its purpose. It tells you which systems to prioritize in a crisis and where your recovery gaps are. Setting RTOs and RPOs is a legitimate discipline with real rigor. But traditional BIA doesn’t directly measure customer harm — and that’s where the gap opens.

What Operational Resilience Actually Measures

Operational resilience flips the question. Instead of asking “how fast can we recover?” it asks “what level of disruption can our customers tolerate?”

The key concept is the impact tolerance: the maximum disruption to an important business service before it crosses a threshold of causing intolerable harm to customers or posing systemic risk.

The UK’s PRA PS6/21 (fully effective March 31, 2025) defines impact tolerances as a maximum time duration “plus any other relevant metrics” — and that “plus” matters. Time alone often isn’t sufficient. The FCA’s operational resilience insights specifically identified as poor practice when firms “set time-bound tolerances exclusively without complementary metrics.”

Metrics that regulators expect to see alongside duration:

If your impact tolerance is only a number of hours, you may face pushback on whether you’ve fully captured the harm picture.

The Core Conceptual Difference: Inside-Out vs. Outside-In

These aren’t contradictory frameworks — they address different but related questions. The broad shift from BCP to operational resilience has been building for years. Your BIA is still required. Your RTOs are still meaningful. What changes is the layer that sits above them: service-level mapping and impact tolerance setting that tells you whether meeting your RTOs is actually sufficient to protect your customers.

The US Regulatory Landscape

The US doesn’t have a standalone operational resilience rule like UK PS6/21 or EU DORA. What it has is an unmistakable directional signal.

The FFIEC BCM IT Handbook (2019) introduced the concept of “maximum tolerable downtime” — structurally similar to an impact tolerance, but defined from the institution’s internal perspective rather than the customer’s. More recently, the OCC/Fed/FDIC 2021 interagency paper on sound practices for large financial institutions used explicit “operational resilience” framing and referenced impact tolerances in the context of critical operations.

US examiners are using operational resilience language in findings. The pattern from the UK — informal regulatory pressure → exam findings increase → institutions rush to implement → formal rule — is repeating in the US context. Financial institutions with any UK or EU operations already subject to PS6/21 or DORA are running dual frameworks. Others are watching and waiting.

The institutions that build impact tolerance thinking into their BIA processes now will have a significant advantage when the formal US requirement materializes. The institutions that wait will be playing catch-up under exam pressure.

How to Update Your BIA for Impact Tolerance Thinking

The good news: you don’t rebuild from scratch. Four additions to your existing BIA process get you most of the way there.

1. Add a Service-Level Mapping Layer

Traditional BIA maps at the function level: loan origination, payments processing, account maintenance. Operational resilience maps at the service level: a customer’s ability to make a payment, access their account, receive their paycheck.

For each important business service your firm provides:

• Map which internal functions and systems deliver it
• Identify the point at which disruption to those functions becomes customer-visible
• Note where backup mechanisms (manual workarounds, alternative channels) absorb internal disruption before it reaches the customer

A payments processing system with an 8-hour RTO might have a 2-hour customer-visible impact threshold — because the first 2 hours of internal downtime can be absorbed by queuing and batch processing, but after that customers start seeing failed transactions. The service-level mapping layer surfaces that distinction.

This mapping doesn’t replace your functional BIA — it translates internal recovery objectives into customer harm assessments.

2. Add Consumer Harm Metrics to Your BIA Interview Questions

Your current BIA questionnaire asks: “What is your RTO for this process? What happens to operations if this system is down for 4 hours?”

Add the following:

• “What happens to customers if this service is unavailable for 2 hours? 4 hours? 24 hours?”
• “How many customers are affected at each duration tier? What is their financial exposure?”
• “Is there a population of customers for whom this disruption is disproportionately harmful — customers depending on direct deposit for immediate expenses, for example?”
• “At what point does unavailability cross from inconvenient to genuinely harmful?”

The FFIEC BIA section acknowledges that BIA should assess the “impact to customers, counterparties, and the broader financial system.” Most BIA processes don’t systematically collect this data. Closing that gap is the core of the update.

3. Define Disruption Scenarios from the Customer’s Perspective

Traditional BIA scenarios are internal: “the data center is unavailable,” “the payments system is down.” Operational resilience scenarios start from the customer experience: “customers cannot make payments,” “customers cannot access their accounts.”

For your BIA, build customer-perspective severity tiers:

These thresholds vary by institution type, customer demographics, and service type. A neobank built around real-time payments has very different tolerances than a business banking platform where most activity happens during business hours. The point is to define where the line is — and then test whether your RTOs keep you below it.

4. Set Proposed Impact Tolerances and Get Board Approval

Once you have service-level mapping and consumer harm data, you can set proposed impact tolerances: for each important business service, the maximum duration and scope of disruption the firm will tolerate.

This is a governance function, not a technical function. Impact tolerances need senior leadership and board approval. The FCA’s good practice guidance noted that firms should have “clear, strong methodologies and rationale for defining important business services and setting impact tolerances,” with board-level documentation to justify the determinations.

What well-documented impact tolerance decisions include:

• The specific service and its customer scope (size, vulnerability, dependency)
• The primary time metric and supplementary metrics
• The evidence base for the threshold — customer data, regulatory expectations, industry benchmarks
• The scenario test results demonstrating the firm can remain within tolerance during simulated severe disruption

The Important Business Services vs. Critical Functions Distinction

This is where many BIA practitioners get confused when first encountering operational resilience frameworks.

Critical business functions are internal: they describe operations that matter to your firm’s ability to operate. They’re defined by asking “what can’t we do without?”

Important business services are external: they describe services that, if disrupted, would cause intolerable harm to customers or pose a risk to market integrity. They’re defined by asking “what can our customers not do without?”

A back-office reconciliation process might be a critical function (you can’t run your operations without it) but not an important business service (customers never directly experience whether reconciliation is running or not — they experience whether their account balance is accurate).

Conversely, a customer-facing digital banking portal might be important to customers even if the underlying systems have adequate manual backup options that limit firm-level impact.

The FFIEC guidance on BIA for banks covers critical function identification in depth. When mapping to operational resilience, the additional step is asking: for each critical function, which customer-facing services depend on it? That mapping produces your important business services list.

Common BIA Gaps When Moving to Impact Tolerance Thinking

Based on FCA observations of firms post-March 2025 and FFIEC exam finding patterns in the US:

The BIA stops at internal systems. RTOs for systems are documented without mapping those RTOs to customer-visible service availability. “Payments processing system — RTO 4 hours” without asking “if payments processing is down for 4 hours, what does that mean for a customer whose direct deposit is due today?”

Tolerances are all time-based. Setting a time tolerance without complementary metrics — customer harm volume, transaction impact, financial exposure — fails to fully capture the harm picture. The FCA called this out explicitly.

Board doesn’t meaningfully own the tolerances. Impact tolerances need board-level engagement with what level of customer harm is acceptable, not just signature sign-off on a document. If the board can’t describe your firm’s impact tolerances, they’re not set correctly.

Testing is theoretical. Paper-based scenarios without empirical validation don’t demonstrate you can actually remain within tolerances during real disruption. The FFIEC BCM booklet calls for testing that validates recovery objectives. The FCA cited “overreliance on recovery capabilities” without empirical testing as poor practice.

Third parties aren’t included. Your impact tolerance depends on your ability to recover within a given window — but if the disruption is at a third-party processor, your recovery options may be constrained. Third-party dependencies need to be in your BIA, and your tolerance-setting process needs to account for scenarios where you don’t control the recovery timeline.

So What?

The BIA you have might be good. If it produces defensible RTOs aligned with your BCP and gets updated annually, it’s meeting current FFIEC requirements.

But if your regulator asks “how much disruption can your customers actually tolerate, and how do you know?” — and your BIA can’t answer that question — you have a gap that’s going to get larger as US operational resilience expectations formalize.

The update isn’t a rebuild. Add the service-level mapping layer. Reframe interview questions around customer harm. Define tiered customer-perspective scenarios. Set proposed tolerances with board engagement. Run a scenario that actually tests whether you can deliver within those tolerances.

That’s the difference between a BIA that meets today’s requirements and one that’s ready for where regulatory expectations are heading.

Need a starting point? The Business Continuity & Disaster Recovery (BCP/DR) Kit includes BIA templates with both RTO and impact tolerance frameworks, alongside scenario planning and testing documentation.

Frequently Asked Questions

What is the difference between an RTO and an impact tolerance?

An RTO measures how fast your organization needs to restore a system for internal operations to resume — an inside-out metric starting with your recovery capabilities. An impact tolerance measures the maximum disruption customers can experience before you’ve caused intolerable harm — an outside-in metric starting with customer impact. Meeting your RTO doesn’t guarantee you’ve stayed within your impact tolerance.

Does the US have operational resilience requirements like the UK’s PS6/21?

Not as a standalone framework. The FFIEC BCM booklet incorporates resilience concepts, US examiners use operational resilience language in findings, and the 2021 interagency paper for large financial institutions explicitly references impact tolerances. Formal US operational resilience requirements are likely to materialize for large financial institutions over the next few years.

How does BIA feed into operational resilience?

BIA is a critical input, restructured at the service level. Traditional BIA identifies critical functions; operational resilience requires mapping which customer-facing services those functions deliver and what disruption to each service means for customers. The BIA output shifts from “restore this process in 4 hours” to “customers cannot tolerate more than 2 hours of inability to make payments.”

What are “important business services” and how are they different from critical business functions?

Critical business functions are internal — operations your firm can’t run without. Important business services are external — services that, if disrupted, cause intolerable harm to customers or market integrity. Impact tolerances are set for important business services, not for all critical functions. The mapping between them is the key analytical step.

How do I update my BIA to reflect impact tolerance thinking?

Four additions: add a service-level mapping layer, add consumer harm metrics to BIA interview questions, define disruption scenarios from the customer’s perspective with tiered harm classifications, and set proposed impact tolerances with board-level approval. You build on your existing BIA — you don’t replace it.