DORA inspection readiness 2026 — what supervisors actually ask

DORA — Regulation (EU) 2022/2554 — has been fully applicable since 17 January 2025 ^[1]. The first Register-of-Information cycle, with a submission deadline of 30 April 2025, was still a formal compliance check: does the register exist, are ICT third parties listed, is the classification scheme documented? Eighteen months on, the second inspection wave is in motion and the supervisory focus has shifted.

The three ESAs (EBA, EIOPA, ESMA) signal in their 2026 Joint Committee work programme that the entry checks are done and substantive testing begins: completeness of the third-party register, mapping of the sub-outsourcing chain, robustness of incident reporting under time pressure, and evidence of board engagement ^[2]. An institution with a register that looks complete on paper but does not map sub-outsourcing to a reasonable depth will no longer be able to hide that fact in a 2026 inspection.

This piece lists the seven focus areas that surface consistently in 2026 inspection preparations — drawn from DORA's Level-1 text, the Joint-Committee RTS, national supervisory priorities for 2026 and the publicly available ESA Q&As. An institution that can answer all seven cleanly walks into a DORA inspection prepared.

Article 28 DORA requires every in-scope financial institution to maintain a register of all ICT third-party service providers and submit it to the competent authority at least annually ^[1]. The 31 March date is the register’s reference (snapshot) date, not a statutory filing deadline; the actual submission window is set each year by the ESAs and national authorities — the first EU-wide collection ran in April 2025, with authorities forwarding registers to the ESAs by 30 April 2025. DORA’s implementing standards for the Register of Information (the ITS under Art. 28(9)) specify the minimum fields: provider identification, service type, criticality assessment, substitutability, contract date and location of data processing ^[3].

2026 inspection practice tests completeness at three levels. First: are ALL ICT providers in the register, including low-spend SaaS tools that process compliance and HR data? Second: does the criticality assessment match actual functional dependency, or has there been an attempt to down-rate critical providers to avoid the additional supervisory burden? Third — and this is the most common finding — is the sub-outsourcing chain resolved to a reasonable depth?

Supervisors have repeatedly signalled that a register naming only the prime provider — but not the chain of sub-contractors that process material data — does not meet the bar set by Art. 28: completeness does not stop at the contracting party ^[5].

The most frequent 2026 inspection question is not "do you have the register?" but "where does your back-end hosting actually run?". In practice that means: the direct ICT vendor is often just the contractual front door. Behind it sit a hyperscaler, a PaaS provider, a database service. The ESAs expect the institution to document this chain at least down to the non-further-delegable infrastructure provider ^[2].

The "reasonable depth" requirement is not trivial, and supervisors know that. In supervisory practice, two pragmatic thresholds have emerged: (a) any sub-provider that processes personal data of customers or staff must be named, regardless of contract value; (b) any infrastructure provider whose outage would interrupt the operation of a critical function within the meaning of Art. 3(22) must be named as well ^[2][5].

An institution that cleanly covers those two thresholds has passed the substantive test of the sub-outsourcing chain in an inspection, even if the prime provider's contractual front was minimally cooperative.

Article 19 DORA and its accompanying RTS (Delegated Regulation (EU) 2025/301) set the reporting deadlines that a 2026 inspection will test retrospectively against actual incidents: the initial notification to the competent authority within 4 hours of classifying the incident as major — and no later than 24 hours after the institution became aware of it; the intermediate notification within 72 hours; the final report within one month ^[1]. Commission Delegated Regulation (EU) 2024/1772 defines the classification criteria — number of clients affected, data loss, geographic reach, economic impact ^[4].

The hardest test is not the final report — under normal conditions it is filed on time — but the 4-hour initial notification. It requires the institution to produce, within four hours of classifying an incident as major, a structured notification to the supervisor: classification criteria, initial damage assessment and a first hypothesis on root cause. An institution without a pre-defined incident-routing process — one that discovers the incident in an internal notification, then manually identifies the right recipient, then completes the notification template — will not hold the four-hour window in a real crisis.

Supervisory communications — BaFin’s among them — treat the speed of the initial notification as an indicator of the maturity of the ICT risk management framework as a whole ^[7]. An institution that cannot hold the four-hour window has a structural maturity problem.

Threat-led penetration testing (TLPT) is DORA's variant of the established TIBER-EU framework — mandatory for institutions the ESAs have classified as systemically relevant ^[1]. Commission Delegated Regulation (EU) 2025/1190 has set the technical-detail requirements: a test cadence of at least every three years, a scope covering "critical functions" including their ICT supply chain, external threat-intelligence providers and red-teamers with demonstrable experience ^[6].

