DORA was introduced because the financial services sector had become deeply dependent on technology, and the existing patchwork of national rules governing ICT risk was inadequate to address the systemic vulnerabilities that dependence created. A major technology failure or cyberattack at a single critical technology provider can simultaneously affect dozens of financial institutions. DORA was designed to address that systemic exposure, and to do so with a level of specificity and prescriptiveness that previous frameworks lacked.
For the risk, compliance, and technology functions of in-scope entities, DORA is one of the most demanding operational frameworks they have faced. This guide covers who it applies to, what each of the five pillars requires in practice, and where the most significant compliance challenges lie.
DORA applies to a wide range of financial entities. The full list in Article 2 of the regulation includes credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds, management companies, insurance and reinsurance undertakings, insurance intermediaries and ancillary insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, and securitisation repositories.
The breadth of this scope reflects the EU's intention to address ICT risk across the full financial system rather than only in banking. For many of these entity types, DORA represents the most detailed technology risk governance framework they have encountered.
DORA introduces a new supervisory category: ICT third-party service providers that are designated as Critical Third-Party Providers by the European Supervisory Authorities (EBA, ESMA, and EIOPA jointly). Designated CTPPs face direct oversight from the Lead Overseer, including the right to conduct inspections and issue binding recommendations. This is a significant departure from previous frameworks, which could only address technology risk at critical providers indirectly through the financial entities using them.
DORA includes a proportionality principle. Microenterprises and small financial entities are subject to simplified obligations in specific areas, including ICT risk management framework requirements and resilience testing. The simplified requirements remain substantive; they are lighter versions of the main requirements rather than exemptions.
UK-regulated firms are not directly subject to DORA following Brexit, but the FCA's own operational resilience framework covers substantially similar ground. Organisations with EU operations, EU-established subsidiaries, or EU clients operating under EU regulatory permissions need to understand DORA requirements for those operations. The EBA's DORA guidance is publicly available and provides detailed specification of the regulatory technical standards.
Every in-scope entity must implement a comprehensive ICT risk management framework. This is not a general expectation of good practice. DORA specifies what the framework must contain, and the technical standards developed by the EBA, ESMA, and EIOPA provide considerable detail on what evidence of compliance looks like.
The management body, meaning the board or equivalent governing body, must explicitly approve and periodically review the ICT risk management framework. This creates personal governance accountability of a kind that financial services boards are still adjusting to. A board that signs off on governance documentation without genuine engagement with its substance is not meeting DORA's standard.
The framework must include a strategy for digital operational resilience that sets the objectives and priorities for managing ICT risk. It must include policies covering ICT security, including access controls, encryption, patch management, and physical security. It must establish procedures for incident management, business continuity, and crisis communication. And it must maintain an ICT asset inventory covering all hardware, software, and data assets, with a clear understanding of how those assets are interconnected.
Continuous monitoring of the ICT environment is required, not only periodic assessments. The framework must be capable of identifying threats and vulnerabilities as they emerge rather than only during scheduled reviews.
DORA requires a dedicated ICT business continuity policy with defined recovery time and recovery point objectives for critical systems. These objectives must be tested. The testing must be genuine: not the confirmation that known plans work in expected scenarios, but exercises that probe whether the organisation can maintain operations under conditions more severe than those normally planned for.
DORA requires entities to have established processes for detecting, managing, and notifying ICT-related incidents. All ICT-related incidents must be logged and classified. The classification criteria are defined in EBA regulatory technical standards and cover parameters including the number of clients affected, the duration of the incident, the geographic spread, the type of data impacted, and the economic impact.
Major incidents, those meeting the thresholds defined in the technical standards, trigger both internal escalation requirements and external notification obligations. The classification decision must be made promptly after an incident is detected, because the reporting timelines run from the point of classification.
The reporting timeline for major ICT-related incidents is one of the most operationally demanding aspects of DORA for most organisations.
An early warning must be provided to the competent authority within four hours of classifying an incident as major. This is four hours from classification, not from the start of the incident. The early warning need not be comprehensive but must confirm that a major incident has been classified and provide initial information about its nature and impact.
An intermediate report must be submitted within 72 hours of the initial classification. This report provides updated information about the incident's cause, impact, management actions taken, and estimated duration or resolution timeline.
A final report must be submitted within one month of the incident being resolved. This provides a comprehensive account of the incident, its root causes, the actions taken in response, and the measures implemented to prevent recurrence.
These timelines make it impossible to design the notification process under the pressure of a live major incident. The detection, classification, and notification processes must be tested and operational before the next significant event.
All in-scope entities must implement a programme of ICT resilience testing. For entities not classified as significant, a basic testing programme is required, covering vulnerability assessments and scans, open-source analysis reviews, network security assessments, gap analyses against the ICT risk management framework, and physical security reviews. These must be conducted at least annually for critical systems and applications.
Vulnerabilities identified through testing must be remediated. The remediation must be evidence-based and documentable. Testing that produces findings that are never addressed does not satisfy DORA's requirements and will not satisfy a competent authority during a supervisory examination.
Significant entities, identified by the competent authorities based on their systemic importance, must additionally undergo Threat-Led Penetration Testing at least every three years. TLPT is a significantly more demanding form of testing than conventional penetration testing.
TLPT involves genuine red-team attacks against live production systems based on threat intelligence specific to the entity. Rather than searching for known vulnerabilities in a controlled test environment, TLPT simulates the tactics, techniques, and procedures that actual advanced threat actors would use against this specific organisation. The scope must cover the critical functions of the entity, including the third-party providers and infrastructure that support those functions.
TLPT must be conducted by approved testers following the TIBER-EU framework or an equivalent national framework endorsed by the competent authority. The process is demanding, time-consuming, and expensive, but it produces a quality of assurance about actual resilience to sophisticated attacks that no conventional testing approach can match.
Every in-scope entity must maintain a Register of Information covering all contractual arrangements with ICT third-party service providers. The register is not a simple supplier list. It must be structured using specific data fields defined in EBA regulatory technical standards, covering the nature of the service provided, whether the service supports a critical or important function, where data is stored and processed, the governing law of the contract, and the subcontracting chain.
The register must be machine-readable in the prescribed format, because competent authorities can request it as part of supervisory activity. Building the register requires data that is typically dispersed across legal, IT, business, and procurement functions and has never been compiled in one place. For most organisations, the data collection exercise for the register is the most immediately resource-intensive DORA compliance task.
DORA requires entities to assess whether they have an excessive concentration of ICT risk in a single provider, or through the supply chains of multiple providers that all depend on the same underlying infrastructure. This is an explicit fourth-party risk requirement: the entity must look beyond its direct suppliers to understand whether critical functions depend on a small number of ultimate providers.
Where concentration is identified, the entity must assess the implications for resilience if the concentrated provider experienced a significant disruption, and must consider what the exit and substitution options are.
DORA specifies provisions that must be present in all ICT third-party contracts for critical or important functions. These include explicit service descriptions and performance standards, security requirements aligned with the entity's ICT security policy, incident notification obligations requiring the provider to notify the entity of significant incidents affecting the services it provides, audit and access rights for the entity and competent authorities, business continuity obligations, and structured exit and termination provisions with realistic transition assistance timeframes.
Many existing contracts do not contain all of these provisions. A systematic review of existing contracts against the mandatory content list is required, with renegotiation where gaps are found.
For each critical or important function supported by an ICT third-party provider, DORA requires a documented exit strategy. The exit strategy must be realistic: it must specify how the entity would transition to an alternative provider or bring the function in-house if the existing provider relationship ended, and it must consider the feasibility and timeframe of that transition under conditions of emergency as well as planned exit.
An inability to exit a critical provider relationship without material service disruption is itself a DORA compliance concern, because it represents a concentration of operational risk with a single provider that cannot be adequately managed.
DORA encourages financial entities to participate in voluntary arrangements for sharing cyber threat intelligence with trusted counterparts, sector bodies, and competent authorities. This is the least prescriptive of the five pillars, reflecting the voluntary nature of threat intelligence sharing rather than a mandatory obligation. Participation is presented as part of a mature operational resilience posture and is likely to be viewed positively by supervisors as evidence of a collaborative approach to systemic risk.
Consistently the most underestimated deliverable. The data required spans multiple internal functions that have never been asked to compile it in a single structured format. Lead time to build the register properly is substantial, and the register must be accurate and current, not completed once and left unchanged.
The four-hour early warning timeline is not achievable without tested, operational detection and classification processes. Most organisations that have reviewed their incident management procedures against DORA find that the existing processes cannot reliably deliver the required notification within the required timeframe. Redesigning these processes and testing them under simulated conditions is essential before a live event tests them for real.
DORA's requirement for management body involvement in approving and overseeing the ICT risk management framework implies a level of board engagement with technology risk that many boards do not currently maintain. Demonstrating that the board is genuinely engaged, rather than simply having approved documentation, requires a different approach to how ICT risk is presented and discussed at board level.
