DORA's First Enforcement Cycle: Fines, Register of Information Failures, and What CISOs Must Fix Now

The Digital Operational Resilience Act (DORA) became fully applicable to EU financial entities on January 17, 2025. Eighteen months later, the first enforcement cycle is producing real penalties. As of June 2026, the European Supervisory Authorities (EBA, ESMA, and EIOPA) have completed initial supervisory reviews across a significant sample of in-scope institutions, and national competent authorities (NCAs) in several member states — most notably the Netherlands (DNB), Germany (BaFin), and Ireland (Central Bank of Ireland) — have issued administrative penalties.

The headline figure from DORA’s penalty framework is up to 10% of total global annual turnover for legal entities, and up to 2% of total daily worldwide turnover per day of continued violation for ongoing breaches. Those numbers are not theoretical. The first batch of penalties, while not publicly disclosed in full, has been described in ESA communications as “material” and calibrated to signal that DORA compliance is not a checklist exercise.

This briefing summarises the enforcement themes emerging from the first cycle and what CISOs and boards need to prioritise before Q3 supervisory reviews.

Lead Finding: Register of Information

The single most common enforcement finding across all three ESAs’ reviews is failure to maintain an adequate Register of Information (RoI) for ICT third-party service providers.

DORA Article 28 requires financial entities to maintain a complete, accurate, and current register of all contractual arrangements with ICT third-party providers. The ESAs mandated a specific reporting template (published as part of the DORA implementing technical standards) that requires entities to categorise providers, assess criticality, document concentration risk, and report to supervisors on demand.

Common RoI failures flagged in the first enforcement cycle:

• Incomplete scope: Entities excluded cloud providers, SaaS tools, and telco providers from the register by classifying them as “non-ICT” contracts despite providing services that underpin ICT systems. The ESAs have clarified that any service that contributes to ICT operations falls within scope regardless of how the contract is labelled internally.
• Stale data: Registers were populated once during the DORA implementation project and not maintained. Supervisors found discrepancies between the register and actual live contracts, including providers that were onboarded post-cutover with no register entry.
• Missing criticality assessments: Entities documented providers but did not complete the DORA-mandated criticality/importance assessment that determines which providers are “critical ICT third-party providers” subject to enhanced oversight.
• No concentration risk quantification: DORA explicitly requires assessment of concentration risk — the exposure that arises from dependence on a small number of providers for critical services. Many registers contained provider lists but no concentration analysis.
• Contractual gaps with existing providers: DORA Article 30 requires ICT contracts to include specific provisions (audit rights, exit plans, security standards, incident notification timelines). Supervisors found that legacy contracts — particularly with long-standing vendors — lacked these clauses, and entities had not renegotiated or supplemented them.

ICT Risk Management Framework Gaps

The second major enforcement theme is ICT risk management framework deficiencies under DORA Chapter II. The ESAs applied a maturity-based assessment model and found that many entities had framework documents in place but had not operationalised them.

Specific findings:

• Board-level ownership: DORA places explicit responsibility for ICT risk on the management body, not IT leadership alone. Several entities could not demonstrate that the board had formally approved the ICT risk management framework, received periodic ICT risk reporting, or engaged with the results of ICT resilience testing.
• Asset management gaps: DORA requires a complete and classified ICT asset inventory. Entities with mature vulnerability management programmes nevertheless had coverage gaps — typically in OT/IoT assets, legacy on-premises systems, and assets introduced through mergers.
• Incident classification inconsistency: DORA’s major incident classification thresholds (introduced in the implementing technical standards) require consistent application. Supervisors found institutions using internal severity definitions that did not map correctly to the DORA criteria, resulting in incidents that should have been classified as “major” and reported to supervisors within 4 hours not being reported at all.
• TLPT planning: Threat-Led Penetration Testing (TLPT) under DORA Article 26 is required for significant institutions on a three-year cycle. The first three-year window started January 2025, meaning the first TLPTs must be completed by January 2028 — but supervisors are already reviewing TLPT planning and have found many institutions have not begun scoping.

Incident Reporting: Timelines Are Non-Negotiable

DORA establishes a three-stage incident reporting obligation for major ICT incidents:

1. Initial notification: Within 4 hours of classification as a major incident
2. Intermediate report: Within 72 hours of initial notification
3. Final report: Within 1 month of incident resolution

The first enforcement cycle identified failures at all three stages. The 4-hour initial notification timeline is particularly challenging because it begins from the point of classification, not discovery — and entities have been penalised for internal processes that delayed classification without justification.

Practical implication: The incident management playbook needs a defined, timed step for DORA major incident classification. The classification decision must be documented with a timestamp and the responsible decision-maker. Any delay beyond the trigger event requires documented justification.

What Boards Need to Do Before Q3

Supervisory review activity is expected to intensify in Q3 2026. CISOs should use the following framework to prepare:

1. RoI Audit and Gap Close

• Extract all active contracts with ICT components from procurement, finance, and vendor management systems — do not rely on the existing register as a starting point
• Apply DORA’s definition of ICT services broadly; when in doubt, include
• Complete or refresh criticality assessments for every provider using the ESA template criteria
• Document concentration risk quantitatively: identify services where a single provider failure would affect critical business functions, and calculate the percentage of critical ICT services covered by the top 1, 3, and 5 providers
• Flag contracts without DORA-required clauses and initiate renegotiation; document the renegotiation status for supervisors

2. Board Reporting Cadence

• Confirm that ICT risk is a standing agenda item at the management body level (board or equivalent), not just a risk committee delegation
• Ensure the board received and formally approved the ICT risk management framework; if approval predates DORA’s full applicability, confirm that a DORA-aligned version has been re-approved
• Provide the board with a DORA compliance status briefing ahead of Q3 that covers RoI status, TLPT planning, and open remediation items

3. Incident Management Playbook Review

• Map each step of your major incident response process to DORA’s 4-hour / 72-hour / 1-month reporting timelines
• Identify who holds classification authority, document the criteria they apply, and ensure consistency with the ESA’s major incident classification thresholds
• Run a tabletop exercise against a realistic major ICT incident scenario and measure actual classification and notification timelines against DORA requirements

4. TLPT Scoping

• If TLPT has not been scoped, begin immediately — the preparation, scope agreement with your NCA, and execution timeline means there is no slack remaining before the 2028 deadline for institutions needing multiple test cycles
• Engage an accredited TLPT provider (the list is published by each NCA) early; availability is constrained as more institutions compete for the same providers
• Ensure the TLPT scope covers critical ICT systems as defined in your RoI, not just the systems IT leadership considers important

The 10% Penalty: How It’s Calculated

When assessing penalties, NCAs consider:

• Gravity and duration: Incomplete registers maintained for the full period since January 2025 produce larger penalties than recent gaps
• Intentional vs negligent: Wilful non-compliance or obstruction of supervisors draws maximum penalties; genuine implementation challenges with documented remediation efforts are mitigating
• Cooperation: Institutions that self-identified gaps and reported proactively have received significantly lighter treatment than those where supervisors discovered deficiencies independently
• Systemic vs isolated: Structural failures (no framework, no register) versus individual control gaps (one missing contract clause) are assessed differently

The practical lesson from the first cycle is that demonstrating documented, good-faith effort — even where full compliance hasn’t been achieved — materially affects penalty calibration.

Timeline of Key Dates

References

• DORA Regulation (EU) 2022/2554
• EBA DORA Implementing Technical Standards
• ESMA DORA Supervisory Framework
• DNB DORA Supervisory Expectations 2026