DORA ICT Risk Management Framework: Complete Practitioner Guide for Financial Institutions and Their Insurers in 2026

The Digital Operational Resilience Act — Regulation (EU) 2022/2554 — became applicable on 17 January 2025. More than a year in, the reality is settling in: DORA is not another box-ticking exercise. It is a structural overhaul of how EU financial entities manage ICT risk, report incidents, test resilience, govern third-party dependencies, and share threat intelligence.

For cyber insurance underwriters and risk engineers, DORA changes the baseline. A financial institution that cannot articulate its DORA compliance posture is, by definition, an incomplete risk assessment. This guide walks through the regulation’s five pillars, its interaction with NIS2, enforcement mechanics, and the specific questions underwriters should be asking insureds in 2026.

For broader context on how DORA fits alongside NIS2 and the Cyber Resilience Act, see our comparison piece: Cyber Resilience Act vs NIS2 vs DORA.

What DORA Is and Why It Matters

DORA is a directly applicable EU regulation — not a directive requiring transposition. It binds 20+ categories of financial entities across all 27 Member States: banks, investment firms, insurance and reinsurance undertakings, asset managers, payment institutions, electronic money institutions, central securities depositories, trading venues, CCPs, and more. The full list appears in Article 2(1).

The regulation’s objective is specific: ensure that financial entities can withstand, respond to, and recover from ICT-related disruptions and threats. It does this by establishing uniform requirements across five pillars, each backed by detailed Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) developed by the ESAs (EBA, EIOPA, ESMA) and finalized in 2024.

As of January 2025, compliance is legally required. The transitional period is over. For insureds still treating this as aspirational, the enforcement risk is now real.

For a broader look at how DORA affects underwriting, see NIS2 and DORA: What Cyber Underwriters Need to Know.

The Five Pillars of the DORA ICT Risk Management Framework

Pillar 1: ICT Risk Management (Articles 5–16)

This is the backbone. Article 5 requires every financial entity to have a comprehensive ICT risk management framework proportionate to its size, complexity, and risk profile. The framework must cover:

• Identification: Mapping all ICT assets, systems, processes, and interdependencies (Art. 8)
• Protection and prevention: Access controls, encryption, vulnerability management, and change management (Art. 9)
• Detection: Continuous monitoring of ICT systems and anomalies (Art. 10)
• Response and recovery: Incident management, business continuity plans, and disaster recovery (Art. 11)
• Learning and evolution: Post-incident reviews, gap analysis, framework updates (Art. 12)

The RTS on ICT risk management (EBA/RTS/2024/02) specifies that the framework must be approved by the entity’s management body and reviewed at least annually. It must also be integrated into the entity’s overall risk management framework — not siloed as an IT matter.

Underwriting implication: If the insured cannot produce a board-approved ICT risk management framework with evidence of annual review, that is a material gap. Ask for the most recent board minute reflecting formal approval.

Pillar 2: ICT-Related Incident Reporting (Articles 17–23)

DORA establishes a tiered incident reporting regime with three notification types:

Report Type	Deadline	Recipient
Initial notification	Within 4 hours of classification	Competent authority
Intermediate report	Within 72 hours	Competent authority
Final report	Within 1 month	Competent authority

Article 18 defines classification criteria: incidents must be reported if they cause or may cause significant operational or financial impact, or affect the provision of critical services. The ESAs’ ITS on incident reporting (EIOPA/ITS/2024/003) standardizes reporting templates across all financial subsectors — a significant harmonization compared to the previous patchwork.

Major incidents must also be reported to the relevant CSIRT under NIS2 where applicable. See our NIS2 Incident Reporting Requirements Guide for the parallel NIS2 timeline.

Underwriting implication: Request the insured’s incident classification procedure and a count of DORA-reportable incidents since January 2025. Zero reports is not necessarily a good sign — it may indicate failure to detect or classify.

Pillar 3: Digital Operational Resilience Testing (Articles 24–27)

Article 24 requires financial entities to establish a comprehensive testing programme that includes:

1. Vulnerability assessments and open-source analyses — at least annually
2. Scenario-based testing — incorporating plausible threats relevant to the entity
3. Penetration testing — risk-based frequency
4. Advanced Threat-Led Penetration Testing (TLPT) — mandatory for significant entities

TLPT (Art. 26) is the most demanding component. It requires red-team exercises conducted by independent external parties, overseen by the entity’s lead overseer under the Joint Examinations Network. The TLPT programme runs on a 3-year cycle: preparation, testing, and remediation phases. The ESAs’ RTS on TLPT (EBA/RTS/2024/08) specifies that tests must be conducted on live production systems.

