The DORA Regulation (Digital Operational Resilience Act, EU Regulation 2022/2554) entered into force on 17 January 2025 for all financial entities subject to supervision in the European Union. It is not a directive that each member state transposes at its own pace: it is a directly applicable regulation, which means that from that date supervisors — the ECB, the EBA, EIOPA, ESMA and, in Spain, the Banco de España and the CNMV — may request evidence of compliance at any time. If your institution still does not have a formal programme, you are already in breach.
This article does not repeat the text of the regulation. What you will find here is an operational roadmap: what needs to be done, in what order, where most organisations get stuck and how to structure the work to reach a defensible level of compliance without consuming two years of resources.
What does DORA actually require? The five pillars
The regulation structures digital operational resilience around five blocks that are not independent but feed into one another. Understanding the logic of the whole avoids the common mistake of treating DORA as a checklist without a connecting thread.
1. ICT risk management (Articles 5–16)
The entity must have a documented ICT risk management framework, approved by the management body and reviewed at least once a year. This framework includes the identification of critical ICT assets, risk assessment, protection measures, response and recovery procedures, and post-incident learning. The management body bears direct, non-delegable responsibility: DORA is explicit that board members must maintain sufficient knowledge of ICT risks.
2. Management, classification and reporting of incidents (Articles 17–23)
Entities must classify ICT incidents according to harmonised criteria that the European Supervisory Authorities (ESAs) have specified in regulatory technical standards (RTS). «Major» incidents are reported in three stages: initial notification (within 4 hours of classification, or a maximum of 24 hours from detection), intermediate report and final report. Failure to meet the reporting deadline is, in itself, grounds for a sanction.
3. Digital operational resilience testing (Articles 24–27)
All entities must test their ICT tools and systems at least once a year. Significant entities — defined by size and criticality thresholds — must go further and carry out threat-led penetration tests (TLPT) every three years, following the TIBER-EU framework. In Spain, the Banco de España has already initiated TIBER exercises with banking sector entities; the CNMV intends to do the same with investment firms and funds.
4. ICT third-party risk management (Articles 28–44)
This block is, in practice, the most costly to implement. DORA requires that contracts with critical ICT providers include mandatory clauses: audit rights, continuity guarantees, disruption-free exit, service levels, data location and sub-contracting. Entities must maintain a register of information on all their contractual arrangements with ICT third parties, in a standardised format as specified by the ESAs' RTS. In addition, critical ICT providers directly designated by the ESAs are subject to a community-level direct oversight framework.
5. Information sharing (Article 45)
DORA encourages — and in certain cases requires — entities to participate in mechanisms for sharing intelligence on cyber threats. In Spain, the CCN-CERT (National Cryptologic Centre) and the Financial CERT channel much of this information for supervised entities.
Comparative table: obligations by type of entity
| Type of entity | ICT risk framework | Incident reporting | Annual testing | TLPT every 3 years | Third-party register |
|---|---|---|---|---|---|
| Significant bank (SSM) | Full + board approval | Yes (4h / 24h) | Yes | Yes (TIBER-EU) | Yes (RTS format) |
| Less significant credit institution | Full | Yes (4h / 24h) | Yes | At supervisor's discretion | Yes |
| Investment firm | Full | Yes | Yes | If thresholds are exceeded | Yes |
| Insurance / reinsurance undertaking | Full (coordinated with Solvency II) | Yes | Yes | If EIOPA thresholds are exceeded | Yes |
| Payment institution / e-money institution | Simplified (Art. 16) | Yes | Yes (basic tests) | Not required | Yes |
| Fund management company (UCITS / AIFM) | Full | Yes | Yes | If designated | Yes |
| Micro-enterprise (Art. 3.1.k) | Simplified | Yes | Yes (basic) | No | Simplified register |
Source: EU Regulation 2022/2554 (DORA) and RTS published by EBA/EIOPA/ESMA in 2024.
Practical roadmap: six phases to defensible compliance
The experience accumulated since 2007 supporting compliance projects in the financial sector has taught us that organisations that try to address DORA «alongside business as usual» either fail or produce documentation that does not survive a supervisory review. The roadmap we propose through our NIS2 and DORA consultancy service organises the work into six sequential phases, although the first two can be run in parallel.
Phase 1 — ICT asset inventory and classification (weeks 1–4)
Without an inventory, risk management is impossible. The starting point is a complete map of all ICT systems, applications, infrastructure, data and services, distinguishing between own assets and services provided by third parties. For each asset, its criticality relative to the business functions it supports is determined: if that system went down, what operational capacity would be lost and in how much time? This Business Impact Analysis (BIA) is the foundation of the entire programme.
Phase 2 — Gap analysis against the DORA framework (weeks 3–6)
With the inventory in hand, the current situation is benchmarked against the requirements of the regulation and the regulatory (RTS) and implementing (ITS) technical standards that develop it. The most frequent gaps we find in mid-sized entities are: absence of a formal incident classification procedure, ICT provider contracts without DORA clauses, and absence of documented resilience tests beyond a backup recovery test. The output of this phase is a prioritised action list.
Phase 3 — ICT risk management framework and policy (weeks 5–12)
The entity's ICT risk management framework is drafted or updated: a policy approved by the board, a risk assessment methodology, risk appetite, roles and responsibilities (including the CISO function or equivalent), and operational procedures for identification, protection, detection, response and recovery. This documentary package is what the supervisor will ask to see first in any inspection.
Phase 4 — ICT third-party contract remediation (weeks 8–20)
Contract renegotiation with ICT providers is, by far, the phase that takes longest. Major cloud providers (AWS, Azure, Google Cloud) have pre-approved DORA/NIS2 addenda, but mid-sized providers of core banking software, risk management or infrastructure typically require direct negotiation. The entity must prioritise contracts with its critical ICT providers (those supporting critical or important functions) and incorporate the minimum clauses from Article 30 of DORA: accessibility, integrity, security, audit, continuity and exit.
Phase 5 — Testing programme and first exercise cycle (weeks 12–24)
The annual resilience testing programme is designed: connectivity and availability tests, disaster recovery (DR) tests, incident simulations with the response team, and — for entities that require it — planning for the first TLPT exercise with an accredited threat intelligence provider. The first test cycle also produces the results report that DORA requires to be kept and made available to the supervisor.
Phase 6 — Information register and continuous governance (weeks 20–28)
The final phase establishes the ICT third-party information register in the format required by the RTS (mandatory fields, periodic updates, change traceability), the programme monitoring indicators, the training plan for the management body on ICT risk, and the annual review calendar. From this point on, DORA is a continuous cycle, not a project with a completion date.
The five mistakes that most delay compliance
Working with entities that arrived at January 2025 without a formal programme, we have identified the bottlenecks that consume the most time:
- Treating DORA as an IT project. The regulation places direct responsibility on the board. Without real executive sponsorship, the project stays at the technical level and the policy is never approved.
- Starting with documentation instead of the inventory. Writing policies without knowing which systems exist produces documents that do not reflect reality and that the supervisor dismisses.
- Underestimating the volume of contracts to renegotiate. A mid-sized entity with 80–120 ICT providers may have 30–40 contracts that need an addendum. The legal process takes months.
- Confusing ISO 27001 with DORA compliance. ISO 27001 is compatible and facilitates the work, but it does not cover DORA-specific requirements: incident classification using ESA criteria, TLPT, third-party registers or notification within specific time frames.
- Ignoring the technical development standards. The RTS and ITS published by EBA, EIOPA and ESMA in 2024 specify many requirements that the regulation leaves open. Without reading them, compliance remains incomplete.
DORA and NIS2: overlapping areas and differences
Many financial entities are subject simultaneously to DORA and the NIS2 Directive (being transposed in Spain through the Draft Law on Cybersecurity Coordination and Governance, which was still in parliamentary proceedings at the time of writing). The relationship between the two instruments follows the lex specialis principle: DORA prevails over NIS2 for financial entities in the areas it regulates. In practice, this means that a financial entity does not have to comply with NIS2 «on top of» DORA for ICT risk management, but it must be clear about which supervisor controls what.
For entities that are part of groups with subsidiaries in non-financial sectors, the question is more complex: non-financial subsidiaries may be subject to NIS2 while the financial parent complies with DORA. Specialist consultancy on NIS2 and DORA is key to correctly mapping the perimeter of each regulation within group structures.
Deadlines and status of supervision in Spain (2025–2026)
DORA has applied since 17 January 2025 with no additional transitional period. However, supervision has not been activated uniformly from that date: supervisors are in an initial phase of documentary review and publication of expectations. The Banco de España published an internal communication in January 2025 addressed to significant entities requesting their implementation status. The CNMV has begun self-assessment questionnaires for investment firms and management companies.
The horizon for the first formal inspections with the possibility of sanctions is, according to market signals and public statements by supervisors, between the second half of 2025 and the first half of 2026. Entities that in that window cannot present a documented programme and evidence of tests carried out are exposed to formal requirements and, in the most serious cases, to sanctions under the sector-specific sanction regimes to which DORA refers (Chapter VII, Articles 50–51). The 1% of average global daily turnover threshold set out in Article 64 of DORA applies specifically to critical ICT third-party providers designated by the ESAs, not to financial entities themselves, whose sanctions are determined by each sector's national legislation.
Frequently asked questions
Does DORA apply to a small fintech with a payment institution licence?
Yes, but under a simplified regime. Article 16 of DORA establishes a simplified ICT risk management framework for micro-enterprises and certain smaller entities. Payment institutions and e-money institutions that do not exceed the thresholds for classification as significant entities may use this regime, which reduces documentary and governance requirements, although it maintains the obligations to report incidents and maintain the ICT provider register. In practice, even under the simplified regime, a fintech must have an ICT policy, an incident procedure and adapted provider contracts.
What happens if an ICT provider refuses to renegotiate the contract?
DORA does not bind the provider, it binds the financial entity. If a provider supporting a critical or important function refuses to include the clauses from Article 30, the entity has three options: initiate a formal substitution process, request a temporarily justified exemption from the supervisor, or accept that the contract does not comply and document the situation with a remediation plan. The first option is the cleanest but the most costly. In practice, most major financial software providers have already published DORA addenda or are in the process of doing so, as their clients are demanding them across the board.
How long does it take to complete the DORA programme in a mid-sized entity?
In entities with between 200 and 1,000 employees and moderately complex ICT infrastructure (50–100 ICT providers, core systems both internal and in the cloud), the full programme to achieve a defensible level of compliance before the supervisor requires between 9 and 18 months. The factors that most lengthen the process are the volume of contracts to renegotiate, prior maturity in ICT risk management and the capacity of the internal team to absorb parallel work. Starting with a specialist external team reduces the time by 30–40% in the gap analysis and documentary framework phases.
What is the difference between annual tests and TLPTs?
The annual tests DORA requires of all entities are internal verification exercises: connectivity tests, disaster recovery tests, incident simulations. They do not require a specific external provider or supervisor validation. TLPTs (Threat-Led Penetration Tests) are advanced exercises that simulate the tactics, techniques and procedures of real threat actors, using up-to-date threat intelligence. They are carried out every three years, with providers accredited under the TIBER-EU framework, under the coordination of the supervisor and with access to production systems. They are far more invasive, expensive (between 150,000 and 500,000 euros in mid-sized entities, depending on scope) and reveal vulnerabilities that internal tests do not detect.