NIS2 and management accountability: what directors must do

The first NIS directive mostly left cybersecurity to the IT department. NIS2 explicitly changes that. Article 20 of Directive (EU) 2022/2555 requires Member States to ensure that the management bodies of essential and important entities:

• approve the cybersecurity risk-management measures taken under Art. 21;
• oversee their implementation;
• can be held liable for infringements of those obligations.

The second paragraph adds a training duty: members of management bodies must follow training, and entities are encouraged to offer similar training to their employees on a regular basis, so that they gain sufficient knowledge to identify risks and assess risk-management practices.

In Romania these requirements come through OUG 155/2024, approved with amendments by Law 124/2025. The wider context — who is in scope and which categories exist — is in the complete NIS2 guide for Romania.

The directive does not mean the head of IT but the people who run the entity: directors, board members, executives with management powers — depending on how the company is organised. The exact wording and who is covered are set by national law and by each company's articles of association.

That does not mean directors must configure firewalls. It means they need to understand the risks well enough to ask good questions, allocate resources and decide knowingly when they accept a risk.

A structure that works well in mid-sized companies: a security lead (internal or external) reports directly to management, not only through the IT director, and security is a standing item on the management meeting agenda. That way risk information reaches the people accountable for it unfiltered, and budget decisions are made on that basis rather than after an incident.

The directive introduces two levers aimed at management, not just the company. The first is the general principle in Art. 20: management body members can be held liable for infringing the risk-management obligations. The second sits in the supervisory regime for essential entities (Art. 32): if ordered measures are not implemented in time, authorities can seek a temporary prohibition on a person discharging managerial responsibilities, at CEO or legal-representative level, from exercising those functions until the deficiencies are remedied.

Separately, the entity itself faces fines which, under the directive, can reach at least up to EUR 10 million or 2% of worldwide annual turnover for essential entities and EUR 7 million or 1.4% for important ones. The concrete forms of liability and the amounts applicable in Romania are those in national law — do not automatically assume either the worst or the mildest scenario.

The directive does not prescribe a syllabus. Its stated aim is that management can identify risks and assess risk-management practices and their impact on the entity's services. Useful board-level training covers:

1. The entity's NIS2 obligations: scoping, Art. 21 measures, reporting to DNSC.
2. The main threats in your sector — for example ransomware and AI-assisted phishing.
3. Management's role during an incident: who decides on reporting, communication, taking services offline.
4. How to read a risk report and which questions to ask the technical team.
5. Formally accepting residual risks and documenting the decision.

Keep the evidence: who attended, when, what was covered and the result of a short assessment. Repeat it regularly — threats and your own infrastructure keep changing.

These frequencies are not prescribed by the directive; they are a reasonable starting point. What matters is a consistent rhythm and decisions that are recorded.

Risk acceptance deserves particular attention. Not every risk can be reduced right away: a legacy system that cannot take MFA, a supplier with no alternative, a budget that does not cover everything. Acceptance is legitimate, but it must be an explicit management decision, with the reason, the duration and compensating measures recorded. A risk tolerated silently for years is exactly what looks bad in a post-incident review.

• Which critical assets do we have and who owns each one?
• Do we have MFA on remote access and on every administrator account? What are the exceptions and why?
• When did we last restore a test backup, and how long did it take?
• How many critical vulnerabilities have been open for more than 30 days?
• Which suppliers have access to our systems and how do we control it?
• If we have an incident at 3 a.m. tomorrow, who sends the early warning to DNSC within 24 hours?

The answers tie directly into the technical controls of Art. 21 and the DNSC notification procedure.

The warning signs are easy to spot: answers like “I think so”, figures nobody can verify, exceptions with no end date or a single person who knows everything. No technical background is needed to ask that every answer come with evidence and a date.