RegTech

DORA Compliance Guide: 8 Steps for Financial Institutions in 2026

IgeraSolutions RegTech Team
June 29, 2026
12 min read
Financial institution compliance team implementing DORA regulation requirements 2026
RegTech · DORA · ICT Risk · Financial Institutions

DORA Compliance Guide for Financial Institutions 2026: 8 Implementation Steps

DORA (Regulation EU 2022/2554) has been enforceable since 17 January 2025. Financial institutions must implement ICT risk management frameworks, report major incidents to their national competent authority within 4 hours of classification, and maintain complete third-party risk registers. Penalties reach 2% of global annual turnover for financial entities, and up to 1% of average daily worldwide turnover per day for critical ICT third-party providers. This guide covers the 8 key implementation steps compliance teams need to follow in 2026, drawing on the final Regulatory Technical Standards (RTS) published by the ESAs in July 2024.

DORA at a Glance

  • Entry into force: 17 January 2025 (Regulation (EU) 2022/2554)
  • Who must comply: 20+ categories of financial entities + ICT third-party service providers
  • Key pillars: 5 — ICT Risk Management, Incident Reporting, Digital Resilience Testing, Third-Party Risk, Information Sharing
  • Penalty ceiling: 2% of global annual turnover (financial entities) | up to 1% of average daily worldwide turnover per day for critical ICT third-party providers
  • RTS published: EBA/ESMA/EIOPA, 17 July 2024

Who Must Comply with DORA in 2026

DORA applies to a wide range of financial entities operating in the EU, irrespective of the country in which they are established. The regulation also extends to ICT third-party service providers that supply technology services to financial entities. The full list of in-scope entities covers more than 20 categories under Article 2 of the Regulation.

Entity TypeRegulatory Sector
Credit institutionsBanking
Payment institutionsPayments
Electronic money institutionsPayments
Investment firmsCapital markets
Insurance & reinsurance undertakingsInsurance
Crypto-asset service providers (CASPs)DeFi / Digital assets
ICT third-party service providersTechnology
Credit rating agenciesData & analytics
Trading venuesMarket infrastructure

Proportionality principle: Microenterprises — defined as entities with fewer than 10 employees and an annual turnover or balance sheet total not exceeding €2 million — qualify for a simplified ICT risk management regime under Article 16 of DORA. However, they are not fully exempt. Core obligations around incident classification, third-party contractual requirements, and information security policies still apply. Entities should confirm their classification with their national competent authority (NCA) before assuming simplified treatment.

The 5 DORA Pillars: What You Need to Implement

Pillar 1 — ICT Risk Management (Art. 6–10)

Establish a comprehensive, board-approved ICT risk management framework covering asset mapping, risk identification, protection measures, detection mechanisms, and continuous monitoring. The RTS on ICT risk management tools (CDR 2024/1774) specifies minimum policy requirements including patch management SLAs, cryptography policy, and SIEM baseline documentation.

DORA article: Art. 6–10 | RTS: CDR 2024/1774 | Common gap: No board-level ownership of the ICT risk management policy

Pillar 2 — Incident Reporting (Art. 17–23)

Classify, manage, and report major ICT-related incidents to competent authorities within strict timelines: initial notification within 4 hours, intermediate report within 72 hours, and a final report within one month of resolution. Standardised reporting templates are set out in the ITS on incident reporting published by EBA/ESMA/EIOPA.

DORA article: Art. 17–23 | ITS: ITS on incident reporting templates | Common gap: Incident classification criteria not aligned with DORA thresholds

Pillar 3 — Digital Resilience Testing (Art. 24–27)

All in-scope entities must conduct annual basic digital resilience testing (vulnerability assessments, scenario-based tests). Significant financial entities identified by their NCA must also conduct Threat-Led Penetration Testing (TLPT) at least every 3 years using an approved external tester following the TIBER-EU methodology.

