DORA became effective on 17 January 2025. For most UK-headquartered financial services firms, the response followed a familiar pattern: a scoping exercise to assess applicability, a gap analysis, a compliance workstream, and a board paper confirming the firm's position.
The problem with that sequence is the assumption embedded in it. Many UK firms concluded, after the scoping exercise, that DORA either did not apply to them or applied only to a narrow subset of their operations. Some of those conclusions were correct. A significant number were not, and the firms that reached the wrong conclusion are now carrying residual DORA exposure that their compliance programmes did not close.
This article addresses the three areas where UK financial services firms most commonly have unresolved DORA obligations in 2026: applicability assessment at the entity level, ICT third-party risk management and exit testing, and the interaction between DORA and the existing FCA and PRA frameworks. It is written for COOs, CTOs, and Heads of Operational Resilience at banking, insurance, and investment management firms with any EU operational footprint.
The Most Common Applicability Mistake
DORA is an EU regulation. It applies to financial entities authorised or registered in EU member states. A UK-domiciled firm regulated only by the FCA and PRA is not, by that fact alone, a DORA-obligated entity.
The mistake most commonly made by UK firms is stopping the analysis there.
DORA's applicability follows the entity, not the group. A UK-headquartered banking group with a subsidiary authorised in an EU member state has a DORA-obligated entity within the group, regardless of where the parent is domiciled. The obligations fall on the EU-regulated entity. But the ICT infrastructure, ICT third-party arrangements, and ICT risk management frameworks that the EU entity relies on are frequently shared with, or managed by, the UK parent. The gap between where the obligation sits and where the infrastructure actually lives is the source of most unresolved DORA exposure at mid-tier firms.
The same logic applies to investment managers with EU-authorised fund structures, to insurers with EU-regulated branches or subsidiaries, and to any firm that provides material ICT services to, or receives them from, an entity that is itself DORA-obligated. In each case, the entity-level analysis may have confirmed limited direct obligation, while the operational and contractual reality creates a de facto compliance requirement that was not fully mapped.
The practical test is not whether the UK parent is DORA-regulated. It is whether any entity in the group or corporate structure is DORA-regulated, and whether the ICT arrangements supporting that entity are documented, managed, and evidenced to the DORA standard. For a significant number of mid-tier UK firms, the honest answer to that second question is no.
The Five DORA Pillars: Where UK Firms Are Most Exposed
DORA establishes obligations across five areas. For UK firms with in-scope entities, the areas of most common unresolved exposure are concentrated in three of the five.
ICT risk management framework. DORA requires in-scope entities to maintain a comprehensive ICT risk management framework that meets the technical standards specified in DORA's implementing regulations. This is not a generalised requirement to manage technology risk. It requires a documented framework covering ICT asset identification, protection, detection, response, and recovery, supported by specific policies and tested against the DORA technical standard. Many UK firms completed a DORA gap assessment in 2024 that identified the framework requirement but deferred the build. In 2026, the gap remains open at a significant number of firms, and the EU competent authorities that regulate the in-scope entity are the supervisors who will examine it.
ICT third-party risk management and Article 28 exit obligations. This is the area of deepest and most consistent exposure at mid-tier firms. DORA Article 28 requires in-scope financial entities to maintain formal contractual arrangements with all ICT third-party service providers whose services support critical or important functions. The contractual requirements include defined service levels, audit rights, subcontracting notifications, data portability provisions, and exit strategy obligations with adequate transition periods. For each ICT third-party arrangement supporting a critical or important function, exit strategies must be documented and tested where dependency, complexity, or substitutability risk is elevated.
The most common gap is not the absence of contracts. It is the absence of contracts that meet the DORA standard. Arrangements that predate DORA, or that were assessed as compliant in a 2024 review but not subsequently updated, frequently do not contain the specific provisions Article 28 requires. The re-papering exercise required to bring legacy contracts into compliance is substantial, and for firms with significant ICT supply chains it requires structured programme management rather than an ad-hoc contract review.
Operational resilience testing. DORA requires in-scope entities to conduct digital operational resilience testing on a defined basis, including threat-led penetration testing for entities designated as significant. Basic resilience testing, covering ICT systems supporting critical or important functions, is a general requirement. The testing standard under DORA is distinct from the PRA scenario testing obligations under SS1/21 and is not automatically satisfied by a firm's existing operational resilience testing programme. The integration of DORA-required testing with the existing SS1/21 testing cycle is something most firms have not yet resolved, and maintaining two parallel programmes creates both cost and complexity.
The incident reporting obligation and the information sharing arrangements under DORA's fifth pillar create compliance requirements that are generally better understood and more commonly addressed. They are noted here for completeness but are less frequently the source of unresolved exposure at mid-tier firms.
How DORA Interacts with FCA and PRA Obligations
For UK firms with in-scope entities, DORA does not replace the FCA and PRA frameworks. It sits alongside them, creating overlapping obligations that are frequently similar in intent but different in specific requirement.
The ICT risk management framework obligation under DORA is broadly aligned with the technology resilience expectations of PRA SS2/21 for banking entities. But the DORA technical standards are more prescriptive than the PRA's principles-based approach, and the documentation required to demonstrate DORA compliance is more granular than what PRA SS2/21 typically demands. A firm whose technology resilience programme was designed around SS2/21 will have covered significant ground relevant to DORA but will not, in most cases, have covered all of it.
The third-party risk management obligations overlap substantially between DORA Article 28 and PRA SS2/21's exit planning requirements. Both require exit strategies, both require testing, and both apply to material or critical third-party arrangements. But the contractual specificity required under DORA, particularly the enumerated provisions that must be present in ICT service contracts, goes beyond the more general obligation to maintain exit plans that PRA SS2/21 creates. A firm that has met the PRA standard for exit planning has done much of the DORA work but has not necessarily done all of it.
The practical implication is that firms should not assume their PRA compliance programme satisfies DORA, and should not assume their DORA programme satisfies PRA requirements. The overlap is real and significant, and building a single integrated programme that addresses both frameworks coherently is materially more efficient than maintaining parallel programmes. The firms that have managed this most effectively are those that mapped both frameworks side by side before building, identified where requirements converge and where they diverge, and designed their programme architecture to address both without duplication.
The Sector-Specific Exposure Profile
The exposure pattern differs meaningfully by sector, and the prioritisation of remediation work should reflect that.
For challenger banks and specialist lenders with EU operations, the primary exposure is ICT third-party risk management, specifically the contract re-papering requirement for legacy arrangements with core banking platform providers, cloud infrastructure suppliers, and payment processing partners. These arrangements are frequently business-critical, involve complex commercial relationships, and have contracts that predate DORA's contractual requirements by several years. The negotiating leverage to re-paper them is often limited, and the timeline to achieve full contractual compliance is longer than firms initially estimate.
For insurers with EU-regulated entities, the primary exposure varies by group structure. Insurers with standalone EU subsidiaries carrying their own ICT infrastructure face the full DORA framework obligation at the entity level. Insurers where the EU entity relies on shared group ICT services face a more complex position: the intragroup ICT arrangement itself may be subject to DORA's third-party oversight requirements, and the contractual and oversight structures that govern intragroup services are rarely designed to the DORA standard.
For investment managers with EU-authorised fund structures, the exposure is frequently underestimated because the fund management entity itself may have limited direct ICT infrastructure. The more relevant question is whether the fund administrator, transfer agent, or other service provider supporting the EU-authorised entity is subject to DORA oversight obligations from the entity's perspective, and whether the contractual and exit planning arrangements in place meet the Article 28 standard.
What an Unresolved DORA Position Looks Like in Practice
The risk for firms with unresolved DORA exposure is not primarily the risk of immediate regulatory action by EU competent authorities against a UK parent. The risk is more subtle and more immediate.
The EU-regulated entity carries the direct DORA obligation. Its competent authority, the national regulator in the EU member state where it is authorised, is the body that will supervise its DORA compliance. When that supervisor examines the entity's ICT risk management framework, its third-party contracts, and its exit testing evidence, the deficiencies that trace back to the group's ICT architecture and contract management will become visible. The remediation that follows will require the UK parent to restructure arrangements it may not have treated as a DORA priority.
The indirect risk is to the UK parent's own regulatory relationships. The PRA and FCA are aware of DORA's implications for UK groups with EU entities. A group-level resilience programme that demonstrates coherent management of DORA obligations alongside PRA and FCA requirements is a more credible programme in a UK supervisory context than one that treats DORA as an EU subsidiary concern.
The Practical First Step
For firms that are uncertain about their current DORA position, the most useful starting point is a structured applicability and gap assessment: confirming entity-level obligations, mapping ICT third-party arrangements against Article 28 requirements, identifying the gap between current contractual provisions and the DORA standard, and producing a prioritised remediation roadmap.
FourthLine has delivered DORA applicability assessments and ICT third-party risk management programmes for banking and insurance clients. Our Diagnostic Assessment covers DORA obligations alongside FCA SYSC 15A and PRA SS2/21 requirements within a single engagement, producing a regulatory traceability matrix that identifies where the three frameworks align and where each creates distinct obligations. For firms where ICT third-party contract re-papering is the priority workstream, our Supplier Exit Testing Managed Service includes DORA Article 28 contractual compliance as a defined programme element.