DORA applied from 17 January 2025. In eighteen months, financial entities in scope (banks, insurers, asset managers, critical ICT providers) have produced policies, registers and mappings. Documentary compliance is progressing. But that is often where the positive picture ends. The first observations by the competent authorities (ECB, ACPR, ESMA) and maturity audits carried out in 2025 and early 2026 reveal four structural gaps in actual ICT governance. In this article, you will learn why these gaps persist, and what an organisation can reasonably correct before the next supervision cycles.
What 18 months of application has actually produced
The interim scorecard is nuanced. According to consolidated feedback from national European supervisors published in the first quarter of 2026, around 78% of essential entities in DORA scope have established a register of third-party ICT providers and a documented ICT risk management policy. This is the minimum standard, and it is broadly respected.
But DORA is not a documentary exercise. Articles 24 to 27 require an effective operational resilience testing programme, precise notification deadlines in the event of a major incident, and integrated ICT risk governance at board level. On these three areas, the gap between the document and operational reality is significant.
A telling data point: according to a Deloitte EU Financial Services survey published in March 2026, 61% of surveyed entities acknowledge that their DORA testing programme "is not yet operational at the required scale". The ratio of declared compliance to operational compliance ranges from 1.4 to 1.8 depending on entity type. For every operationally active measure, there are between 0.4 and 0.8 measures on paper only.
Gap 1: resilience tests remain cosmetic
DORA distinguishes two levels of testing. Basic tests (Article 24), such as vulnerability reviews, scans and penetration tests, apply to all entities in scope. Threat-Led Penetration Tests (TLPT, Article 26) concern entities of systemic importance designated by supervisors and must be conducted by certified providers under the TIBER-EU framework.
The observed problem: even basic tests are frequently one-off annual exercises, disconnected from the remediation cycle. An entity that carries out a penetration test in March 2025, fixes 60% of the vulnerabilities identified, and does not retest before March 2026 does not have a resilience programme. It has an audit with an annual publication cycle. DORA expects a continuous programme, with traceable and auditable remediation loops.
The common mistake: entrusting tests to the internal security team without external oversight, then presenting the results as evidence of DORA compliance. A test conducted by the team that operates the systems being tested does not meet the independence requirements of Article 24(3). Supervisors are beginning to ask for testers' mandates and CVs during on-site inspections.
Gap 2: the ICT register does not cover levels 2 and 3
DORA Article 28(3) requires the maintenance of an "exhaustive and up-to-date" register of all contractual arrangements with third-party ICT providers. In practice, most registers established in 2025 cover direct providers, that is level 1. Visibility stops there.
Yet the most costly systemic incidents of recent years precisely involve levels 2 and 3. The CrowdStrike incident of July 2024 paralysed systems in entities that had no direct contractual relationship with the vendor: it was embedded in the solutions of their managed service providers. The Cloudflare outage of January 2025 affected hundreds of financial entities that did not list it in their DORA register, because they were unaware of their indirect dependency.
The practical rule: for each critical ICT provider, defined as a provider whose failure would affect critical or important functions, request an additional level of mapping: its own subcontractors hosting processing on your behalf. This information must be contractually communicable under Article 30. If your provider refuses, this is a hidden concentration signal to document.
Gap 3: notification deadlines are theoretical
DORA requires an initial notification to the competent authorities within 4 hours of classifying a major incident, and an intermediate report within 72 hours. In the crisis simulations run by ACPR teams in 2025, the median time between detecting an incident and formally classifying it as a "major incident" is 6 to 14 hours, before the regulatory 4-hour clock even starts.
The friction point is structural: the classification process. Who decides that an incident is "major" within the meaning of DORA? On which quantified criteria? Within what time window? In most audited entities, this process involves a validation chain of three or four hierarchical levels. The time needed to reach a decision means the 4 hours are often exceeded.
The fix is organisational, not technical: formalise a DORA classification table with thresholds pre-approved by the board (number of users affected, duration of interruption, volume of data compromised), and delegate the classification decision to the CISO or CRO with an autonomous right to raise an alert. The regulator may accept a missed deadline made in documented good faith; it does not accept an unformalised decision process.
Gap 4: ICT risk is not integrated into the board's decision cycle
DORA (Article 5) requires members of the management body to remain "actively involved in the management of ICT risk" and to define "ICT risk tolerance strategies". In practice, ICT governance remains within technical departments and reaches the board as aggregated reports, once a year in 68% of surveyed entities (Deloitte, March 2026).
This is not a question of board members' technical competence. It is a question of reporting format. An ICT dashboard designed for a CISO, with the rate of vulnerabilities fixed, mean time to detection and incident logs, does not allow a board to take strategic decisions on risk tolerance. What a board can decide is: what level of service interruption is acceptable for which critical function? What share of the budget should go to business continuity? These decisions require business risk language, not technical language.
The practical test: can your board answer, without consulting the IT department, the following question: "what is our RTO for the payment system in the event of a major ICT incident?" If the answer requires a back-and-forth, your ICT governance is not integrated in the sense of Article 5 DORA.
What you can start now
Three actions with immediate scope, without a transformation programme. First, reassess the independence of your testers: verify that your DORA penetration tests are conducted by parties independent of the operating teams. This is your first risk of deficiency at inspection. Second, add a layer to your ICT register: contact your five most critical providers and ask for their list of subcontractors hosting data or functions on your behalf. The answer, or the absence of one, is already an indicator. Third, formalise your incident classification table: a one-page document, pre-approved, with explicit thresholds and delegated decision-making to the CISO.
Presidio includes an ICT risk management module aligned with DORA: third-party register by level, incident tracking with an integrated regulatory timer, and a structured notification workflow. To assess the gap between your current governance and regulatory expectations, a 30-minute interview is enough to map priorities. See also our analysis of DORA Article 28 contractual clauses and our review of ICT concentration risks.
Conclusion
Eighteen months after DORA began to apply, three things are clear. Documentary compliance is progressing but does not prejudge operational compliance, and regulators know it. The first in-depth inspections, expected for 2026-2027, will target precisely the gap between policies and their actual implementation. Entities that invest now in operational remediation (independent testing, level 2 register, formalised notification process, structured board governance) will have a head start in a supervision cycle that has just begun. And in your context: if you received a supervisor's request for information tomorrow morning, which link in your ICT governance chain would be the weakest?