“Significant entities” are designated by competent authorities based on size, market impact, and systemic importance. The threshold varies by subsector.

Underwriting implication: Ask whether the insured is classified as a significant entity. If yes, request the TLPT remediation tracker. If no, verify that their scenario-based testing programme is risk-proportionate and actually executed — not just documented.

Pillar 4: ICT Third-Party Risk Management (Articles 28–44)

This is where DORA has the broadest reach beyond financial entities. Articles 28–44 establish a comprehensive framework for managing ICT third-party service provider risk, including:

• Due diligence before contracting (Art. 30)
• Contractual requirements: audit rights, exit strategies, data localization, incident notification obligations, service level agreements (Art. 30(2))
• Ongoing monitoring and periodic reviews (Art. 31)
• Concentration risk assessment — identifying critical dependencies on single providers (Art. 31(5))
• Intruder access rights: ensuring contracts grant auditors and competent authorities access to provider systems

The Register of Information (Art. 28) is a critical deliverable. Every financial entity must maintain a detailed register of all contractual arrangements with ICT third-party service providers, including service descriptions, criticality assessments, and concentration risk indicators. The ESAs’ ITS on the register (EIOPA/ITS/2024/006) provides the standardized template.

For deeper coverage of supply chain risk management principles, see our NIS2 Supply Chain and Third-Party Risk Management Guide.

Underwriting implication: Request the Register of Information. Pay particular attention to concentration risk — entities heavily dependent on a single cloud provider (e.g., AWS hosting 85%+ of critical workloads) present aggregation risk that should inform retention and pricing decisions.

Pillar 5: Information Sharing (Article 45)

Article 45 enables — but does not mandate — financial entities to share cyber threat intelligence and incident-related data through recognized Information Sharing Arrangements (ISAs). These can be facilitated by:

• ISACs (Information Sharing and Analysis Centers)
• Computer Emergency Response Teams
• Trade associations acting as intermediaries

Information shared under DORA ISAs benefits from liability protections (Art. 45(7)) — entities acting in good faith are shielded from liability arising from the sharing itself. Participants must implement appropriate safeguards including anonymization and access controls.

Underwriting implication: Participation in an ISA is a positive risk indicator. It signals active engagement with the threat landscape. Ask which ISA the insured participates in and what threat intelligence feeds are integrated into their SOC.

DORA’s Dual Application: Financial Entities vs. ICT Third-Party Service Providers

DORA regulates two distinct populations, and understanding this distinction matters for both compliance and underwriting.

Financial Entities (Direct Obligations)

Articles 2–4 define the in-scope entities. These organizations bear the full weight of all five pillars. They must implement the ICT risk management framework, report incidents, conduct testing, manage third-party risk, and may share threat intelligence.

Key point: DORA applies proportionality. Microenterprises (fewer than 10 employees and ≤€2 million annual turnover or balance sheet) are exempt from most requirements but remain subject to specific provisions on incident reporting (Art. 3).

ICT Third-Party Service Providers (Articles 28–44, Indirect Oversight)

ICT third-party service providers are not directly regulated by DORA in the same way. Instead, DORA creates an indirect oversight mechanism:

• Financial entities impose DORA requirements contractually on their providers
• The ESAs maintain a registry of critical ICT third-party service providers (Art. 34)
• Designated critical providers are subject to direct oversight by a Lead Overseer appointed from the ESAs via the Joint Examinations Network
• Lead Overseers can conduct inspections, issue recommendations, and — in extreme cases — issue penalty payments up to €5 million or 1% of average daily worldwide turnover for up to six months (Art. 36)

The first designations of critical ICT third-party service providers were completed in 2025, with major cloud providers (AWS, Microsoft Azure, Google Cloud), data analytics firms, and core banking platform providers among the first cohort.

Underwriting implication: For insurers writing policies on ICT service providers serving EU financial institutions, DORA creates a new regulatory surface. Ask whether the insured has been designated as a critical provider and, if so, what the Lead Overseer’s most recent assessment found.

Key Compliance Deadlines and Ongoing Requirements

The primary compliance date was 17 January 2025 — the date DORA became applicable. But compliance is not a one-time event. The ongoing obligations include:

Requirement	Frequency	Reference
ICT risk management framework review	Annual minimum	Art. 5(2)
ICT risk management policy update	After material changes	Art. 6
Vulnerability assessments	Annual minimum	Art. 24
TLPT cycle (significant entities)	Every 3 years	Art. 26
Register of Information update	Continuous	Art. 28
Third-party contract alignment	By 17 January 2025 (existing); ongoing	Art. 30(4)
Incident reporting	Per event (4h / 72h / 1 month)	Art. 17–20
Concentration risk review	Annual	Art. 31(5)

