We have written before about how 2026 is the year the European Union’s two flagship cyber-resilience regimes stop being aspirational and start being enforced. That broader picture — the convergence of DORA enforcement and the NIS2 deadline, the Register of Information, incident reporting, and why U.S. companies are caught in scope — is laid out in our companion analysis, DORA Enforcement Arrives and NIS2 Hits Its October Deadline. This article narrows the lens to the one consequence that should concentrate the minds of directors and senior executives more than any fine schedule: under both regimes, the management body is personally on the hook.

This is not a drafting flourish. Both DORA and NIS2 deliberately move cyber-risk accountability out of the IT function and into the boardroom, attaching duties that cannot be delegated away and, in NIS2’s case, sanctions that reach individuals. With the NIS2 national compliance deadline culminating in October 2026 and DORA already in its first genuine supervisory enforcement cycle, the window for treating these as documentation exercises has closed.

Where the Deadline Actually Stands

NIS2 (Directive (EU) 2022/2555) set a transposition deadline of 17 October 2024, which most member states missed. As of mid-2026 the great majority have now adopted transposing legislation, while a handful — including France, Ireland, Luxembourg, the Netherlands, and Spain — remained in their legislative procedures into 2026, with the European Commission pursuing infringement action against laggards. The practical effect is a staggered but converging compliance horizon throughout 2026, with national registration duties, self-assessments, and supervisory readiness consolidating around the autumn. For in-scope entities, October 2026 is the point by which “we are still implementing” stops being an acceptable answer.

DORA (Regulation (EU) 2022/2554) faces no such patchwork. As a directly applicable regulation it has been in force since 17 January 2025, and supervisors are now past the orientation phase. The first full annual cycle of structured supervision has run, and competent authorities have signalled where they will press first. The two regimes therefore arrive at the same place from opposite directions: NIS2 through a transposition deadline, DORA through an enforcement cycle. In both, the board is the accountable party.

The Management-Liability Framework Both Regimes Share

The architecture is strikingly parallel across the two instruments, and understanding the overlap is the first step to discharging it.

NIS2 Article 20 — approval, oversight, and personal liability. Article 20(1) requires that the management bodies of essential and important entities approve the cybersecurity risk-management measures, oversee their implementation, and can be held liable for the entity’s infringements. This is the provision that makes cybersecurity a board-level legal duty rather than a delegated technical task. Article 20(2) adds a personal obligation that is easy to overlook: members of the management body are required to follow training, and entities must offer comparable training to staff, so that directors acquire sufficient knowledge to identify risks and assess cybersecurity risk-management practices. A director who has never been trained and who rubber-stamps a measures document they do not understand has not satisfied Article 20.

Several national transpositions sharpen this further. Germany’s implementing legislation, building on the revised BSI Act, makes cybersecurity an explicit board-level responsibility and exposes management to liability for failures to oversee risk-management measures — and notably constrains the ability of companies to simply waive or indemnify directors out of that exposure. The directive itself contemplates that supervisory authorities, for essential entities, may temporarily prohibit individuals from exercising management functions where serious failures persist.

DORA Article 5 — the management body owns ICT risk. DORA places equivalent weight on governance. Under Article 5, the management body of a financial entity bears ultimate responsibility for managing ICT risk. It must define, approve, and oversee the ICT risk-management framework; set clear roles for all ICT-related functions; approve and review the digital operational resilience strategy and the policy on the use of ICT third-party providers; and — mirroring NIS2 — maintain sufficient knowledge and skills, including through regular, dedicated training, to understand and assess ICT risk. The responsibility is non-delegable in substance: a board may rely on a CISO or a chief risk officer to execute, but it cannot outsource the duty to understand and direct.

The common thread is unambiguous. Both regimes reject the model in which the board receives an annual slide and signs off. They require approval based on understanding, active oversight, documented training, and personal accountability when those duties are neglected.

What Supervisors Are Acting On First

Enforcement priorities are not evenly distributed. Supervisors are pursuing the failures that are easiest to evidence and most diagnostic of weak governance. Three sit at the front of the queue.

1. DORA incident-reporting failures. DORA’s ICT-related incident reporting regime (Articles 17 to 23, operationalised through the relevant regulatory and implementing technical standards) imposes hard obligations: classify incidents against defined criteria, and for major ICT-related incidents submit an initial notification, an intermediate report, and a final report to the competent authority within prescribed windows. Reporting failures — missed deadlines, misclassification that keeps a major incident off the radar, or final reports that cannot reconstruct root cause and remediation — are exactly the kind of breach that supervisors can identify from the record without a forensic investigation. They are an early and favoured enforcement target precisely because the obligation is concrete and the failure is documented in the entity’s own timeline.

2. Deficiencies in the Register of Information. Every financial entity must maintain a complete Register of Information cataloguing its contractual arrangements with ICT third-party providers and submit it to its national competent authority, which consolidates and forwards registers to the European Supervisory Authorities. The annual submission cycle has now run more than once, and persistent Register deficiencies — incomplete entries, inaccurate data fields, an inability to trace the chain of subcontractors supporting critical or important functions — have been flagged as a supervisory priority. A defective Register is doubly damning: it is a documented compliance failure in its own right, and it is evidence that the entity does not actually understand its own third-party dependency map, which is the foundation of the entire third-party risk pillar.

