EU DORA Compliance

Operational resilience used to be a part of operational risk that supervisors expected firms to manage well. DORA makes it a direct legal obligation with its own structure, reporting lines, and enforcement. For the first time, the regulation also reaches past the financial entity to the ICT providers that sit underneath it, including the cloud platforms and software vendors that a whole class of firms relies on.

This guide is a practitioner's walk through DORA as it operates today: who it binds, the five pillars, the proportionality principle that adjusts the load for smaller entities, the management body's responsibility, and the timeline that puts the regulation in force now. Where a point turns on a precise threshold or template, the source of record is the regulation and its technical standards, and this guide says so at each point.

What DORA is and who it applies to

DORA is a regulation, which means it applies directly across the EU without each Member State having to transpose it into national law. Its purpose is the digital operational resilience of the financial sector: the ability of firms to keep their network and information systems running, and to absorb and recover from ICT disruption, whether caused by a cyber attack, a failure, or an external provider going down.

Article 2 of the regulation lists the financial entities in scope. The list is wide and includes credit institutions, payment institutions and electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, insurance and reinsurance undertakings and intermediaries, institutions for occupational retirement provision, credit rating agencies, and crowdfunding service providers, among others. The regulation also reaches ICT third-party service providers, the technology firms that supply these entities, in two ways: through the contracts each financial entity must put in place, and, for the largest, through a direct oversight framework.

A first step in any DORA assessment is confirming the entity sits in one of the Article 2 categories and is not carved out by the regulation's exemptions, then deciding which version of the regime applies under the proportionality rules below.

Proportionality and the simplified regime

DORA does not put the same weight on a small pension fund as on a large bank. The proportionality principle in Article 4 requires the ICT risk management rules to be applied in proportion to the entity's size, overall risk profile, and the nature, scale, and complexity of its operations.

On top of that, a simplified ICT risk management framework applies to a defined set of smaller entities, including small and non-interconnected investment firms, certain exempted payment and e-money institutions, some exempted credit institutions, and small occupational pension funds. These entities are not held to the full Article-by-Article framework, but they still have to maintain a sound, documented ICT risk framework covering protection, detection, business continuity, testing, and follow-up. Microenterprises, broadly those with fewer than ten staff and limited turnover or balance sheet, get specific relief throughout the regulation. Classify the entity under these rules before assessing anything, because the classification decides which obligations apply.

The management body's responsibility

DORA places accountability for ICT risk on the entity's management body, its board or equivalent governing body, and does not let it delegate that accountability away. The management body has to define, approve, and oversee the ICT risk management framework and bears ultimate responsibility for the entity's ICT risk. It sets the risk tolerance and the digital operational resilience strategy, approves the policy on ICT third-party arrangements and the internal audit plan, allocates the budget, and keeps itself trained so it can understand and challenge ICT risk rather than rubber-stamp it.

This is the spine that runs through everything that follows. The five pillars describe what the entity must do; the management body is the party the regulation holds answerable for whether it gets done.

The five pillars of DORA

DORA is organised into five areas. The first four are obligations on the financial entity. The fifth is a supervisory framework aimed at the providers behind the sector.

Pillar	What it covers
1. ICT risk management	The governance and the controls: identify assets and dependencies, protect and detect, respond and recover, back up and restore, and learn from what goes wrong.
2. Incident management and reporting	Detect, manage, and classify ICT-related incidents, and report the major ones to the supervisor in defined stages.
3. Resilience testing	A testing programme across the systems that matter, rising to threat-led penetration testing for entities the supervisor identifies.
4. ICT third-party risk	Govern the providers: due diligence, contractual requirements, a register of information, concentration risk, and exit strategies.
5. Oversight of critical providers	Direct EU oversight of the ICT third-party providers the whole sector depends on.

Pillar 1: ICT risk management framework

The first pillar is the foundation. DORA requires a sound, comprehensive, and well-documented ICT risk management framework that forms part of the entity's overall risk management. It runs through a recognisable lifecycle:

• Identification. Identify, classify, and document the business functions, information assets, and ICT assets the entity depends on, map their criticality and interdependencies, keep the inventories current, and review them regularly.
• Protection and prevention. Put security policies and tools in place that preserve the availability, authenticity, integrity, and confidentiality of data, with controls such as access management on a least-privilege basis, strong authentication, network segmentation that can be isolated quickly, controlled change management, and patching.
• Detection. Maintain mechanisms that promptly detect anomalous activity and single points of failure, with alert thresholds and regular testing of those mechanisms.
• Response and recovery. Hold an ICT business continuity policy with documented response and recovery plans, run a business impact analysis, and test the continuity and recovery plans at least yearly, including against cyber-attack and switchover scenarios.
• Backup and restoration. Maintain backup policies scoped to how critical the data is, with restoration methods, segregated backup systems, periodic testing, and recovery time and recovery point objectives set for each function.
• Learning and evolving. Gather threat intelligence, run post-incident reviews after major incidents, feed the lessons back into the framework, and provide ICT security awareness and resilience training to staff and management.

For entities above the microenterprise threshold, DORA also expects an independent control function, a separation of duties along three lines of defence, and regular internal audit with a formal follow-up on critical findings. The precise technical content of several of these requirements is set out in the regulation's technical standards, which is where the detail has to be checked.

Pillar 2: incident management, classification, and reporting

The second pillar turns an ICT failure into a disciplined process and, when the failure is serious, a regulatory event. The entity has to maintain a process to detect, manage, and notify ICT-related incidents, record all incidents and significant cyber threats, identify and address root causes, and escalate the serious ones to senior management and the management body.

The regulation sets the classification criteria the entity uses to judge severity: how many clients, counterparts, and transactions are affected, the duration and the downtime, the geographical spread (notably whether more than two Member States are hit), any data losses, the criticality of the services involved, and the economic impact. An incident that crosses the materiality thresholds becomes a major ICT-related incident, which triggers reporting.

Major incidents are reported to the competent authority in three stages on standard templates: an initial notification when the entity first identifies the major incident, an intermediate report as the situation develops and status changes, and a final report once root-cause analysis is complete. Where clients' financial interests are affected, the entity has to inform them without undue delay. Reporting can be outsourced, but the entity stays fully responsible for it. The materiality thresholds that make an incident "major," along with the exact templates and time limits, are set in the technical standards and have to be read there rather than recalled from memory.

Pillar 3: resilience testing, including TLPT

The third pillar makes the entity prove its resilience rather than assert it. Entities above the microenterprise threshold must run a sound, risk-based testing programme inside the ICT risk framework, use independent testers and avoid conflicts of interest, remediate the findings with internal validation, and test all the ICT systems that support critical or important functions at least once a year. The test types range from vulnerability assessments and scans through network security assessments, gap analyses, source-code reviews where feasible, scenario-based and performance testing, and penetration testing.

At the top of the testing pyramid is threat-led penetration testing (TLPT), an advanced exercise that mimics a real attacker against live production systems. Entities identified by their competent authority must carry out TLPT at least every three years. The test must cover several or all of the entity's critical or important functions, its scope is validated by the competent authority, and ICT third-party providers in scope have to take part. When direct participation by a provider would harm its other customers, a pooled-testing route is available. A successful test produces an attestation that competent authorities across the EU can recognise. Entities under the simplified regime and microenterprises are not required to run TLPT. The methodology detail lives in the technical standards.

Pillar 4: ICT third-party risk management

The fourth pillar is where DORA reaches outside the entity's own walls, and it is one of the densest control surfaces in the regulation. The governing principle is that the entity remains fully responsible for compliance at all times, no matter how much it outsources. Around that principle DORA builds a set of concrete requirements:

• Strategy and policy. Above the smaller-entity thresholds, adopt and review an ICT third-party strategy and a policy on the services that support critical or important functions.
• Register of information. Maintain and keep current a register of all ICT contractual arrangements, at entity, sub-consolidated, and consolidated level, distinguishing the arrangements that support critical or important functions. Report it to the competent authority each year, make it available on request, and notify planned arrangements for critical or important functions in advance.
• Due diligence. Before contracting, assess the criticality of the service, the provider's suitability, supervisory conditions, conflicts of interest, and the risk and concentration the arrangement creates.
• Contractual requirements. Set the rights and obligations in writing. Every contract has to carry a defined set of provisions; contracts for critical or important functions carry an enhanced set, covering full service levels, the right to inspect and audit, the provider's obligation to take part in resilience testing, and exit arrangements.
• Concentration risk. Before contracting for a critical or important function, assess whether the provider is hard to substitute, whether the entity is concentrating multiple critical arrangements with one provider or closely connected providers, and the risks in long or third-country subcontracting chains.
• Exit strategies. For critical or important functions, build documented and tested exit strategies with transition plans, so the entity can move off a provider without losing continuity.

