DORA applicable from 17 January: Regulation (EU) 2022/2554 and the five operational pillars

On 17 January 2025, Regulation (EU) 2022/2554 — DORA, Digital Operational Resilience Act — enters application for the European financial sector. The date has been on the calendar since publication in the OJEU on 27 December 2022, with a two-year transition. The regulation has been in force since late 2022; what changes on 17 January is applicability — from that date obligations are enforceable and authorities can start to inspect.

We covered the operational reminder of DORA in the December bulletin. This post gets into detail: who it applies to, the five pillars of obligations, how it relates to NIS2, what is required on 17 January and what is required over the next 12-36 months.

Reading: analysis of the OJEU text (consolidated version) and of the Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) published by the ESAs — EBA, ESMA, EIOPA — during 2024. The RTS on TLPT are formally approved in mid-2025; this post anticipates the calendar against the final available draft.

Who it applies to

Article 2 of DORA defines the subject scope. Two categories:

Financial entities (Art. 2.1)

Twenty types of entity listed, groupable into blocks:

• Credit and payments: credit institutions (banks), payment institutions, electronic money institutions, account information service providers (AISPs under PSD2).
• Investment and markets: investment firms, UCITS and AIF managers, central securities depositories (CSDs), central counterparties (CCPs), trading venues, trade repositories (TRs), crowdfunding service providers.
• Insurance: insurance and reinsurance undertakings, insurance and reinsurance intermediaries, IORPs (institutions for occupational retirement provision).
• Regulated crypto: crypto-asset service providers authorised under MiCA (Regulation 2023/1114), issuers of asset-referenced tokens.
• Other: managers of long-term investment funds (ELTIFs), credit rating agencies, administrators of critical benchmarks, data reporting service providers.

There are limited exemptions for small entities (Art. 16) with a simplified regime, but the general rule is: if authorised as a financial entity under EU legislation, you fall under DORA.

Critical ICT third-party providers (Art. 2.2 and Chapter V Section II)

ICT third-party service providers (TPPs) are not under DORA by default. They are when designated as critical by the ESAs (Art. 31). Designation is based on Article 31.2 criteria: systemic impact, operational dependency of financial entities, substitutability. The first batch of designations is expected during 2025; the ESAs will publish the official list.

Likely candidates for critical TPPs: cloud hyperscalers (AWS, Microsoft Azure, Google Cloud), core banking SaaS providers (Temenos, Finastra, Mambu), market data platforms (Bloomberg, Refinitiv), SWIFT messaging providers, identity providers (Okta, IBM, Microsoft), large MSSPs. The regime for critical TPPs is direct oversight by the ESAs, not compliance requirements in the style of financial entities.

Who falls outside

• Small insurers and reinsurers below the Solvency II threshold.
• Micro-enterprises (Art. 3.60, with the definition in the Annex to Recommendation 2003/361/EC), with a very simplified regime.
• External auditors — not TPPs in the DORA sense.
• Third-country financial entities without an EU branch — but if they have an authorised branch, the branch does apply.

The five pillars of obligations

DORA organises obligations into five blocks. Each has its own chapter and articles. Operational table:

The five apply at once on 17 January. The one that requires 12-36 month planning separately is TLPT.

Pillar 1 — ICT risk management framework

Article 6 sets out the central piece: a documented ICT risk management framework, approved by the management body of the entity, integrated into business strategy and reviewed at least once a year.

Mandatory components (Arts. 7–14):

• Identification: inventory of business functions that depend on ICT, business impact analysis (BIA) mapping each function to systems, assets, dependencies. Asset classification by criticality and sensitivity.
• Protection and prevention: information security policies, access control, identity management, network segmentation, encryption, change management, patch management, hardening.
• Detection: continuous monitoring mechanisms, alerting, capability to detect anomalous incidents within reasonable time.
• Response and recovery: ICT business continuity policy, response plans, recovery plans with RTOs and RPOs per function, recovery sites, immutable backups.
• Learning and evolution: lessons learned after incidents, continuous improvement, ICT-related incident root cause analysis.

For large entities (not micro-enterprises), Art. 6.4 requires an independent control function overseeing ICT risk management — typically the CISO with functional reporting to the board or risk committee.

Pillar 2 — ICT-related incident management and reporting

Chapter III is where DORA presses hardest on day-to-day operations. Article 17 requires a documented ICT incident management process. Article 18 requires classifying each incident and determining whether it is major under the criteria in the RTS on classification (published by the ESAs in 2024).

Major incident criteria from the RTS (combination of):

1. Number of clients affected / value of transactions affected.
2. Reputation.
3. Duration.
4. Geographical spread.
5. Data loss.
6. Criticality of affected services.
7. Economic impact.

If the incident crosses the thresholds, there is an obligation to report to the national competent authority (in Spain: Bank of Spain, CNMV, DGSFP — Directorate-General for Insurance and Pension Funds — depending on the type of entity) under Annex III deadlines:

Significant cyber threats (Art. 19): voluntary obligation to notify significant cyber threats that have not materialised into an incident but have been detected.

