Nine months into DORA's application, the supervisory posture is no longer theoretical. National competent authorities across the EU have begun their first structured engagements with financial entities, and a recognisable pattern is emerging. The questions supervisors ask first tell you exactly what they consider foundational — and, by extension, where they expect to find the most significant gaps.
If your entity has not yet received a supervisory inquiry under DORA, the experience of those who have is instructive. The first wave is not about edge cases or advanced testing scenarios. It is about basics: does the entity have a documented ICT risk management framework? Is the register of information complete and accurate? Can the entity demonstrate incident reporting readiness? Supervisors are testing the foundation before they examine the superstructure.
The First Supervisory Wave: What We Are Seeing
The supervisory approach in the first nine months has been largely consistent with what the European Supervisory Authorities — the EBA, EIOPA, and ESMA — signalled in their 2024 communications. The ESAs' joint technical standards and guidelines, which provide the detailed implementation requirements under DORA, were finalised in phases through 2024 and early 2025. Supervisors are now assessing compliance against these standards.
The initial engagement model varies by Member State and by the supervised entity's classification, but a common pattern has emerged:
Questionnaire-based self-assessment. Many competent authorities began with structured questionnaires distributed to in-scope entities, asking for self-declarations on DORA readiness across the five pillars: ICT risk management, incident management, digital operational resilience testing, third-party risk management, and information sharing. These questionnaires serve a dual purpose: they provide supervisors with a landscape view of sector readiness, and they force entities to formally assess their own compliance status.
Document requests. Following the self-assessment phase, supervisors have issued targeted document requests to a subset of entities, typically the larger or more systemically relevant ones. These requests focus on framework documentation, governance records, and the register of information.
Supervisory dialogues. For entities identified as higher-risk or strategically important, some competent authorities have initiated direct supervisory dialogues — structured meetings where the entity presents its DORA compliance programme and the supervisor probes specific areas. These dialogues are not adversarial, but they are substantive. Supervisors arrive prepared, and entities that cannot answer detailed questions about their own ICT risk framework leave a poor impression.
The proportionality principle under DORA Article 4 is being applied, but not in the way some entities hoped. Proportionality calibrates the depth and complexity of required measures, not the requirement to have measures at all. A small investment firm receives less intensive supervision than a systemically important bank, but both are expected to have a documented ICT risk management framework, a complete register of information, and functioning incident reporting processes.
Top Three Questions Supervisors Ask First
Based on the first wave of supervisory engagements across multiple jurisdictions, three lines of inquiry dominate the opening phase.
1. Show Us Your ICT Risk Management Framework Documentation
DORA Article 6 requires financial entities to have a "sound, comprehensive and well-documented ICT risk management framework" as part of their overall risk management system. Articles 5 through 16 elaborate the specific elements this framework must cover: ICT risk identification, protection and prevention, detection, response and recovery, and learning and evolving.
Supervisors are not asking whether the entity manages ICT risk. They are asking for the documented framework. The distinction matters. Many financial entities have competent IT security teams that manage risk effectively in practice but have not produced the specific documentation that DORA requires.
The documentation supervisors expect includes:
- A formal ICT risk management framework document approved by the management body (Art. 5(2))
- An ICT risk management policy defining the entity's approach to identifying, assessing, and mitigating ICT risks
- An information security policy (referenced in the EBA's RTS on ICT risk management framework)
- Documentation of the management body's responsibilities and governance arrangements for ICT risk (Art. 5(2) and Art. 5(4))
- Evidence of at least annual review of the framework by the management body
The most common gap is not a complete absence of documentation but rather documentation that predates DORA and does not map to the Regulation's specific requirements. Entities that updated existing ISO 27001 documentation to reference DORA requirements without restructuring it to address DORA's specific framework elements are finding that supervisors consider this insufficient.
2. Produce Your Register of Information
Article 28(3) requires financial entities to maintain and keep up to date a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers. This is not an abstract obligation. The ESAs published a detailed template for the register (the "templates for the register of information" in the implementing technical standard), and supervisors expect entities to produce a register that conforms to this template.
The register is arguably the single most operationally demanding DORA obligation. It requires entities to catalogue every ICT third-party service arrangement, including:
- Identification of the ICT third-party service provider and any sub-contractors
- Description of the ICT service provided
- Assessment of whether the service supports a critical or important function
- Data processing locations
- Contractual start and end dates
- Assessment of substitutability
Supervisors are asking for the register early because it serves as a litmus test. An entity that has a complete, current register of information has necessarily done the work of identifying its ICT third-party dependencies, classifying them by criticality, and understanding its concentration risks. An entity that cannot produce the register — or produces one with obvious gaps — signals broader weaknesses in its vendor risk management programme.
The most common problems supervisors are finding in register submissions: incomplete coverage (major providers present but mid-tier and tail-end providers missing), missing sub-contractor information, stale data (contracts listed that have been terminated, or missing contracts entered into after the register was initially populated), and failure to assess criticality consistently.
3. Demonstrate Incident Reporting Readiness
DORA Article 19 requires financial entities to report major ICT-related incidents to their competent authority. The EBA's RTS on the classification of ICT-related incidents and the ITS on reporting templates define the mechanics: initial notification within four hours of classification, intermediate report within 72 hours, and final report within one month.
Supervisors are not waiting for an actual incident to assess reporting readiness. They are asking entities to demonstrate their reporting capability through:
- Documentation of the incident classification process, showing how the entity applies the classification criteria (including thresholds for client impact, data loss, geographic spread, duration, and economic impact)
- Internal escalation procedures that ensure incidents are assessed against the classification criteria within four hours of detection
- Designated personnel responsible for regulatory notification
- Familiarity with the reporting templates and submission channels
- Evidence of at least one tabletop exercise or simulation testing the end-to-end reporting process
The four-hour initial notification window is where most entities struggle in simulations. Four hours from classification — not from detection — sounds feasible in theory. In practice, it requires that on-call staff can access classification tools, apply the criteria, draft the initial notification, obtain necessary internal approvals, and submit the report within that window, potentially at 3 AM on a Saturday. Entities that have not tested this workflow under realistic conditions are discovering its difficulty in supervisory dialogues.
Common Gaps Found in Early Reviews
Beyond the three core lines of inquiry, supervisors are identifying several recurring gaps.
Register of information quality. As noted above, register completeness and accuracy are persistent problems. But a subtler issue is emerging: registers that are technically complete but not operationally useful. A register compiled by procurement by exporting contract data from a vendor management system may list every provider but fail to reflect the actual ICT service dependencies, the criticality assessments, or the concentration risk analysis that DORA contemplates. Supervisors distinguish between a register that has been filed and a register that reflects genuine understanding of third-party risk.
Exit strategy credibility. DORA Article 28(8) requires that contractual arrangements with ICT third-party service providers include exit strategies. Article 28(1)(h) specifically references the need for adequate transition periods and exit plans. Supervisors are asking to see exit strategies for critical ICT service providers, and they are assessing whether those strategies are credible.
Credibility means more than a contractual clause stating "the entity may terminate with 90 days' notice." Supervisors want to see evidence that the entity has identified alternative providers, estimated transition timelines and costs, assessed data portability, and considered the operational risks of transition. For critical cloud infrastructure providers, credible exit strategies require technical work — not just legal drafting.
The gap here is often between the legal team's confidence (contractual right to exit is established) and the operational reality (nobody has tested whether the entity can actually move its critical workloads to an alternative provider within a reasonable timeframe). Regulatory export capabilities that demonstrate evidence of exit planning are increasingly important in this context.
TLPT scoping and readiness. DORA Article 26 requires certain financial entities to conduct Threat-Led Penetration Testing (TLPT) based on the TIBER-EU framework. The specific entities required to conduct TLPT are designated by competent authorities, and the first designations are now being communicated. Entities that have been designated — primarily larger banks, central counterparties, and central securities depositories — are expected to scope and initiate their first DORA TLPT cycle within the first application year.
The gap is not in the technical capability to conduct TLPT (most designated entities already run red team exercises) but in the specific DORA/TIBER-EU requirements around scope, threat intelligence, and supervisory involvement. TLPT under DORA requires the testing scope to cover critical or important functions, the use of external threat intelligence providers to inform the testing scenario, and notification of the competent authority before testing begins. Entities accustomed to running penetration tests as internal security exercises are adjusting to the regulatory overlay.
The Proportionality Dialogue
Proportionality under DORA is not automatic. It requires an active dialogue between the entity and its supervisor.
Article 4 provides the framework: measures shall be proportionate to the entity's size, overall risk profile, and the nature, scale, and complexity of its services, activities, and operations. But proportionality is not self-executing. An entity cannot simply assert that a particular requirement does not apply due to proportionality without being prepared to explain its reasoning.
In practice, supervisors are approaching proportionality through two mechanisms:
Tiered expectations based on entity classification. Systemically important institutions, significant credit institutions, and central counterparties face the most demanding expectations. Mid-tier banks, insurance undertakings, and investment firms face calibrated expectations. Small and non-interconnected investment firms face the lightest touch. This tiering is largely set by the competent authority and communicated through supervisory guidance.
Entity-specific proportionality assessments. Within each tier, entities are expected to conduct and document their own proportionality assessment, explaining how the nature of their services, their ICT architecture complexity, and their risk profile inform the depth of their DORA implementation. Supervisors review these assessments and may agree, disagree, or request adjustments.
The entities handling proportionality well are those that proactively document their reasoning, map their implementation to the specific DORA articles and RTS provisions, and explain where and why they have calibrated the depth of their implementation. The entities handling it poorly are those that treat proportionality as a blanket exemption, asserting that "we are small, therefore many of these requirements do not apply" without article-by-article analysis.
Remediation Expectations and Timelines
When supervisors identify gaps, they are not — at this stage — reaching immediately for enforcement tools. The prevailing approach in the first year is constructive: identify gaps, set remediation expectations, and follow up.
However, "constructive" does not mean "indefinite." Supervisors are communicating specific remediation timelines, and those timelines are measured in months, not years. Common patterns:
- ICT risk management framework documentation gaps: three to six months to remediate
- Register of information deficiencies: three months for critical providers, six months for complete register
- Incident reporting readiness: immediate expectation to have core process in place; three months for full tabletop-tested capability
- Exit strategy gaps for critical providers: six to twelve months, recognising the operational complexity
Entities that respond to supervisory findings with concrete remediation plans, assigned ownership, and realistic timelines are building supervisory credibility. Entities that respond with vague commitments to "work on it" are flagging themselves for more intensive follow-up.
Preparing for the Next Round
The first supervisory wave has been largely exploratory. The next round will be more demanding. Based on supervisory signals and ESA communications, expect the following themes to intensify in 2026:
Register of information as a supervisory reporting obligation. The ESAs have indicated that they will collect registers of information from financial entities on a sector-wide basis for the purposes of critical third-party provider designation under Article 31. Entities should prepare for their register to be not just internally useful but submission-ready.
Resilience testing evidence. Supervisors will increasingly expect to see not just testing plans but testing results, including findings, remediation actions, and evidence of improvement over time. DORA resilience testing requirements move from planning to execution.
Concentration risk analysis. As the ESAs aggregate register data and identify sector-level concentration patterns, expect pointed questions about entities' dependency on designated critical third-party providers and the adequacy of their mitigation measures.
Sub-contracting chain visibility. Early reviews have surfaced that many entities have limited visibility into their ICT providers' sub-contracting arrangements. Supervisors will push harder on this in subsequent rounds.
The message for financial entities is clear: use the findings from the first supervisory engagement — whether your own or the sector-wide patterns described here — to prioritise remediation now. The next round will assume the basics are in place.
Key Takeaways
- The first wave of DORA supervisory engagements focuses on three foundational areas: ICT risk management framework documentation, register of information completeness, and incident reporting readiness. These are not advanced requirements — they are the baseline supervisors expect to be in place from day one.
- Register of information quality is the most common gap. Registers that are technically populated but operationally shallow — missing sub-contractors, stale data, inconsistent criticality assessments — are not meeting supervisory expectations.
- The four-hour incident notification window is operationally demanding and most entities have not tested it under realistic conditions. Tabletop exercises that simulate weekend or overnight incident detection are essential.
- Exit strategy credibility — not just contractual rights but operational ability to transition — is a supervisory focus that many entities have underestimated.
- Proportionality requires proactive, documented, article-by-article reasoning. It is not a blanket exemption for smaller entities.
- Remediation timelines from supervisors are measured in months. Entities that respond with concrete plans and ownership build credibility; those that respond vaguely attract closer scrutiny.