European financial supervisory landscape — the ESAs now operate a continuous, data-driven oversight cycle across all EU member states.
On March 31, 2026, the clock ran out on DORA‘s administrative phase. That was the hard deadline for National Competent Authorities across the EU to transmit their Registers of Information — the comprehensive filings of every financial entity’s ICT third-party service provider relationships — to the European Supervisory Authorities: the EBA, EIOPA, and ESMA. For many financial institutions, the filing felt like the end of a long and demanding compliance project. For regulators, it was the beginning of something more consequential: an active, data-driven supervisory cycle that the ESAs will now run continuously.
The message from supervisors across Europe could not be clearer. As AQMetrics noted in its February 2026 compliance analysis, 2025 was, for many institutions, “a dress rehearsal.” Regulators largely guided firms through initial setup with an emphasis on good-faith effort. That era of tolerance has ended. The new supervisory mandate, as expressed by NCAs from the Central Bank of Ireland to the AMF in France, is “interventionist supervision.” The question is no longer whether your organization has a DORA framework on paper. It is whether that framework functions effectively in real-world conditions — and whether the data you submitted on March 31 will survive automated regulatory scrutiny.
What Has Changed Since January 2025
When DORA became applicable on January 17, 2025, the regulatory focus was on establishment: build your ICT risk management framework, compile your register, test your incident response, map your third-party dependencies. For institutions still catching up, regulators signaled patience. That posture reflected the practical reality that DORA’s requirements are operationally demanding and the technical standards were still being finalized.
Fifteen months later, the regulatory environment has shifted fundamentally on three dimensions:
Automated supervision is now operational.
NCAs are no longer relying on manual audits as their primary oversight tool. The ESAs have deployed sophisticated automated systems that cross-reference ICT registers across the EU’s entire financial sector simultaneously. Your register is not reviewed in isolation — it is compared against registers submitted by the same vendor’s other clients and against information submitted by the vendors themselves. Inconsistencies, technical gaps, late updates, and data quality failures are flagged automatically. As Noggin’s March 2026 supervisory guide notes, the March 31 RoI transmission entered data into “the ESA’s centralized processing engine — for good.” From that point, your data is live, continuously referenced, and the basis for supervisory action.
The penalty framework is now being actively applied.
The financial consequences of DORA non-compliance have moved from theoretical to operational. For Tier 1 violations, turnover-linked fines can reach 2 percent of total annual worldwide turnover — not a fixed fee, but a systemic penalty calibrated to the potential systemic impact of a firm’s digital failure. Daily compulsion payments are being issued for ongoing violations. NCA enforcement teams that were previously focused on guidance are now focused on intervention. Institutions that were hoping the penalty framework would remain aspirational are discovering that it is not.
The supervisory scope has expanded to ICT concentration risk.
One of the ESAs’ declared priorities for the 2026 supervisory cycle is identifying systemic concentration in ICT third-party providers across the EU financial sector. This is a macro-prudential concern: if the majority of European financial institutions are dependent on the same handful of cloud providers, payment infrastructure vendors, or data service providers, a single disruption becomes a sector-wide event. Institutions whose registers reveal high concentration in critical ICT dependencies should expect heightened supervisory attention — and in some cases, mandatory remediation requirements.
The Five DORA Compliance Gaps Regulators Are Finding
Based on supervisory guidance, NCA feedback, and compliance assessments published in the first quarter of 2026, five failure patterns are emerging consistently across institutions that submitted their March 31 registers:
1. Incomplete or Inconsistent ICT Third-Party Registers
The most widespread compliance failure identified in the Q1 2026 supervisory cycle is incomplete register data — missing vendor relationships, inconsistent classification of criticality, and data that does not align with information submitted by vendors or peer institutions. Many firms treated the register as a documentation exercise rather than a live operational tool, resulting in filings that pass a surface-level review but fail automated cross-referencing. The ESA’s 116-point automated audit, as documented by Noggin, catches inconsistencies that manual reviews routinely miss.
ACTION POINTS
- Treat your Register of Information as a living operational document, not a compliance deliverable — establish a defined update cadence (at minimum quarterly) and a named owner responsible for accuracy and completeness.
- Cross-reference your register against your actual contractual relationships with ICT vendors: discrepancies between what is filed and what contracts exist are one of the most common automated-audit failure triggers.
- Where your register covers a critical ICT third-party provider, validate that the information you have filed is consistent with what that provider would file on its own behalf — regulatory cross-referencing will surface inconsistencies regardless.
2. ICT Risk Management Frameworks That Exist on Paper but Not in Practice
DORA requires a continuous, documented ICT risk management framework — not a policy document, but an operational process that is actively maintained across the full technology lifecycle. The gap that regulators are most frequently citing in Q1 2026 is the difference between a framework that exists as documentation and one that generates real-time evidence of operation: updated risk assessments, documented management decisions, current control testing records, and incident logs.
ACTION POINTS
- Commission an independent assessment of your ICT risk management framework against DORA’s Article 6 requirements — specifically testing whether documented processes are operationally active and generating current evidence, rather than reflecting a point-in-time implementation.
- Establish a quarterly ICT risk management review cycle with documented outputs: updated risk assessments, control effectiveness ratings, and identified remediation actions — each with a named owner and deadline.
- Ensure your board receives a structured ICT risk management report at least annually, with sufficient granularity to demonstrate that board-level oversight of digital operational resilience is substantive, not ceremonial.
3. Digital Operational Resilience Testing That Does Not Meet the Threat-Led Standard
DORA requires financial institutions — particularly those classified as significant — to conduct threat-led penetration testing (TLPT) using the TIBER-EU framework or national equivalents. TLPT is not a standard penetration test. It is a comprehensive, intelligence-led exercise that simulates the tactics, techniques, and procedures of real-world threat actors against live production systems. The supervisory feedback from Q1 2026 indicates that many institutions have conflated existing penetration testing programs with DORA-compliant TLPT — a conflation that will not survive regulatory scrutiny.
ACTION POINTS
- Confirm whether your institution is classified as significant under DORA and therefore subject to mandatory TLPT requirements — and if so, whether a compliant TIBER-EU exercise has been completed or scheduled within the required three-year cycle.
- Where TLPT has not yet been conducted, engage a DORA-qualified testing provider and initiate the exercise now — the lead time for a compliant TLPT engagement, including intelligence gathering, red team execution, and formal reporting, is typically six to nine months.
- Ensure that the outputs of your resilience testing program — including identified vulnerabilities and remediation actions — are formally documented, reported to senior management, and tracked to closure with evidence.
4. Third-Party Risk Management That Stops at Tier-One Suppliers
DORA’s third-party risk requirements extend beyond direct ICT vendor relationships to the subcontractors and supporting providers on which those vendors depend. For most institutions, regulatory focus has been on tier-one relationships — the vendors they contract with directly. But the systemic risk the ESAs are concerned about often resides in tier-two and tier-three dependencies: the infrastructure providers, data center operators, and software vendors that critical ICT service providers themselves depend on. Supervisory scrutiny of concentration risk at these deeper tiers is increasing.
ACTION POINTS
- Extend your ICT third-party risk assessment to cover material sub-contractor relationships for your five most critical ICT vendors — specifically mapping where those sub-contractors create additional concentration or single-point-of-failure risk.
- Review the contractual provisions in your critical ICT vendor agreements to ensure they require vendors to notify you of material changes to their own sub-contractor relationships — and that they grant you audit rights over material sub-contractors.
- Where sub-contractor concentration creates unacceptable risk, engage your critical vendors on risk mitigation — and document the outcome of those conversations as evidence of active third-party risk management.
5. Incident Classification and Reporting That Does Not Align With DORA’s Definitions
DORA establishes specific criteria for classifying ICT-related incidents and cyber threats as “major” — triggering mandatory reporting obligations to NCAs within defined timeframes. The supervisory feedback from Q1 2026 indicates that many institutions are applying their own internal incident classification criteria rather than DORA’s definitions, resulting in incidents that should have been reported going unreported, and in some cases, report formats and timelines that do not meet regulatory requirements.
ACTION POINTS
- Conduct an immediate review of your ICT incident classification framework to validate that it accurately reflects DORA’s materiality thresholds for major incident designation — and update internal procedures where gaps exist.
- Test your incident reporting workflow: from initial detection to NCA notification, can your organization meet DORA’s initial report requirement (within four hours of classification as major) and intermediate report requirement (within 72 hours)? If not, identify and close the operational gaps.
- Ensure your incident response team has been trained specifically on DORA reporting obligations — including the distinction between major incidents, significant cyber threats, and other ICT incidents — and that this training is documented and regularly refreshed.
From Compliance to Competitive Advantage
DORA was designed to do something more ambitious than produce regulatory filings. Its architects intended it to make the European financial system genuinely more resilient to ICT disruption — more capable of absorbing, adapting to, and recovering from operational shocks without cascading systemic consequences. The institutions that have treated DORA as a compliance burden to be minimized are discovering that the regulation’s operational demands are not going away — and that supervisory patience with minimum-viable compliance has ended.
The institutions best positioned for the active supervisory phase that began on April 1, 2026, are those that treated DORA not as a filing deadline but as an operational standard. Their ICT risk frameworks are running continuously. Their registers are current. Their resilience testing has been completed. Their incident response capabilities have been exercised. For those institutions, DORA compliance is becoming a differentiator — in regulatory relationships, in client confidence, and in the credibility they can demonstrate when the next operational disruption arrives.
The grace period is over. The supervisory cycle has begun. The question for every financial services leader is whether their organization is ready to be scrutinized — not just reviewed.
Assess Your DORA Readiness Before the Regulator Does
Karysburg works with financial services organizations to assess DORA compliance gaps, strengthen ICT risk management frameworks, and build the operational resilience capabilities that active supervisory scrutiny demands. If the March 31 filing has raised questions about your organization’s readiness for the supervisory cycle ahead, now is the time to find the answers.
Book a DORA compliance readiness assessment with our team today.