Operational resilience for risk, ops, and second-line teams
Operational resilience is the ability of a firm to keep important business services running through disruption, within a pre-declared impact tolerance. This page shows the programme as it actually runs - identify, map, set tolerances, test, remediate, report - and how to keep the dependency diagrams alive instead of letting them rot in Visio.
By Jack Finnegan · Updated 21 May 2026
What operational resilience actually is
Operational resilience is the ability of a firm to prevent, adapt to, respond to, recover from, and learn from operational disruption. The Basel Committee on Banking Supervision codified the modern definition in its March 2021 Principles for Operational Resilience: identify important business services, map dependencies, set impact tolerances, test against severe-but-plausible scenarios, and govern the programme at board level.
Every national regime - the PRA’s SS1/21 and FCA’s PS21/3 in the UK, APRA’s Prudential Standard CPS 230 in Australia, OSFI’s Guideline E-21 in Canada, and the EU’s Digital Operational Resilience Act (DORA) - traces its substantive obligations back to these principles. The vocabulary differs (“critical operations” vs “important business services” vs “critical or important functions”) but the shape is the same.
The status quo is a Visio file from 2019
In most firms, the dependency map for an important business service is a Visio diagram authored once by a former operational-risk manager, exported to PDF, attached to a SharePoint folder, and never opened again. Three years later the third-party landscape has shifted, the underlying systems have been re-platformed, and the impact tolerances were set against a service definition that no longer matches the live process. When the regulator asks to see how the firm would recover from a severe-but-plausible disruption, the answer is a slide deck that nobody believes.
Operational resilience as a discipline asks the opposite: keep the maps alive, keep the tolerances next to the services they govern, keep the scenario tests honest, and keep the board accountable for the outcome. That requires modelling tooling that treats BPMN as a first-class output - not as an export afterthought.
Four pieces of an operational resilience programme
The same four pillars show up under every regulator’s vocabulary. Each is a diagram - and each diagram links back to the same register of important business services.
Important business services
The activities whose disruption would harm customers, the firm, or the wider financial system. Every regime starts here - if you cannot name your important business services, every tolerance and dependency below floats unmoored.
Dependency mapping
For each important business service, map the people, processes, technology, data, third parties, and premises it relies on. Dependency mapping is the diagrammatic core of operational resilience - and the part that decays fastest if it lives in stale Visio files.
Impact tolerances
The maximum tolerable disruption (time, scale, volume) before customer or systemic harm becomes unacceptable. Tolerances live next to the service they govern so they cannot drift away from the operation they protect.
Scenario testing and board reporting
Severe-but-plausible scenarios (cyber outage, supplier failure, premises loss, pandemic) tested at regulator-specified frequency, with lessons learned and remediation plans reported to the board annually. The same diagrams drive the test design and the board pack.
Operational resilience as a process map
A regulator-agnostic operational resilience programme rendered as a BPMN 2.0 process. The same shape sits underneath APRA CPS 230, OSFI E-21, PRA SS1/21 and FCA PS21/3, and EU DORA - the labels change, the structure does not.
An operational resilience programme as a process map
A regulator-agnostic operational resilience programme rendered as a BPMN 2.0 process map. The flow identifies important business services, maps their dependencies (people, processes, technology, data, third parties, premises), sets impact tolerances, assesses severe-but-plausible scenarios, drives remediation where tolerances are breached, and reports findings to the board. Concrete regulator implementations (APRA CPS 230, OSFI E-21, PRA SS1/21 and FCA PS21/3, EU DORA) sit underneath this shape.
- Identify important business services (IBS) - the activities whose disruption would harm customers, the firm, or financial stability.
- Map dependencies for each service: people, processes, technology, data, third parties, premises.
- Set an impact tolerance per service - the maximum tolerable disruption before customer or systemic harm becomes unacceptable.
- Assess each service against severe-but-plausible scenarios (cyber outage, supplier failure, premises loss, pandemic).
- If a scenario breaches the impact tolerance, route to a remediation plan and re-assess. Otherwise continue to formal testing.
- Run scheduled scenario tests, capture lessons learned, and report annually to the board (and regulator where applicable).
What this diagram shows: The programme starts when the resilience function kicks off the annual cycle. The first three tasks build the foundation: identify important business services, map the dependencies (people, processes, technology, third parties, premises) each service relies on, and set an impact tolerance per service. The fourth task assesses each service against severe-but-plausible scenarios. At the impact-tolerance gateway, services that breach their tolerance route to a remediation plan and re-assess; services that stay within tolerance continue to formal scheduled scenario testing, with findings and lessons learned reported annually to the board. The end event represents continuous monitoring rather than programme completion - operational resilience is a cycle, not a project.
Frequently asked questions
What is operational resilience?
Operational resilience is the ability of a firm to prevent, adapt, respond to, recover from, and learn from operational disruption. The Basel Committee on Banking Supervision codified the modern definition in its March 2021 Principles for Operational Resilience: identify important business services, map dependencies, set impact tolerances, test against severe-but-plausible scenarios, and govern the programme at board level. National regimes (PRA SS1/21 and FCA PS21/3 in the UK, APRA CPS 230 in Australia, OSFI E-21 in Canada, the EU Digital Operational Resilience Act) all trace back to these principles.
How is operational resilience different from operational risk management?
Operational risk management is the broader discipline of identifying, measuring, and managing the risk of loss from inadequate or failed internal processes, people, systems, or external events. Operational resilience is a specific outcome inside that discipline: keeping important business services running through disruption, within a pre-declared impact tolerance. Resilience is outcome-focused (the service stays up); risk management is exposure-focused (where could things go wrong).
What is an impact tolerance?
An impact tolerance is the maximum tolerable disruption a firm will accept for an important business service before customer or systemic harm becomes unacceptable. It is expressed in concrete terms - hours of outage, number of failed payments, percentage of transactions affected - not as a risk appetite statement. Every important business service has its own tolerance, set by the board and tested against severe-but-plausible scenarios.
Which regulations require an operational resilience programme?
The major regimes are the UK rules (PRA Supervisory Statement SS1/21 and FCA Policy Statement PS21/3, both in force since 31 March 2022), Australia's APRA Prudential Standard CPS 230 (in force from 1 July 2025, with legacy service-provider arrangements required to comply by the earlier of the next contract renewal or 1 July 2026), Canada's OSFI Guideline E-21 (revised 2024), and the EU Digital Operational Resilience Act (DORA, applicable from 17 January 2025). All four trace their substantive obligations back to the Basel Committee's 2021 Principles for Operational Resilience.
How does process mapping fit into an operational resilience programme?
Process mapping is the medium that turns operational resilience from a policy document into a running programme. Every important business service needs an end-to-end process map showing the people, systems, third parties, and decision points involved - that is exactly what an APRA, OSFI, FCA, PRA, or EIOPA reviewer asks to see. Dependency mapping is the diagrammatic core of the programme, and BPMN 2.0 is the notation that survives audit because the symbols are unambiguous and tool-portable.
Does BA Copilot replace our operational resilience programme?
No. BA Copilot is the modelling layer. It does not set tolerances, run scenario tests, or sign off on board reports. It speeds up the part of the programme where you have to draw, share, and maintain the process maps and dependency maps that the regulator and your second-line teams will ask for. The substantive obligations sit with your operational-risk and resilience teams.
What is the difference between a critical operation and an important business service?
The terms come from different regulators but cover broadly the same concept. APRA CPS 230 uses "critical operation", the UK regime (PRA SS1/21 and FCA PS21/3) uses "important business service", OSFI E-21 uses "critical operation", DORA uses "critical or important function". In practice they all mean the same thing: an activity whose disruption would cause material harm to customers, the firm, or the financial system. Pick whichever term your regulator uses and stay consistent inside the firm.
14 Years in BPMN
I'm Jack Finnegan. I've spent fourteen years working hands-on with BPMN, as an analyst, an engineer, and a product director, where I felt every sharp edge of legacy business process platforms.
BA Copilot is the platform I wanted on every one of these projects: AI-first process management, which treats BPMN as a first-class output rather than an export afterthought.
Sources and verification
Last verified 21 May 2026 by Jack Finnegan.
Verified against: Basel Committee Principles for Operational Resilience (March 2021)
References cited on this page:
- Basel Committee Principles for Operational Resilience (2021)
- PRA SS1/21 and FCA PS21/3
- APRA CPS 230
- OSFI E-21
- EU DORA
Make your operational resilience programme a living process
Start with the important business service that worries you most. Open the template, rename the steps to match your firm, and capture impact tolerances on the same diagram.