Summarise the article with your AI
Here you can read:
The Digital Operational Resilience Act (DORA) which is an EU Regulation that came into force in 2025, ensures that banks, insurance companies, investment firms and other financial entities can withstand, respond to, and recover from ICT disruptions, such as cyberattacks or system failures. But what may surprise many UK CFOs is that although the UK is no longer part of the EU, the DORA regulation has significant extraterritorial reach. UK firms may fall within scope if they have EU subsidiaries, operate EU branches, or provide ICT services to EU-regulated financial entities.
Who is impacted? Cross-border implications for UK firms
The extraterritorial scope of DORA, as an EU regulation, means geography offers limited protection. The DORA regulation applies to financial entities and ICT service providers operating within the EU, as well as the ICT infrastructure supporting them from outside the EU. This creates a web of compliance obligations that UK firms have to deal with if they engage with any of those overseas regulated companies in a business context.
UK entities need to determine if they fall in scope of DORA, based on the broad range of financial markets activities included and whether those take place within EU jurisdictions.
The critical question is not "Are we an EU firm?" but rather "Do we serve EU clients, operate through EU subsidiaries, or provide services that touch the EU financial sector?"
The risk extends beyond obvious cross-border operations. If an intra-group company provides IT services to EU operations, that entity is also in scope, bringing the entire ecosystem of financial service providers to the same level of operational resilience. A UK parent company providing cloud infrastructure to its Madrid subsidiary suddenly finds itself subject to a Brussels-conceived regulation.
The risk of intra-group outsourced services
One of the most frequently overlooked aspects of DORA is its treatment of intra-group ICT arrangements. Many UK-headquartered financial groups assume that internal IT shared services or group technology functions fall outside regulatory scrutiny. This assumption is incorrect.
Under DORA, undertakings that are part of a financial group and provide ICT services predominantly to their parent undertaking, subsidiaries, or branches are considered ICT third-party service providers. This means a UK-based group IT function providing services to an EU-regulated subsidiary must be documented, assessed, and managed under DORA's third-party risk framework.
The practical implications are significant:
- Contracts must be formalised between the UK parent and EU subsidiary for ICT services, even if historically treated as internal arrangements
- The EU subsidiary must conduct due diligence on its UK parent's ICT resilience
- Exit strategies and business continuity provisions must be documented, even for intragroup relationships
- The Register of Information submitted to EU supervisors must include intragroup ICT arrangements
Financial entities must assess whether intragroup ICT services support critical or important functions. If they do, the more stringent contractual and oversight requirements of DORA apply, regardless of the corporate relationship between the entities.
Dual regulatory compliance: DORA vs FCA and PRA rules
For UK treasury teams already navigating domestic operational resilience requirements, DORA presents a complex dual compliance challenge. The message is blunt: DORA addresses many topics that already apply to financial services firms operating in the EU and the United Kingdom, while being more prescriptive around ICT and cyber resilience than current UK operational resilience regulation.
The UK framework, built around important business services and impact tolerances, focuses on outcomes. DORA, by contrast, is prescriptive and controls-focused. DORA adds a more detailed, uniform blueprint: how to structure ICT risk frameworks, how to classify incidents, how to test resilience, and how to manage critical third parties.
Comparison: UK Operational Resilience vs DORA
| Aspect | UK FCA/PRA Framework | EU DORA |
| Focus | Outcomes-based (impact tolerances) | Prescriptive controls and processes |
| Key concept | Important business services | Critical or important functions |
| Third-party oversight | Firm remains responsible | Direct ESA oversight of Critical Third-party providers (CTPPs) |
| Testing requirement | Scenario testing within impact tolerance | Mandatory Threat-led penetration testing (TLPT) for significant entities |
| Incident reporting | Thresholds under consultation | 4-hour initial notification, 72-hour intermediate |
| Compliance deadline | 31 March 2025 (full compliance) | Phased implementation throughout 2025 (varies by member state and entity type) |
This divergence creates friction. UK firms with EU operations cannot simply map their FCA compliance onto DORA requirements. Even for those entities that are familiar with financial markets resilience regulation, certain capabilities such as more detailed operational resilience testing around ICT (particularly threat-led penetration testing) and threat intelligence sharing require attention.
Yet there is common ground. Both regimes demand robust governance, comprehensive testing programmes, and incident management capabilities. Smart organisations are capitalising this overlap, building unified resilience strategies that satisfy both regulators without duplicating effort.
The 5 Core Pillars of the DORA Regulation
DORA's architecture rests on five interconnected pillars that together create a comprehensive framework for digital operational resilience.
1. ICT risk management and personal liability
The five key topics at the centre of DORA are: ICT Risk Management; ICT-related Incident Management, Classification & Reporting; Digital Operational Resilience Testing; ICT Third Party Risk Management; and Information Sharing Arrangements. The first pillar establishes the foundation: financial entities must implement sound, comprehensive ICT risk management frameworks with clear governance and control measures.
What makes this requirement particularly consequential is the personal accountability it creates. Management bodies must define, approve, oversee, and be responsible for all relevant arrangements. This responsibility cannot be delegated.
2. Third-party risk management (TPRM) and Critical Third-Party Providers (CTPPs)
For UK firms, this is the pillar that changes everything. Given the strong focus on third party risk management, entities are expected to satisfy themselves of a third party's resilience, which will require close interaction and joint efforts with their critical ICT third-party service providers.
DORA establishes an EU-wide oversight framework for critical ICT third-party providers to ensure that the financial sector remains secure and resilient against ICT disruptions, meaning that reporting on cyber incidents will be streamlined and third-party risk supervised. The European Supervisory Authorities (ESA) now have direct oversight powers over designated Critical Third-Party Providers, creating a new regulatory layer that bypasses traditional financial institution intermediaries.
3. Major ICT-related incident reporting
Under DORA, firms must detect, classify, and report major ICT incidents quickly. The incident reporting requirements specify strict timelines:
- Initial notification: Within 4 hours of classifying an incident as major (and no later than 24 hours from detection).
- Intermediate report: Within 72 hours.
- Final report: Within one month.
For UK institutions, this means integrating DORA's reporting obligations with existing FCA operational resilience rules, creating dual reporting streams with different timelines and formats.
4. Threat-led penetration testing (TLPT)
DORA requires a risk-based programme that can include vulnerability assessments, advanced security testing, scenario-based exercises, and for some entities, threat-led penetration testing (TLPT), with the goal to simulate realistic attacks and disruption, then remediating the findings. UK firms already involved in CBEST or TIBER-UK have a strong head start, with the next step being aligning scope, documentation, and follow-up with DORA's expectations so one testing programme satisfies both regimes.
5. Information sharing and threat intelligence
DORA actively encourages financial entities to exchange cyber threat intelligence, indicators of compromise, and cybersecurity alerts. This represents a cultural shift for an industry historically reluctant to share information about security incidents. While not mandatory, participation in information-sharing arrangements should be notified to competent authorities, and such collaboration can enhance the sector's collective ability to detect and respond to emerging threats.
Your DORA compliance checklist
Step 1: Conduct a DORA gap analysis
Regardless of where your entity is in terms of the maturity of digital and operational resilience, DORA should serve as the catalyst for aligning other programmes the organisation has running (such as Operational Resilience, Third Party Risk Management, Technology Risk Remediation, Cloud Transformation and Cyber Transformation), and identifying what the additional requirements to be addressed are through an initial gap analysis and maturity assessment.
Step 2: Secure supply chain resilience and vendor due diligence
The treasury technology stack suddenly becomes a compliance liability. Legacy systems, bespoke Excel macros, on-premise servers maintained by a single vendor, these are the hidden operational risks that DORA brings into sharp relief.
DORA requires that contractual obligations be inserted into contracts of financial entities for procuring ICT services and products, applying to existing in-scope contracts, which will need to be collated, reviewed and amended to ensure compliance. This is not a minor administrative exercise. It means renegotiating terms with every significant technology provider, embedding audit rights, exit strategies, and subcontracting provisions into agreements.
Partnering with secure financial technology
Back to our compliance officer. She's identified the core issue: the treasury function relies on ageing infrastructure and point solutions cobbled together over decades. Each connection is a potential point of failure. Each vendor relationship is an audit exposure. Each manual process is a compliance gap.
The solution emerges not from regulatory gymnastics but from operational modernisation. Moving treasury operations to a cloud-native treasury management platform built with security and resilience at its core addresses DORA requirements not through compliance theatre but through sound architectural design.
UK entities will need to act quickly to determine if they fall in scope of DORA. But beyond mere compliance, forward-thinking treasury teams recognise DORA as the catalyst for transformation they needed. Replacing obsolete legacy systems with robust cloud platforms does not simply tick regulatory boxes—it reduces operational risk, improves efficiency, and positions treasury as a strategic function rather than a compliance burden. The automation of the finance department is no longer a "nice to have"; it is becoming a regulatory expectation.
Having a Treasury Management System (TMS) is crucial since they are designed from inception for the post-DORA regulatory landscape, offer ISO 27001:2022 certification, AES-256 encryption at rest and TLS encryption in transit, real-time bank connectivity via secure Open Banking protocols, and comprehensive audit trails. These are not bolt-on compliance features but fundamental design principles.
This article is for informational purposes only and does not constitute legal, regulatory, or compliance advice. Firms should consult with qualified legal and compliance professionals regarding their specific DORA obligations. This article has been prepared using sources from EIOPA, the European Banking Authority, the FCA, and Embat security documentation.