DORA article: Art. 24–27 | RTS: RTS on TLPT | Common gap: Conflating standard penetration testing with DORA-compliant TLPT

Pillar 4 — ICT Third-Party Risk Management (Art. 28–44)

Maintain a complete register of all ICT third-party service providers, including fourth-party sub-contractors. Ensure contracts include DORA-mandated clauses covering audit rights, service levels, exit strategies, and incident reporting obligations. Critical third-party providers designated by the ESAs face direct supervisory oversight. 68% of European financial institutions did not have a complete ICT third-party risk register as at 31 December 2024 (Igera sectoral survey).

DORA article: Art. 28–44 | RTS: RTS on subcontracting ICT services | Common gap: Missing fourth-party entries and contractual audit rights clauses

Pillar 5 — Information Sharing (Art. 45)

Financial entities may voluntarily participate in cyber threat intelligence-sharing arrangements with other financial institutions. While participation is not mandatory, supervisors view active engagement favourably as evidence of a mature digital operational resilience programme.

DORA article: Art. 45 | Common gap: No internal process to review and act on shared threat intelligence

DORA Implementation: 8 Steps for Compliance Teams

Step 1 — Conduct your ICT risk assessment (Art. 6–10)

Identify all information assets, map dependencies across business functions, and classify risks by likelihood and impact. This assessment forms the backbone of your DORA ICT risk management framework and must be approved by the management body. Review it at least annually and after any significant ICT change.

Common mistake: Relying on pre-DORA risk registers that do not cover ICT-specific threat scenarios required under EBA RTS CDR 2024/1774.

Step 2 — Map all ICT third-party providers (Art. 28)

Build or update your ICT third-party register to include all providers, sub-contractors, and cloud services used across the organisation. Classify each by criticality to your business functions. The ITS on the register of information (CDR 2024/2956) specifies mandatory fields and standardised templates for annual submission to NCAs.

Common mistake: Omitting fourth-party (sub-contractors of ICT providers) from the register, which the RTS on subcontracting explicitly requires.

Step 3 — Classify incidents by DORA severity criteria (Art. 18–19)

Apply the five classification criteria from the ITS on incident reporting: number of clients affected, data losses, service duration, geographic spread, and economic impact on the entity. Only incidents meeting the “major incident” threshold trigger the 4-hour notification obligation.

Common mistake: Using internal severity scales that do not map to the DORA regulatory thresholds, leading to under-reporting or incorrect classifications.

Step 4 — Set up the 4-hour initial notification process (Art. 19)

Define who triggers the notification, which competent authority receives it (your NCA), and what minimum content must be included. Document the escalation path from incident detection to classification to notification dispatch. Automate where possible using your SIEM or incident management platform.

Common mistake: Assigning notification responsibility to IT teams without legal or compliance oversight of the regulatory content and timing.

Step 5 — Run TLPT if applicable (Art. 26)

Significant financial entities identified by their NCA must conduct Threat-Led Penetration Testing at least every 3 years. TLPT must use an approved external tester and follow the intelligence-led TIBER-EU methodology. Results must be shared with the NCA and remediation actions documented within 3 months.

Common mistake: Assuming standard annual penetration tests satisfy the TLPT requirement — DORA TLPT follows a specific intelligence-led methodology that is materially different.

Step 6 — Update contracts with ICT providers (Art. 30)

DORA Article 30 mandates specific contractual provisions for all ICT service agreements supporting critical or important functions: defined service levels, audit rights, data location disclosure, incident reporting obligations, and termination and exit assistance rights. Review and update all provider contracts, prioritising critical third-party providers first.

Common mistake: Sending a generic addendum without verifying that all Article 30 mandatory clauses are explicitly addressed, particularly audit rights and exit assistance.

Step 7 — Train the board and senior management (Art. 5)

DORA places explicit responsibility on the management body. Directors must follow ICT risk training, be capable of challenging ICT risk reports, and are personally accountable for approving the ICT risk management framework. The CISO (or equivalent function) must report to the management body at least once a year.

