For a decade, regulators across the EU, UK, and Australia have been quietly rewriting the same expectation in different dialects: stop telling us how you will recover after a failure, and start proving you can keep operating through one. The vocabulary differs by jurisdiction, but the underlying demand does not. A bank running services in London, Frankfurt, and Sydney now answers to three regimes that each ask for the same evidence in a slightly different template.
That is the trap most teams walk into. They treat each regulator as a separate project, rebuild the same business impact analysis in a fresh spreadsheet for each one, and discover at audit time that the numbers no longer agree. The rest of this guide unpacks why the regulatory landscape shifted, how the major regimes converge, what the duplication actually costs, and how to build a single evidence base that satisfies many frameworks at once.
Why operational resilience regulation surged
The regulatory centre of gravity moved from disaster recovery to demonstrable resilience over roughly a decade, pushed by high-profile failures and a steadily deepening reliance on a handful of concentrated technology providers. The reasoning matters, because it explains why every regime now asks for proof rather than a plan on a shelf.
From 'Recover After Failure' to 'Prove You Can Withstand'
The old model assumed disruption was rare. Plans sat in binders, recovery was the goal, and the test of a good program was how fast you bounced back. Regulators no longer accept that framing. They start from the assumption that disruption is inevitable and that the relevant question is whether a customer or a market gets harmed when it arrives.
The shift is also outward-facing. SS1/21 and DORA are written around customer and market harm, not internal recovery time. A firm can restore its own systems quickly and still breach an impact tolerance if a vulnerable customer cannot access funds for two days.
Cyber sits at the centre of that worry. Cyber threats were rated the highest risk for both the coming year and the next five to ten years in the BCI Horizon Scan 2025, which tells you where examiner attention is going. Boards that still treat continuity as an IT housekeeping task are reading last decade's risk map.
Read our learnings from Disaster recovery journal DRJ spring
Concentration Risk and the Cost of Getting It Wrong
Centralised vendors are efficient. They are also a single point through which one failure cascades across entire sectors at once. That is the lesson regulators drew from the last two years, and it now drives the third-party oversight language in nearly every regime.
On 19 July 2024, a faulty Channel File 291 content update to CrowdStrike's Falcon sensor sent Windows endpoints into boot loops worldwide. CrowdStrike reverted the update within 78 minutes, but the damage was already done: recovery required machine-by-machine manual intervention. Roughly 8.5 million Windows systems crashed, grounding flights, pushing hospitals onto paper records, and disrupting banks and emergency lines. CISA published remediation guidance the same day.
The financial scale made it a board problem. Fortune 500 companies absorbed an estimated $5.4 billion in direct losses. No firm in that blast radius had done anything wrong in the conventional sense. They had simply concentrated a critical dependency on one vendor and never tested what happened when that vendor pushed a bad update. The practitioner takeaway is uncomfortable: your resilience is bounded by the resilience of providers you do not control, and regulators now expect you to have mapped and tested that exposure.
What Are Regulations & Standards in Operational Resilience?
The terms get used interchangeably in meetings, which causes real confusion about what is legally binding and what is advisory. This section draws the line clearly, then shows how the two types reinforce each other in practice.
Regulation and standards in operational resilience are two different instruments. A regulation is a legally enforceable rule set by a government or supervisor for a defined jurisdiction, carrying penalties for breach. A standard is a voluntary, cross-border methodology published by a standards body that gives organisations a recognised way to structure the work regulators then inspect.
Regulations vs Standards: What's Enforceable
Regulations are binding, jurisdiction-specific, and backed by penalties. DORA, the UK's SS1/21, and APRA CPS 230 all sit here. Miss a deadline or fail to evidence a requirement and you face supervisory action, fines, or both.
Standards are different. ISO 22301:2019 and the NIST Cybersecurity Framework 2.0 are voluntary. No law compels certification. Yet they frequently become the operational backbone that satisfies regulators, because a documented management system maps neatly onto what a supervisor wants to see.
Sitting underneath both is business continuity itself. Business continuity is a holistic process that begins with a business impact analysis, informs the development of business continuity plans and recovery strategies, and helps an organisation keep critical operations running during and after disruption. None of the regimes discussed here replaces that discipline. They extend it and demand evidence of it.
How the Two Reinforce Each Other
A certified ISO 22301 management system gives you a documented structure that examiners recognise on sight: governance, a tested BIA, recovery strategies, exercise records, and an improvement loop. That structure does a lot of the regulators' structural heavy lifting for you.
The BIA is the non-negotiable shared foundation. Every regime traces back to a credible analysis of which operations matter and how quickly their loss causes harm. The BCI Good Practice Guidelines treat it the same way. Resilience does not retire continuity management. It encompasses it.
The Major Regulatory Regimes
Four instruments dominate the regulated-sector landscape, plus one cybersecurity framework that increasingly bridges into the resilience picture. Each is summarised here with scope and key dates, and each has a deeper-dive guide for the full requirement set. Read these as a map, not a manual.
ISO 22301:2019: The Methodological Backbone
ISO 22301 is the international standard for business continuity management systems. It is voluntary but widely certified, and it gives organisations a recognised structure that many use as the spine of a multi-regime program.
The standard runs on a Plan-Do-Check-Act cycle across Clauses 4 to 10, covering organisational context, leadership, planning, support, operation, performance evaluation, and improvement. The clause-by-clause structure is what makes it portable across jurisdictions: build it once and you have satisfied the structural expectations of several regulators at the same time.
EU DORA: Digital Operational Resilience for Financial Entities
The Digital Operational Resilience Act, Regulation (EU) 2022/2554, entered into application on 17 January 2025. It covers 20 types of financial entity plus the critical ICT third-party providers they depend on, harmonising rules for ICT risk management, incident reporting, and resilience testing across the bloc.
DORA Article 24 sets out general testing requirements, while Article 26 mandates advanced threat-led penetration testing (TLPT) for significant entities. EIOPA's oversight framework brings critical ICT third parties under direct supervisory attention, which is the regime's sharpest departure from what came before.
UK SS1/21: Impact Tolerances for Important Business Services
The PRA and FCA supervisory statement SS1/21 requires firms to identify their important business services, set impact tolerances for each, and demonstrate they can remain within those tolerances under severe-but-plausible scenarios. Firms had to be able to do so by 31 March 2025.
The regime is deliberately outcome-focused rather than prescriptive. The supervisory statement tells you what to achieve, not how. That flexibility is a gift and a burden: you own the methodology, and you own the consequences if it does not hold up.
APRA CPS 230: Australia's Operational Risk Standard
CPS 230 is a cross-industry prudential standard that took effect on 1 July 2025, applying across banking, insurance, and superannuation. It replaces five prior outsourcing and business continuity standards with one consolidated regime.
Firms must identify critical operations, set tolerance levels, and maintain a material service provider register. Paragraph 51 of CPS 230 sets out that register requirement explicitly. APRA's practice guide CPG 230, released June 2024, lays out baseline expectations for every regulated entity regardless of size.
NIST CSF 2.0: The Cybersecurity Crossover
The NIST Cybersecurity Framework 2.0, released February 2024, is the first major update since 2014. The headline change is the new Govern function, which sits alongside Identify, Protect, Detect, Respond, and Recover.
The scope also expanded beyond critical infrastructure to all organisations. The official CSF 2.0 document frames cybersecurity as a governance concern, not a technical one, which is precisely the bridge that ties cyber risk into the broader resilience and continuity picture. For US healthcare and critical infrastructure, it has become the de facto cyber-resilience backbone.
What They All Have in Common: The Convergence
Strip away the jurisdictional vocabulary and the major regimes ask for nearly identical evidence. This convergence is the practitioner's advantage. Solve the underlying problem once and you can express the answer in several regulators' templates without rebuilding the substance each time.
Critical Operations and Important Business Services
Every regime opens with the same question: what must keep running? DORA calls them critical or important functions. SS1/21 calls them important business services. CPS 230 calls them critical operations. The labels differ; the concept is a sibling across all three.
The identification of important business services under SS1/21 starts, like the others, from a credible business impact analysis. That makes the BIA the common foundational input. Get it right once and three regimes inherit the same starting point. Get it wrong and you propagate the same error into every submission.
Impact Tolerances and Severe-but-Plausible Testing
Setting a maximum tolerable level of disruption, then proving you can stay inside it, is now a shared requirement rather than a UK quirk. The vocabulary travels: impact tolerances in the UK, tolerance levels in Australia, broadly equivalent expectations in the EU.
Testing is where the regimes diverge most. The EBA's interactive single rulebook for DORA Article 24 sets general testing requirements, and DORA layers TLPT on top for significant entities, which goes further than SS1/21 or CPS 230 demand. Validation evidence, not the existence of a plan, is what auditors inspect. A scenario library that nobody has executed is documentation, not assurance.
Third-Party Dependencies and Board Accountability
Dependency mapping and a material service provider register appear across the board. Paragraph 51 of CPS 230 makes the register explicit in Australia; DORA brings critical ICT third parties under direct oversight; SS1/21 expects firms to map the resources their important business services rely on. The concern is identical: concentration risk in a small number of providers.
Board accountability is the other constant. Every regime names accountable executives and expects board sign-off, because supervisors learned that operational risk floats up to senior management slowly, if at all. The convergence on cascading dependency exposure is the single strongest signal that these regimes are converging by design, not by accident.
The Hidden Cost of Treating Each Regime Separately
Most organisations run a separate compliance project per regulator. Each project rebuilds the same evidence in a different template, on a different timeline, owned by a different person. The result is duplication, drift, and audit risk, and the enforcement record shows exactly what is at stake when it goes wrong.
Duplication, Stale Data, and Audit Risk
The pattern is familiar to anyone who has run a resilience program across borders. The same critical-services list and the same dependency data get re-keyed into a DORA template, then an SS1/21 self-assessment, then a CPS 230 register. Three copies. Three update cycles. Three chances for the numbers to disagree.
Point-in-time spreadsheets drift the moment they are filed. A vendor changes, a service is re-platformed, an RTO is revised, and the three copies fall out of sync until someone notices at the next audit. A multinational firm sitting under both DORA and SS1/21 does not need two dependency maps. It needs one, expressed two ways. The duplication is not just inefficient. It manufactures the inconsistencies examiners are trained to find.
Enforcement Reality: What Failure Costs
In April 2018, TSB Bank migrated 1.3 billion customer records from Lloyds Banking Group's systems onto parent company Sabadell's platform. The migration failed on launch. Branch, telephone, online, and mobile banking went down for a significant share of 5.2 million customers, and problems persisted into December. The bank lost 80,000 customers and its CEO.
The regulators acted. TSB was fined a total of £48.65 million (FCA £29.75m, PRA £18.9m) for operational risk and governance failures, with the Bank of England confirming the joint action. On top of the fines, TSB paid £32.7 million in customer redress.
Set TSB beside the 2024 CrowdStrike outage and the same lesson surfaces twice. TSB concentrated a critical migration on an outsourced platform it had not adequately tested. The CrowdStrike victims concentrated a critical control on a single vendor they could not control. Different decades, different triggers, identical failure mode: an unmanaged dependency that cascaded. Enforcement and market harm are not abstractions. They are what the convergence is designed to prevent.
A Methodology for Mapping One Evidence Base to Many Frameworks
Rather than a compliance project per regime, build a single resilience evidence base and express it many ways. The structure follows the consulting shape every senior practitioner recognises: inputs, analytic steps, artifacts, decisions. Done once, it turns regulatory overlap from a cost into an efficiency.
Inputs: BIA, Dependency Data, and Tolerance Definitions
Start with one canonical business impact analysis that every regime draws from. Clause 8 of ISO 22301 frames the BIA and risk assessment as the operational core of the management system, which makes it a natural single source of truth.
The inputs are short to list and hard to maintain:
- A single business impact analysis covering every critical operation, owned in one place.
- One dependency and third-party register that serves DORA, SS1/21, and CPS 230 simultaneously.
- Tolerance definitions captured once and expressed per regulator, so the underlying number never forks.
- Test and exercise records linked to the operations they validate.
- Governance artifacts: accountable owners, board minutes, sign-off dates.
Analytic Steps: Crosswalk and Gap Analysis
With inputs canonical, the analytic work is a crosswalk. Map each data point you hold to each requirement each regime imposes, then look for the gaps where one regime asks for more than another.
Follow these steps in order:
- List every requirement clause from each regime in scope.
- Tag each requirement to the canonical input that satisfies it.
- Flag requirements with no matching input as gaps.
- Mark requirements where one regime exceeds the others, such as DORA Article 26 advanced TLPT.
- Reconcile differing terminology to one internal definition set.
- Record the mapping so the next audit reuses it rather than rebuilding it.
The table below shows how the four core requirements line up once you stop reading each regime in isolation.
| Requirement | ISO 22301:2019 | EU DORA | UK SS1/21 | APRA CPS 230 |
|---|---|---|---|---|
| Identify what must run | Critical activities (Clause 8) | Critical/important functions | Important business services | Critical operations |
| Set disruption limits | Recovery objectives (RTO/RPO) | Implicit in ICT risk tolerance | Impact tolerances | Tolerance levels |
| Map dependencies | Resources and supply chain | Critical ICT third parties | Resources and third parties | Material service provider register (para 51) |
| Test under stress | Exercise programme | Testing + TLPT (significant entities) | Severe-but-plausible scenarios | Scenario testing |
| Accountability | Top management commitment | Management body | Senior management / board | Board and senior management |
Artifacts and Decisions: The Audit-Ready Evidence Set
The crosswalk produces a defined set of artifacts: dependency maps, test reports, tolerance statements, board minutes. These are the things an examiner asks to see, regardless of which regime they enforce.
The artifacts then drive decisions: where to invest, what to remediate first, which residual risks the board explicitly accepts. The DRI professional practices frame this as a managed lifecycle rather than a one-off submission. The point of the single evidence base is that each regulator's template renders from one source, so a decision recorded once shows up everywhere it is needed.
Industry-Specific Nuance: Financial Services and Beyond
Convergence dominates, but sector specifics still shape scope. Financial services carries the densest overlap of any industry; healthcare and critical infrastructure carry their own contingency mandates. The generic mapping is a strong starting point, not a finished answer, and this section flags where it must be tailored.
Financial Services: The Densest Overlap
A multinational financial firm can sit under DORA, SS1/21, and CPS 230 at the same time. One dependency map and one tolerance set must serve all three, which is exactly the case the single-evidence-base methodology is built for. The cross-border oversight framework under DORA means a critical ICT provider used across the group draws supervisory attention from more than one direction.
The divergence points are specific and worth isolating early. TLPT obligations under DORA, material-service-provider notification timelines under CPS 230, and the precise mapping of important business services under the UK regime do not align perfectly. Treat the 90% that converges as shared, and project-manage the 10% that does not. Firms running operational resilience across financial services learn this distinction the expensive way if they leave it until audit.
Healthcare and Critical Infrastructure
US healthcare runs on a different statute. The HIPAA Security Rule sets a contingency plan standard requiring covered entities to maintain data backup, disaster recovery, and emergency-mode operation plans. The vocabulary is HIPAA's, but the underlying logic is the same convergence: identify what is critical, plan for its loss, test the plan.
The Change Healthcare ransomware attack in February 2024 made the stakes concrete. BlackCat/ALPHV gained access through a Citrix portal that lacked multi-factor authentication, exposed the health data of a significant share of the US population, and disrupted pharmacy and claims processing for weeks. A single missing control on a single concentrated service provider cascaded across the US healthcare payment system. For critical infrastructure more broadly, NIST CSF 2.0 is becoming the cyber-resilience backbone, and the convergence logic still holds: identify critical operations, test them, prove they hold.
From Compliance Event to Continuous Capability
The status quo treats compliance as a periodic scramble before each audit. The converging regimes reward the opposite. A living evidence base, updated as operations change rather than reconstructed before an examiner arrives, is the practical endpoint of everything above.
Keeping Evidence Current, Not Reconstructed
The difference between a continuous capability and an annual fire drill is whether the evidence updates when the business does. A vendor swap, a re-platformed service, a revised tolerance: each should flow into the single evidence base at the moment it happens, not get re-keyed weeks before an audit.
Reporting and dashboards earn their keep here by surfacing staleness and gaps as they appear, which is the practical mechanism behind always-on resilience. The payoff is measurable. The mean time to identify and contain a breach fell to 241 days in 2025, the lowest in nine years, and the global average breach cost dropped to $4.44 million, down 9% on 2024. Faster detection correlates with lower impact, and current evidence is what makes fast detection possible.
