The EU Digital Operational Resilience Act came into full application on January 17, 2026. The two-year implementation period that preceded it was, in theory, sufficient time for financial entities across the EU to build the ICT risk management frameworks, incident reporting procedures, digital operational resilience testing programs, and third-party risk management arrangements that DORA requires. In practice, the first quarter of enforcement has revealed that a substantial portion of financial entities within scope are not compliant, and that the gaps are not primarily technical.
Key findings
- The most common gap is not in ICT systems but in governance documentation. Organizations that have mature ICT security operations frequently lack the documented ICT risk management framework, the management body accountability structures, and the incident classification procedures that DORA requires at a governance level.
- Third-party ICT risk management is the largest substantive compliance gap. DORA's requirements for registering, assessing, and managing third-party ICT service providers, including the specific provisions for critical third-party providers, represent genuinely new obligations that most organizations have not yet implemented at the required standard.
- Digital operational resilience testing under Article 26 is underimplemented. Most organizations have not conducted threat-led penetration testing to the DORA standard. Those that have existing TLPT programs often find they do not meet DORA's specific requirements for scope, documentation, and remediation follow-up.
- The management body accountability requirement is creating governance friction. DORA requires the management body to approve the ICT risk management framework, review it regularly, and bear accountability for its implementation. This requires a level of board engagement with operational technology risk that most financial services boards have not previously exercised.
What DORA actually requires at the governance level
DORA's five pillars are well documented: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. What is less well understood is the governance layer that sits above all five. Articles 5 through 16 establish, in considerable detail, what the management body of a financial entity must do, approve, and be accountable for in relation to ICT risk.
The management body is required to define and approve the ICT risk strategy, approve the ICT risk management framework, oversee the implementation of the ICT business continuity policy, and ensure adequate resources are allocated to ICT risk management. These are not IT department functions. They are board-level governance obligations. The management body's accountability cannot be delegated to the CTO or the CISO in a way that removes the board's direct responsibility for the outcomes.
The ICT risk management framework gap
The most common finding in Q1 2026 reviews is that organizations with sophisticated ICT security operations have not translated those operations into the documented ICT risk management framework that DORA requires. They are managing ICT risk effectively, in the sense that their security operations are mature and their incident response is practiced. But they have not produced the documented framework that DORA requires to be approved by the management body, reviewed at defined intervals, and made available to competent authorities on request.
This is a governance documentation gap, not a capability gap. The capability is present. The governance record that demonstrates the capability is managed under board oversight is absent. In a regulatory examination, the absence of the documented framework is an infringement regardless of the underlying capability. Supervisory authorities are required to assess what is documented, not what is practiced.
DORA does not require financial entities to become more secure. It requires them to govern their security formally, document that governance, and demonstrate to their competent authority that the management body owns it.
KIG Field Intelligence, Briefing, March 2026Third-party ICT risk: the substantive gap
DORA Chapter V establishes a comprehensive regime for managing third-party ICT service providers. The requirements go substantially beyond what most financial entities have implemented under existing EBA guidelines or national supervisory expectations. The register of information on all contractual arrangements with ICT third-party service providers, required under Article 28, must be maintained in a format specified by the Joint Committee regulatory technical standards and must be reported to competent authorities annually.
For critical ICT third-party service providers, DORA establishes a direct supervisory relationship with Lead Overseers designated by the European Supervisory Authorities. Financial entities must ensure their contracts with critical third-party providers include the specific provisions required under Article 30, including audit rights, subcontracting visibility, and business continuity obligations calibrated to the DORA standard.
The gap most commonly identified is in the contractual provisions. Organizations that have existing contracts with major cloud providers, core banking system vendors, and other critical ICT service providers find that those contracts, even recently negotiated ones, often do not include the specific provisions DORA requires. Renegotiating contracts with major technology vendors takes time. Organizations that have not begun this process are exposed to a compliance gap that cannot be closed quickly.
Threat-led penetration testing requirements
Article 26 requires financial entities to conduct threat-led penetration testing at least every three years. The DORA framework for TLPT is based on the TIBER-EU framework developed by the ECB, but with specific modifications for DORA's scope and requirements. Key differences from existing TLPT programs include: the requirement for a DORA-specific scope document approved by the management body; mandatory engagement of accredited external testers; defined remediation timelines for identified vulnerabilities; and a completion certificate that must be submitted to the competent authority.
Organizations with existing penetration testing programs often find that their programs do not meet the DORA TLPT standard. The accreditation requirements for external testers, the scope documentation requirements, and the remediation reporting obligations are specific to DORA and do not automatically correspond to existing industry practice. Organizations should not assume that their current testing program satisfies Article 26 without a specific gap analysis against the regulatory technical standards.
A practical remediation sequence
For organizations that have identified compliance gaps following the January 2026 application date, the remediation priority sequence should be: first, produce the documented ICT risk management framework in the format DORA requires and present it to the management body for approval; second, conduct a comprehensive review of contractual arrangements with ICT third-party service providers against the Article 30 requirements and initiate renegotiation where gaps exist; third, assess the current TLPT program against the Article 26 requirements and develop a remediation plan if gaps are identified; fourth, review incident classification procedures against the RTS on classification of major ICT-related incidents and ensure the reporting timelines and formats are understood and operationally tested.
The sequencing matters because the management body approval of the ICT risk management framework is the governance foundation for everything else. Without that documented framework, the organization's compliance posture cannot be assessed holistically, and the management body cannot meaningfully exercise the oversight obligations that DORA assigns to it.