The contractual alignment requirement deserves attention. Article 30(4) required financial entities to bring existing contracts with ICT third-party providers into compliance with DORA’s contractual requirements by 17 January 2025. In practice, many entities negotiated transition periods with providers — and the ESAs acknowledged this reality in their supervisory statements. However, as of 2026, supervisory patience is wearing thin.

DORA and NIS2: Which Regulation Applies When

This is one of the most frequently asked questions, and the answer has practical consequences for both compliance teams and underwriters.

The relationship is governed by the lex specialis principle. DORA, as a sector-specific regulation, takes precedence over NIS2 for financial entities on matters covered by DORA. Article 4 of DORA explicitly states that financial entities as defined in Article 2(1) are excluded from the scope of NIS2 in areas where DORA applies.

However, the interaction is nuanced:

• Incident reporting: Financial entities report under DORA to their financial competent authority. Major incidents may require parallel CSIRT notification under NIS2. In practice, the ESAs and ENISA are working to streamline this via common reporting formats.
• Supply chain risk: DORA’s third-party risk management provisions are more granular than NIS2’s. For financial entities, DORA prevails.
• Governance and management body liability: Both DORA and NIS2 impose personal accountability on management bodies. DORA’s provisions (Art. 5(2), Art. 6) are more prescriptive for financial entities.
• Entities outside DORA’s scope: If an organization provides ICT services to financial entities but is not itself a financial entity, it may fall under NIS2 as an essential or important entity rather than DORA.

For detailed NIS2 compliance requirements, see our NIS2 Directive Compliance Guide.

Underwriting shortcut: If the insured is a financial entity, DORA is the primary regulatory framework. NIS2 is secondary. If the insured is an ICT service provider to financial entities, NIS2 may be their primary obligation unless designated as a critical ICT third-party provider under DORA. Map this correctly in your risk assessment.

What Underwriters Should Ask: DORA Compliance Evaluation Checklist

When evaluating DORA compliance for an insured financial institution, these questions should be embedded in your risk assessment workflow:

Governance and Framework

1. Has the management body formally approved the ICT risk management framework? When was the most recent approval?
2. Is there a named Chief Information Security Officer or equivalent with direct board reporting?
3. Does the framework undergo annual independent review? By whom?

Incident Reporting

4. How many DORA-reportable incidents have been filed since January 2025?
5. What is the average time from detection to initial notification?
6. Has the entity tested its incident reporting procedures against the 4-hour deadline?

Testing Programme

7. Is the entity classified as “significant” for TLPT purposes?
8. When was the most recent TLPT or scenario-based test conducted?
9. What percentage of critical findings from the last test have been remediated?

Third-Party Risk

10. Can the entity produce its Register of Information?
11. What is the concentration ratio for critical ICT services (e.g., percentage of critical workloads on a single cloud provider)?
12. Do contracts with critical ICT providers include DORA-compliant audit rights and exit strategies?

Information Sharing

13. Does the entity participate in an ISA? Which one?
14. What threat intelligence feeds are consumed and how are they operationalized?

For more underwriting-focused questions across the broader EU regulatory landscape, see NIS2 Underwriting Questions for Brokers.

Penalties and Enforcement Mechanisms

DORA’s enforcement architecture is built on existing supervisory structures — it does not create a new EU-level regulator. Instead, it mandates that national competent authorities (NCAs) for financial services enforce DORA requirements within their jurisdictions.

Key enforcement provisions:

• Supervisory powers: NCAs can issue warnings, fines, restrictions on business activities, and temporary bans on new product launches (Art. 47)
• Penalty ranges: Member States must establish “effective, proportionate, and dissuasive” penalties. The regulation does not prescribe maximum amounts for financial entities, leaving this to national transposition — but guidance suggests alignment with existing sectoral penalty frameworks (typically up to €5 million or 1–2% of annual turnover)
• Personal liability: Management body members can be held personally accountable for failure to implement adequate ICT risk management (Art. 5(2))
• Critical ICT third-party providers: Face specific penalty provisions — up to €5 million or 1% of average daily worldwide turnover for up to six months (Art. 36(8))

As of early 2026, the first supervisory reviews under DORA are underway. The ESAs’ 2025 annual reports indicate that initial supervisory focus has been on the largest systemic institutions, with thematic reviews on third-party risk management and concentration risk planned for 2026–2027.

