Picture the moment. A ransomware incident has taken down a critical supplier. Your organisation's services are degraded for six days. The regulator's follow-up letter doesn't ask your CIO what happened. It asks your board — by name — three questions: What was your ICT risk framework? When did you last review it, personally? And can you demonstrate that you understood what you approved?
Under DORA and NIS2, that is not a hypothetical. It is the letter of the law.
For most of my career, digital risk was a management concern — the CIO's problem, escalated to the board as a slide, nodded through, filed. That era is over. Three pieces of EU legislation — the Digital Operational Resilience Act (DORA), the NIS2 Directive, and the AI Act — have, in different ways, moved ICT and AI risk out of the appendix and onto the board's own desk. Not as an oversight duty you can delegate to the people who report to you. As a personal one.
I've spent 30 years on the operating side of exactly this line — inside a DNB-regulated bank's technology function, and more recently advising an Executive Board on cloud, data, and AI risk at a listed geo-data company. What follows is what I've learned about what these three laws actually ask of a board, translated out of legal text and into the questions you should be able to answer this week.
Three liabilities, not one — and they don't work the same way
It's tempting to lump DORA, NIS2, and the AI Act together as "more compliance." That's a mistake, and not just a semantic one. Each creates board exposure through a different mechanism, and knowing which is which changes what you actually have to do about it.
DORA is the sharpest of the three. Article 5(2)(a) requires the management body to "bear the ultimate responsibility for managing the financial entity's ICT risk." Not "should be aware of." Not "should ensure someone owns it." Ultimate. Recitals 45 and 46 frame that as full and ultimate responsibility — an overarching principle, not a duty you discharge by assigning it downward. Article 28(1)(a) closes the obvious escape route: entities "shall, at all times, remain fully responsible for compliance" even when the work sits with a third party. Article 5(4) adds the competence requirement, obliging board members to keep up to date with sufficient knowledge and skills to understand and assess ICT risk, including through regular training. DORA has applied in full since January 2025, and it covers a wide scope of financial entities and their critical ICT third parties. If your organisation sits inside financial services in any form, this is not on the horizon. It is already the law you operate under.
NIS2 does something structurally similar, for a much broader set of organisations. Article 20 requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures the organisation takes, to oversee their implementation — and states explicitly that those management bodies can be held liable for the entity's infringements of Article 21. If you want the individual-level hook, it is Article 32(6): authorities can temporarily bar a CEO or legal representative from exercising managerial functions. It also requires board members themselves to follow training — and encourages, though stops short of mandating, that they extend equivalent training to their staff. NIS2 pulls in sectors well beyond finance: energy, transport, health, digital infrastructure, manufacturing, and their supply chains. In the Netherlands this landed on 15 August 2026, when the Cyberbeveiligingswet entered into force — more than 8,000 organisations now in scope, with NCSC registration obligatory from that date. This is not a horizon item. It is the week you are in. If you sit on a board in one of these sectors, or you supply into one, the obligation reaches you — and it travels with the entity through an acquisition, which is a trap most deal teams have not priced.
The Dutch implementation went further still, in a way that lands on individual directors rather than on the entity — enough of a departure to warrant a separate piece on article 24 Cbw and its €25,000 personal fine.
The AI Act is different in kind — and this is the nuance most commentary flattens. Unlike DORA and NIS2, the AI Act does not contain an explicit "the management body bears ultimate responsibility" clause aimed at boards. What it does instead is create deployer obligations for high-risk AI systems, including the requirement under Article 26(2) that human oversight be assigned to people with the competence, training, and authority to exercise it meaningfully. Breach that obligation and Article 99(4) puts you at up to €15 million or 3% of global annual turnover. The €35 million or 7% ceiling in Article 99(3) is reserved for the prohibited practices in Article 5 — a different failure, but the same board table. That penalty structure alone forces the question onto the board's desk, even without a named personal-liability clause: a fine of that magnitude is, by any ordinary governance standard, a material risk a board is expected to understand and oversee. The mechanism is different. The practical effect on you is the same. You need to be able to answer for it.
(One honest caveat, because precision matters more than momentum here: how "management body" maps onto a two-tier bestuur/raad van commissarissen structure specifically is worth confirming with counsel for your own governance structure — not something to take from an article, mine included.)
What this actually asks of you
Strip the legal language away, and each of these laws is asking the same underlying question of a board member: if you were asked to explain this decision under oath, could you?
Not "did the CIO present a deck and did the board nod." Could you, personally, walk a regulator or a court through:
- what your ICT risk framework actually covers, and why it's structured that way
- which third parties your organisation is critically dependent on, and what happens if one fails
- which of your AI systems carry real risk, who actually owns their governance, and what "meaningful human oversight" concretely means in your organisation — not just that a human can technically click a button
- when you personally were last briefed on any of this, and whether you understood it well enough to challenge it
On the AI question specifically, there is a concrete test. Ask to see one high-risk system's oversight arrangement on paper: who is named, what they are authorised to overrule, what training they had, and what evidence exists that they have ever actually intervened. "Meaningful human oversight" that has never once produced a recorded intervention is not oversight. It is a person listed on a diagram. That distinction is what Article 26(2) asks you to be able to demonstrate, and it is answerable in an afternoon.
That last point is the crux. DORA and NIS2 don't just ask you to receive information. They ask you to be competent to assess it — competent enough to push back on a risk framework that looks tidy on a slide but wouldn't survive a real incident.
The gap in most boardrooms
Here is the uncomfortable part. Most supervisory boards I've observed — across financial services, industrial, and infrastructure sectors — have deep expertise in finance, law, and commercial strategy. Very few have a member who can independently assess whether the ICT risk framework put in front of them is sound, or whether it's a well-formatted document that has never been stress-tested against how technology actually fails.
I've seen the alternative up close, more than once: an ISO 27001 or ICT risk programme run as a compliance exercise — a slidepack, a spreadsheet, a yearly audit fire-drill — that satisfies the paperwork and tells you almost nothing about whether the organisation would hold up under a real incident. That's not a board being negligent. It's a board that was never given the competence to tell the difference between a control that works and one that merely exists on paper. Under DORA and NIS2, that distinction is now personally yours to make.
And it isn't a gap you close with a one-day workshop, however much DORA's competence wording might suggest otherwise. Not a former CISO who reads a deck and asks the questions written on the back of it. Not a lawyer who knows the text but has never defended an architecture decision under pressure. What Article 5 describes, if you read it for what it asks, is someone who can translate technical exposure into a verdict the rest of the board can act on; tell a real control from a decorative one, because they've built both kinds; ask the question a vendor's deck was designed to avoid; and evaluate AI well enough to judge not just the risk it introduces but how it reshapes the tools for managing that risk.
That combination — operator-grade judgment at board altitude — is rarer than it should be. Most technologists who reach that level move into executive roles, not supervisory ones. Most supervisory board members come from finance, law, or general management, and inherit ICT risk as an unfamiliar late addition to a full remit.
Five questions to ask at your next board meeting
You don't need a consultant to start closing this gap. Start here, this month:
- Can we name our critical ICT and AI third parties, and do we understand our concentration risk if one of them fails? (This is what DORA's Register of Information exists to force you to know.)
- When were we — personally, as board members — last briefed on our ICT risk framework, and could each of us explain it back in our own words? If you are Dutch and in scope: can each member produce the article 24 certificate, and do we have a defensible answer for what "demonstrably current" means for us? The clock runs to 15 August 2028.
- Do we know which of our AI systems would count as "high-risk" under the AI Act, and who holds real human-oversight authority over them?
- If a regulator asked us tomorrow to prove we understood what we approved, what would we actually be able to show them?
- Does anyone on this board have the standing and the technical depth to challenge a risk framework that looks complete but has never been tested against how systems actually fail?
If the honest answer to the fifth question is no, that isn't a training gap. It's a competence gap in the room — and under DORA and NIS2, it is now a personal one.
Next
If you are Dutch and in scope, the local version bites harder and lands closer to home — what article 24 Cbw asks of you personally, and by when.
If your board is asking itself the five questions above and isn't satisfied with the answers, that is a conversation worth having — delfen.com.
Sources & further reading
- Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA) — European Parliament and Council, December 2022. Article 5(2)(a) places ultimate responsibility for ICT risk on the management body; Article 5(4) adds the ongoing knowledge-and-training requirement; Article 28(1)(a) keeps the entity fully responsible when third parties are involved.
- Directive (EU) 2022/2555 — NIS2 Directive — European Parliament and Council, December 2022. Article 20(1) covers management-body approval, oversight, and liability for Article 21 infringements; Article 20(2) the board training obligation; Article 32(6) the power to bar a CEO from managerial functions.
- Regulation (EU) 2024/1689 — Artificial Intelligence Act — European Parliament and Council, June 2024. Article 26(2) sets the deployer's human-oversight competence obligation; Article 99(3) and 99(4) set the €35M/7% and €15M/3% penalty tiers respectively.
- Cyberbeveiligingswet en Wet weerbaarheid kritieke entiteiten vanaf 15 augustus 2026 van kracht — Rijksoverheid, July 2026. The Dutch NIS2 transposition, in force from 15 August 2026, covering more than 8,000 organisations.
- Cyberbeveiligingswet — Staatsblad 2026, 187, Wet van 8 juli 2026. Article 24 sets the individual board-member knowledge, currency and certificate duty; article 92 the dwangsom against a board member; article 93 the €25,000 personal administrative fine.
- Cyberbeveiligingsbesluit — Staatsblad 2026, 189, Besluit van 8 juli 2026. Articles 20–22 set the training's purpose, its content, and what the certificate must contain; article 35 brings both the Act and the Decree into force on 15 August 2026.
- Bestuurlijke aansprakelijkheid en trainingsplicht — NCTV. Confirms the two-year deadline and that no specific training or provider is prescribed.