Zero Assumptions #8: Your board is personally liable under NIS2. Have you told them?


Zero Assumptions · Week 8 of 25 · Pillar 2: Software stack & contextual risk

Your board approved the security budget.
That means they've fulfilled their NIS2 obligation.

NIS2 Article 20 does not ask your board to approve a budget. It requires management bodies to oversee, be trained in, and be personally liable for your organisation's cybersecurity risk management. Most boards have done none of these things. Most CISOs have not told them.

In every previous volume of this series, the assumption we examined was held by the security team. This week the assumption belongs to the board — and the consequences of it being wrong are no longer limited to the organisation. Under NIS2, they are personal.

The assumption most management bodies are currently operating under: cybersecurity is a technical function. The board's role is to ensure adequate budget is allocated and that the CISO reports upward. If something goes wrong, accountability sits with the security team.

The reality: NIS2 Article 20 places explicit legal obligations on management bodies — not the CISO, not the IT department. Individual board members can be held personally liable, temporarily banned from management roles, and named publicly in enforcement actions. Most boards in scope have not been briefed on any of this.

10 million

Maximum administrative fine under NIS2 for essential entities — or 2% of total annual worldwide turnover, whichever is higher. For important entities the ceiling is €7 million or 1.4% of global turnover. These are not theoretical maximums — GDPR enforcement history shows regulators apply them.

Source: NIS2 Directive (EU) 2022/2555, Article 34

What NIS2 Article 20 actually requires of your board

Article 20 of the NIS2 Directive is unambiguous. Management bodies of essential and important entities must: approve the cybersecurity risk management measures adopted by the organisation; oversee implementation of those measures; complete cybersecurity training — and ensure that board members receive sufficient training to identify risks and assess their business impact on a regular basis; and bear personal liability when these obligations are not met following a significant incident.

The liability clause is the one most boards have not seen. NIS2 permits competent authorities to temporarily prohibit any natural person performing managerial responsibilities at CEO or legal representative level from exercising management functions if that person is found to have repeatedly or seriously infringed their NIS2 obligations. This is not a fine paid by the organisation. It is a professional consequence imposed on the individual.

NIS2 Article 20 obligation What it requires Typical board status
Approve risk measures Board must formally approve cybersecurity risk management measures — not delegate to management Rarely done at board level
Oversee implementation Ongoing oversight of implementation — not a one-time sign-off No structured mechanism in place
Complete training Board members must receive regular cybersecurity training sufficient to assess risk impact Not completed in most organisations
Ensure employee training Board must ensure staff receive adequate cybersecurity hygiene training Delegated to HR, not board-owned
Personal liability Individual management liability including temporary ban from management roles for serious infringement Not known to most board members

72 hours

The maximum time NIS2 allows for initial incident notification to your competent authority after becoming aware of a significant incident — with a full report due within one month. The board must be able to oversee this process. Most have never been briefed on what constitutes a notifiable incident under NIS2.

Source: NIS2 Directive (EU) 2022/2555, Article 23

The CISO's position in this framework has shifted fundamentally. Under previous models, the CISO was the accountable party for cybersecurity outcomes. Under NIS2, the CISO is the technical expert who enables the board to fulfil its legal obligations — but the board is the accountable party. The CISO who has not briefed their board on Article 20 has not completed their job under NIS2, regardless of how mature the technical controls are.

The blueprint — three things your board needs before the next incident

1. A NIS2 Article 20 briefing that uses their language, not yours: The board does not need to understand FIDO2 or CAE. They need to understand that they are personally liable, what the liability conditions are, and what evidence of compliance looks like in a regulatory investigation. The briefing should take 45 minutes and end with a board resolution formally approving your cybersecurity risk management framework — the documented evidence that Article 20's approval obligation has been met.

2. A recurring board-level cybersecurity agenda item: NIS2 requires ongoing oversight, not a one-time sign-off. Quarterly reporting to the board on your three most significant identity risk exposures, the controls addressing them, and the metrics showing whether those controls are working — in plain language, on a single slide. This satisfies the oversight requirement and creates the documented evidence trail that a regulator would examine in an enforcement action.

