Operational Resilience

Ideal: Technology should continue serving legitimate users during disruption, failure, error, attack, or unexpected circumstances. Security, automation, and efficiency must never eliminate recoverability, continuity, or human agency.

Focus: Operational resilience, continuity of operations, recoverability engineering, identity continuity, digital infrastructure failure modes, and human-centered recovery pathways.

Page purpose: To provide global clients, regulators, the general public, and technical audiences with a unified framework for understanding operational resilience, along with resource access and an incident reporting channel. Whatever stage of resilience development your organization is at, this hub offers framework understanding, self-assessment tools, regulatory updates, and practical resources.

1. What Is Operational Resilience

Operational resilience is the capability of an organization to continue delivering its critical business services during a disruption — including the ability to identify, prepare, respond, adapt, recover, and learn from disruption. It is not equivalent to “eliminating all disruption.” Rather, it means ensuring that under the most severe but plausible conditions, disruption is contained within acceptable limits and does not cause intolerable harm to customers, the market, or the organization’s own viability.

The core philosophy of operational resilience rests on three fundamental recognitions:

First, disruption will happen. Cyber attacks, third-party failures, natural disasters, technology failures — these are not a question of “if” but “when.” A genuinely resilient organization demonstrates its preparedness through the quality of its response when disruption occurs, not through the fantasy of preventing all risk.

Second, resilience is an outcome, not an activity. Regulatory frameworks (such as the Basel Committee’s Principles for Operational Resilience) explicitly define operational resilience as a “result” — a bank’s ability to deliver critical operations during disruption — and this result is the output of effective operational risk management.

Third, severity is a property of the system’s response, not a label on the event. A scenario that appears “moderate” on paper (such as a 24-hour outage of a critical third party) may expose severe cascading effects under real pressure. The purpose of testing is therefore not to verify “we will not fail” but to discover “where we might fail.”

2. Core Framework

The operational resilience framework at this hub is built on international regulatory consensus, integrating the core requirements of the following major regimes:

Basel Committee Principles for Operational Resilience (2021): Seven principles covering governance, operational risk management, business continuity planning and testing, mapping interconnections and dependencies, third-party dependency management, incident management, and ICT and cyber security
UK FCA/PRA Operational Resilience Rules (SS1/21, SS2/21): Anchored on Important Business Services (IBS), requiring impact tolerances to be set and severe but plausible scenario testing to be completed
EU DORA (Digital Operational Resilience Act): Focused on ICT risk management, incident reporting, resilience testing, and third-party risk
Central Bank of Ireland Cross-Industry Guidance (2021, revised 2025): Three-pillar model — identify and prepare, respond and adapt, recover and learn
Hong Kong HKMA OR-2: Critical operations identification, mapping, scenario testing, and third-party dependency management

Our Framework Structure

Our operational resilience framework is organized around six pillars, aligned with the international standards above and applicable across industries and jurisdictions:

Pillar	Core Question	Key Output
1. Governance and Roles	Who is accountable? What does the board do?	Resilience strategy, responsibility matrix, reporting lines
2. Important Business Services (IBS)	Which service disruptions would cause intolerable harm?	IBS inventory, identification methodology
3. Impact Tolerances	How severe must a disruption be to be “unacceptable”?	Quantitative/qualitative tolerances, metrics
4. Mapping and Dependency Management	What is required to deliver IBS? Where are the fragilities?	People/technology/process/facility mapping, third-party inventory
5. Incident Management and Crisis Response	What do we do when something goes wrong? Who decides what?	Incident playbook, escalation paths, communication plans
6. Testing and Continuous Improvement	Can we actually operate under pressure?	Scenario testing programmes, lessons-learned closure

3. Important Business Services (IBS)

What Is an IBS

An Important Business Service (IBS) is a service provided by an organization to external end users whose disruption would cause material harm to the organization’s viability, customer interests, or market integrity. IBS is the anchor of operational resilience work — without a clear definition of IBS, impact tolerances, mapping, and testing all lose their target.

Criteria for Identifying IBS

A service should be identified as an IBS if its disruption meets at least one of the following:

Causes material harm to customers (financial loss, inability to access essential services, safety risk)
Poses a threat to market integrity or financial stability
Threatens the organization’s viability (licence, reputation, financial sustainability)
Breaches regulatory obligations or legal requirements

Common Misconceptions

The FCA’s 2026 “one-year observations” report noted that some firms fail to adequately distinguish between consumer harm and market impact, leading to imprecise tolerance-setting and evidence collection. IBS identification is not a one-time exercise — as business models, technology architecture, and third-party arrangements change, the IBS inventory should be reviewed at least annually, or immediately following material change.

4. Impact Tolerances

Definition

An impact tolerance is the maximum acceptable level of disruption an organization sets for each IBS — that is, the level beyond which disruption would cause intolerable harm to customers, the market, or the organization itself.

An impact tolerance is not “the maximum loss we can withstand” but “the boundary we commit not to cross.” It should be approved by the board and aligned with the risk appetite framework.