In the 2026 inspection the TLPT-relevant question has two steps. First: is the institution in scope? The thresholds and applicability criteria were set out in the TLPT RTS (Delegated Regulation (EU) 2025/1190) itself ^[6]. Second: if yes, is the TLPT plan documented, is scoping done, is an external provider engaged? The first mandatory TLPTs run across 2026 – 2027; an institution that cannot produce a plan by early 2027 will produce findings.

DORA requires every institution to identify its "critical or important functions" and to meet enhanced requirements for those: documented ICT-risk assessment, defined recovery-time objectives, business-continuity plan, periodic tests ^[1]. DORA defines the term in Art. 3(22): a function is critical or important when its disruption would materially impair the financial performance, or the soundness or continuity of the institution’s services and activities ^[1]. The enhanced contractual requirements for ICT services supporting such functions are set by Art. 30.

Inspection practice here is less a pass/fail test than a consistency check. The auditor will request the list of critical functions, cross-reference it with the third-party register (which ICT vendors support which critical function?), and finally cross-reference with incident reports from the past twelve months (have incidents touching critical functions been classified and escalated correctly?). Inconsistencies across those three datasets are the most likely 2026 path to a finding.

Articles 5 – 17 DORA together form the ICT risk management framework. A 2026 inspection will not test it in detail — there isn't time — but sample-test it. The most common sample questions: who is the ICT risk owner? When was the framework last updated? Is that update recorded in board minutes? How were the lessons from the most recent major incident fed back into the risk assessments?

For the ICT risks of AI use, DORA’s own framework already applies (Art. 6–16): an institution that uses a foundation model or an LLM API in a critical function must have documented how it handles the model-specific ICT-risk topics — hallucinations, data leakage, model drift. The older EBA Guidelines on ICT and Security Risk Management (EBA/GL/2019/04) were in fact narrowed in 2025 (EBA/GL/2025/02) because DORA now occupies this field directly for financial entities ^[8]; AI-specific ICT supervision is currently emerging at national level — for example BaFin’s December 2025 guidance on ICT risks from AI use ^[7] — and moves into systematic inspection for the first time in 2026.

Article 5(2) DORA requires that the ICT risk management framework be approved and periodically reviewed by the "management body" — i.e. the board or executive committee ^[1]. DORA itself prescribes no fixed cadence — the text says merely that the framework is reviewed periodically. What is anchored is an at-least-annual comprehensive review of the framework (Art. 6(5) ^[1]); more frequent briefings on material updates and incidents are good practice, not an explicit regulatory duty.

The inspection test is the "soft test": the auditor asks for board minutes that address ICT risk topics. Present / absent / formal-but-empty / substantive-and-recorded. The last two categories are the difference between a good and a bad inspection. A substantive board-minute entry looks like this: "Board noted: three critical findings from DORA sources in the previous quarter, one of which touches the critical function 'payment processing'. Action: risk-assessment of the affected third party will be re-run; status update in next quarterly report."

An institution whose board minutes substantively address ICT-risk topics is not attackable in a 2026 DORA inspection.

The seven focus areas above share a common technical substrate: an immutable, timestamped audit log. An institution that claims in an inspection that a finding was "identified in time and correctly routed" must evidence that with a log that cannot be edited after the fact. An institution that claims a board briefing on sub-outsourcing risk took place on 12 March 2026 must be able to evidence that with a record actually created on 12 March 2026.

That is the practical bar for "audit-ready" in 2026. The DORA Level-1 text does not require it verbatim — but inspection practice makes it the de-facto precondition. Institutions whose compliance documentation lives in unstructured Outlook inboxes, shared OneDrive folders and manually maintained Excel trackers will produce findings in 2026 inspections — not because of missing substance, but because of missing evidence.

Horizon Scanner monitors all three ESAs (EBA, EIOPA, ESMA) in parallel with every national DORA source — RTS, ITS, Q&As, national implementing acts, supervisory letters — and routes every DORA-relevant finding to the responsible team the day it is published. Each finding is classified across three dimensions: Impact, Reach, Substantiveness — a score ≥ 3 triggers four-eyes review. Every routing step is recorded in the audit log; retention is five years, export is CSV or JSON.

For the seven inspection focus areas in this piece that means, concretely: sub-outsourcing updates are reconciled against the third-party register; 4-hour incident routings are configured as pre-built workflows; board briefings for the DORA quarterly update are auto-assembled; every audit-log entry is timestamped and not editable after the fact. In a 2026 DORA inspection that is the evidence layer the auditor wants to see — present, complete, audit-ready.