Operational resilience is the ability of an organization to keep delivering its important services through disruption, whatever the cause, within limits it has set in advance for how much disruption its customers and the wider system can bear. The definition is deliberately different from business continuity’s. Continuity planning asks how fast a process or a site can be recovered; operational resilience asks which services matter most to the people outside the organization, how long and how badly each can be disrupted before the harm becomes intolerable, whether the organization can stay inside that limit when severe but plausible things happen, and what it will change if it cannot. The framing emerged from UK financial regulation between 2018 and 2021 and has since been adopted, in its vocabulary or its substance, by the Basel Committee, the US banking agencies, the European Union, Australia, Canada, Singapore and Hong Kong, and by organizations outside finance that found it a better way to think.
This guide explains the framing and what it asks of an organization and of internal audit. It covers why continuity planning was found wanting, the five building blocks of the approach (important business services, impact tolerances, mapping, scenario testing and the self-assessment), how an impact tolerance differs from a recovery time objective and why the difference matters, the regimes that adopted the approach and how they differ, where business continuity, disaster recovery, third-party risk and cyber fit inside it, what internal audit tests under the framing, how the IIA’s Organizational Resilience Topical Requirement (effective 30 April 2027) formalizes the audit expectation, the failures that make a resilience program decorative, and a worked example of a US regional bank adopting the approach without being required to. It sits alongside the business continuity risk guide, the cyber resilience and third-party resilience audit guides and the Topical Requirement workbook.
In this guide
- Why continuity planning was not enough
- The five building blocks
- Important business services
- Impact tolerances, and how they differ from RTOs
- Mapping the service end to end
- Severe but plausible scenario testing
- The self-assessment and the board
- The regimes that adopted the framing
- Where BCM, DR, third-party risk and cyber fit
- What internal audit tests
- The Organizational Resilience Topical Requirement
- Failures that make resilience programs decorative
- Worked example: Lakeshore Bancorp adopts the framing
- Questions about operational resilience
- Related guides
Why continuity planning was not enough
Business continuity management matured in the 1990s and 2000s around a clear logic: identify critical processes, decide how fast each must be recovered, build recovery capability (alternate sites, backups, call trees) and test it. It worked for the disruptions it imagined, a building lost, a data center down, a pandemic keeping staff at home. It worked less well for the disruptions that actually hurt customers in the 2010s: a failed core banking migration that locked customers out for weeks, payment outages that lasted days, cyber incidents that disabled a firm whose recovery plans assumed its data was intact, and third-party failures the firm could not recover because it did not own the failing component. Three weaknesses were common to these cases. The unit of analysis was wrong: firms planned around processes and sites, while harm happened to services customers used, which cut across many processes, systems, sites and suppliers. The objective was wrong: recovery time objectives were set by technology and operations as what they could achieve, not by asking how much disruption customers could tolerate, and nobody tested whether the two matched. And the assumption was wrong: plans assumed disruption could be prevented or quickly reversed, so the question “what if it happens anyway and lasts” was never asked. The UK regulators’ discussion paper in 2018 named these problems and proposed an approach built on the opposite assumptions: disruption will occur; the firm should decide in advance which services must survive and for how long they can fail; and it should prove to itself, by testing, that it can stay inside those limits.
The five building blocks
| Building block | Question it answers | Output | Common failure |
|---|---|---|---|
| 1. Important business services | Which services, if disrupted, would cause intolerable harm to customers, the firm or the system? | A short list (typically 5 to 20 for a mid-size firm) with the criteria used | A list of 60 “services” that is really the process inventory renamed |
| 2. Impact tolerances | For each service, what is the maximum disruption (duration and other dimensions) before harm becomes intolerable? | A tolerance per service, approved by the board, with the reasoning | Tolerances copied from existing RTOs; tolerances set at what is achievable rather than what is tolerable |
| 3. Mapping | What people, processes, technology, facilities, information and third parties does each service depend on, end to end? | A dependency map per service, maintained | Maps that stop at the firm’s boundary or at the application layer |
| 4. Scenario testing | Can the service stay within tolerance under severe but plausible scenarios? | Test results per service and scenario, with the breaches and the remediation they drive | Testing only likely scenarios; testing the plan rather than the service; never finding a breach |
| 5. Self-assessment and lessons learned | What has the firm concluded about its resilience, what is it doing about the gaps, and what did incidents and tests teach? | A board-approved document, updated at least annually, that regulators read | A compliance narrative with no vulnerabilities admitted |
Two further elements run through all five: governance (the board owns the approach and approves the services, tolerances and self-assessment; a senior manager is accountable) and communications (plans for telling customers, regulators and staff what is happening during a disruption, which several of the outages that prompted the regime had handled badly).
Important business services
A business service is something the firm provides to an external end user: making a payment, accessing an account, drawing on a credit line, settling a trade, paying a claim. It is defined from the user’s side, which is what distinguishes it from a process (what the firm does internally) and from a system (what runs it). A service is important when its disruption could cause intolerable harm to consumers or market participants, threaten the firm’s safety and soundness, or (for systemically significant firms) threaten financial stability. Identification works from the outside in: list the services customers would name if asked what they rely on the firm for; apply the harm criteria to each, considering the number and vulnerability of the users affected, the substitutability of the service, the time-criticality, and the knock-on effects; and record the reasoning for inclusions and exclusions, because regulators and auditors will test the exclusions harder than the inclusions. A retail bank’s list usually includes making and receiving payments, accessing cash, accessing account information, lending drawdowns and mortgage completions; a payments firm’s list is shorter and more concentrated. The risk taxonomy guide’s rule applies in reverse here: services are not risk categories, and a firm that lists “operational risk” or “IT” as a service has confused the axes.
Impact tolerances, and how they differ from RTOs
| Dimension | Recovery time objective (RTO) | Impact tolerance |
|---|---|---|
| Applies to | A process, application or resource | An important business service as experienced by its users |
| Set by | Operations and technology, from the business impact analysis | The board, from the harm the service’s disruption causes outside the firm |
| Asks | How fast can and should we recover this? | How much disruption is too much for the people who depend on this? |
| Assumes | Recovery capability can be built to meet it | Disruption will occur; the question is whether the firm stays inside the limit |
| Metric | Time to restore | Always a maximum duration; often also volume (payments not made), value, number of customers affected, or data (loss or integrity) |
| Relationship | The RTOs of a service’s components must together deliver the service inside its tolerance; an RTO longer than the tolerance is a finding | One tolerance per service; the mapping shows which RTOs it constrains |
| Example | Core banking platform RTO 4 hours; payment gateway RTO 2 hours | Domestic payments: no customer unable to make an urgent payment for more than 24 hours; no payment lost; batch of salary payments never later than the next business day |
Setting a tolerance is a judgment about harm, and the useful discipline is to force the board to own it: a tolerance is the point at which the firm says disruption beyond this is unacceptable to us, and the regulators’ point was that firms had never made that statement, so technology had made it for them. Tolerances are tested, not merely declared: the scenario testing below asks whether the firm can in fact stay inside them, and a tolerance the firm cannot meet is not revised upward to fit; the gap is remediated or accepted at board level with the regulator informed. The Topical Requirement workbook carries the IIA’s version of the same expectation.
Mapping the service end to end
Mapping is the inventory of everything a service depends on, from the customer’s first touch to the final outcome, across the six resource types the UK policy names: people (teams, key individuals, skills), processes, technology (applications, infrastructure, data flows), facilities, information (data the service needs and its integrity) and third parties (including the third parties’ own dependencies, the fourth parties of the concentration guide). The map’s purpose is to find single points of failure, concentrations (one cloud region, one payment processor, one team of three people) and the dependencies nobody owned, and to make scenario testing possible: a scenario is tested by walking the map and asking what the disruption does to each node. Mapping is where most programs underestimate the work; a service map that is honest typically reveals dependencies on spreadsheets, on individuals and on suppliers that the process documentation never mentioned. Maps are maintained as the business changes, which is why the Lakeshore example below ties the map to the change and vendor processes.
Severe but plausible scenario testing
The test asks: under this scenario, does the service stay inside its tolerance? Scenarios are severe (they stress the service hard) but plausible (they have happened to someone, or could), and they are chosen to probe the map’s vulnerabilities: loss of the primary data center and the failover not working as designed; a ransomware event that makes backups suspect; the failure of a critical third party for a week; the loss of a key team; a cyber attack on a payment network; a failed major change. Testing methods range from desk-based walkthroughs of the map to live exercises (failing over, restoring from backup, invoking the vendor’s exit plan), and credible programs use both, with live tests for the dependencies that matter most. The output is a conclusion per service and scenario, inside or outside tolerance, with the breach’s cause and the remediation it drives, and the honesty of a program shows here: a test program that never finds a breach has either tested gently or set tolerances it could not fail. Lessons from real incidents, the firm’s own and the industry’s, feed the scenario set, and the cyber resilience audit guide shows what a live restore test reveals.
The self-assessment and the board
The self-assessment is a document, approved by the board, that records the firm’s important business services and why, the impact tolerances and the reasoning, the mapping and testing performed, the vulnerabilities found and the remediation plan with dates, the lessons from incidents and tests, and the firm’s overall conclusion on whether it can remain within tolerance. Regulators read it as the primary evidence of the program and judge its candor: a self-assessment that admits no vulnerability is read as a sign that the testing was weak. Boards use it as the resilience equivalent of the risk appetite statement, and the audit committee calendar gives it a deep-dive slot. Internal audit treats it as the artifact against which the whole program is audited.
The regimes that adopted the framing
| Jurisdiction and source | Scope | Distinctive features |
|---|---|---|
| United Kingdom: PRA Supervisory Statement SS1/21 and FCA Policy Statement PS21/3 (March 2021), with the Bank of England’s equivalent for market infrastructures | Banks, building societies, PRA-designated investment firms, insurers, financial market infrastructures; FCA solo-regulated firms in the enhanced SM&CR tier, payment and e-money firms, recognized exchanges | The archetype: important business services, impact tolerances with a time element, mapping, scenario testing, self-assessment; policy in force 31 March 2022 with firms expected to be able to remain within tolerances by 31 March 2025 |
| Basel Committee: Principles for Operational Resilience (March 2021), alongside the revised Principles for the Sound Management of Operational Risk | Internationally active banks; the reference for national supervisors | Seven principles: governance, operational risk management, business continuity planning and testing, mapping interconnections and interdependencies, third-party dependency management, incident management, and ICT including cyber; critical operations and tolerance for disruption |
| United States: interagency paper, Sound Practices to Strengthen Operational Resilience (October 2020), Federal Reserve, OCC and FDIC | The largest banking organizations | Sound practices rather than rules: governance, operational risk management, business continuity, third-party risk, scenario analysis, secure and resilient information systems, surveillance and reporting; critical operations and core business lines as the unit; smaller banks adopt it voluntarily, as Lakeshore does below |
| European Union: Digital Operational Resilience Act (Regulation 2022/2554), applying from 17 January 2025 | Financial entities across the EU, and critical ICT third-party providers | ICT-focused: ICT risk management framework, incident reporting, digital operational resilience testing including threat-led penetration testing, ICT third-party risk and the register of information, oversight of critical providers; the DORA guide covers the audit |
| Australia: APRA Prudential Standard CPS 230 Operational Risk Management, effective 1 July 2025 | APRA-regulated banks, insurers and superannuation trustees | Critical operations, tolerance levels, service provider management and business continuity in one standard; transition for existing contracts |
| Canada: OSFI Guideline E-21 Operational Risk Management and Resilience (2024), phased in to 2026 | Federally regulated financial institutions | Critical operations, tolerances for disruption, mapping, scenario testing; aligned to Basel |
| Singapore (MAS Business Continuity Management Guidelines, 2022) and Hong Kong (HKMA Supervisory Policy Manual OR-2, 2022) | MAS- and HKMA-regulated institutions | Critical business services with service recovery time objectives; HKMA set a multi-year path to demonstrable resilience |
| The IIA: Organizational Resilience Topical Requirement (issued 30 April 2026, effective 30 April 2027) | Internal audit functions auditing resilience, in any sector | Twenty requirements across governance, risk management and control processes; the audit-side codification of the framing (workbook) |
Dates and scopes are as this guide is written; several regimes are still phasing in and firms should check the current text. The spread outside finance has come without regulation: utilities, healthcare providers, logistics companies and manufacturers have adopted the service-and-tolerance framing because it answers the board’s question (“what happens to our customers if this fails, and for how long can we let it”) better than a recovery-time table does, and the IIA’s requirement applies to any organization an internal audit function serves.
Where BCM, DR, third-party risk and cyber fit
| Discipline | Role inside the resilience framing | What changes for it |
|---|---|---|
| Business continuity management | The capability that recovers processes and sites; the BIA feeds the mapping and the RTOs | RTOs are constrained by the service tolerances above them; plans are tested against service scenarios, not only site scenarios |
| Disaster recovery | The technology recovery capability | Recovery objectives must deliver the service inside tolerance; backup integrity and immutability become resilience questions, not only IT ones |
| Third-party risk management | The management of the suppliers the map depends on | Critical suppliers are identified by the services they support; exit and substitution plans are tested; fourth parties are mapped (third-party resilience) |
| Cyber and ICT risk | The main source of severe scenarios | Scenarios assume compromise, not only outage; recovery from data loss or corruption is tested (cyber resilience) |
| Operational risk management | The framework the resilience program sits in; the framework audit covers it | Resilience scenarios join the scenario analysis program; incident data feeds lessons learned |
| Incident and crisis management | The response during disruption | Communications to customers and regulators planned in advance; decision rights for invoking tolerances |
| Change management | The source of many disruptions | Major changes assessed against the service map; the failed-migration scenario tested |
What internal audit tests
| Area | Tests | Evidence |
|---|---|---|
| Governance | Board approval of services, tolerances and self-assessment; accountable executive; program resourcing | Board minutes; the self-assessment; the accountable executive’s statement of responsibilities |
| Service identification | Criteria applied consistently; exclusions justified; customer-side definition; completeness against the product and channel inventory | Identification workpapers; challenge of three exclusions |
| Impact tolerances | Set from harm, not from current RTOs; time element present; board rationale; alignment with regulatory expectations where applicable | Tolerance papers; comparison of tolerances with RTOs for the mapped components |
| Mapping | Completeness against application, vendor and site inventories; third and fourth parties; single points of failure identified; currency after changes | Maps; reconciliation to inventories; change log |
| Scenario testing | Scenario severity and plausibility; coverage of the map’s vulnerabilities; live versus desk-based mix; breaches found and remediated; results reported honestly | Test plans and results; remediation tracking; re-performance of one live test |
| Remediation | Vulnerabilities funded and on track; acceptance of residual breaches at board level | Remediation plan; board acceptance records |
| Self-assessment | Candor; consistency with test results and incidents; regulator feedback addressed | The document; incident records; supervisory correspondence |
| Lessons learned | Incidents and tests analyzed; changes made | Post-incident reviews; scenario set updates |
The engagement is a framework audit with one live-test component: the function should witness or re-perform at least one scenario test, because the gap between the documented test and the real capability is where the most serious findings live. The BCM audit program gives the detailed steps for the continuity components; the Topical Requirement workbook maps the tests to the IIA’s requirements.
The Organizational Resilience Topical Requirement
The IIA issued the Organizational Resilience Topical Requirement on 30 April 2026, effective 30 April 2027, as the fourth in its series after cybersecurity, third-party risk and organizational behavior. It is mandatory for any assurance engagement whose subject is organizational resilience and recommended for advisory work, and it sets twenty requirements across governance (six), risk management (four) and control processes (ten) that an internal audit function must assess, including the board’s oversight, the definition of what must be resilient and the tolerances for disruption, dependency mapping, scenario testing, incident response and recovery, third-party dependencies, and lessons learned. The requirement adopts ISO 22316’s definition of organizational resilience and applies across sectors, which means the service-and-tolerance framing has become an audit expectation for organizations that no financial regulator reaches. The workbook paraphrases each requirement and gives the evidence; the Topical Requirements overview explains how the series works.
Failures that make resilience programs decorative
| Failure | How it shows | Fix |
|---|---|---|
| Services defined from the inside | The list mirrors the org chart or the application inventory | Start from what customers would name; apply harm criteria |
| Tolerances reverse-engineered | Every tolerance equals the current RTO plus a margin | Set from harm by the board; then compare with RTOs and treat gaps as findings |
| Maps stop at the boundary | No fourth parties; no people dependencies; no data integrity | Six resource types; reconcile to inventories; name the individuals |
| Gentle testing | Desk-based only; likely scenarios; no breaches ever | Live tests of the critical dependencies; severe scenarios from real incidents |
| Program as a project | Done for the regulatory date, then unmaintained | Tie the map to change and vendor processes; annual cycle; board calendar slot |
| Self-assessment as advocacy | No vulnerabilities admitted | Report breaches and remediation plainly; regulators and auditors reward candor |
| Resilience owned by IT | Business services nobody in the business owns | Business owner per service; technology owns components |
Worked example: Lakeshore Bancorp adopts the framing
Lakeshore Bancorp, the $9 billion regional bank used in examples across this site, is not within the scope of the US interagency sound practices paper and faces no rule requiring the service-and-tolerance approach. Its board risk committee adopted it anyway in 2025, after two events: a seven-hour digital banking outage caused by a failed change that the continuity plan, built around sites, had nothing to say about, and the cyber resilience audit‘s finding that the bank’s recovery plans assumed intact data. The chief risk officer proposed a program modeled on the UK policy and Basel’s principles, with internal audit as challenger rather than designer under the objectivity safeguards, and the committee approved a two-year path.
The program identified nine important business services from a candidate list of 23, applying harm criteria that weighed the number of customers affected, substitutability and time-criticality: making domestic payments (wire and ACH), receiving payroll and benefit deposits, accessing account balances and transactions through digital channels, accessing cash through branches and ATMs, card payments at point of sale, drawing on committed commercial credit lines, mortgage closings and funding, treasury management client services (positive pay, ACH origination) and trust client disbursements. Tolerances were set by the board for each, with a maximum duration and a second dimension; domestic payments, for example, carried a tolerance of no customer unable to make an urgent payment for more than 24 hours and no payment lost, which was tighter than the payment platform’s existing 48-hour RTO and became the first remediation item. Mapping took five months and found 31 single points of failure, including a three-person team that alone understood the ACH returns process, a statement rendering vendor with no tested alternative, and the digital banking platform’s dependency on a single cloud region. Scenario testing in year one ran twelve scenarios across the nine services, four of them live (a data center failover, a core platform restore from immutable backup, a payment processor outage simulation with the vendor and a key-team-loss walkthrough), and found that four services could not demonstrably stay inside tolerance under at least one scenario. The self-assessment reported all four breaches, the remediation plan and its dates, and the committee accepted one residual breach (card payments under a prolonged network failure, judged outside the bank’s control) with the reasoning recorded.
| Element | Year-one result | Internal audit’s role and findings |
|---|---|---|
| Important business services | 9 from 23 candidates; criteria documented; 14 exclusions reasoned | Challenged three exclusions; one (loan payment processing) added as a tenth service in year two |
| Impact tolerances | 9 set by the board; 3 tighter than existing RTOs | Confirmed tolerances were set from harm; the RTO gaps raised as findings against the platform owners |
| Mapping | 9 maps; 31 single points of failure; 14 critical third parties, 6 with identified fourth parties | Reconciled maps to the application and vendor inventories; found two unmapped dependencies (a reconciliation spreadsheet and a courier contract) |
| Scenario testing | 12 scenarios, 4 live; 4 services outside tolerance in at least one scenario | Witnessed the immutable backup restore (achieved in 19 hours against a 24-hour component RTO); rated the desk-based tests as insufficiently severe in two cases |
| Remediation | Payment platform RTO reduced to 12 hours; ACH returns cross-training; alternate statement vendor contracted; multi-region design approved for digital banking | Tracked as High and Medium findings; validated at year end |
| Self-assessment | Approved by the board risk committee; four breaches disclosed; one residual breach accepted | Reviewed for consistency with test results; no observations on candor |
| Examiner response | Program described in the examination’s governance assessment as a strength relative to peers | Internal audit’s framework audit report shared with examiners on request |
The chief risk officer’s comment at the year-end committee was that the bank had run continuity planning for twenty years and had never before written down how long its customers could go without making a payment; the chief audit executive’s was that the finding that mattered most, the 48-hour RTO behind a 24-hour tolerance, had been visible in two documents for years and invisible until someone put them side by side.
Questions about operational resilience
What is the difference between operational resilience and business continuity?
Business continuity recovers processes and sites against recovery time objectives set by what is achievable. Operational resilience starts from the services customers depend on, sets tolerances for how much disruption they can bear, maps every dependency and tests whether the organization can stay inside the tolerances when severe things happen. Continuity is one of the capabilities resilience relies on.
What is an important business service?
A service provided to external users whose disruption could cause intolerable harm to customers or market participants, threaten the firm’s viability or, for the largest firms, financial stability. It is defined from the user’s side, not as a process or a system.
What is an impact tolerance and how does it differ from an RTO?
An impact tolerance is the maximum tolerable disruption to a service, set by the board from the harm disruption causes, always including a duration. A recovery time objective is the recovery target for a process or system, set by operations. The components’ RTOs must together deliver the service inside its tolerance.
Which regulations require operational resilience?
The UK PRA and FCA policy (2021), the Basel Committee’s principles (2021), the US interagency sound practices for the largest banks (2020), the EU’s DORA for ICT resilience (2025), Australia’s CPS 230 (2025), Canada’s E-21 and the Singapore and Hong Kong guidance, among others; the IIA’s Topical Requirement (effective 2027) makes it an audit expectation in any sector.
What does severe but plausible mean?
Scenarios that stress a service hard (prolonged third-party failure, data corruption, loss of a key team, a failed major change) but that have happened to someone or credibly could, chosen to probe the vulnerabilities the map reveals rather than the disruptions the firm finds comfortable.
Does operational resilience apply outside financial services?
Not by regulation in most sectors, but the framing is being adopted by utilities, healthcare, logistics and manufacturing because it answers the board’s question better than a recovery-time table, and the IIA’s Organizational Resilience Topical Requirement applies to internal audit functions everywhere.
What should internal audit test first?
Whether tolerances were set from harm rather than copied from RTOs, whether the maps reach third and fourth parties and named people, and whether at least one severe scenario has been tested live. Those three tests find most of what is wrong with a decorative program.
Related guides
- The Organizational Resilience Topical Requirement — the twenty requirements and a conformance workbook.
- Business continuity risk: complete overview — the discipline resilience builds on.
- Five business continuity concepts auditors must master — RTO, RPO, MTPD and the rest.
- How to audit the BCM program — the detailed program.
- How to run a business impact analysis — the input to mapping and RTOs.
- Auditing cyber resilience — the live restore test.
- Third-party resilience — critical suppliers and exit plans.
- Fourth-party risk and vendor concentration — the dependencies behind the dependencies.
- DORA for internal auditors — the EU’s ICT resilience regime.
- Backup and recovery audit — immutability and restore evidence.
- Incident response audit — the response during disruption.
- How to audit operational risk management — the framework the program sits in.
- IT change management audit — the failed-change scenario’s root.
- IIA Topical Requirements explained — how the series works.
- Internal audit in banking — the supervisory context.
- Risk taxonomy — why services are not risk categories.
Leave a Reply