DORA in 2026: What Banks, Fintechs and Insurers Need

DORA enforcement is active. The Digital Operational Resilience Act has been fully applicable since 17 January 2025, and national competent authorities across the EU are now running formal supervisory reviews. For banks, fintechs, and insurers, what matters in 2026 is whether your ICT risk framework, Register of Information, and incident response capability hold up under that scrutiny, and where supervisors are focusing their attention depends heavily on which of the three sectors you sit in.

DORA is the EU's Digital Operational Resilience Act, formally Regulation (EU) 2022/2554. It entered into force on 16 January 2023 and became fully applicable on 17 January 2025. It establishes binding requirements for ICT risk management, incident reporting, digital operational resilience testing, third-party risk oversight, and information sharing across financial services.

The regulation applies to over 22,000 financial entities across the EU, including banks, payment institutions, e-money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, and critical ICT third-party providers (CTPPs). The EBA, ESMA, and EIOPA jointly oversee implementation and have published the Regulatory Technical Standards that underpin the regulation's detailed requirements.

Proportionality: Obligations Scale by Entity Type

DORA applies a proportionality principle. The framework simplifies ICT risk management for microenterprises and smaller institutions under Article 16; the Register of Information, incident reporting, and third-party risk obligations still apply regardless of size. Larger and systemically significant entities face the full framework, including threat-led penetration testing (TLPT) obligations.

EU-Level Coordination: The Oversight Forum

DORA's third-party oversight doesn't stop at the individual institution. Under Article 31, the ESAs designate certain ICT providers as critical (CTPPs) and appoint one of themselves as Lead Overseer for each, responsible for coordinating supervision across the Union. The Lead Overseer works through a Joint Examination Team (JET), a dedicated group combining ESA and national competent authority staff for each CTPP, established under Article 40.

The Oversight Forum, the ESAs' standing committee for DORA oversight under Article 32, keeps this approach consistent across CTPPs and prepares the collective recommendations the Joint Committee issues. As of November 2025, 19 providers, including AWS, Microsoft, and Google Cloud, are formally designated as CTPPs and sit under this direct EU-level oversight.

DORA is structured around five interconnected pillars. Understanding what each one requires operationally is the foundation for any compliance programme.

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

The ICT risk management framework needs documenting, board approval, and review at least annually. It must cover identification, protection, detection, response, and recovery. The board carries explicit, personal accountability here: DORA requires management bodies to define, approve, and own the ICT risk strategy themselves.

1. ICT risk appetite statement approved by the management body.
2. Asset register covering all ICT systems supporting critical or important functions.
3. Business impact analysis (BIA) for all critical functions.
4. Recovery time and recovery point objectives (RTOs and RPOs) tested and documented.
5. Lessons-learned process after every significant ICT incident.

Pillar 2: ICT Incident Management and Reporting (Articles 17-23)

DORA introduces a harmonised classification methodology for ICT-related incidents and a mandatory reporting timeline for major incidents: initial notification to the NCA within 4 hours of classification, an intermediate report within 72 hours, and a final report within one month.

A common finding in 2026: institutions that have never submitted a major incident report are drawing supervisory scrutiny. NCAs increasingly read a zero-notification record as a signal to check whether the classification methodology itself is actually working.

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

All in-scope entities must run basic resilience testing annually, including vulnerability assessments and scenario-based testing. Designated entities, usually significant institutions, must additionally complete threat-led penetration testing (TLPT) every three years, with the first TLPT cycle due by January 2028. TLPT has to be conducted by qualified external testers using the TIBER-EU framework or national equivalents, with results shared with the NCA

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

Third-party risk is where DORA introduces its most operationally significant new obligations. Every in-scope entity must maintain a Register of Information documenting all contractual arrangements with ICT third-party providers, classify each arrangement by whether it supports a critical or important function, and ensure contracts supporting critical functions include DORA-mandated clauses: audit rights, exit plans, performance SLAs, and sub-contractor visibility. The Register must go to the NCA on request, and in some jurisdictions on an annual basis.

The Register of Information is the single most scrutinised DORA artefact in 2026. Incomplete registers, missing criticality assessments, and contracts without DORA-compliant clauses are the most common findings in first-wave supervisory reviews, covered in full further down this guide.

Pillar 5: Information and Intelligence Sharing (Article 45)

DORA encourages voluntary participation in information-sharing arrangements on cyber threats and vulnerabilities. Participation needs governing by a documented policy that complies with GDPR and data protection obligations wherever personal data is involved.

The same regulation creates different pressure points depending on which sector you sit in. Use this as a quick reference before the sector-by-sector detail below.

Banks face the most intensive DORA obligations. Significant institutions supervised directly by the ECB sit under the full framework with no simplifications, and the ECB has built DORA into its supervisory examination priorities for 2026.

Where Banks Are Under the Most Pressure

ICT risk governance at board level