The register template and the subcontracting detail are set in the regulation's technical standards. The fields the register has to carry are not a matter of judgement; they are specified, and they have to be checked against the current standard.

Pillar 5: the oversight framework for critical ICT third-party providers

The fifth pillar is not a self-assessment for a financial entity. It is a supervisory regime aimed directly at the ICT providers the whole sector leans on. The European Supervisory Authorities (the EBA, ESMA, and EIOPA), acting through their Joint Committee, designate the most systemically important providers as critical ICT third-party providers (CTPPs). The designation turns on factors such as the systemic impact a large-scale failure of the provider would cause, the systemic importance of the entities that rely on it, how much the sector depends on the provider for critical or important functions, and how easily the provider could be substituted.

Each designated provider is assigned a Lead Overseer, one of the three authorities, which assesses the provider against ICT requirements, governance, incident handling, testing, and audit, adopts an annual oversight plan, and has powers to request information, run investigations and inspections, and issue recommendations. A coordinating network ties the overseers together. If you advise an ICT provider that meets the designation criteria, treat designation as a live possibility and prepare it to meet oversight expectations.

Currency and timeline

DORA is in force now, and the detail is still settling. The dates that matter:

• DORA entered into force on January 16, 2023, the twentieth day after its publication in the Official Journal on December 27, 2022.
• DORA applies from January 17, 2025. The application date, not the entry-into-force date, is the compliance deadline.
• The regulation is supplemented by roughly thirteen binding technical standards, the regulatory and implementing technical standards (RTS and ITS), developed jointly by the European Supervisory Authorities. The regulation sets the principles; the operative technical detail lives in these standards.
• The first batch of standards, including those on the ICT risk management framework, incident classification, the ICT third-party policy, and the template for the register of information, applies from the January 17, 2025 application date.
• The second batch, including the standards on subcontracting, TLPT, oversight cooperation, and the criteria for designating critical providers, phases through 2025 and into 2026.
• As of 2026, the supervisors have moved from preparation into enforcement and have begun designating critical ICT third-party providers under the oversight framework. Expect supervisory engagement, register collection, and live oversight of designated providers.

The practical consequence is that the operative numbers a team needs, the exact incident thresholds, the reporting deadlines and templates, the register fields, and the TLPT methodology, do not live in the body of the regulation. They live in the technical standards, and they have to be pulled from the current standard rather than quoted from memory. This guide gives the structure; the standards give the specifics.

What good DORA evidence looks like

DORA, like any resilience regime, is satisfied by the evidence an entity can produce. Confidence that things are fine carries no weight with a supervisor. The difference shows up most clearly in the third-party pillar:

The strong version names the arrangements, separates the critical ones, ties each to the contractual and exit requirements, surfaces the concentration, and records the test and the report. That is the record a supervisor asks for, and it is the record the oversight regime is built to read.

A DORA readiness checklist

Run this against an entity before treating it as DORA-ready:

• The entity's scope and proportionality classification is settled: in scope under Article 2, and standard regime, simplified regime, or microenterprise relief.
• The management body has defined and approved the ICT risk framework and the resilience strategy, with named accountability and its own training.
• The ICT risk management framework covers identification, protection, detection, response and recovery, backup, and learning, and is reviewed on a regular cadence.
• An incident management process classifies incidents against the regulation's criteria and can produce the initial, intermediate, and final reports for a major incident.
• A resilience testing programme tests the systems behind critical or important functions yearly, with TLPT addressed if the entity is in scope for it.
• The register of information is current, distinguishes critical or important arrangements, and is on the annual reporting cycle.
• Contracts for critical or important functions carry the enhanced provisions, including audit rights, testing participation, and exit strategies.
• Concentration risk across providers and subcontracting chains has been assessed and recorded.
• The operative thresholds, templates, deadlines, and register fields are taken from the current technical standards, not from memory.

DORA rewards the entity that can show its work. A clean set of policies says the firm intends to be resilient. A current register, tested exit strategies, a working incident-reporting workflow, and a board that owns the strategy show that it is. The second kind of record is the one that holds up under oversight.

For the terms used throughout this guide, see the EU DORA glossary.