NIS2 Article 21: what the ten measures mean in practice

Article 21 of the NIS2 Directive (Directive (EU) 2022/2555) sets out the ten minimum measures that essential and important entities must take to manage their network and information systems. It is not a technical list and not an audit package. It is a set of governance and risk functions that must demonstrably sit within your organisation, with board-level accountability for what happens on top of them and what lies beneath. That is a different register from most of the cybersecurity checklists circulating in Dutch practice, and it explains why an ISO 27001 certification or an ongoing penetration testing cycle does not automatically cover Article 21.

What does Article 21(2) say?

Article 21(1) requires the management body to take appropriate technical, operational and organisational measures, proportionate to the risks. Paragraph 2 makes explicit what that means at a minimum. The ten measures are EU legislative text and carry the same scope across the Union. What differs per Member State is the supervisory authority and the enforcement practice, not the standard.

Below are the ten measures, paraphrased in working language, with what must actually be delivered per measure to achieve demonstrability. This is what your programme must be able to show to an investigator, an auditor or an insurer.

Policies on risk analysis and information security. An adopted policy that describes how risks are identified, classified, accepted or mitigated, with a board-level decision on acceptance. Not a document on the shelf, but an established line from risk to control that the management body signs off on annually.

Incident handling. A working incident procedure covering detection, classification, escalation, containment, recovery and evaluation. Demonstrability here is a log of handled incidents and their lessons, not a policy document with phase names.

Business continuity and crisis management. Continuity plans that have been tested, with backup and recovery that actually work when systems or sites are lost, linked to a crisis organisation that functions during real outages and not only during exercise rounds. The test counts, not the presence of the plan.

Supply chain security. Management of risks at suppliers and service providers, including agreements on their security and the verifiability of that security. Cloud providers, administrators, software suppliers, everything that falls under a processor or service relationship and touches your critical systems. Contractual clauses without periodic verification do not count as management.

Security in acquisition, development and maintenance. Security as a quality property across the entire lifecycle of systems, including the reporting, assessment and remediation of vulnerabilities. This touches development, procurement and management processes, not only a vulnerability scanner.

Effectiveness of cybersecurity risk management. Policies and procedures to assess whether the measures taken actually work. An internal audit or a review cycle that specifically examines whether the risk approach has the effect expected of it, with adjustment as evidence.

Basic cyber hygiene and training. Operational baseline measures (patching, configuration management, fundamental access controls) plus structural awareness and training for staff and management. A one-off e-learning module is not a training function, it is a date in a register.

Cryptography and encryption. Policies on and use of cryptography where appropriate, including key management. The question is not whether encryption is applied, but whether the keys are under management and whether the policy substantiates the choice between encrypting and not encrypting.

Human resources security, access control and asset management. Managing who comes in, who may view or change what, and where which assets sit. Identity and access management, screening where appropriate, and a current asset register line that connects to the risk analysis from measure 1.

Multi-factor authentication, secured communications and emergency communications. Strong authentication for relevant systems, secured voice, video and text communications, and a working emergency provision for when primary communication channels fail. The last element is the one most often skipped and, in an incident, the first that turns out to be missing.

These ten measures are the minimum set. Paragraph 3 adds that the implementation must be proportionate to the specific risks, the scale of the entity and the likelihood and severity of incidents. The Dutch cybersecurity centre (NCSC) has published guidance on comparable topics that gives substance to continuity, supply chain and incident handling, among others, and you may lay those alongside your own analysis. The standard is Article 21, the substance is yours.

Why the ten measures are not a technical list

Anyone who reads Article 21 as a row of ticks misses the subject. The ten measures are not ten pieces of technology. They are ten functions that must sit within the organisation, with board-level ownership, periodic assessment and evidence that they work. Measure 1 is not a document, it is a decision line. Measure 6 is not an audit report, it is a habit of testing whether the other nine actually have an effect. Measure 10 is not an MFA rollout, it is the arrangement that communications remain standing during an outage.

That explains why an organisation with a mature ISO 27001 implementation can still have gaps on Article 21. ISO 27001 is a management system for information security. NIS2 asks for a broader spectrum, with explicit continuity, supply chain, communications and board-level accountability functions. Much of what ISO delivers counts, but the overlap is partial and the demonstrability test is different. ENISA has published implementation guidance that sets out the relationship between ISO controls and NIS2 measures, and it also shows where the gaps sit.

The second misconception is that Article 21 is a one-shot. The directive makes proportionality and periodic assessment part of the standard. That means your programme must be able to show not only that measures are in place, but also that they are maintained, tested and adjusted on the basis of what happens in your own sector and your own landscape. A threat picture that is a year old does not meet the spirit of paragraph 3.

What does Article 21 change for your programme?

In practice it changes the order of thinking. A programme that starts with tools and ends with a report does not comply. A programme that starts with risk, ends with board-level acceptance and keeps the ten functions operational in between does comply. That looks like a formal change, but in practice it shifts where time and budget go.

We see three shifts in engagements where Article 21 comes into play.

One, from technical measures to board-level decision lines. Risk acceptance becomes explicit and signed off. Not once in a project plan, but as a recurring decision moment with an owner. That touches the relationship between you as CISO and the board directly: Article 20 of the directive establishes management body accountability for cyber risk, and Article 21(2) is what that board must have in hand to carry that accountability.

Two, from internal scope to supply chain scope. Measure 4 forces you to look beyond your own perimeter. Many organisations have their own environment reasonably in view and their supplier chain not. That is not a shortcoming in one place, it is a missing function. A third-party risk process with periodic verification, linked to procurement and architecture, is what Article 21 asks for here.

Three, from final reporting to continuous demonstrability. Supervisory authorities do not ask for an annual report of what has happened. They ask what is in place now, when it was last tested, and what the board makes of it. That changes the programme cycle. Demonstrability is not a delivery moment, it is a state you can show at any given moment.

The issue where most goes wrong is not which measure is missing. It is which measure is formally in place and does not actually work. A continuity plan that has not been tested for two years, a supplier register that does not connect to the risk analysis, a training function without evidence that it has changed behaviour, an encryption policy where no one knows who manages the keys. On Article 21 you are not held to account for what is missing on paper. You are held to account for what is missing beneath the paper reality.

How to arrange the programme for it

You approach an Article 21 implementation not as a compliance project, but as a programmatic shift within the existing security function. That means: first lay the ten measures alongside your current programme and answer, per measure, what is in place, what is missing, and what actually works. Then prioritise on risk and board-level position, not on convenience. The measure that is most urgent is almost never the one that implements most easily.

The division of roles that goes with this is clear. The CISO is responsible for the demonstrability of the ten functions. Operations carry the execution of most technical and operational components. The CFO or board member carries the decision burden on risk acceptance and on the investment that the proportionality clause imposes. An Article 21 implementation without formal decisions at board level is not an Article 21 implementation, it is an internal IT action with a new name.

The ten measures give you the frame. The substance is yours. The test is whether, on any given Thursday, in a conversation with a supervisory authority, an insurer or a supply chain partner, it can be explained with a straight face. Not what is in place, but what works, and how you know.