3. NIS2 governance and the sanctions behind it. On the NIS2 side, supervisors examine whether the management body has genuinely approved and is overseeing the risk-management measures required under Article 21 (the all-hazards measures covering risk analysis, incident handling, business continuity, supply-chain security, and more), and whether incident notification under Article 23 — the early warning within 24 hours, the incident notification within 72 hours, and the final report within one month — actually functions. The penalties give these inquiries teeth. For essential entities, administrative fines reach a maximum of at least €10 million or 2% of total worldwide annual turnover, whichever is higher. For important entities, the ceiling is at least €7 million or 1.4% of total worldwide annual turnover, whichever is higher. Layered on top are the personal consequences for management bodies, up to and including temporary management bans for essential entities.

The pattern across all three is consistent: supervisors are starting with obligations that are objective, time-stamped, and self-documenting, because those are the failures that prove themselves.

The Compliance Gap Nobody Should Ignore

The uncomfortable backdrop is that a large share of in-scope organisations are operating under binding obligations they have not finished implementing. Industry readiness surveys have repeatedly indicated that only around half of in-scope financial institutions reached full DORA compliance on the timeline regulators expected, with a substantial cohort pushing completion targets into 2026 and beyond. NIS2 readiness across the broader population of essential and important entities is, if anything, more uneven, given the staggered transposition.

This produces the defining risk condition of 2026: covered entities that are bound now, supervised now, and still building. There is no grace in that gap. An entity that suffers a major incident in the third quarter of 2026 will be judged against the obligations as they stand in October 2026, not against its internal project plan. For management bodies, the implication is direct — the unfinished state of a control program is not a defence; it is itself the exposure the board is responsible for overseeing.

Board and Management-Body Readiness Checklist for October 2026

The following is a concrete agenda for directors and senior management to work through before the deadline. It is organised around the duties the two regimes will not let the board delegate.

Governance and accountability

  • Confirm, in writing, which board committee or management-body forum owns DORA ICT-risk oversight (Article 5) and NIS2 risk-management oversight (Article 20), and ensure the mandate, meeting cadence, and reporting lines are documented in the terms of reference.
  • Ensure the management body has formally approved the current ICT risk-management framework, the digital operational resilience strategy, the ICT third-party policy (DORA), and the Article 21 risk-management measures (NIS2) — with minutes that evidence substantive discussion, not a pro-forma sign-off.
  • Verify that every member of the management body has completed cybersecurity training as required by NIS2 Article 20(2) and DORA Article 5, and that the training is recurring, dated, and recorded. Untrained directors are a documented gap.

DORA incident reporting

  • Test that the incident classification process correctly distinguishes major ICT-related incidents and that the criteria are applied consistently, not improvised during a crisis.
  • Run a tabletop against the initial / intermediate / final reporting windows and confirm the entity can actually produce each report on time, with the data fields supervisors require.
  • Confirm the board receives timely escalation of major incidents — the management body cannot oversee what it learns about after the regulator does.

Register of Information

  • Commission an independent quality review of the Register before the next submission: completeness of entries, accuracy of data fields, and traceability of subcontractors supporting critical or important functions.
  • Reconcile the Register against the entity’s actual third-party dependency map and contract inventory; a Register that does not match reality is the failure mode supervisors are already citing.

NIS2 measures and notification

  • Validate that the Article 21 all-hazards measures are implemented and evidenced, with particular attention to supply-chain security and business continuity.
  • Test the 24-hour / 72-hour / one-month notification chain under Article 23 end to end, including who has authority to notify when key personnel are unavailable.
  • Confirm national registration and any member-state-specific self-assessment obligations are complete in every jurisdiction where the entity is in scope.

Liability hygiene

  • Obtain a clear legal read on personal liability and management-ban exposure under the applicable national transposition, and on the extent to which D&O insurance and indemnification actually respond — recognising that some jurisdictions limit the ability to indemnify directors out of NIS2 duties.
  • Maintain a defensible evidence trail of approval, oversight, training, and escalation, so the board can demonstrate it discharged its duties even where a control program remains in flight.

Conclusion

The structural shift in both DORA and NIS2 is the relocation of cyber-risk accountability into the management body and the attachment of personal consequences to its neglect. NIS2 Article 20 makes directors approve, oversee, train, and answer; DORA Article 5 gives the board ultimate responsibility for ICT risk; and the supervisors arriving in 2026 are starting with the failures that prove themselves — late or misclassified incident reports, defective Registers of Information, and governance that exists on paper but not in practice. Against penalties reaching €10 million or 2% of turnover for essential entities, and the prospect of individuals being barred from management functions, the unfinished compliance program is not a mitigating circumstance but the very exposure the board is charged with overseeing. The deadline is October 2026. The accountable party is in the boardroom. The work that remains is to make oversight real and to be able to prove it.

For the wider regulatory map — scope, the lex specialis relationship between the two regimes, and the cross-border reach into U.S. operations — see our companion piece, DORA Enforcement Arrives and NIS2 Hits Its October Deadline.

This article is provided for informational purposes only and does not constitute legal advice.