5 October 2026

NIS2 just landed on your desk. 10 questions to ask your IT team

A scene that is easy to picture in many organisations. The board has established that the company is covered by NIS2, and the topic has gone to someone who is supposed to "sort it out". Often that is a quality manager, someone from compliance or an office manager. Rarely the IT person, because the IT person already has a full-time job.

If that is you, this article is for you. You do not need to understand servers to check whether one of the more important areas, vulnerability management, actually works. Ten questions and some careful listening are enough.

This is the first part of a series in which I take one obligation from the law, show where the gap usually is in practice, and how to close it. The following parts expand the questions on this list.

A housekeeping note: I am not a lawyer and this is not legal advice. Confirm your organisation's status and obligations with the text of your national law or with counsel.

Why this is your business at all

Article 20 of the NIS2 Directive says plainly that management bodies approve the cybersecurity risk-management measures, oversee their implementation and can be held liable for that. Article 21 lists the measures. One of them is security in the acquisition, development and maintenance of systems, including vulnerability handling and disclosure. Another is assessing whether the measures in place are effective.

Each Member State implements NIS2 through national law, so check the deadlines that apply under yours. In Poland, where the amended KSC Act implements NIS2, the adjustment period ends on 3 April 2027 for entities that met the criteria on the day the amendment entered into force, 3 April 2026. By then, the process must be working, not merely documented. The adjustment period does not postpone obligations a company already had. Deadlines for entities that met the criteria later have to be established separately.

The law does not say which tool to scan with or how often. The organisation chooses measures appropriate to its risk and has to be able to defend that choice. That is why the questions below are not about tools, only about whether the process leaves a trail.

The rule: do not ask "is everything fine?" Ask them to show you

Almost everyone answers "yes" to "are we on top of this?" When you say "show me", the answer is either concrete or missing. Each of the ten questions below ends with something you can see: a list, a date, a name, a file.

1. Which servers does our vulnerability report cover, and which are missing from it?

A good answer is a list of systems and a clear statement of what the report does not cover, for example workstations, network devices or industrial control systems. An evasive one is "everything". No single scanner sees everything, and a report that does not say what it leaves out gives a false sense of security.

2. When was the last scan and how often do we scan?

A scan is an automated check of whether a server runs software with known vulnerabilities. Ask for three things: the date of the last scan, a written schedule and the name of the person who approved it. An evasive answer is "whenever it is needed". Frequency can differ between systems, but it should come from a decision, not depend on when someone has a free moment.

3. How many vulnerabilities are past their remediation deadline, and is that number going up or down?

This answer says more than the total number of vulnerabilities. A company can have hundreds of open items and a process that works well, if it keeps to its deadlines. It can also have a handful of items and a process that has stalled. Ask for the number of overdue items at the end of each of the last three months. An evasive answer is a single number with nothing to compare it to.

4. What remediation deadlines apply, and where are they written down?

A good answer points to a document and to specific numbers, for example: critical within 14 days, high within 30, the rest within 90, set out in a policy approved by the board. That is only an example; the numbers are chosen according to risk. An evasive answer is "as soon as possible". If the deadlines exist only in the administrator's head, nobody can check whether they are met.

5. What are you starting with this week, and who is doing it?

A scanner report can have hundreds or thousands of items. Ask for the first three tasks for this week, each with a responsible person and a due date. An evasive answer is "we are working on it".

6. What are we deliberately not fixing, who approved it, and when do we come back to it?

Not every vulnerability can be removed straight away. Sometimes an update requires stopping a service, sometimes the application vendor does not support the newer version. Postponing a fix still requires a risk assessment and measures that limit the risk until the update. A written decision is not enough on its own, but without one you cannot show the assessment ever happened. A good answer names the justification, the risk owner, the safeguards in place and the review date. "We fix everything" is a suspicious answer, because in a real company it is almost never true.

7. Which systems run without vendor support, and what is the plan?

A server that still works but no longer receives security updates is a typical gap that everyone knows about and nobody decides on. A good answer says who leads the migration, by when, and what happens in the meantime. An evasive one is "we will move it eventually".

8. If an outside company maintains our servers: what do we get from them, and how often?

You can outsource tasks, not accountability. Ask for the provider's latest report, the date of the next one and the name of the person on your side who reads it. It helps if the contract says what such a report must contain. An evasive answer is "we have a company that takes care of it".

9. Show me one vulnerability decision from last quarter and all the records behind it.

Take one serious vulnerability and check, for example, when it was found, who handled it and when it disappeared. Measure how long it takes to find that information. If it takes minutes, the trail is created as people work. If it has to be pieced together from emails, spreadsheets and people's memory, that is a sign that before an audit you will be reconstructing by hand, and reconstruction is rarely complete.

10. If a serious incident happened today, who decides about reporting it, and where are the facts recorded?

The directive requires significant incidents to be reported without undue delay: an early warning within 24 hours and an incident notification, as a rule, within 72 hours of becoming aware of the incident. For trust service providers the notification deadline is shorter. That leaves no time to work out who is supposed to decide. A good answer is a name and one place where the facts are collected. An evasive one is "we will call the IT guy".

How to read the answers

Do not judge the technical content; judge how concrete it is. A good answer has a date, a number, a name or a file. A poor one has "ongoing", "basically", "when needed".

If most answers are evasive, that is no reason to panic or to look for someone to blame. Usually it means the administrator is doing the work, but nobody has given them the time or the tools for that work to leave a trail. That can be fixed, but check the deadline that applies to your organisation, because there is less time than it seems. A record of activity takes months to build up; it cannot be written a week before an audit.

Where Secvalis helps, and where it does not

Secvalis collects vulnerability scan results from Linux servers and from the images of containers running on them, tracks remediation deadlines and records decisions. Of the ten questions above it answers several directly: the management report shows remediation timeliness, the task list groups vulnerabilities by package, meaning the software component that needs updating, risk acceptance requires a justification, an owner, a description of safeguards and a review date, for end-of-life systems it checks the migration owner and the target date, and the Evidence Pack puts the reports, the risk decision register and the audit log for this area into one archive.

It does not scan Windows workstations, network devices or industrial control systems. It does not replace a security policy, an organisation-wide risk analysis, backups or training. It does not report incidents for you. The answers to questions 1, 8 and 10 lie largely outside any vulnerability tool.

In the next parts I take these questions one by one: from how the board can judge whether IT is keeping up, through working with an outside IT provider and planning fixes, to risk decisions and evidence for the auditor.

If you want to see what the answers to these questions look like in a working system, open the public demo. It uses a fictitious company's data and needs no registration.

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.