NIS2 Article 21: ten measure areas, one inventory — where to start when the deadline has already passed

The shape of the obligation

Directive (EU) 2022/2555 — NIS2 — had to be transposed by 17 October 2024. Most Member States were late; several still are. That matters less than it sounds, because the operative articles are short and stable and the national laws mostly copy them. Three carry almost all of the work for an essential or important entity:

• Article 20 — governance. The management body approves the cybersecurity risk-management measures, oversees their implementation, can be held liable, and must follow training.
• Article 21 — cybersecurity risk-management measures. “Appropriate and proportionate technical, operational and organisational measures”, based on an all-hazards approach, covering at least ten areas listed in paragraph 2.
• Article 23 — reporting. Early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, a final report within a month.

The ten areas of Article 21(2) — risk analysis and information-system security policies; incident handling; business continuity and crisis management; supply-chain security; security in acquisition, development and maintenance; assessing the effectiveness of measures; basic cyber hygiene and training; cryptography; human-resources security, access control and asset management; multi-factor authentication and secured communications — read like a table of contents for a policy binder. That is the trap.

Article 21 says what to cover. It never says which system the measure protects. “Appropriate and proportionate” only has a meaning relative to a specific asset, its exposure and the harm if it fails.

Why the policy binder comes second

A policy per measure area is easy to produce and easy to audit — and it proves nothing about the network and information systems the entity actually operates. Article 21(1) ties proportionality to “the degree of the entity’s exposure to risks, the entity’s size and the likelihood of occurrence of incidents and their severity”. Every one of those is a property of what you run: which services face the public, which hold personal data, which are single points of failure for a critical function, which are delivered by a supplier you cannot replace in a week.

So the first record is not a policy. It is the inventory: the assets, the IT services they compose, the business solutions those services support, and the third parties in the chain. Without it, “we apply MFA” and “we have a backup policy” are statements about intent. With it, they become statements about coverage — MFA on these 14 externally reachable services, backups tested on these 6 systems that a critical function depends on.

A working order

Not a project plan; an order that keeps each step small and leaves a record behind.

1. Scope and classify. List the network and information systems that support the services in scope of the Directive. Mark which of them a critical function depends on. This is Article 21(2)(i) — asset management — done first because everything else refers to it.
2. Put the management-body decision on record. Article 20 asks for approval and oversight of the measures. Approve the approach — the risk method, the framework you will adopt, who owns what — as a governance document with a version and a review date. Liability follows the decision; the decision should be findable.
3. Assess risk on the inventory, not in the abstract. One risk register, entries linked to the assets or services they concern, a repeatable score. The point is not the number; it is that “appropriate and proportionate” now has an anchor per system.
4. Adopt one framework and decide applicability per requirement. Take a NIS2-oriented requirement set and, requirement by requirement, record: applies, does not apply (with the reason), deferred to a date, waived. Scope the decision to the whole tenant or to a specific service or solution where that is honest. This turns the ten areas into a finite list of yes/no/why.
5. Map your controls, link the assets, attach the evidence. Each requirement that applies points at the control that satisfies it; the control is linked to the systems it protects; evidence sits on the control with a date. Coverage becomes visible per asset — which is the only place a supervisor can check it.
6. Prepare the 24 / 72 / one-month path. Article 23 is a process, not a tool: who decides “significant”, who notifies the CSIRT or competent authority, what the early warning must contain (whether malicious, whether cross-border). Write it, name the roles, rehearse it once.
7. Assess effectiveness on a cadence. Article 21(2)(f) asks for it explicitly. Findings from tests, audits and incidents go into one log with owners and due dates; the register and the applicability decisions get a review date.

What “supply chain” means in practice

Article 21(2)(d) — supply-chain security — is the area most entities under-record. The Directive expects you to consider the vulnerabilities specific to each direct supplier and service provider and the overall quality of their products and cybersecurity practices. That is a per-provider statement, and it only makes sense if you know which of your services each provider delivers. Model the provider, link it to the IT services it supports, and inherit criticality from the business solutions above them. Concentration risk — one provider under three critical services — becomes a query instead of a workshop.

What to expect from tooling

Any tool worth using for NIS2 should let you do the seven steps above without re-typing the inventory in a second place. In Secantra that is one tenant workspace: the CMDB holds assets, IT services, business solutions and processes with their structural links; a NIS2-oriented framework pack is adopted at a pinned version and applicability is decided per requirement; controls, asset compliance links and evidence items sit on the same records; the risk register scores entries against the assets; the third-party registry links providers to the services they deliver. Nothing there writes your policies for you — and it should not. It gives every “appropriate and proportionate” a system to point at.

Checklist

• Network and information systems in scope listed, with the critical-function dependency marked
• Management-body decision on the risk approach recorded as an approved, versioned document
• Risk register entries linked to assets or services, with a repeatable score
• One NIS2-oriented framework adopted; applicability decided and justified per requirement
• Controls mapped to requirements, linked to assets, with dated evidence
• Article 23 roles and the 24 h / 72 h / one-month path written and rehearsed
• Findings from tests, audits and incidents in one log with owners and due dates
• Every direct supplier recorded with the services it delivers