Reports use harmonised templates that the ESAs publish as ITS. It is not free prose.

Pillar 3 — Digital operational resilience testing

Chapter IV (Arts. 24–27) distinguishes two levels of testing:

General testing (Arts. 24–25) — mandatory for all entities under scope. Annual testing programme that includes, depending on criticality: vulnerability assessments, scans, source code reviews, scenario-based tests, compatibility testing, performance testing, end-to-end testing, penetration testing. Small entities have a proportional regime.

TLPT — Threat-Led Penetration Testing (Arts. 26–27) — mandatory for important entities designated by the national competent authority under the criteria of the RTS on TLPT.

The final RTS on TLPT (published by the ESAs in July 2024, awaiting Commission approval during 2025) establishes:

• Frequency: at least once every three years (Art. 26.1).
• Scope: critical production systems, not test environments. Cover critical functions supporting key financial services.
• Methodology: structure practically aligned with TIBER-EU — the threat-led red teaming framework the ECB has coordinated since 2018. The test consists of: scoping, specific threat intelligence (Targeted Threat Intelligence report produced by an accredited TI provider), red team exercise (weeks-months), post-test reporting, remediation tracking.
• Testers: can be external or internal. Internal testers allowed in up to two of every three cycles (one test in three cycles must be external). Testers must meet Article 27 requirements — recognised certifications, minimum experience, separation of duties.
• First TLPT: the deadline to complete the first TLPT depends on the entity’s designation as subject to TLPT by the competent authority. For the first designations (during 2025), the realistic first TLPT falls in 2027–2028.

For an internal red team, the operational pieces of TLPT are three things:

1. The TI provider must be accredited. It’s not a generic pentesting consultant — it must produce a Targeted Threat Intelligence report following TIBER-EU methodology. The list of accredited TI providers is maintained by each national central bank.
2. The test is intelligence-led. Before any breaking starts, there are 4-6 weeks of TI dedicated to the entity: which actors target it, which TTPs they use, what objectives they would assume. The red team simulates those actors, not generic ones.
3. There is a Test Authority — typically the national central bank, in Spain the Bank of Spain via TIBER-ES — that coordinates the exercise, validates deliverables and files the final report. It isn’t a self-validated internal exercise.

Pillar 4 — ICT third-party risk management

Chapter V Section I (Arts. 28–30) requires managing ICT third-party risk. The operational pieces:

Register of information (Art. 28.3) — each entity keeps a detailed register of all contractual arrangements with ICT TPPs, distinguishing those that support critical or important functions. The register uses the harmonised format from the ITS on register of information (published by the ESAs in 2024). It is submitted annually to the competent authority.

Pre-contractual due diligence (Art. 28.4) — before signing, assessment of provider risk: financial situation, technical capabilities, security controls, data location, concentration risk, provider’s own dependencies on other providers (fourth-party risk).

Mandatory contractual clauses (Art. 30) — the Annex to Article 30 lists clauses that must appear in contracts with TPPs supporting critical functions. Operational block:

• Full description of the service.
• SLAs with measurable metrics.
• Data processing locations.
• Information security provisions.
• Right of access, inspection and audit for the financial entity and for the competent authority.
• Cooperation with authorities.
• Exit strategy provisions with deadlines and portability.
• Subcontracting: conditions, prior notification, visible chain.

Concentration (Art. 29) — requirement to assess and mitigate concentration risk on a single TPP or on a group of interdependent TPPs. For large entities, the regulator can require active reduction of concentration.

Oversight of critical TPPs (Chapter V Section II) — for providers designated as critical (Art. 31), obligations apply directly to them via ESAs oversight. This is new in the EU — it’s the first time the ESAs exercise direct supervision over non-financial providers.

Pillar 5 — Information & intelligence sharing

Article 45 enables — does not require — the exchange of cyber threat intelligence between financial entities within trusted communities. The operational idea is to legally facilitate a bank sharing IoCs and TTPs with others without legal risk over the exchange of customer information or personal data.

For this, entities need: documented exchange arrangements, confidentiality safeguards, data protection safeguards (compatible with GDPR), source validation, framework for use of information received.

In practice, this pillar is built on existing communities — FS-ISAC, national communities such as CCN-CERT, the ENISA Financial Sector Cyber Threat Intelligence Group. DORA gives legal support without replacing what exists.

Mapping DORA ↔ NIS2 ↔ NIST CSF 2.0

DORA coexists with NIS2 (Directive 2022/2555) and with frameworks like NIST CSF 2.0. The administrative rule that matters:

DORA is lex specialis for the financial sector. Where DORA and NIS2 overlap on the same entity, DORA prevails (Art. 1.2 of DORA and Art. 4 of NIS2).

This resolves the conflict of obligations but not the operational doubt, because many financial entities are also operators of essential services under NIS2 via non-financial activities (payment processing for critical infrastructure, for example). Practical mapping:

The most operationally relevant difference for a bank CISO already mapping NIS2: DORA is more prescriptive on testing and on third-party. NIS2 says “do resilience testing”; DORA says “do annual testing and, if you are important, TLPT every 3 years with accredited TI provider and supervising authority”. NIS2 says “manage provider risk”; DORA says “keep a register in a harmonised format, put these clauses into contracts, and if your provider is designated critical, the ESAs supervise it directly”.