The ECB's 2026 supervisory priorities require management bodies to demonstrate active oversight of ICT risk that goes beyond policy approval. Banks need to evidence board engagement: minutes showing ICT risk on the agenda, challenge questions from non-executive directors, and a named management body member with explicit accountability.

Register of Information completeness

First-wave ECB desk reviews have found many banks submitted Registers with incomplete criticality assessments, missing sub-contractor chains, and contracts predating DORA that still await renegotiation. Remediation letters with 60-day timelines have followed.

Concentration risk

Banks that depend heavily on a small number of cloud providers, usually two or three hyperscalers, are being asked to show that concentration risk has been assessed, that exit plans exist, and that substitutability has at least been assessed in principle.

In practice, these pressures show up as parallel spreadsheets for assets and suppliers with no single owner, resilience tests that never get retested after a fix, and incident report fields that don't match what the NCA actually asks for, which forces rework in the first 24 hours of a live incident.

What Good Looks Like for Banks

1. Board-approved ICT risk appetite with quantified tolerances.
2. Register of Information covering 100% of ICT third-party arrangements, with criticality classification for each.
3. DORA-compliant contract clauses in all agreements supporting critical or important functions, with a remediation tracker for legacy contracts.
4. Tested RTOs and RPOs for all critical functions, with evidence of testing dates and outcomes.
5. A major incident classification methodology that has actually been exercised, with documented rationale for past classification decisions, including decisions not to classify as major.

But the board accountability gap remains the most common finding for banks. Supervisors aren't satisfied with a CISO presenting to the board once a year; they want evidence that the management body understands, challenges, and owns ICT risk directly.

Fintechs face a different challenge from banks. Most aren't systemically significant, but many still sit in scope for the full DORA framework as payment institutions, e-money institutions, or investment firms. The proportionality principle helps smaller entities, but the Register of Information, incident reporting, and third-party risk obligations still apply.

The Fintech-Specific Compliance Gaps

Third-party dependency is structural

Fintechs commonly run on cloud-native stacks with deep dependencies on hyperscalers, payment processors, open banking API providers, and SaaS infrastructure. Every one of those relationships needs a Register of Information entry, a criticality assessment, and, for critical function providers, DORA-compliant contract terms. For many fintechs, that means renegotiating contracts with providers who hold significant bargaining power.

Incident classification at speed

Fintechs often run lean operations teams. The 4-hour initial notification window for major incidents assumes a classification process that can run at pace, 24/7, and many fintechs lack the on-call structure and documented decision trees to meet that timeline consistently.

Proportionality requires documentation

If a fintech relies on the simplified framework under Article 16, that reliance needs documenting and justifying against the threshold criteria. Supervisors expect that assessment documented and recorded, with evidence behind it.

In practice, these gaps show up as a polished policy document with no operational proof connected to it, vendor sprawl with no refresh cadence for supplier artefacts, and incident timelines improvised live during the event instead of rehearsed in advance.

What Good Looks Like for Fintechs

The growth trap: fintechs scaling fast often find their Register of Information is out of date within months of submission. Third-party relationships added during a product launch or infrastructure migration can go uncaptured. Treat the Register as a living document with a mandatory update trigger on every new ICT procurement decision.

Insurers and reinsurers sit under DORA's full framework, supervised by EIOPA. For many, DORA runs alongside Solvency II operational risk requirements, and the two frameworks share enough common ground that a well-structured DORA programme can integrate with existing Solvency II governance rather than being built in parallel.

Where Insurers Face the Most Complexity

Legacy ICT estate

Large insurers often run multiple legacy policy administration systems, claims platforms, and data environments that predate modern resilience architecture. Mapping these systems to DORA's asset register and BIA requirements is operationally demanding, particularly where systems sit with long-standing outsourced providers under pre-DORA contracts.

EIOPA supervisory focus areas for 2026

EIOPA has signalled its 2026 supervisory focus includes the completeness and accuracy of Registers of Information, the adequacy of ICT incident classification methodologies, and board-level governance of ICT third-party oversight. Insurers with group structures spanning multiple EU jurisdictions face added complexity from multi-NCA coordination.

TLPT designation

Larger insurers are among the entities being designated for TLPT. EIOPA, working with national NCAs, is identifying which insurers must complete their first TLPT by January 2028. Designated insurers need to start scoping and provider selection now to meet that deadline.

In practice, this shows up as local entities keeping separate asset and supplier lists with no group-level view, backup restores that are never tested or documented, and third-party adjusters working to different reporting clocks than the rest of the group.

What Good Looks Like for Insurers

1. A DORA-Solvency II integration map showing where requirements overlap and where DORA adds net new obligations.
2. A legacy system remediation plan with prioritisation based on criticality assessment outcomes.
3. An EIOPA-compliant Register of Information covering all ICT third-party arrangements, including legacy outsourcing agreements.
4. Board-level ICT risk governance with documented evidence of management body oversight.
5. A TLPT readiness assessment if the institution is likely to be designated.

Solvency II already requires operational risk management, outsourcing governance, and business continuity planning, and DORA extends and specifies those existing requirements instead of introducing a parallel set. Insurers who build their DORA programme on top of what Solvency II already demands cut most of the duplicated evidence work out entirely.

