DORA (EU Regulation 2022/2554) has applied since January 2025 to banks, fintech, insurers and their critical ICT providers in the financial sector.
To whom does DORA apply in Spain?
Three blocks. Financial entities: commercial and investment banks, fund management companies, insurers, reinsurers, EMIs (electronic money institutions), crowdfunding platforms, authorised fintech. Critical ICT providers: those the ESA designates as critical (cloud hyperscalers, payment platforms, sector-specific SaaS providers). Sector ICT auditors: with specific competence requirements.
What does an entity have to do to comply with DORA?
Five pillars. (1) A documented ICT risk-management framework, approved by the board. (2) A management and reporting system for serious ICT incidents, notifying the supervisor within 4 hours. (3) An operational-resilience testing programme: pentest, red team at least every 3 years. (4) Specific third-party ICT risk management (contracts, due diligence, continuous monitoring). (5) Sharing of cyber-threat information with the authorities.
What is the difference between DORA and NIS2?
DORA is specific to the financial sector and its ICT providers. NIS2 is cross-cutting across critical sectors (energy, water, healthcare, food, etc.). A financial entity is subject to DORA (lex specialis) and NOT to NIS2 for the same subject matter. A manufacturing, water or energy company is subject only to NIS2. There are areas of controlled overlap between the two.
Real case: a Spanish EMI prepares for DORA against the clock
An electronic money institution (EMI) headquartered in Madrid, with 95 employees and an annual processed volume of EUR 380M, found in July 2024 that its ICT risk-management framework would not withstand a DORA inspection. Its incident-reporting system relied on spreadsheets, it had no ICT-provider contracts aligned with the Regulation, and it had never run a red team. The board took on the project as a regulatory priority.
The compliance budget closed at EUR 168,000, split as follows: EUR 54,000 on ICT risk-framework and policy consulting; EUR 38,000 on an incident management and reporting platform integrated with the supervisor; EUR 41,000 on resilience testing (an annual pentest plus a reduced-scope TLPT — Threat-Led Penetration Testing); EUR 22,000 on renegotiating 14 contracts with ICT providers, including two cloud hyperscalers; and EUR 13,000 on training the board and key staff. The project ran over 6 months, with the framework going live in December 2024, just before the application date.
The return was not only avoiding sanctions. The entity used the certification of its resilience as a commercial argument in two tenders with large corporate clients that required DORA-ready payment providers, and it cut its cyber-insurance premium by 11% by demonstrating documented resilience testing. The cost of not acting was estimated at a sanction exposure of up to EUR 1.9M plus the loss of its operating licence in the worst-case scenario.
The 5 pillars of DORA: deadlines and entities affected
EU Regulation 2022/2554 is built around five blocks of obligations. This table summarises what each pillar demands, its reference deadline and which entities it affects most intensely.
| DORA pillar | Key requirement | Deadline / frequency | Most affected entities |
|---|---|---|---|
| 1. ICT risk management | Documented framework approved by the board; map of critical functions | In force since 17 Jan 2025; annual review | All financial entities |
| 2. ICT incident management | Classification, initial notification to the supervisor, and intermediate and final reports | Initial notification: 4 hours after classifying as serious | Banks, EMIs, payment platforms |
| 3. Resilience testing | Periodic pentests and scans; TLPT for significant entities | Basic tests annually; TLPT every 3 years | Designated significant entities |
| 4. Third-party ICT risk | Register of information, contracts with minimum clauses, due diligence and monitoring | Register of information: annual report to the supervisor | Entities dependent on cloud and SaaS |
| 5. Information sharing | Voluntary exchange of cyber-threat intelligence | Voluntary and ongoing | The whole financial sector |
ICT providers designated as critical (CTPP) by the European Supervisory Authorities are additionally subject to a direct oversight regime, with an assigned lead overseer and the power to impose periodic penalty payments of up to 1% of their average daily turnover.
DORA compliance checklist
A 12-step roadmap for a financial entity starting from scratch or with partial compliance:
- Confirm scope: check whether the entity is a financial entity, an ICT provider or an auditor, and map the critical or important functions.
- Appoint a digital operational resilience lead and assign accountability to the board.
- Run a gap analysis against the five pillars and the associated regulatory technical standards (RTS).
- Document and approve the ICT risk-management framework, including the business-continuity and recovery policy.
- Inventory all ICT assets and classify those supporting critical or important functions.
- Implement an incident-management process with severity-classification criteria aligned to the DORA thresholds.
- Set up the channel and templates for notifying the supervisor to meet the 4-hour deadline for serious incidents.
- Build the ICT-provider register of information and report it annually to the competent authority.
- Renegotiate ICT contracts to include the mandatory minimum clauses: access, audit, sub-outsourcing, exit.
- Plan the resilience-testing programme: an annual pentest and, where applicable, a TLPT every three years.
- Train the board and key staff in ICT risk and resilience.
- Establish periodic review of the framework and a continuous-improvement cycle with internal audit.
5 common mistakes when implementing DORA
- Treating DORA as an IT project rather than a governance one. If the board does not approve and oversee the framework, the entity breaches pillar 1 even if the technical side is flawless. Consequence: a supervisory requirement and sanction exposure.
- Ignoring the 4-hour deadline for the initial notification. Many entities prepare the final report but lack an agile process for early notification. Consequence: a late notification logged as a formal breach.
- Failing to update contracts with ICT providers. Keeping old cloud contracts without audit, sub-outsourcing and exit clauses leaves the entity without cover. Consequence: an inspection finding and unmanaged dependency on a critical third party.
- Confusing a commercial pentest with a TLPT. Significant entities need threat-led testing with a recognised methodology; a generic scan does not comply. Consequence: an invalid test and a repeat exercise under regulatory pressure.
- Forgetting the third-party register of information. Failing to keep the register updated and to report it annually is one of the easiest breaches for the supervisor to detect. Consequence: an immediate requirement and reputational damage with the authority.
Official sources
Authored by Ángel Ortega Castro · independent consultant in strategy, quality and digitalisation for SMEs.