DORA, the EU's Digital Operational Resilience Act, applied from 17 January 2025 across EU financial entities in scope. The regulation applies to banks, investment firms, insurance companies, crypto-asset service providers, trading venues, and a range of other financial entity types authorised or licensed in the EU. It also creates obligations for ICT third-party service providers that are designated as critical by the European Supervisory Authorities.
DORA does not apply to UK firms on the basis of their UK authorisation. A firm that is authorised only by the FCA or PRA and provides services only in the UK is not subject to DORA. The compliance question for UK firms arises when they have EU-facing operations: an EU-licensed subsidiary, a branch in an EU member state, or ICT services provided to EU-regulated entities. In those cases, the EU-regulated entity or the ICT service provider designation may bring DORA obligations directly into scope.
This article covers the five main DORA pillars, their practical requirements for EU-regulated financial entities, and the three scenarios in which UK firms most commonly need to assess and address DORA compliance.
Pillar 1: ICT Risk Management Framework
DORA's ICT Risk Management requirements are set out in Articles 5 to 16 of the regulation, with detailed requirements in the EBA's regulatory technical standards under EBA/RTS/2024/07. Financial entities must maintain a documented ICT Risk Management Framework that identifies, classifies, and addresses ICT risks across the full technology stack. The framework must be reviewed at least annually, more frequently when the ICT risk profile changes materially.
The ICT Risk Management Framework under DORA is more prescriptive than the general operational risk requirements under existing frameworks like the FCA's SYSC rules. It must specifically address ICT asset management (maintaining a full register of ICT assets and dependencies), cyber security controls, information security policy, access and identity management, and cryptographic controls. The EBA's RTS specifies minimum content requirements for each component.
For EU-licensed subsidiaries of UK groups, a question that arises in practice is whether the group's existing ICT risk framework satisfies DORA's requirements for the EU subsidiary. The answer depends on the substance of the group framework, not its label. A group ICT risk framework that was designed around SYSC or ISO 27001 requirements may satisfy many DORA requirements by content, but may lack the specific DORA-mandated components. A gap assessment against the EBA/RTS/2024/07 minimum requirements is the starting point.
Pillar 2: ICT-Related Incident Management and Reporting
DORA introduces mandatory reporting requirements for major ICT-related incidents to competent authorities. Commission Delegated Regulation (EU) 2024/1772 sets out the classification criteria for major incidents and the reporting timeline. The timeline has three stages: an initial notification within 4 hours of the incident being classified as major, an intermediate report within 72 hours providing a preliminary root cause analysis, and a final report within 1 month providing full impact assessment and remediation steps.
The incident classification criteria distinguish between incidents based on their impact on services, the duration of service disruption, the geographic spread of impact, and the potential reputational effect. Not every ICT incident is a major incident requiring regulatory reporting. The classification process itself must be documented and consistently applied. Competent authorities have discretion to request additional information beyond the minimum reporting content, and this discretion is exercised regularly in practice.
UK firms whose EU subsidiaries experience ICT incidents face a dual reporting question: the EU subsidiary must report to its EU competent authority under DORA, and the UK parent may have independent reporting obligations to the FCA or PRA under existing operational resilience rules. The two processes are not aligned in detail, and a group incident management policy that does not distinguish between the DORA reporting requirements and the UK reporting requirements may produce either under-reporting to the EU competent authority or over-reporting that creates confusion about the scope of the incident.
Pillar 3: Digital Operational Resilience Testing
DORA requires financial entities to conduct regular testing of their ICT systems and security. For all entities in scope, this includes basic digital operational resilience testing at minimum annually. For significant institutions (those meeting the size and systemic importance thresholds set by the ESAs), DORA requires advanced testing in the form of Threat-Led Penetration Testing (TLPT), which must be conducted at least every three years.
The TLPT requirement under DORA is modelled on the TIBER-EU framework that the ECB and some national competent authorities have been running for major European banks. TIBER-EU (Threat Intelligence-Based Ethical Red-teaming) involves intelligence-led red team testing of critical production systems by approved external testers, with a structured process including threat intelligence gathering, red team execution, and blue team response assessment. DORA's Article 26 mandates TLPT for significant institutions and requires the testing to be conducted by approved external testers following the TIBER-EU framework or an equivalent national framework.
For UK subsidiaries in scope of DORA's significant institution thresholds, TLPT is a new compliance obligation that has no direct equivalent in the current UK FCA/PRA operational resilience framework. The PRA's supervisory expectations on operational resilience (SS1/21) require firms to test their ability to remain within impact tolerances, but do not mandate TIBER-EU-style penetration testing. A UK group whose EU subsidiary is subject to the TLPT requirement needs to assess whether the group's existing penetration testing programme meets the DORA standard or whether separate TLPT exercises are required for the EU subsidiary.
Pillar 4: ICT Third-Party Risk Management
DORA's third-party risk management requirements under Article 28 are among the most operationally complex aspects of the regulation. Financial entities must maintain a complete register of all ICT third-party service providers, classify providers by their criticality to the entity's operations, and conduct due diligence proportionate to that criticality. Contracts with ICT third-party service providers must include specific minimum terms set out in Article 30 of DORA, including provisions on service levels, audit rights, incident reporting, business continuity, and termination rights.
The contract content requirements in Article 30 are not entirely new: the FCA's and PRA's existing outsourcing rules under SYSC and SS2/21 require similar provisions in outsourcing contracts. But DORA applies to all ICT third-party service providers, not only those providing outsourced functions. Software vendors, cloud providers, data analytics providers, and network service providers all fall within scope if they support the financial entity's ICT functions. The contract review and amendment exercise this implies for EU-licensed subsidiaries with large third-party supplier bases is a significant project.
The ESAs are also designating the largest and most systemic ICT third-party service providers as Critical ICT Third-Party Service Providers (CTPPs). Designated CTPPs are subject to direct oversight by the lead overseer (EBA, ESMA, or EIOPA depending on the CTPP's primary service sector). Financial entities that use a CTPP must cooperate with the oversight process, which includes providing information to the lead overseer about the nature and extent of their use of the CTPP's services.
Pillar 5: Information and Intelligence Sharing
DORA's Article 45 creates a voluntary framework for financial entities to share cyber threat information and intelligence. The voluntary sharing framework operates through arrangements established between financial entities and competent authorities, and the ESAs have developed technical standards for the sharing protocols. Participation is voluntary; the benefit to participants is access to aggregated threat intelligence that improves their own monitoring and response capabilities.
The information sharing pillar is the least operationally burdensome of the five DORA pillars for most financial entities. It is nonetheless worth noting because the intelligence shared through the framework is likely to be more relevant and actionable than generic public cyber threat reports. For EU-licensed subsidiaries of UK groups, participation in the information sharing framework is an operational resilience benefit that is available at relatively low cost.
Three UK-Linkage Scenarios
UK firms most commonly encounter DORA compliance obligations in three scenarios. The first is where the UK group has an EU-licensed subsidiary that is directly in scope of DORA. The subsidiary must comply with DORA's ICT risk management, incident reporting, resilience testing, third-party management, and information sharing requirements. Where the group's shared services team provides ICT infrastructure to the EU subsidiary, those shared services are subject to Article 28 scrutiny from the EU subsidiary's perspective.
The second scenario is where the UK firm is an ICT service provider to EU-regulated financial entities. If the UK firm provides cloud services, data analytics, software, or other ICT services to EU-regulated clients, those clients must manage the UK firm as an ICT third-party service provider under Article 28. The UK firm will receive contractual requirements from its EU-regulated clients that reflect Article 30, including audit rights, incident notification obligations, and service level commitments. These are contractual obligations on the UK firm driven by its clients' DORA compliance, even though the UK firm is not itself directly regulated by DORA.
The third scenario is where the UK firm provides financial services to EU customers in a context that overlaps with DORA's operational resilience expectations. This scenario is the most indirect of the three. The UK firm is not subject to DORA directly, but EU customers may include DORA operational resilience standards in their vendor assessment criteria, and UK firms that cannot demonstrate DORA-equivalent resilience may find their EU business development constrained.
Ongoing Monitoring: DORA Is Not Static
We are not saying that DORA compliance is a one-time project with a completion date. The regulatory technical standards underpinning DORA are being finalised on a rolling basis across the five pillars. The ESAs are publishing Q&As, supervisory guidance, and CTPP designation decisions that continue to refine how DORA applies in practice. A compliance function that completed a DORA gap assessment in early 2025 and has not reviewed its conclusions since may be working with an incomplete picture of the current requirements.
Kalipso monitors ESA publications, including DORA-related technical standards, Q&As, and CTPP designation decisions. For UK firms with EU-licensed subsidiaries, maintaining current awareness of DORA's evolving detail is part of the compliance programme for those subsidiaries, alongside the UK regulatory monitoring that covers the rest of the group's obligations. Integrating EU and UK regulatory monitoring in a single feed rather than two separate processes is how Kalipso reduces the overhead of dual-track compliance monitoring for firms in this position.
