DORA and UK's PS 16/24: Comparing the Two Operational Resilience Regimes

Two Frameworks, One Month, Different Philosophies

January 2025 was a historic month for operational resilience regulation. On January 1, the UK's operational resilience framework reached its final implementation deadline — institutions supervised by the FCA and PRA were required to have identified their important business services, set impact tolerances, and demonstrated that they could remain within those tolerances through severe but plausible scenarios. Seventeen days later, on January 17, DORA became applicable across the EU, bringing 22,000 financial entities under its prescriptive operational resilience requirements.

The simultaneous implementation created a unique regulatory moment: two of the world's largest financial markets, recently separated by Brexit, deploying parallel but philosophically distinct approaches to the same fundamental problem — ensuring that financial services continue to function when technology fails.

For the significant number of financial institutions operating in both jurisdictions — UK-headquartered banks with EU subsidiaries, EU banks with London branches, global investment firms with presence in both markets — the two frameworks create a dual compliance obligation that demands understanding of both their similarities and their material differences.

The Philosophical Divide

The most significant difference between DORA and the UK framework is not technical — it is philosophical.

The UK approach: outcome-based. PS 16/24 (and its predecessor framework) asks institutions to define what matters most to their customers and the market (important business services), determine how much disruption is tolerable (impact tolerances), and demonstrate they can stay within those tolerances. The "how" is largely left to the institution. The regulator cares about the outcome — can you deliver your important business services within tolerance? — not the specific processes, controls, or technologies you use to achieve that outcome.

The DORA approach: requirement-based. DORA prescribes specific obligations across five pillars: what your ICT risk management framework must contain (Art. 5-16), how you must classify and report incidents (Art. 17-23), what your testing programme must include (Art. 24-27), what your third-party contracts must specify (Art. 28-44), and how you should share threat intelligence (Art. 45-49). The "what" is largely defined by the regulation. Compliance is assessed against specific requirements, not outcomes.

This philosophical divide produces practically different compliance experiences. Under the UK framework, an institution that has never experienced a major incident and can demonstrate through testing that it remains within impact tolerances has strong evidence of compliance — regardless of how simple or sophisticated its underlying controls are. Under DORA, the same institution must demonstrate compliance with specific requirements even if its track record is perfect — because DORA measures process, not just outcomes.

The Comprehensive Comparison

Where the Frameworks Converge

Despite their philosophical differences, DORA and the UK framework share significant common ground:

Board-level responsibility. Both frameworks place operational resilience governance squarely on the management body/board. DORA Art. 5 requires board approval of the ICT risk management framework. The UK framework requires the board to set impact tolerances and ensure adequate resilience. In both cases, operational resilience is not delegated to the technology department.

Testing as validation. Both frameworks require institutions to test their resilience — not just document it. DORA Art. 24-27 prescribe formal testing programmes. The UK framework requires scenario testing against impact tolerances. The emphasis on demonstrated capability over documented intent is shared.

Third-party risk awareness. Both frameworks recognize that institutional resilience depends on the resilience of technology providers. DORA addresses this through the comprehensive Pillar IV framework. The UK framework addresses it through the Critical Third Party regime (which operates under separate legislation) and through the expectation that impact tolerance testing includes third-party failure scenarios.

Incident management. Both frameworks require structured incident management. DORA prescribes specific classification criteria and reporting timelines. The UK framework relies on existing reporting obligations while expecting institutions to learn from incidents and update their resilience arrangements.

Where the Frameworks Diverge

The practical divergences create the dual compliance challenge:

Important Business Services vs. Critical Functions

The UK framework centers on "important business services" — services provided to clients or market participants whose disruption would cause intolerable harm. These are identified by the institution, subject to regulatory challenge.

DORA uses "critical or important functions" (Art. 3(22)) as a key concept but does not structure its entire framework around them. DORA's requirements apply broadly to the institution's ICT risk management, not just to critical functions.

Dual compliance implication: Institutions must maintain both an important business service mapping (UK) and a comprehensive ICT asset and critical function register (DORA). The mappings overlap but are not identical.

Impact Tolerances vs. Prescriptive Requirements

The UK's impact tolerance concept has no direct DORA equivalent. Under the UK framework, an institution sets a maximum tolerable disruption for each important business service (e.g., "payment processing must not be disrupted for more than 4 hours"). Compliance is assessed against this self-set standard.

DORA does not ask institutions to set impact tolerances. It prescribes what the ICT risk management framework must contain, what testing must cover, what contracts must include, and how incidents must be reported. Compliance is assessed against these prescribed requirements.

