13 August 2026

NIS2 Article 20: the board is accountable for cybersecurity. Personally

For years cybersecurity was, in practice, the IT department's affair. The board approved a budget, listened to a quarterly presentation and returned to the matters it considered its own. NIS2 changes one thing about this that is talked about surprisingly little: accountability stops being the IT department's and becomes the board's. Personally.

This is not a rhetorical flourish. Article 20 places duties directly on management bodies, while the Polish KSC Act translates them into specific duties for the head of the entity. Delegating tasks does not release that person from responsibility. I write this without scaremongering, because fear is a poor adviser on decisions about money and priorities. A caveat: I am not a lawyer, this is not legal advice, and you should confirm the interpretation for your situation with counsel.

What Article 20 places on the board

Three things, each concrete.

Approving risk management measures. The board must not only know that the company does something in the security area, but formally approve the measures adopted. That means a decision exists somewhere, with a date and a signature, rather than an assumption that "IT is handling it".

Overseeing implementation. Approval is not the end. The board must oversee whether the approved measures are actually implemented and whether they work. Oversight without a trace does not exist, so it must leave evidence.

Training. Under the Polish Act, the head of the entity must undergo training at least once a year so they understand the risks they decide on. This is not a certificate for the wall, it is so that the person accepting a risk knows what they are accepting.

The Polish Act also provides for fines on the head of an entity: up to 300 per cent of monthly remuneration in a private entity and up to 100 per cent in a public entity. These are ceilings, not an automatic rate for every shortcoming.

What "proof of oversight" means

This is the concept that causes the most trouble in practice, because it sounds soft yet must take a hard form. Oversight that cannot be shown did not, as far as a supervisory authority is concerned, take place. In practice, proof of oversight is:

regular security status reports reaching the board, with dates and evidence that someone actually discussed them, rather than merely received them,
approved policies and decisions with a date, showing when and what the body adopted,
decisions to accept significant risks signed by an authorised person, not an anonymous line in a spreadsheet,
a security budget with a justification, showing the measures are adequate to the risk rather than arbitrary.

The common denominator: each of these leaves a trace with a date and a responsible person. Oversight is not the board's state of awareness, it is a documented sequence of decisions.

Five questions a board should put to its IT team

You do not need to be technical to judge whether a process exists. It is enough to ask five questions and listen for whether the answers are concrete or evasive.

Which of our systems are covered by NIS2, and how do we know. A good answer contains a number and a reason. A bad one starts with "well, basically".

When did we last detect a critical vulnerability and how long did it take to remove. A good answer is a specific date and a specific number of days. A bad one is "we handle that as it comes".

What do we have open that we consciously choose not to fix, and who accepted that. A good answer points to entries in a risk register with names. A bad one implies everything is fixed, which is suspicious in itself.

If a supervisory authority came tomorrow and asked for a year's evidence, how long would it take to gather. A good answer is hours. A bad one is weeks, which means the evidence does not exist and can only be reconstructed, and that is not the same thing.

Who besides one person understands how our security process works. A good answer names more than one person and points to documentation. A bad one is the name of a single admin, after whose departure the process vanishes.

After those five answers you will know more about the company's real security posture than from many a presentation.

What a tool will not do

Here I must be honest, because I sell a tool and a tool has its limits. No system or delegation of tasks removes statutory responsibility. A working, documented process can, however, demonstrate due performance of the duties. A tool lowers the cost of running part of that process and makes the decision trail emerge during daily work rather than being assembled by hand before an inspection.

That is real value, but not magic. If the process does not exist, the tool will not create it. If it does exist, the tool makes proving it stop being a project.

What to do about it

The simplest first step is to see what a security status report written for a board looks like, as opposed to one written for an administrator. If you want to see such a report and the rest of the process with your own eyes, create an account and go through it from the perspective of the person answerable to the authority.

Article 20 does not require the board to be technical. It requires the board to be in command of the risk and able to prove it. The difference between those two things is the difference between a presentation and a document, and at an inspection it is the latter that counts.

Sources

One email a week with newly published vulnerabilities worth knowing about. No account needed.

This digest covers new vulnerabilities in general, not your servers. If you want to know which of them actually run in your infrastructure, that is what Secvalis does: it scans your machines and reports only what concerns them.