Common mistake: Treating DORA training as an IT department exercise — supervisors are examining board minutes for evidence of substantive ICT risk discussions.

Step 8 — Document, audit, and iterate (Art. 16)

Maintain living records of your ICT risk management framework, testing outcomes, incident reports, and third-party provider reviews. DORA requires an independent review of the ICT risk management framework at least annually (Art. 15). All documentation is subject to supervisory inspection without prior notice.

Common mistake: Documenting the framework once at implementation and not keeping evidence current — DORA requires a continuously maintained and auditable compliance programme.

DORA Incident Reporting: The 4-Hour Rule Explained

Article 19 of DORA introduces a three-stage reporting obligation for major ICT-related incidents. The clock starts from the moment the entity classifies an incident as “major” using the criteria in the ITS on incident reporting templates, not from the moment of detection. This distinction is critical for compliance teams designing their incident response workflows.

StageTimelineContent RequiredRecipient
Initial notificationWithin 4 hours of classification as majorBasic incident facts, initial impact assessmentNCA (national competent authority)
Intermediate reportWithin 72 hours of initial notificationUpdated impact scope, containment actions takenNCA + EBA/ESMA/EIOPA (as applicable)
Final reportWithin 1 month of incident resolutionRoot cause analysis, lessons learned, permanent fixesNCA + ESAs

Major incident vs significant cyber threat:

  • Major incident: meets at least one of the DORA classification thresholds set out in the ITS (e.g., number of clients impacted, data losses, duration of service disruption, geographic spread, economic impact). Triggers the mandatory three-stage reporting obligation.
  • Significant cyber threat: a potential attack that, if materialised, would constitute a major incident. Under Art. 19(2), notification to the NCA is recommended but not mandatory. Swift voluntary notification is considered good practice by supervisors.

The ITS published by EBA/ESMA/EIOPA in July 2024 provides standardised templates for all three reporting stages. These templates are mandatory for entities supervised directly by the ECB and are expected to be adopted as best practice by all NCAs across EU member states.

How IgeraRegTech Supports DORA Compliance

Keeping pace with DORA’s evolving RTS, ITS, and supervisory guidance is a substantial workload for compliance teams managing day-to-day regulatory obligations. The full regulatory corpus — Regulation (EU) 2022/2554, three Delegated Regulations, three Implementing Regulations, ESA Q&As, and NCA supervisory expectations — runs to several hundred pages of technical text.

IgeraRegTech is an AI-powered regulatory intelligence platform that indexes the complete DORA text alongside all EBA/ESMA/EIOPA RTS and ITS, supervisory Q&As, and sector guidance. Compliance officers and IT risk managers query the platform in plain language and receive precise, article-level cited answers — specifying the exact DORA provision and technical standard that applies to their question.

Anonymous case study: Spanish bank, 450 employees

“A mid-size Spanish bank with 450 employees deployed IgeraRegTech ahead of the DORA enforcement date. The compliance team reduced DORA regulatory research time by 70%, accelerated third-party contract reviews using automatically generated Article 30 clause checklists, and passed their NCA supervisory review without receiving any remediation requests.”

Explore how IgeraRegTech can cut your DORA compliance research time. Visit IgeraRegTech or start a 14-day free trial at igerasolutions.com/igeraregtech.

Ready to simplify your DORA compliance programme?

IgeraRegTech gives your compliance team instant, cited answers on DORA obligations — from ICT risk management to incident reporting timelines.

Start Free Trial — 14 Days

No credit card required. GDPR compliant. Available in EN, ES, FR, DE.

Frequently Asked Questions — DORA 2026

Does DORA apply to my institution if we are below the microenterprise threshold?

