Definition: DORA (Digital Operational Resilience Act)
DORA, the Digital Operational Resilience Act, is EU Regulation (EU) 2022/2554 that requires banks, insurers, and other financial entities, along with the ICT providers serving them, to manage ICT risk, report major incidents, test operational resilience, and monitor third-party technology dependencies.
Core characteristics of DORA
DORA replaces a patchwork of national financial IT-security rules with one EU-wide framework built on five pillars. It applies directly, without national transposition, and reaches beyond financial entities to the vendors that keep their systems running.
- Direct EU regulation, binding since 17 January 2025 with no grace period
- Covers ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing
- Extends contractual obligations to ICT third-party providers, including cloud and AI vendors
- Creates a formal oversight regime for providers designated as “critical”
DORA vs. NIS2
DORA and NIS2 both set EU cybersecurity and resilience obligations, but they cover different territory. NIS2 applies broadly across sectors such as energy, transport, and digital infrastructure, while DORA is sector-specific legislation for banks, insurers, and financial market infrastructure. Where a financial entity falls under DORA, EU law treats it as lex specialis, so its ICT risk and incident rules take precedence over equivalent NIS2 provisions for that entity. A vendor serving both a hospital and a regional bank may need to satisfy NIS2 for one relationship and DORA for the other.
Importance of DORA in enterprise AI
Financial entities increasingly rely on AI-based fraud detection and credit scoring, which puts the vendors behind those systems under DORA’s third-party oversight even when the AI itself is separately regulated. The European Supervisory Authorities designated 19 critical ICT third-party providers for direct oversight in November 2025, including cloud platforms hosting financial-sector AI workloads (EBA, EIOPA, ESMA, 2025). For Mittelstand vendors, one customer’s DORA obligations can shape contract terms long before the vendor itself is directly regulated.
Methods and procedures for DORA
Financial entities and their ICT providers implement DORA through defined operational and contractual procedures.
ICT risk management framework
Every financial entity must maintain a documented ICT risk management framework covering identification, protection, detection, response, and recovery, approved by the management body and reviewed at least annually.
- Asset and dependency mapping across critical business functions
- Defined recovery time and recovery point objectives
- Board-level accountability for ICT risk decisions
Incident classification and reporting
DORA harmonizes how financial entities classify and report major ICT-related incidents, replacing the fragmented national regimes that existed before 2025. Entities submit an initial notification shortly after detecting a major incident, then intermediate and final reports as the case is resolved.
Register of information and due diligence
Before signing a contract with an ICT third-party provider, financial entities must run due diligence, then log the arrangement in a register of information under Article 28(3) DORA. BaFin requires this register to cover every SaaS contract, cloud instance, and external IT support arrangement, so AI vendor risk management on the vendor side now has to produce the evidence the bank’s register demands.
Important KPIs for DORA
Organizations tracking DORA readiness monitor operational and contractual indicators.
Operational resilience metrics
- Recovery time objective (RTO): target per critical function
- Major incident classification time: target under a defined internal threshold
- Third-party register completeness: target 100% of active ICT contracts
- Threat-led penetration test (TLPT) cycle: every 3 years for in-scope entities
Strategic oversight indicators
Boards increasingly track ICT concentration risk: how much of the entity’s critical operations depend on a small number of vendors. Fraunhofer-affiliated resilience research flags concentration in cloud and core-banking software as a systemic risk area supervisors now watch closely.
Vendor compliance quality
Financial entities score ICT providers on how completely they support audit rights, subcontractor transparency, and exit planning, not just uptime. A provider that cannot produce evidence quickly during a review becomes a documented risk in the customer’s own DORA file.
Risk factors and controls for DORA
Non-compliance with DORA creates risk on both sides of the financial entity and vendor relationship.
Contractual and concentration risk
Financial entities that cannot demonstrate adequate due diligence or exit strategies face supervisory findings and remediation orders. Concentration in a handful of providers raises systemic risk even when each contract looks compliant on its own.
- Missing or incomplete exit strategy for critical ICT services
- Subcontracting chains not disclosed to the financial entity
- Single points of failure shared across multiple financial entities
Enforcement and penalties
Critical ICT third-party providers under direct ESA oversight can face periodic penalty payments of up to 1% of average daily worldwide turnover per day of non-compliance, capped at six months. Authorities can also require financial entities to suspend or terminate non-compliant contracts.
Vendor readiness gaps
Many Mittelstand vendors underestimate how much documentation a DORA-covered customer will demand, from ISO 27001 certification to signed data processing agreements with audit clauses. Treating these requests as one-off sales friction risks losing financial-sector contracts at renewal.
Practical example
A 90-employee software vendor in Frankfurt building AI-based document analysis tools for regional banks found itself named in three customers’ DORA registers of information within a single quarter, each asking for the same evidence in a different format: subcontractor lists, incident response procedures, exit plans, and penetration test proof. Rather than answering each request manually, the company built a standing compliance package and a company brain that keeps every past due-diligence answer and contract clause in one place, so the next request pulls from precedent. Response time for due diligence requests dropped from three weeks to four days.
- Standing evidence package covering subcontractors, incident response, and exit planning
- Reusable answers to recurring due diligence and questionnaire requests
- Documented negotiation history for audit and exit clauses across customer contracts
- Faster renewal cycles with financial-sector customers
Current developments and effects
DORA enforcement is still maturing well into 2026.
Critical provider oversight matures
The first list of 19 designated critical ICT third-party providers, published in November 2025, marked the start of direct ESA oversight rather than its conclusion. Supervisors are expected to expand the list and finalize oversight fees through 2026.
- Additional CTPP designations expected as ESAs review market concentration
- Joint examination teams conducting first on-site reviews of critical providers
Overlap with EU AI Act enforcement
As financial entities deploy more AI for credit decisions and fraud detection, supervisors are working out how EU AI Act obligations for high-risk AI systems interact with DORA’s ICT risk rules for the same system. Vendors increasingly need to satisfy both frameworks in one contract negotiation.
Convergence with product security law
The Cyber Resilience Act adds a separate layer of security requirements for software products with digital elements, which overlaps with DORA for vendors selling packaged software rather than pure services. Mittelstand vendors serving financial customers now track two overlapping compliance calendars instead of one.
Conclusion
DORA has moved financial-sector ICT resilience from a patchwork of national rules to one directly applicable EU regulation, and its third-party provisions now reach deep into the vendor base serving European banks and insurers. For Mittelstand companies selling software, AI, or cloud services to financial entities, DORA compliance is a recurring contractual requirement, not optional groundwork. The designation of the first critical ICT third-party providers in late 2025 signals that direct oversight will keep expanding beyond hyperscalers. Vendors that build durable, reusable compliance documentation now will handle the next wave of due diligence requests faster than competitors starting from scratch.
Frequently Asked Questions
What is DORA in simple terms?
DORA is an EU regulation requiring banks, insurers, and other financial entities to manage ICT risk, report major incidents, test operational resilience, and monitor the technology vendors they depend on. It has applied directly across the EU since 17 January 2025.
Does DORA apply to a 50-person Mittelstand software company?
DORA formally binds financial entities, not the vendor itself, but if that vendor supplies a bank or insurer, the customer’s DORA obligations flow down through the contract. In practice, audit rights, incident notification clauses, exit plans, and subcontractor disclosure become standard requirements regardless of vendor size.
How does DORA relate to the EU AI Act and GDPR?
DORA, the EU AI Act, and GDPR address different risks and can all apply to the same AI system sold to a financial entity. DORA covers ICT operational resilience and third-party oversight, the EU AI Act covers AI-specific risk classification, and GDPR governs personal data, so vendors typically need a data processing agreement plus DORA-aligned contract terms in parallel.
What does DORA compliance cost for an ICT vendor serving banks?
Costs vary by company size and existing security maturity, but typically include ISO 27001 or equivalent certification, incident response documentation, and legal review of contract clauses. Vendors that already maintain strong security documentation for other frameworks usually adapt it for DORA rather than starting a separate program.
Do we need dedicated IT staff to respond to DORA due diligence requests?
Not necessarily a dedicated team, but someone needs ownership of the register-of-information evidence, incident procedures, and contract clauses that financial-sector customers will request repeatedly. Centralizing that documentation, rather than answering each questionnaire from scratch, keeps the workload manageable as the number of regulated customers grows.
Is DORA the same as NIS2?
No. DORA is sector-specific regulation for financial entities and takes precedence over NIS2 for those entities under the lex specialis principle, while NIS2 covers broader sectors including energy, healthcare, and digital infrastructure. A vendor could face NIS2 obligations from one customer and DORA obligations from another.
