NIS2 Management-Body Liability: Encoding Accountability Into Sign-Off Workflows

NIS2 does something most cyber regulation avoids: it names the individuals who are personally on the hook. If your management body treats cyber oversight as an informal expectation rather than an evidenced act, it has nothing to show a supervisor after an incident.

Directive (EU) 2022/2555 — NIS2 — moved cybersecurity from an operational concern that IT owned to a governance duty the management body owns and can be held liable for. Most of the commentary treats this as a training-slide problem: run an awareness session, minute an approval, move on. That reading misses the point. The obligation is not to have approved once; it is to be able to demonstrate, on the day a competent authority asks, that the body genuinely approved specific measures, oversaw their implementation, and understood what it was signing. This is a workflow problem before it is a legal one, and it is solvable with the same discipline you would apply to any other decision that carries personal exposure.

What Article 20 actually places on the management body

Article 20 is short and it is specific. It requires the management bodies of essential and important entities to approve the cybersecurity risk-management measures taken to comply with Article 21, and to oversee their implementation. It states plainly that members of the management body can be held liable for infringements of Article 21 by the entity. And it requires those same members to follow training, so they gain sufficient knowledge and skills to identify risks and assess cybersecurity risk-management practices and their impact on the services the entity provides.

Read those three limbs as verbs the body has to be able to evidence: approve, oversee, learn. Each one implies an artefact. Approval implies a record of what was approved and by whom. Oversight implies a recurring flow of information the body demonstrably reviewed, not a one-off sign-off. Training implies completion, dated, mapped to named individuals. An entity that can produce all three tells a coherent story. An entity that produced a single board resolution eighteen months ago and nothing since has a gap that widens every quarter it goes unfilled. This is the same personal-liability shift we have written about in the context of board cyber accountability more broadly — NIS2 simply codifies it for in-scope firms.

Why the enforcement teeth change the calculation

The reason this deserves a workflow rather than a policy is what sits at the enforcement end. Article 34 sets administrative fines for essential entities at a maximum of at least EUR 10 million or 2% of total worldwide annual turnover, whichever is higher, and for important entities at a maximum of at least EUR 7 million or 1.4%. Those are the headline numbers everyone quotes. The provision that should concentrate a board’s attention is Article 32(5). For essential entities, where lesser measures have failed, a competent authority can temporarily prohibit any natural person discharging managerial responsibilities at chief executive officer or legal representative level from exercising those functions. Article 32(6) requires that natural persons responsible for, or legally representing, an essential entity can be held liable for breach of their duties to ensure compliance.

Note the asymmetry: the managerial-prohibition power in Article 32(5) attaches to essential entities, not important ones, though exact scoping and remedies live in the national transposition and should be verified against the law that applies to you. The direction of travel is unambiguous either way. When the sanction can reach a named individual’s ability to hold office, the difference between an evidenced approval and an assumed one stops being a documentation nicety and becomes the thing that determines whether that individual has a defence.

Encoding the sign-off so it produces evidence

An informal expectation offers no protection because it leaves no trace. The fix is to route the Article 20 duties through a workflow that produces the evidence as a by-product of doing the work, rather than as a document assembled retrospectively when the regulator writes. In practice that means encoding four things:

• What was approved, with version. The approval must point at a specific, versioned set of risk-management measures mapped to Article 21, not at a policy title. When the measures change materially, a fresh approval is triggered. A resolution that approves “the cyber strategy” is worth little; one that approves version 3.2 of a named measures register is worth a great deal.
• Who approved, individually. Article 20 liability is personal, so the record has to show which members were present, how each voted or assented, and any recusal. A collective “the board noted” does not allocate the accountability the directive assumes.
• Oversight as a recurring flow. Implementation oversight is continuous. That means a standing agenda item, a defined metrics pack the body actually reviews, and minuted challenge — evidence the body interrogated the numbers rather than received them. Oversight you cannot see in the minutes did not happen for evidential purposes.
• Training completion, dated and named. Each member’s training should be logged against their name with a date and a description of content sufficient to show it addressed risk identification and the assessment of practices, as Article 20(2) requires. “The board had a briefing” is not a completion record.

None of this requires a new platform. A governance workflow tool, or even a disciplined use of your existing board portal and risk register, will carry it — provided the fields are mandatory and the approval cannot close without them. The engineering principle is the one that governs any control you want to survive scrutiny: make the evidence a required output of the process, not an optional afterthought.

Where the measures being approved come from

A sign-off workflow is only as credible as the thing it signs off. If the underlying measures are a vague restatement of Article 21’s ten headings, the board is approving an abstraction and its evidenced approval protects it less than it appears to. The measures register has to be concrete — actual controls, actual owners, actual implementation status — which is the work of translating Article 21 into a concrete control baseline before you ever put it in front of the body. Approve a real baseline and the oversight flow has something to measure against; approve a policy summary and there is nothing for the metrics to track.

The pattern here is not unique to NIS2. Prudential regimes have been converging on named-individual ownership of resilience for years — the same logic runs through the board and senior-management ownership OSFI expects under E-21. What NIS2 adds is a sanction that can reach the individual directly, which is why the evidence has to be individual too.

The management body that treats Article 20 as a workflow ends up protected by the ordinary act of running it. The one that treats it as a slide finds out, at the worst possible moment, that an expectation is not a record.