Setting Methodology

Effective tolerance-setting typically uses multi-dimensional metrics:

Dimension	Example Metrics
Duration	Maximum tolerable disruption (MTD), recovery time objective (RTO)
Volume	Number of affected customers, transactions, transaction value
Severity	Degree of data loss/corruption, level of service degradation
Geographic/Scope	Affected markets, business lines, jurisdictions

Key Principles

Tolerances must be testable. If a tolerance cannot be verified in scenario testing as “breached or not breached,” it is merely a statement. The FCA has explicitly noted that some firms’ tolerances lack sufficient evidential support — particularly when firms assert that “no scenario could breach our tolerances” without providing testing evidence.

5. Mapping Interconnections and Dependencies

Why Mapping Matters

Mapping is the process of understanding how IBS are delivered — identifying and documenting the people, technology, processes, information, facilities that support each IBS, along with their interconnections and dependencies, including reliance on third parties and intra-group entities.

Without complete mapping, you do not know where the fragilities are, and you do not know what testing should target.

Scope of Mapping

Internal dependencies: Key personnel, proprietary systems, core processes, data centres
External dependencies: Third-party service providers, cloud providers, outsourcing arrangements, intra-group shared services
Interconnections: Single points of failure, concentration risk, cascading failure paths

Common Problems

The FCA’s observations found that some firms’ mapping work is overly focused on IT, with insufficient mapping of people, processes, facilities, and — most critically — third-party dependencies. Complete mapping should enable the board to confirm with confidence: we know what IBS depend on, and we know where the fragilities are.

6. Third-Party and Supply Chain Resilience

Core Principle

Outsourcing does not outsource responsibility. Regardless of who delivers the service, the organization retains ultimate responsibility for the resilience of its IBS.

Key requirements for third-party dependency management:

Pre-onboarding assessment: Before establishing a relationship with a critical third party, verify that its operational resilience is at least equivalent to your own. This includes its business continuity capability, security controls, and incident response capability.

Ongoing monitoring: Throughout the relationship, appropriate arrangements should exist to continuously confirm that the third party maintains an acceptable level of resilience. Annual assessments, audit rights, and service-level monitoring are common mechanisms.

Exit strategy: An exit plan must be maintained for every critical third-party arrangement — including arrangements for service transition, data retrieval, and asset return. This is explicitly required by regulators, including the FCA’s CTP rules.

Substitutability assessment: For critical third parties, assess whether viable alternatives exist (backup suppliers, insourcing), and within what timeframe a switch could be completed.

FCA Warning

The FCA’s 2026 observations specifically identified third-party fragility as one of the most prominent current areas for improvement. Many firms have insufficient identification, assessment, and remediation of third-party dependencies, leaving critical services exposed to risks that are not fully understood.

7. Incident Management and Crisis Response

Core Elements of Incident Management

Incident management is not “emergency reaction after something goes wrong” but a pre-defined, repeatable, tested response capability. An effective incident management playbook should include:

Escalation paths: What level of incident triggers what level of response? Who has authority to activate the crisis team? When is the board informed?

Decision authority: During a disruption, who can decide to shut down services, reallocate resources, and communicate externally? The decision chain must be clear in advance.

Communication plans: Internal communication (employees, management, board) and external communication (customers, regulators, media, market), including alternatives when normal communication channels are unavailable. The FCA specifically emphasises that communication plans should be stress-tested — not exercised only “when everything is normal.”

Regulatory reporting: Organizations operating in multiple jurisdictions face different reporting timelines and standards (see Chapter 10). When an incident occurs, teams must know to whom, when, and what to report.

From “Response” to “Learning”

The Central Bank of Ireland’s guidance places incident management within the “recover and learn” element of its three-pillar model: following every disruption, a lessons-learned exercise must be conducted, and findings fed back into improvements in preparedness and response capability. The FCA’s phrasing is more direct: “never let a good crisis go to waste.”

8. Testing and Scenario Exercises

Purpose of Testing

The purpose of operational resilience testing is not to prove “we are fine” but to discover “where we might fail.” The FCA states explicitly: tests designed to “guarantee a pass” produce almost no value; the tests that generate real insight are those that could “fail.”

Correct Understanding of “Severe but Plausible”

“Severe but plausible” is one of the most commonly misused phrases in operational resilience testing. The key point: plausibility is a property of the conditions; severity is a property of the system’s response.

This means: do not label a scenario “severe” or “moderate” at the design stage. Design plausible conditions (such as third-party outage, key personnel unavailability, system failure), and then allow severity to emerge from system behaviour — by observing whether tolerances are breached.

Testing Methods

Method	Use Case	Characteristics
Tabletop	Decision processes, communication plans, role rehearsal	Low cost, high learning value
Simulation	End-to-end processes, cross-functional coordination	More realistic, requires more preparation
Live-system testing	Technical recovery, failover capability	Highest fidelity, used where risk is controllable