The Register of Information is the single artefact supervisors across all three sectors are examining most closely in 2026. It's the operational record of every contractual arrangement an entity holds with an ICT third-party provider, and it must meet the detailed data requirements set out in the EBA's implementing technical standards.

What the Register Must Contain

The Register is a detailed operational record spanning far more than a supplier list. Each entry needs to include:

1. Legal entity identifiers (LEI) for both the institution and the provider.
2. Classification of whether the arrangement supports a critical or important function.
3. Sub-contractor chain visibility, including fourth-party providers.
4. Contract start and end dates, notice periods, and termination rights.
5. Data location and cross-border transfer details.
6. Exit plan reference and substitutability assessment.
7. Annual spend and concentration risk flags.

The Most Common Register Failures

1. Incomplete criticality assessments

Many institutions classify arrangements as non-critical with no documented rationale. Supervisors want the methodology documented alongside the outcome.

2. Missing sub-contractor chains

The Register needs to reflect the full delivery chain, including any sub-processors or infrastructure sub-contractors a direct provider relies on.

3. Legacy contracts left unrenegotiated

Contracts predating DORA that support critical functions need DORA-mandated clauses. Institutions are expected to run a remediation plan with clear timelines.

4. Static registers

A Register submitted in January 2025 and left untouched since is already a finding risk. New procurement decisions, contract renewals, and provider changes all need to trigger an update.

5. No exit plans

Critical function providers need a tested exit plan. A plan that says an institution 'would migrate to an alternative provider' has to name the alternative and assess migration complexity to hold up under review.

Practical step: assign a named owner for Register of Information maintenance, and build an update trigger into your procurement and contract management process so every new ICT supplier engagement creates a Register entry automatically before go-live.

DORA overlaps with several existing frameworks for most financial institutions, and integrating compliance work across them is the most efficient path forward.

DORA and ISO 27001

ISO 27001 provides the ISMS governance backbone that DORA's ICT risk management framework builds on. If your organisation holds ISO 27001 certification, your risk assessment process, asset register, incident management procedure, and supplier management controls all have direct DORA equivalents. The remaining gaps are DORA-specific: the Register of Information format, the incident reporting timelines, and the TLPT requirements, all mapped control by control in DORA and ISO 27001 Compliance: One Unified Programme.

DORA and NIS2

NIS2 applies to operators of essential services and important entities across critical sectors. Financial services entities in scope for both DORA and NIS2 should note that DORA takes precedence for ICT risk and incident reporting obligations in the financial sector, as lex specialis. NIS2 obligations for physical security, supply chain security, and business continuity still apply in parallel, a three-way overlap mapped in full in DORA vs NIS-2 vs ISO 27001: Where They Overlap and How to Combine Them.

DORA and Solvency II

For insurers, Solvency II's outsourcing governance, operational risk requirements, and business continuity obligations overlap substantially with DORA. The practical approach is to run a gap analysis against both frameworks at once and build a single integrated compliance programme with a crosswalk showing where each obligation gets satisfied.

DORA and the EU AI Act

Financial institutions deploying AI in critical functions face obligations under both DORA and the EU AI Act. DORA's ICT risk management framework treats AI systems as ICT assets, while the EU AI Act adds specific requirements for high-risk AI systems covering risk management, data governance, transparency, and human oversight. An ISO 42001 AI Management System provides the control structure to satisfy both.

Five pillars. Twenty-two thousand entities. One Register that ties them together. DORA compliance runs as a continuous operating discipline: the Register of Information needs ongoing maintenance, incident classification has to work at 4-hour pace, and third-party risk assessments need to run at scale, a cadence that outgrows spreadsheets and shared drives fast.

SureCloud's DORA compliance and Third-Party Risk Management capabilities give banks, fintechs, and insurers a single place to run their DORA programme, from ICT risk assessment and Register of Information maintenance through to incident management, resilience testing, and audit evidence.

Register of Information Management

A centralised register with mandatory data fields pre-built to EBA implementing technical standards, a criticality classification workflow with a documented methodology and sign-off trail, sub-contractor chain capture with concentration risk flagging, and automatic update triggers on new procurement and contract renewal events.

ICT Risk and Third-Party Oversight

Third-Party Risk Management with standardised workflows built for faster vendor assessments, contract compliance tracking against DORA-mandated clause requirements, and exit plan documentation with substitutability assessment templates.

Incident Management and Audit Readiness

Incident classification decision trees built around the 4-hour notification workflow, automated report generation for NCA submissions across all three stages, a pre-built DORA framework with pillar-by-pillar control mapping, and a 75% reduction in audit prep time with an evidence library that stays current between supervisory reviews.

Gracie AI Agents with Personas and Skills perform DORA compliance activities across the programme: keeping the Register of Information current, flagging third-party risk changes, and maintaining the evidence library between review cycles. Every action stays immutably logged and human-reviewable.