Key takeaways
- • DORA has applied bindingly since January 2025 to over 22,000 financial entities in the EU: banks, insurers, payment service providers, asset managers, and their critical ICT providers.
- • Art. 28 requires a complete register of all ICT third-party providers with documented dependencies. Most institutions still manage it as a spreadsheet.
- • Art. 30 mandates supervision-proof contract clauses: audit rights, exit strategies, SLA measurement. Technical infrastructure evidence for availability and integrity is what makes the contract actually usable before the supervisor.
- • The BaFin50 scan (DACH Enterprise Readiness Report 2026) shows: 0 of 50 financial domains CERTIFIED. The gap at the technical evidence level exceeds the gap at the contract level.
- • Technical infrastructure evidence (DNS integrity, TLS chain, SOVP parameters) forms the third pillar alongside contractual documentation and internal risk management.
The Digital Operational Resilience Act (DORA) has applied since January 17, 2025 as directly applicable EU law: a regulation with direct effect in all 27 member states, without a national transposition step. Affected are over 22,000 financial entities: credit institutions, insurers, payment service providers, investment firms, asset managers, crypto-asset service providers, and the ICT providers that deliver critical services to them.
The regulatory logic behind DORA is clear: anyone who has outsourced their critical IT to external providers must be able to demonstrate the operational resilience of that outsourcing in a measurable, supervision-proof way. This article shows where that proof stands today.
What DORA requires of the financial entity: the Art. 28 core
Art. 28 DORA is the regulatory core of the ICT third-party requirements. It obligates financial entities to maintain a complete, current, and audit-proof register of all ICT third-party providers with whom a contractual relationship exists. The register serves supervisory authorities (BaFin, ECB, ESMA, EIOPA) as the data basis for identifying systemic concentration risks in the financial sector.
| DORA article | Requirement | Form of evidence |
|---|---|---|
| Art. 28(3) | Register of all ICT third-party providers: complete, continuously updated, categorized by criticality | Structured register, reportable to the ESAs on request |
| Art. 28(4) | Classification of all ICT services by criticality level, with the assessment basis documented | Risk classification with traceable criteria |
| Art. 29 | Pre-contract review of new ICT third-party providers: due diligence before contract conclusion | Review record, technical and organizational assessment |
| Art. 30(2) | Essential contractual clauses: SLA definitions, audit rights, exit strategies, incident reporting duties | Contract text plus evidence of actual SLA fulfillment |
| Art. 11(5) | Tested backup and recovery procedures, demonstrable data integrity | Test reports, integrity verification of the backup infrastructure |
| Art. 19 | Reporting of major ICT incidents to the competent authority within defined deadlines | Incident classification, reporting record, root-cause analysis |
NIS2 requires the implementation of security measures. DORA requires ongoing, measurable, supervision-proof evidence of operational resilience. The state of the ICT infrastructure must be documentable at all times. An overview of the requirements of both frameworks: DORA compared with NIS2.
The documentation reality: BaFin50 under the scanner
The DACH Enterprise Readiness Report 2026 provides the most comprehensive public measurement to date of technical compliance readiness in the German financial sector. CERTavia scanned the 50 largest German financial domains from the BaFin register (banks, insurers, asset managers, and payment service providers) using the SOVP protocol.
These figures document where the German financial sector stands technically. DORA assesses technical parameters in a contractual context. Institutions that can technically demonstrate neither their own DNS infrastructure nor that of their ICT provider carry an Art. 28 risk into their next BaFin review meeting.
Why a spreadsheet falls short as a DORA register
The overwhelming majority of ICT third-party registers that financial entities maintain today are Excel spreadsheets or ERM system exports: provider name, contract volume, classification, last review. What's left out is the continuous technical state: whether the provider, right now, at this moment, is actually delivering the contractually agreed availability and integrity.
A register with ongoing technical verification is evidence of operational resilience. That is exactly what DORA requires.
The EBA outsourcing guidelines (EBA/GL/2019/02) and the ESAs' JC/2023/86 guidelines make this concrete: audit rights and monitoring obligations must not only be contractually agreed but actually exercised. The monitoring must be demonstrably documented.
The three evidence layers under DORA
Art. 28 through 30 DORA and the ESA guidelines together establish a three-tier evidence structure that financial entities build for every critical ICT third-party provider:
| Layer | Content | Frequency | Gap in practice |
|---|---|---|---|
| 1. Contract layer | SLA definition, audit rights, exit clause, incident reporting duties under Art. 30 | At contract conclusion and renewal | Clauses present, supervision-proof wording still has room to improve |
| 2. Governance layer | Risk assessment, classification by criticality, due-diligence record under Art. 29 | Annually and on an ad hoc basis | Classification exists, update cadence still to be established |
| 3. Technical evidence layer | Demonstrable ICT state: DNS integrity, TLS chain, availability metrics, infrastructure parameters | Continuous, at least quarterly | Still to be built at nearly every institution |
The first and second layers exist in some form at most DORA-obligated institutions, though with room to improve. The third layer is the open gap. It is also the first thing a supervisory authority will demand once an ICT incident has occurred and the institution must prove it actually monitored its third-party provider.
BaFin examiners start with the monitoring documentation: “Show me the records for this provider for the past 12 months.” Whoever can present a complete monitoring history passes this test.
What must be concretely documented: the Art. 30 checklist
Art. 30(2) DORA exhaustively lists the essential contractual clauses. Behind each clause stands a documentation duty that goes beyond the contract text itself:
DORA, NIS2, EU AI Act: the trio comes full circle
For the financial sector, DORA completes the regulatory trio described on this platform since our very first post: the EU AI Act requires transparency and labeling for AI systems under Art. 50 — CERTavia delivers the machine-readable infrastructure evidence for it. NIS2 requires security measures for critical infrastructure. DORA requires operational resilience evidence for the entire ICT stack: for AI systems just as much as for every other critical digital dependency.
| Regulation | Target group | Core requirement for infrastructure evidence | Overlap |
|---|---|---|---|
| EU AI Act | Providers & deployers of high-risk AI | Art. 50: transparency, labeling, and provenance of AI outputs | Financial entities using AI-based credit scoring, fraud detection, risk models |
| NIS2 | Essential & important entities | Art. 21: technical security measures incl. supply-chain risks | Banks and financial infrastructure as “essential entities” |
| DORA | Financial entities and critical ICT providers | Art. 28 through 30: ICT third-party register, monitoring, technical evidence | Full overlap with NIS2; precedes the EU AI Act for the financial sector |
For a bank operating an AI-driven credit scoring system while relying on a cloud ICT provider, all three frameworks apply at once. Infrastructure evidence is documentation created once and reusable many times over: a single SOVP scan of the ICT provider serves Art. 50 EU AI Act, Art. 21 NIS2, and Art. 30 DORA in one step.
Risk matrix: DORA audit risks for financial institutions 2026
| Risk | Likelihood | Impact | Control | Reg. | Reputation | Overall |
|---|---|---|---|---|---|---|
| ICT register stuck at inventory stage: ongoing technical verification still missing | 5 | 5 | 2 | 5 | 4 | 5.0 |
| ICT register with overdue update cycle | 4 | 5 | 2 | 5 | 4 | 4.8 |
| Audit rights under Art. 30 without documented exercise | 4 | 5 | 2 | 5 | 3 | 4.6 |
| Untested exit strategies for critical providers | 4 | 5 | 3 | 4 | 4 | 4.4 |
| Incident reporting history for ICT incidents still to be built | 3 | 4 | 3 | 5 | 3 | 4.1 |
| Concentration risk: alternative-provider register has room to improve | 3 | 4 | 3 | 4 | 3 | 3.8 |
The five immediate actions for DORA compliance in 2026
Technical infrastructure evidence retains its full audit value for up to 90 days. What was CERTIFIED in January must be re-measured by April. This applies to the entity's own infrastructure just as much as to every critical ICT third-party provider in the register. Building a fixed monitoring cadence of at least quarterly into the governance process is the DORA minimum standard.
What CERTavia contributes to DORA documentation
CERTavia is a deterministic infrastructure verifier that delivers technical evidence for layer 3 of the DORA evidence structure. A SOVP scan of the ICT third-party provider produces a cryptographically signed, DNS-anchored finding: DNS integrity, TLS configuration, security headers, AI infrastructure parameters — machine-readable, dated, immutably archivable.
This finding is a technical measurement record. It complements the risk classification under Art. 28, the contractual clauses under Art. 30, and the organizational governance with the technical evidence layer: proof that at time X, provider Y actually met technical requirements Z.
Banks already working with CERTavia evidence under Art. 50 EU AI Act (as described in Part 1 of our banking series) extend that infrastructure evidence directly to DORA requirements. The same scan, the same evidence, triple the regulatory value.
CERTavia analyzes technical infrastructure signals and produces machine-readable findings. The result is a technical measurement record. For legally binding compliance assessments within the meaning of DORA, consult a licensed audit or advisory firm with regulatory financial-sector expertise.