DORA — Digital Operational Resilience Act

DORA (the Digital Operational Resilience Act, Regulation 2022/2554) is the EU's binding framework for ICT risk management in the financial sector. Effective 17 January 2025, DORA imposes direct operational resilience requirements on banks, insurers, investment firms, crypto-asset service providers, and — critically — their ICT third-party service providers.

This page covers DORA's scope, the five pillars of operational resilience it codifies, what ICT third-party risk management looks like in practice, and how evidence infrastructure supports DORA compliance.

What DORA requires

DORA codifies operational resilience across five pillars, each with detailed technical and organizational requirements:

• ICT risk management framework — documented governance, risk identification, protection, detection, response, and recovery processes.
• ICT-related incident reporting — classification of major incidents and cyber threats; structured reporting to competent authorities within tight SLAs.
• Digital operational resilience testing — regular testing of ICT tools and systems; threat-led penetration testing (TLPT) for significant financial entities.
• ICT third-party risk management — comprehensive oversight of ICT service providers, including contractual requirements, concentration risk management, and exit strategies.
• Information and intelligence sharing — voluntary arrangements for exchanging cyber threat intelligence.

Who DORA applies to

DORA applies broadly across EU financial services:

• Credit institutions, payment institutions, e-money institutions
• Investment firms, asset managers, central counterparties, trading venues
• Insurance and reinsurance undertakings, insurance intermediaries
• Crypto-asset service providers (CASPs) under MiCA
• Crowdfunding service providers
• Critical ICT third-party service providers (designated by the European Supervisory Authorities)

Fintechs and BaaS platforms operating in or into the EU typically encounter DORA through two paths: direct application (if they're a regulated financial entity under any of the categories above) and cascade via banking partners (whose DORA obligations flow contractually to their service providers).

ICT third-party risk management — the load-bearing pillar

Pillar 4 is where most fintechs and BaaS platforms feel DORA most directly. Financial entities must maintain comprehensive oversight of their ICT service providers, including:

• Contractual requirements — DORA-specific clauses on service levels, security, data handling, audit rights, termination, and exit planning.
• Concentration risk assessment — evaluation of dependency on any single ICT provider and any single cloud region.
• Sub-processor transparency — complete visibility into the sub-processor chain used by ICT service providers.
• Incident-reporting flow-through — ICT service providers must notify financial entity clients of security incidents within specific SLAs.
• Exit strategies — documented plans for migrating away from an ICT service provider if required.

For a fintech running 8+ vendor integrations, DORA third-party risk management is a significant operational burden. Each vendor needs its own contractual review, security questionnaire, and ongoing risk assessment. A fintech orchestration platform consolidates this surface area — one vendor relationship replacing N.

Effective dates

DORA was adopted in December 2022 and entered into force 17 January 2023. The application date — the date financial entities must be compliant — is 17 January 2025. Enforcement activity has begun; supervisory authorities across member states are now auditing DORA compliance actively.

Evidence requirements

DORA's operational requirements imply specific evidence artifacts that financial entities must be able to produce:

• Register of ICT risk events (all incidents, not just reportable ones)
• Register of third-party ICT service providers with risk classification
• Documentation of testing activities, results, and remediation
• Incident reports with classification, root cause, and response actions
• Business continuity and disaster recovery test records
• Supplier-chain transparency documentation

The common feature: all of this is evidence infrastructure — structured, timestamped, queryable records that demonstrate controls operated as designed. Producing this manually across disparate systems is expensive; producing it as a byproduct of execution through an orchestration platform is almost free.

How FinQub supports DORA compliance

FinQub provides evidence infrastructure relevant to DORA in three specific ways:

• ICT incident logging — every vendor API failure, webhook delivery failure, and service degradation is logged to the audit trail with classification metadata. This feeds into DORA's incident register.
• Third-party risk consolidation — using FinQub as an orchestration layer replaces N direct vendor relationships with one. DORA third-party risk management applies to one platform rather than to 10. FinQub provides a complete sub-processor list and associated risk assessment artifacts.
• Examiner-ready audit trail — hash-chained tamper-evident records exportable by framework (DORA, AMLD6, SOC 2, etc.), entity, and date range. When a supervisory authority requests evidence under DORA, the answer is a query, not a project.

FinQub does not make DORA compliance determinations. Whether a specific control environment and third-party risk posture meets DORA requirements remains the responsibility of the obliged financial entity, its compliance officers, and its supervisory authorities. What FinQub provides is the evidence infrastructure required to demonstrate compliance.

Practical next steps

1. Map every ICT service provider in your operational chain. For most fintechs this includes cloud, identity verification vendors, payment processors, banking partners, monitoring tools, and communications vendors.
2. Classify each provider's criticality to your operations and assess concentration risk (any single provider whose loss would disrupt core services).
3. Review existing contracts against DORA's specific contractual requirements — most pre-DORA contracts need amendment.
4. Establish incident-reporting flow-through — when a third-party has an incident, you need structured notification fast.
5. Consolidate where possible. Every vendor relationship you can replace with an orchestration layer is one fewer DORA third-party risk surface.