Microenterprises with fewer than 10 employees and annual turnover or balance sheet under €2 million qualify for the simplified ICT risk management regime under Article 16. However, they are not exempt from all DORA obligations — core requirements around incident classification, third-party contractual provisions, and information security policies still apply. Confirm your classification with your NCA before assuming simplified treatment applies to your entity.

What is the difference between DORA and NIS2?

NIS2 is a broad cybersecurity directive covering multiple sectors (energy, health, transport, digital infrastructure), while DORA is a sector-specific regulation exclusively for financial entities. DORA is more prescriptive: it mandates specific incident reporting timelines (4-hour initial notification), detailed contractual requirements with ICT providers, and TLPT testing for significant entities. Where both frameworks apply to a financial entity, DORA takes precedence under its lex specialis principle. See our full DORA vs NIS2 comparison for a detailed breakdown.

What are the penalties for non-compliance with DORA?

For financial entities, administrative penalties can reach 2% of total annual worldwide turnover. For critical ICT third-party service providers under direct ESA oversight, periodic penalty payments can reach 1% of average daily worldwide turnover per day, applied for up to six months. Member States may impose additional criminal or administrative sanctions under national law. The reputational risk of a public supervisory finding — which NCAs are required to publish — often exceeds the financial penalty itself.

Do ICT third-party providers need to be registered with supervisory authorities?

Not all of them. Only ICT third-party providers formally designated as “critical” by the Joint Committee of ESAs are subject to direct supervisory oversight. Financial institutions, however, must maintain a complete register of all ICT providers — critical or otherwise — and ensure DORA-compliant contractual clauses are in place for every service that supports a critical or important function within the institution.

Is TLPT mandatory for all financial institutions?

No. Threat-Led Penetration Testing under Article 26 is mandatory only for financial entities explicitly identified by their NCA as required to conduct it. In practice, this applies to larger, systemically important institutions. Smaller entities are subject to the basic digital resilience testing programme under Article 25, which covers vulnerability assessments, open-source analyses, and scenario-based testing — without the full TIBER-EU intelligence-led methodology.

How does AI (RAG) help with DORA compliance documentation?

AI-powered regulatory intelligence tools using Retrieval-Augmented Generation (RAG) allow compliance teams to query DORA’s full regulatory text — including RTS, ITS, and ESA Q&As — in plain language and receive cited, article-level answers in seconds. This is particularly valuable for third-party risk assessments, DORA article 17 incident classification decisions, drafting Article 30 contract clauses, and preparing board-level DORA compliance reports. Unlike general-purpose AI tools, RAG systems grounded on the official regulatory corpus eliminate the risk of hallucinated regulatory references.

Three findings stand out from this guide that compliance and IT risk teams should act on immediately:

  1. DORA is enforceable now. The 17 January 2025 deadline has passed and supervisory inspections are already underway across EU member states. There is no grace period for institutions that have not yet implemented the framework.
  2. Third-party risk is the most common compliance gap. With 68% of institutions lacking a complete ICT provider register at end of 2024, Pillar 4 (ICT Third-Party Risk Management) should be the first priority for any institution behind on implementation.
  3. Incident reporting timelines are strict and non-negotiable. The 4-hour initial notification window for major incidents requires pre-built escalation processes, trained teams, and tested workflows — not ad-hoc responses assembled during a live incident.

Use IgeraRegTech to run a structured DORA gap assessment across your organisation. Start with Pillars 1 (ICT Risk Management) and 4 (Third-Party Risk), where supervisory scrutiny is concentrated, and build your remediation roadmap from there.

Last updated: June 2026 | Author: IgeraSolutions RegTech Team | Reviewed by: Igera Compliance Team | Sources: Regulation (EU) 2022/2554, EBA/ESMA/EIOPA RTS July 2024, ESAs Joint Guidelines on ICT Risk Management

#DORA compliance guide 2026#Digital Operational Resilience Act implementation#DORA ICT risk management#DORA incident reporting 4 hours#IgeraRegTech DORA

COMPARTIR

Comparte el conocimiento con tu red