Underwriting implication: Request the insured’s most recent supervisory correspondence or examination findings related to DORA. Unresolved supervisory findings are material risk factors.

Cross-Border Supervisory Cooperation

DORA’s cross-border architecture is one of its most innovative features. For significant entities and critical ICT third-party service providers, oversight involves:

The Joint Examinations Network (JEN)

Established under Art. 49, the JEN brings together relevant NCAs, the ESAs, and — where relevant — competent authorities from non-EU jurisdictions. The JEN coordinates examinations, shares findings, and ensures consistent supervisory outcomes.

Lead Overseer Model

For critical ICT third-party service providers, a Lead Overseer is designated from one of the ESAs (EBA, EIOPA, or ESMA) based on the provider’s primary financial sector exposure. The Lead Overseer:

• Conducts risk assessments and on-site inspections
• Issues recommendations and, if necessary, penalty payments
• Coordinates with other relevant authorities through the JEN

colleges of Supervisors

For significant financial entities operating across multiple Member States, DORA mandates the establishment of supervisory colleges — mirroring existing arrangements under sectoral financial legislation (CRD, Solvency II, MiFID II).

Practical point: For multinational financial groups, DORA compliance is not 27 separate national exercises. The college structure ensures a coordinated approach — but the lead supervisor’s expectations will set the tone. Identify the lead supervisor early in your underwriting process.

Practical Compliance Roadmap for Financial Institutions

For entities still maturing their DORA compliance — or for underwriters assessing where an insured stands — the following roadmap reflects the prioritization that supervisory experience has validated:

Phase 1: Foundation (Completed by January 2025 — Non-Negotiable)

• Formal adoption and board approval of the ICT risk management framework
• Establishment of the Register of Information for all ICT third-party arrangements
• Implementation of incident classification and reporting procedures
• Initial vulnerability assessment programme

Phase 2: Maturation (2025–2026)

• Completion of first TLPT cycle (for significant entities)
• Concentration risk mapping and mitigation planning
• Contract renegotiation with critical ICT providers to achieve DORA alignment
• Integration of DORA requirements into internal audit workplans

Phase 3: Optimization (2026–2027)

• Automated continuous monitoring of ICT risk indicators
• Threat intelligence operationalization through ISA participation
• Remediation tracking from TLPT findings
• Preparation for thematic supervisory reviews on third-party risk

Phase 4: Evidence of Embedded Practice (Ongoing)

• Regular board reporting on ICT risk posture
• Demonstrable improvement cycle — evidence that findings drive changes
• Mature concentration risk management with viable alternative provider strategies
• Fully operationalized incident response with measured time-to-notify performance

Insurance Implications: Where DORA Meets the Policy

DORA has specific implications for cyber insurance that go beyond general regulatory compliance:

Aggregate risk management: Concentration risk requirements (Art. 31(5)) force financial entities to examine single-provider dependencies. For insurers, this is the same concentration analysis — but applied to your portfolio. How many of your insureds use the same cloud provider? How many rely on the same core banking platform?

Business interruption exposure: DORA’s testing requirements are designed to reduce the probability and impact of ICT disruptions. Entities with mature testing programmes should demonstrate lower BI frequency. Use TLPT results as a direct input to BI exposure modeling.

Regulatory fines insurability: While DORA penalties may not always be insurable under standard cyber policies (depending on jurisdiction and policy wording), the costs of regulatory investigation, remediation, and compliance uplift are real first-party losses that policies should address.

Supply chain liability: As DORA’s third-party oversight regime matures, ICT providers designated as critical will face their own regulatory costs and penalties. This creates new underwriting opportunities for specialist products.

For guidance on structuring coverage in this evolving regulatory environment, see our Cyber Insurance Buying Guide.

Conclusion

The DORA ICT risk management framework is the most comprehensive regulatory intervention in financial sector operational resilience to date. Its five pillars create a structured, testable compliance architecture that — when properly implemented — materially reduces ICT risk.

For underwriters and risk engineers, DORA provides something rare in cyber risk assessment: a standardized, enforceable framework that produces auditable evidence. Use it. Ask the right questions. Request the documentation. And recognize that DORA compliance, properly evidenced, is one of the strongest positive risk signals available for EU financial institution risks in 2026.

The entities that treat DORA as a compliance burden will lag. The ones that embed it into operational practice will be the better risks — and the better insureds.

---

Need to assess DORA compliance for your insureds? Our regulatory compliance assessment tools map directly to DORA’s five pillars. Get started with Resiliently.