DORA, NIS2 and the UK Regime: One Control Set, Three Rulebooks

A group with EU and UK operations, in-scope entities under both DORA and NIS2, and a UK bank subject to the operational resilience rules, is subject to three regimes that regulate substantially the same risk with substantially different vocabulary. Treating them as three programmes is the default outcome and the wrong one.

The Three Regimes at a Glance

The Concepts That Do Not Map

Three genuine differences drive most of the duplicated effort.

Impact tolerance versus critical or important function. The UK regime asks firms to identify important business services and set a maximum tolerable level of disruption for each — a quantified outer limit, expressed in time or another metric, that the firm must remain within in severe but plausible scenarios. DORA has no direct equivalent. It asks which functions are critical or important and then scales obligations accordingly.

These are complementary rather than conflicting. A firm can identify one set of business services, tag each with both its UK importance determination and its DORA criticality determination, and set impact tolerances that inform DORA recovery objectives. What does not work is maintaining two service inventories with different names for the same processes — which is exactly what happens when the UK and EU programmes report to different executives.

Reporting recipients and clocks. DORA reports go to the financial competent authority on the initial-intermediate-final sequence. NIS2 reporting runs to the CSIRT or competent authority with an early warning followed by a fuller notification. UK notification runs to the PRA or FCA under their own rules. An incident affecting a dual-regulated group can trigger all three with different deadlines and different content.

This is the single highest-value integration point. Build one incident record with a jurisdictional routing layer: one classification exercise, one set of facts, three outbound templates populated from the same source. Firms that maintain separate incident processes per regime produce inconsistent accounts of the same incident to different supervisors, which is a materially worse outcome than a late report.

Third-party depth. DORA is the most prescriptive of the three on contracts and the only one with a union-level provider oversight regime. If a group builds its third-party control set to DORA's standard, it will generally satisfy the other two. Building to the lowest common denominator and uplifting for DORA is the more expensive path.

The Practical Architecture

One control set, mapped three ways:

1. One service inventory. Business services identified once, with regime-specific tags: DORA criticality, UK importance, NIS2 essentiality. 2. One control library. Controls stated once, each mapped to the articles or rules it satisfies in each regime. When a control changes, the mapping shows every regime affected. 3. One third-party register. Built to DORA's data model — the most demanding — with flags for the other regimes' scope. 4. One incident process. Single classification, jurisdictional routing, templated outputs. 5. One testing programme. Scenarios designed against services, with test coverage reported against each regime's requirement. 6. Regime-specific reporting layers only. The only thing that should be duplicated is the output format.

The governance implication is that operational resilience needs a single accountable executive across the group. Where the EU and UK programmes report separately, the inventories diverge within a year regardless of how good the initial mapping was.

Where Integration Fails

Integration usually breaks at the boundary between the second line and the local entity. A group control set is designed centrally, and each in-scope legal entity's management body is required to approve and oversee its own framework. If local boards receive the group pack without local application, DORA's governance obligation — set out in the ICT risk framework article — is not met, however good the group design is.

The fix is cheap: an entity-level annex to the group framework, approved locally, recording which services, providers and functions apply to that entity and what the local board challenged.

Key Takeaways

• Build the third-party control set to DORA's standard; it is the most demanding and generally satisfies NIS2 and the UK rules.

• Maintain one service inventory with regime tags rather than parallel inventories per regime.

• The incident process is the highest-value integration point — inconsistent accounts to different supervisors are worse than a late report.

• UK impact tolerances and DORA criticality are complementary; use tolerances to inform recovery objectives.

• Group frameworks still require entity-level board approval and locally recorded challenge.

Frequently Asked Questions

Can a financial entity in scope of DORA also be in scope of NIS2? DORA operates as the sector-specific regime for financial entities on ICT risk, but group companies outside the financial perimeter — a shared services entity, a technology subsidiary — can fall within NIS2 in their own right. Scope must be assessed entity by entity.

Does UK operational resilience require a register of information? Not in DORA's prescribed format. UK rules require identification and management of outsourcing and third-party risk, and firms with EU operations generally find it cheaper to run the DORA register group-wide than to maintain two datasets.

Which regime should drive the group operating model? DORA, in most cases, on the principle of building to the most prescriptive standard once. The exception is impact tolerance setting, which is a UK innovation worth adopting group-wide because it forces a quantified answer where DORA accepts a qualitative one.

About the author

Jonas Mohamed Osman Abdelghafour is a risk and compliance expert advising banks, insurers, payment institutions and asset managers on operational resilience, ICT and third-party risk, financial crime and enterprise governance across EU and UK regimes. He works at the point where digital operational resilience obligations meet the evidence a board and a supervisor actually ask for. See qualifications and services, or get in touch to discuss an engagement.

*This article discusses regulatory frameworks in general terms and is not legal advice. Jurisdictional interpretation should be confirmed with qualified counsel.*