The board does not need to understand IT. It needs to know whether IT is keeping up
A board meeting at a water utility. The IT manager brings a printout of the latest scan: 1,240 vulnerabilities, 18 of them critical. A month ago there were 1,100. The chair asks whether things are better or worse. The IT manager says it depends. Everyone nods and moves on to the next item.
Nobody did anything wrong here. The IT manager brought what they had, and the board asked what it should. The trouble is that this number does not answer the chair's question. Nor will it next month, when it is 1,300 or 900.
This is the second part of a series in which I take one obligation from the rules, show where the gap usually is in practice, and how to close it. This time for the board and the owner of the business.
A note before we start: I am not a lawyer and this is not legal advice.
What the law says
The NIS2 Directive, implemented in Poland by the amended National Cybersecurity System Act (KSC), requires in Article 20(1) that management bodies approve the cybersecurity risk-management measures, oversee their implementation and can be held liable for infringements. Article 21(2)(f) adds policies and procedures to assess the effectiveness of those measures.
Oversight and assessing effectiveness both need feedback. The board does not need to understand what a vulnerability in a system library is. It needs to be able to judge whether the process it approved actually works. For that it needs different numbers from the ones it usually gets.
Why the vulnerability count tells you nothing
The number of vulnerabilities describes how many known flaws sit in the company's software today. It does not describe how well the company deals with them. It rises and falls for reasons that have nothing to do with the work of the IT team.
It rises when a vendor publishes a new batch of fixes, because descriptions of the vulnerabilities those fixes remove are published with them. It rises when a new server is added. It falls when a scan fails or covers less than usual. The worst month in the company's history can look like a success on paper.
On top of that, most of this number is nobody's backlog. On my own nine servers, which I described in a separate article, there were 165,608 entries, and ninety percent of them were waiting for a fix the vendor had not yet released. An update will not remove those, which does not mean nothing needs doing: for some of them the risk has to be reduced another way, for example by restricting access to the service. When the board gets such a number without context, it can choose between panic and indifference. It usually chooses indifference, and it is hard to blame it.
The vulnerability count is useful to the administrator. The board needs an answer to a different question: is IT keeping up?
Five indicators that fit on one page
Whether IT is keeping up can be judged regardless of how many vulnerabilities there are. Ask for five pieces of information.
1. Timeliness. The company has set deadlines for fixing vulnerabilities, depending on their severity. The indicator shows what share of items was fixed on time in the last period. This is the main number for the board. If the deadlines are not written down anywhere, that is the first thing to do before anything can be measured.
2. What is overdue today, and who owns it. A list of items past their deadline, with a responsible person next to each. This is not about finding someone to blame. It is about every overdue item having an owner instead of hanging in the air.
3. Time to fix. How many days pass on average from detecting a vulnerability to removing it. What counts as the end matters: the next scan no longer finding it, not someone closing a ticket. The first is a fact; the second is a statement.
4. Whether the data is current and complete. How many servers have not been scanned recently or are not covered by the report at all. Indicators 1 to 3 are only as good as the data underneath them. A report that does not say what it leaves out gives a false sense of security.
5. What is waiting for a board decision. Vulnerabilities we are deliberately not fixing, and systems running without vendor support. A board decision is always needed here. For the other points it is needed when the backlog grows or the data is incomplete.
Add one line of assessment at the top: good, needs attention, bad. It should follow from the process indicators, not from the vulnerability count. Open critical vulnerabilities do not by themselves mean a bad assessment if they are recent and within their deadlines. The deadlines must, however, match the risk, because meeting deadlines that are too loose proves nothing. A company can also have few vulnerabilities and be in a bad state if for three months nobody has decided what to do with an unsupported server.
How to introduce it without a revolution
Ask IT for such a report once a month, on one page, in the same layout. A fixed layout matters more than good looks, because only a comparison with last month says anything. At the board meeting, discuss the assessment and its reasons, point 5, and any other point that needs a decision or intervention, such as a growing backlog.
If IT cannot calculate timeliness because there are no recorded deadlines or history, that is an answer too. It means the work is being done but leaves no trace from which its effectiveness could be judged. Then the board's job is to provide the time and tools for that, not to demand a report that cannot be produced.
Keep these reports. A series of monthly pages with recorded decisions helps show that the board really oversaw the implementation of the measures. It is not the only evidence an auditor may ask for, but without such a trail it is hard to show oversight in the vulnerability area.
Where Secvalis helps, and where it does not
The management report in Secvalis is built around these questions. The verdict at the top ("Good standing", "Needs attention", "Critical" or "No data") takes into account, among other things, remediation timeliness, gaps in the deadline register, stale scans, risk decisions and end-of-life systems that lack a migration owner, a target date or a valid risk acceptance. The vulnerability count alone does not determine it.
The mean time to fix is measured from the first observation of a vulnerability to its disappearance from the next full scan, not from a click in the interface. It excludes items already present when tracking began and items closed while they were excluded from deadlines. The company sets its own remediation deadlines, and for vulnerabilities actively exploited in attacks an additional limit applies that can shorten the deadline. The report can be sent on a schedule, for example monthly, to selected people with access to account-wide reports, so it reaches the board without intermediaries.
Secvalis will not assess what a given vulnerability means for your business, will not set a budget and will not make decisions for the board. It covers Linux servers and the images of containers running on them. It does not scan Windows workstations, network devices or industrial control systems, so at a water utility it will say nothing about the controllers at the treatment plant. The verdict concerns the server vulnerability area, not the company's whole cybersecurity, and it does not replace the training for members of the management body required by Article 20(2) of the Directive.
If you want to see such a report on a fictitious company's data, open the public demo and download the management report from the reports hub. No registration needed.
In the next part: what to do when your servers are maintained by an outside company and the report comes from them.
Sources
Weekly CVE digest
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.