Incident reporting also differs: DORA requires an initial report within 4 hours of classification as major; NIS2 requires early warning within 24h but the actual initial report at 72h. For a financial entity with an incident crossing thresholds in both, DORA’s deadlines are tighter.

Decision flowchart

For an organisation wondering whether DORA applies:

1. Are you a financial entity authorised under EU legislation? (bank, fintech, manager, insurer, IORP, MiCA CASP, etc.) → DORA applies from 17 Jan 2025. Go to step 4.
2. Are you an ICT third-party provider designated as critical by the ESAs? (the list will be published by the ESAs during 2025-2026) → Direct oversight by the ESAs under Chapter V Section II. Different regime to financial entities.
3. Are you an ICT third-party provider not designated but providing service to financial entities? → DORA doesn’t apply to you directly, but your financial clients will pass DORA-compliant clauses to you. Prepare for audits, access rights, time-bound exit strategies, register entries your client will hand to its authority.
4. You’re under DORA. Are you an “important entity” under the RTS on TLPT criteria? (thresholds by assets under management, number of clients, systemic criticality) → Yes: add TLPT every 3 years. No: annual general testing, no mandatory TLPT.
5. Are you also an operator of essential services under NIS2? → DORA prevails for the obligations that overlap. NIS2 applies to the rest.

Question 2 is the one that will generate most debate during 2025: the first critical TPP designations will set operational precedent — which hyperscalers, which core banking SaaS, which identity providers. The designation methodology is in the RTS on criticality assessment.

What to have ready on 17 January

For a CISO or COO of a financial entity arriving with work still outstanding, minimum viable on 17 Jan 2025:

1. ICT risk management framework documented and approved by the board / management body. Even v1 with room to improve, it has to exist with formal approval.
2. Complete inventory of critical business functions and ICT assets supporting them, with preliminary BIA. RTOs and RPOs defined per function.
3. ICT incident management policy with classification criteria aligned with the RTS, defined internal escalation, initial report template ready for the 4h Annex III deadline.
4. Register of information of ICT providers — at least for those supporting critical functions. Harmonised ITS format. First submission is annual; the actual submission to the regulator typically falls in Q1-Q2 of each year.
5. Review of contracts with critical TPPs — identify gaps with the mandatory clauses in Art. 30, plan for renegotiation. Old contracts aren’t renegotiated all at once on 17 January; but the gaps and remediation plan must be identified.
6. Annual testing programme with 2025 calendar: which test types, which systems, which providers.
7. Internal designation of the independent ICT risk control function (typically the CISO with functional reporting to the board or risk committee).

What doesn’t need to be ready on 17 January but does need to be on the calendar:

• First TLPT: 24-36 months from designation of the entity as subject. Starts with designation during 2025 → first TLPT 2027-2028.
• Full migration of contracts to DORA-compliant clauses: realistic at 2-3 years.
• Full integration of the framework with NIS2 where applicable: NIS2 remains untransposed in Spain as of 17 January. Once transposed, there is overlap to coordinate.

What remains open

As of 17 January, items pending:

• Official list of critical TPPs: the ESAs will publish during 2025. Designation methodology is in the RTS, but the list isn’t.
• Final RTS on TLPT: the July 2024 draft is awaiting European Commission approval. The final version with Official Journal publication is expected during 2025.
• NIS2 transposition in Spain: draft bill in Parliament as of December 2024, with no firm approval date. The operational coordination DORA ↔ NIS2 in Spain depends on how the national NIS2 law turns out.
• Specific sanctions: DORA has no fine brackets in the style of the AI Act or GDPR. Sanctions apply via the sanctioning regime of each national competent authority. In Spain, the regimes of Bank of Spain, CNMV or DGSFP will apply depending on the sector.
• First inspection cycle: national authorities will open inspections from 17 January. The first ones are expected to target systemic entities; the rest of the sector will see them during 2025-2026.

References

• Official OJEU text — Regulation (EU) 2022/2554: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• Art. 6 (ICT risk management framework): https://www.digital-operational-resilience-act.com/Article_6.html
• Arts. 26–27 (Threat-Led Penetration Testing): https://www.digital-operational-resilience-act.com/Article_26.html
• ESAs Joint Committee — DORA RTS and ITS published 2024: https://www.eba.europa.eu/regulation-and-policy/operational-resilience
• ESAs Final report on DORA RTS on TLPT (JC 2024/29, July 2024): https://www.esma.europa.eu/sites/default/files/2024-07/JC_2024-29_-_Final_report_DORA_RTS_on_TLPT.pdf
• TIBER-EU framework (ECB): https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html
• TIBER-ES (Bank of Spain): https://www.bde.es/wbe/es/areas-actuacion/estabilidad-financiera-y-politica-macroprudencial/ciberresiliencia/tiber-es.html
• EIOPA — DORA overview: https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en
• Previous IRONHACKERS post: Bulletin — December 2024