3. A documented incident response escalation path to the board: The 72-hour notification obligation under NIS2 Article 23 requires a clear escalation path from the SOC to the board. This path must be documented, tested, and known to all parties before an incident — not assembled under pressure during one. The board member who receives the 03:00 call needs to know what their role is, what decisions require their sign-off, and what the notification to the competent authority will say.

Series recap — where we are

Pillar 1 (Weeks 1–5): EDR blind spots, AiTM bypass, deepfake helpdesk attacks, hardware supply chain risk, hybrid Kerberos blindspots.
Week 6 — Risk assessment integration: Annual assessments vs continuous monitoring. Catching entitlement drift before exploitation.
Week 7 — Session token vulnerability: 207 days to detect, 50% of incidents at the weekend. CAE and device-bound tokens close the gap.
Week 8 — Boardroom accountability: NIS2 Article 20 puts personal liability on your board. Most boards don't know. Most CISOs haven't told them.
Week 9 (next): Your identity provider, EDR, SIEM, and network monitoring tools each generate risk signals independently. None of them talk to each other in real time.

Coming up next week

Week 9 — Real-time signal orchestration
Your identity provider, EDR, SIEM, and network monitoring tools each generate risk signals in isolation. An impossible-travel alert in your IdP and a lateral movement alert in your EDR firing within 10 minutes of each other should be the same incident. They aren't — because nothing correlates them in real time.

Week 10 — Convergence of physical and logical access
Your building access control and your IT authentication systems are separate. An attacker who badges into your server room at 02:00 on a Saturday generates a physical access log entry that your SOC will never see — because the two systems don't share a data feed.

Free passwordless audit

Has your board formally approved your cybersecurity risk management framework under NIS2 Article 20?

In a free 30-minute passwordless audit we'll review your current authentication stack, map your NIS2 Article 20 compliance posture, and give you a plain-language summary of what your board needs to do — and document — before the next significant incident.

No sales deck. No follow-up unless you ask.

The CISO who has not briefed their board on NIS2 Article 20 has left their organisation's most senior leaders personally exposed — to a liability they don't know they hold, for obligations they have never been asked to fulfil. That briefing is part of the job now.

Mikael Rodin
Managing Director, Ciptor

P.S. If your board has not formally approved your cybersecurity risk management framework and completed NIS2 training — book a free 30-minute audit. We'll tell you exactly what documentation you need before a regulator asks for it.

New to the series? Start at ciptor.com/zero-assumptions/zero-assumptions-vol-1/

Kungsporten 4A, 427 50 Billdal, Sweden
Unsubscribe · Preferences

Ciptor

The 2026 threat landscape doesn't care about your 2024 budget. It only cares about your vulnerabilities. Join 10,000+ infrastructure leaders securing the future.

Read more from Ciptor

Zero Assumptions · Week 9 of 25 · Pillar 2: Software stack & contextual risk Your SIEM fired an alert at 09:14.Your EDR caught the same attack at 09:24. Two tools. Same attacker. Ten minutes apart. Neither told the other. Your analyst saw two separate alerts in two separate consoles and triaged them as two separate incidents. The attacker had already moved. In weeks 6, 7, and 8 we covered the operational gaps between assessment cycles, session windows, and board oversight. This week we move...

Zero Assumptions · Week 7 of 25 · Pillar 2: Software stack & contextual risk Your morning login was legitimate.So the session running at 17:00 must be too. Session tokens are hijacked, not phished. Once an attacker has your token, they don't need your password, your MFA, or your hardware key. They already passed authentication. The question is whether your SOC finds them before they find what they came for. Last week we covered identity drift — the entitlement state that diverges from policy...

Zero Assumptions · Week 6 of 25 · Pillar 2: Software stack & contextual risk Your annual pen test showed no critical findings.So your identity posture is under control. A penetration test is a point-in-time snapshot. Your identity risk changes daily — new users, new devices, drifting permissions, unchecked access accumulation. The gap between the snapshot and today is where most incidents begin. Welcome to Pillar 2 — Software stack & contextual risk Pillar 1 covered the adversary tactics...