Dual compliance implication: For UK entities, the impact tolerance testing programme can be designed to also produce evidence relevant to DORA's testing requirements (Art. 24-27). The scenario testing that validates impact tolerances can simultaneously validate BCP effectiveness (Art. 11) and recovery capabilities (Art. 12).

The Register of Information

DORA's Register of Information (Art. 28(3)) has no UK equivalent. The UK's Critical Third Party regime requires firms to manage third-party risk, but does not mandate a standardized register submission to supervisors in the EBA's prescribed format.

Dual compliance implication: Institutions must maintain the Register for their EU entities. The data collected for the Register (third-party relationships, criticality classifications, sub-outsourcing chains) is useful for UK compliance as well — even without a formal UK submission requirement.

Incident Reporting Timelines

DORA Art. 19 prescribes specific timelines: 4-hour initial notification, 72-hour intermediate report, one-month final report. The UK framework relies on existing reporting obligations, which vary by entity type and do not specify equivalent timelines for operational resilience incidents specifically.

Dual compliance implication: An incident affecting both EU and UK operations triggers different reporting obligations. The DORA timeline (4 hours) is the binding constraint — institutions that can meet DORA's timeline will necessarily satisfy UK reporting expectations.

The Unified Compliance Framework

For institutions operating in both jurisdictions, the most efficient approach treats the two frameworks as complementary rather than duplicative:

Step 1: Unified Service and Function Mapping

Maintain a single mapping that identifies:

• Important business services (UK definition)
• Critical or important functions (DORA Art. 3(22))
• ICT assets supporting both (Art. 8)
• Third-party dependencies for both

This unified mapping serves both the UK's impact tolerance framework and DORA's ICT risk management requirements.

Step 2: Impact Tolerance + RTO/RPO Integration

For each important business service / critical function:

• Set UK impact tolerances (maximum tolerable disruption)
• Set DORA RTO and RPO targets (Art. 11-12)
• Align the targets: the more stringent of the two becomes the design target

Step 3: Unified Testing Programme

Design testing programmes that simultaneously validate:

• UK: Can the institution remain within impact tolerances during severe scenarios?
• DORA Art. 24-27: Does the testing programme cover all required domains?
• DORA Art. 26: For TLPT-designated entities, does the programme include threat-led penetration testing?

A single testing exercise can produce evidence relevant to both frameworks if the test design explicitly addresses both sets of requirements.

Step 4: Unified Third-Party Risk Management

Maintain a single third-party risk management programme that satisfies:

• DORA Art. 28-30: Register of Information, contractual provisions, exit strategies
• UK: Third-party risk management as part of operational resilience

The Register data serves both jurisdictions. Contract renegotiation for Art. 30 compliance benefits UK operations as well, even without a legal mandate.

Step 5: Unified Governance and Reporting

Board reporting should address both frameworks in a single reporting structure:

• Operational resilience posture (both jurisdictions)
• ICT risk framework review (DORA Art. 14)
• Impact tolerance compliance (UK)
• Incident summary and trend analysis
• Third-party risk and concentration

The Competitive Dimension

The coexistence of two operational resilience frameworks creates competitive dynamics:

EU institutions entering the UK market must adapt from DORA's prescriptive approach to the UK's outcome-based approach. This is generally easier — prescriptive compliance discipline translates well to outcome achievement.

UK institutions entering the EU market must build prescriptive compliance capabilities on top of their outcome-based approach. This requires additional documentation, formal processes, and register maintenance that the UK framework does not demand.

Cross-border institutions that master both frameworks develop operational resilience capabilities that exceed what either framework alone requires — creating a competitive advantage in both markets.

Looking Forward: Convergence or Continued Divergence?

The long-term question is whether these two frameworks will converge or continue to diverge. Several factors favor convergence:

• Both frameworks respond to the same underlying risk: financial sector ICT dependency
• Both learned from the same events: CrowdStrike, cloud outages, ransomware campaigns
• International standard-setting bodies (Basel Committee, FSB) influence both
• Financial institutions operating in both markets will advocate for harmonization

But structural factors maintain divergence: Brexit politics, different regulatory philosophies (principles-based UK vs. prescriptive EU), and the institutional momentum of established frameworks all resist convergence.

For the foreseeable future, dual compliance is the reality. The institutions that accept this reality and build unified compliance frameworks — rather than maintaining parallel programmes — will operate more efficiently and with greater actual resilience than those that treat each framework as an isolated obligation.

---

This analysis reflects DORA Regulation (EU) 2022/2554 and the UK's operational resilience framework (PS 16/24, SS 1/21, SS 2/21) as applicable from January 2025.

---