Testing should cover multiple severe but plausible scenarios, including: prolonged outages, concurrent disruptions, critical third-party outages, cyber attacks, natural disasters, technology failures, and more. Testing frequency should be proportionate to the criticality of the IBS and the risk environment.

9. Regulatory Requirements Overview

The operational resilience regulatory frameworks of major global jurisdictions converge on core concepts, but differ in scope, reporting timelines, and specific obligations.

Jurisdiction	Primary Framework	Core Characteristics	Incident Reporting Timeline
UK	FCA/PRA SS1/21, SS2/21	IBS + impact tolerances + severe but plausible testing	Initial report: 24 hours (4 hours for PSPs)
EU	DORA	ICT risk management + incident reporting + TLPT testing	Initial: 4 hours (or 24 hours after detection); update: 72 hours; final: 1 month
US	SEC 2026 examination priorities	Principles-based governance, covering cyber risk and AI	No fixed timeline, but “promptly”
UAE	CBUAE / DFSA	Board-approved operational risk strategy + BCP/DR testing	Cyber incidents: immediately; AML suspicious transactions: without delay
Australia	APRA CPS 230	Critical operations + service provider management	As required by APRA
Hong Kong	HKMA OR-2	Critical operations + mapping + scenario testing	As required by HKMA
Canada	OSFI E-21	Critical operations + severe but plausible scenario testing	As required by OSFI

Recommendation for multinational organizations: Establish a unified core resilience framework with localized adaptation in each jurisdiction. Incident reporting processes should have pre-defined trigger conditions and timelines for each jurisdiction, to avoid improvised coordination during a crisis.

10. Resources and Downloads

Resource Name	Type	Target Audience	Description
Operational Resilience Self-Assessment Tool	Interactive tool	All organizations	Six-pillar-based self-assessment questionnaire
IBS Identification Workshop Template	Template	Business and risk teams	Facilitated workshop materials
Impact Tolerance Setting Guide	Guide	Risk and compliance	Multi-dimensional metric-setting methodology
Third-Party Resilience Assessment Questionnaire	Template	Procurement and vendor management	For pre-onboarding and annual assessment
Incident Management Playbook Template	Template	Operations and security teams	Includes escalation paths, decision authority, communication plans
Scenario Testing Design Toolkit	Toolkit	Resilience teams	Includes severe but plausible design principles and examples
Regulatory Reporting Requirements Comparison Table	Reference	Compliance and legal	Overview of reporting timelines across major jurisdictions
Glossary (alphabetical)	Reference	All audiences	See below

11. Report an Incident

If you need to report an operational resilience-related incident or suspected incident, please use the following channels.

Customers/external parties: Please submit via [Incident Report Portal]. If the incident involves a data breach or security threat, please also comply with the data protection requirements applicable to you.

Regulators: If you are a regulator and need to contact us regarding the operational resilience framework or incident response, please contact [Regulatory Liaison Contact].

Internal teams: Please follow your internal incident escalation process. The [Incident Management Playbook Template] provided in this hub may serve as a reference.

12. Glossary

Term	Definition
Business Continuity Plan (BCP)	A set of pre-defined procedures and resource arrangements for maintaining or restoring critical operations during a disruption.
Critical Operations	An organization’s core business activities whose disruption would cause material harm to viability, customers, or the market. Corresponds to the concept of “Important Business Services” in the Basel framework.
Disruption	Any event or series of events that causes operations to deviate from normal, potentially triggered by cyber attacks, technology failures, natural disasters, third-party failures, and more.
DORA	Digital Operational Resilience Act. The EU’s unified regulatory framework for ICT risk management by financial entities, applicable from 2025.
Impact Tolerance	The maximum acceptable level of disruption an organization sets for an IBS, beyond which intolerable harm is constituted.
Incident	A single event or series of related events that causes disruption to service delivery or impairment of data availability, integrity, or confidentiality.
Important Business Service (IBS)	A service provided to external end users whose disruption would cause material harm to the organization’s viability, customers, or market integrity.
Mapping	The process of identifying and documenting the people, technology, processes, information, facilities required to deliver IBS, along with their interconnections and dependencies.
Operational Resilience	An organization’s capability to identify, prepare, respond, adapt, recover, and learn from disruption in order to continue delivering critical operations.
Recovery Time Objective (RTO)	The maximum acceptable time window between the occurrence of a disruption and the restoration of service.
Scenario Testing	Exercises that assess whether an organization can maintain IBS within impact tolerances under severe but plausible conditions.
Severe but Plausible	The scenario testing standard required by regulatory frameworks — scenarios should be severe enough to expose fragilities while remaining realistically possible.
Third-Party Dependency	Reliance on third-party service providers, vendors, or intra-group entities in the delivery of IBS, requiring identification, assessment, and ongoing management.
TLPT	Threat-Led Penetration Testing. Advanced security testing methods required by frameworks such as DORA, based on real threat intelligence.

Hunter Storm