4 October 2026

NIS2 Article 21: ten measures on one map

Consider an example: a manufacturing company with 150 employees. The information security officer receives from the board the list of ten measures in Article 21 of the NIS2 Directive and splits it into ten separate projects. Each has its own folder, its own owner and its own deadline. Three months later, the "policies" folder is full, while work on the other areas has stalled.

Meanwhile, the administrator has been scanning servers for a year, keeping track of vulnerability remediation deadlines and recording what is deliberately left unfixed. Nobody has connected this work to the list. Vulnerability handling is named explicitly in letter (e), but data from this process is also useful for assessing effectiveness and for cyber hygiene. The same material fits several items at once; nobody has entered it there.

This article is a map: the ten measures in plain language, an example of evidence for each, and the places where one working process provides material for several items.

What the law says

Article 21(1) of the NIS2 Directive requires essential and important entities to take appropriate and proportionate technical, operational and organisational measures. They are meant to manage the risks to the security of the network and information systems the entities use, and to prevent or minimise the impact of incidents on recipients of their services and on other services. Article 21(2) adds that the measures are based on an all-hazards approach that also protects the physical environment of those systems, and lists ten areas, marked (a) to (j), that they must cover at a minimum.

In Poland, the directive is implemented by the National Cybersecurity System Act (KSC), amended in 2026. The obligations concerning the information security management system are in its Article 8, but the numbering of its points does not map one-to-one to the letters of the directive. For example, letter (i) of the directive is split into several separate points in the Act. Audits refer to the provisions of the Act, so it is worth adding references to them to your map.

Article 20 of the directive adds that management bodies approve these measures, oversee their implementation and can be held liable for infringements. The list in Article 21 is therefore not a task for the IT department alone.

The ten measures in plain language

Letter	What it covers	Example of evidence
a	Policies on risk analysis and information system security	An approved policy with a version number, and the risk analysis it refers to
b	Incident handling	A procedure and an incident register with the moment of detection, decisions and notification dates
c	Business continuity: backup management, disaster recovery, crisis management	The record of the last backup restore test
d	Supply chain security, including security-related aspects of relationships with direct suppliers or service providers	An assessment of key suppliers and contract clauses
e	Security in the acquisition, development and maintenance of network and information systems, including vulnerability handling and disclosure	Scan history, remediation deadlines, decisions on exceptions
f	Policies and procedures to assess the effectiveness of cybersecurity risk-management measures	Indicators from several periods and conclusions from a review
g	Basic cyber hygiene practices and cybersecurity training	A training attendance list and data on timely updates
h	Policies and procedures on the use of cryptography and, where appropriate, encryption	A cryptography policy and a list of systems covered by encryption
i	Human resources security, access control policies and asset management	An asset inventory with owners and an access rights review
j	Where appropriate: multi-factor or continuous authentication solutions, secured voice, video and text communications, and secured emergency communication systems within the entity	A list of systems with an enforced second factor

The measures must be proportionate to the risk, the size of the entity and the impact of potential incidents. The list does not prescribe tools or how often to act; that has to be decided taking into account the risk and the regulations that apply to the entity. The examples in the table are materials typically shown, not forms required by law or a complete set of evidence for a given letter.

Where the gap is

Ten letters are not ten projects. The list organises requirements, but work in a company is not divided the same way. A working vulnerability management process is evidence for letter (e) and at the same time provides data for several others: the vulnerability policy is part of the policies in letter (a), timeliness indicators are material for the effectiveness assessment in letter (f), timely updates are part of cyber hygiene in letter (g), and a server inventory with owners is a piece of asset management in letter (i). Separate projects for each letter easily lead to collecting the same data several times.

Some letters have no data in any system. The record of a backup restore test, a supplier assessment or a cryptography policy are materials that no scanner will produce. You need to have them, and also know where they are, who is responsible for them and when someone last checked them.

A map without owners ages quickly. A table prepared once for an audit looks good on the day it was made. Without reviews, its links start pointing to outdated files.

How to build your own map

Below is one way to organise the work. It is not a procedure imposed by law or an assessment of a particular company's obligations. The person responsible for KSC will prepare the first version of the map together with the administrator and the owners of the other areas; how long it takes depends on how much documentation already exists.

1. List the ten letters in a table. One row per letter, with the corresponding provisions of the KSC Act next to it.

2. For each letter, write down where the evidence is. A specific location: a system, a folder, a register. Not "in the IT department".

3. Mark the type of evidence. System data generated automatically during work, a document someone has to keep up to date, or missing. This distinction shows where a regular review is needed.

4. Assign an owner and the date of the last review. This makes it easier to check whether materials are current. A review date alone does not prove that the activity was carried out, so each row should also link to the document or result itself.

5. Mark the processes that provide material for more than one row. In each such row, link to the same source instead of collecting the data separately.

6. Start with the gaps, not the documents. A row marked "missing" is the first topic for the next review with the board. Article 20 requires the management body to approve the measures and oversee their implementation, so present significant gaps to the board together with proposed actions and the resources needed.

7. Set a review cycle for the map. For example once a quarter and after every major change, such as a change of supplier, the rollout of a new system or a change in the team.

Where Secvalis helps, and where it does not

Secvalis has a compliance map that links selected requirements to product signals and references to available data, and also points to areas where evidence has to come from outside the product. For the ten letters it looks like this:

Letter	Data from Secvalis	Outside the product
a	An editable vulnerability management policy template with the account's SLA and EOL thresholds	Other policies, risk analysis, approval
b	An incident register with history and a document for preparing a notification	Detecting and assessing the incident, submitting the notification
c	An evidence review register: location, owner, cycle, history	Backups, restore tests, crisis management
d	Evidence review register as in (c)	Supplier assessment and contracts
e	Scans, remediation deadlines with a threshold for actively exploited vulnerabilities, a task list, exception decisions, an EOL report, the Evidence Pack	Rolling out and verifying patches in the company, systems not covered by the agent's scan
f	A management report with a process verdict, timeliness and mean time to remediate	Assessing the effectiveness of other measures
g	Data on how promptly vulnerabilities are remediated	Training
h	Evidence review register as in (c)	Cryptography policy and its use
i	A list of machines with criticality and exposure	Human resources, access control in the company, assets without the agent
j	The option to require a second login factor from members of the Secvalis account	Multi-factor authentication in the company's systems

The product has the most data for letter (e), as this is its core area. For letters (c), (d) and (h) it only stores where the evidence is, who is responsible for it and when someone checked it. It does not check whether the document exists or whether the activity was carried out. Multi-factor authentication under letter (j) concerns access to Secvalis itself, not the company's systems.

The incident register does not detect incidents and does not send notifications to a CSIRT. For an incident marked as reportable, Secvalis calculates 24-hour and 72-hour deadlines from the recorded time since which the incident has been reportable. The KSC Act counts the deadlines for the early warning and the notification of a serious incident from the moment it is detected, so that moment has to be documented separately and reliably, and the statutory deadlines checked independently.

The agent scans Linux hosts and images of running containers. It does not see Windows servers, network devices or machines where it is not installed. Secvalis does not ensure compliance with NIS2 or the KSC Act. It organises evidence in the vulnerability area and points to areas where evidence has to be collected outside the product.

You can see the compliance map on an example company's data in the public demo, with 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.