NIS2 Article 21 Measures Translated Into Controls: From the Ten Measures to a Concrete Baseline

Article 21(2) of NIS2 lists ten cybersecurity risk-management measures. Read on their own, they are headings — a table of contents for a security programme, not the programme itself. An inspector tests whether each heading resolves into a working control, a named owner and evidence produced without warning.

Directive (EU) 2022/2555 required essential and important entities to have their measures in place from the point their national transposition took effect. The transposition deadline was 17 October 2024, and most Member States missed it — by late November 2024 only a handful had transposed, and the Commission had opened infringement proceedings against twenty-three of them. That delay bought firms time on paper, but not on substance. When the transposing law arrives, the ten measures apply as written, and enforcement in the earlier-moving jurisdictions is already showing what supervisors look for. They do not read the policy. They ask you to demonstrate the control.

The headings, verbatim, and why they are not enough

Article 21(1) sets the frame: appropriate and proportionate technical, operational and organisational measures to manage the risks to network and information systems, on an all-hazards basis. Article 21(2) then lists what those measures must, as a minimum, be based on:

1. Policies on risk analysis and information system security.
2. Incident handling.
3. Business continuity, such as backup management and disaster recovery, and crisis management.
4. Supply chain security, including aspects concerning the relationships between the entity and its direct suppliers or service providers.
5. Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.
6. Policies and procedures to assess the effectiveness of cybersecurity risk-management measures.
7. Basic cyber hygiene practices and cybersecurity training.
8. Policies and procedures regarding the use of cryptography and, where appropriate, encryption.
9. Human resources security, access control policies and asset management.
10. The use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems, where appropriate.

Each of those is a category, not an instruction. “Incident handling” tells you nothing about your severity thresholds, your escalation path, or whether your logging can reconstruct what happened. The work is translating each heading into three things a supervisor can inspect: the control that operates, the person accountable for it, and the artefact that proves it ran. For certain digital infrastructure and digital service providers, Commission Implementing Regulation (EU) 2024/2690 spells out technical and methodological detail for exactly this, and it is worth reading even if it does not bind your sector directly, because it signals the depth expected.

The mapping, measure by measure

Read each line below as heading, then control, then owner, then evidence — the four columns of a baseline that survives inspection.

• Risk analysis and security policy. A documented risk-assessment method and an approved information-security policy set. Owner: the risk owner or CISO. Evidence: a dated risk register tied to real assets, and a board-approved policy carrying a version history rather than a creation date and silence thereafter.
• Incident handling. A response procedure with severity classification that maps to the reporting clock. Owner: the security operations lead. Evidence: runbooks, the ticket trail of real incidents, and post-incident reviews. The classification logic is the part that fails first, because it is where the 24-hour early-warning obligation actually starts or does not.
• Business continuity and crisis management. Tested backups, stated recovery-time and recovery-point objectives, and a crisis plan naming decision-makers. Owner: IT operations and continuity. Evidence: restore-test logs, not backup-success logs — a backup nobody has restored is a hope, not a control.
• Supply chain security. Supplier security assessments, contractual security clauses, and a maintained register of direct suppliers. Owner: procurement with security. Evidence: assessment records and the register itself. This is the measure most firms underscope; turning point (d) into supplier assessments that scale is a programme in its own right.
• Secure acquisition, development and maintenance. A secure development lifecycle, patch and vulnerability management with defined timelines, and a disclosure route. Owner: the engineering lead. Evidence: patch service levels against real dates, scan output, and change records.
• Effectiveness assessment. A control-testing or internal-audit programme with metrics. Owner: second and third lines. Evidence: audit reports and the measures you track. This is the measure that checks the other nine, and the one most often absent.
• Cyber hygiene and training. Hardening baselines, enforced basics, and role-appropriate awareness training. Owner: IT with HR. Evidence: completion records by role and dated configuration baselines.
• Cryptography and encryption. An encryption standard and key management with defined lifecycles. Owner: security architecture. Evidence: the crypto policy and a key inventory that someone maintains.
• HR security, access control and asset management. A joiner-mover-leaver process, role-based access, and an asset inventory. Owner: IT with HR. Evidence: periodic access reviews with sign-off, and an asset register that reconciles to reality.
• Multi-factor authentication and secured communications. MFA enforced on privileged and remote access, with secured channels for crisis coordination. Owner: the identity and access lead. Evidence: MFA coverage reports showing the gaps as well as the coverage.

The column firms skip is the owner

Most organisations can, with effort, produce a control and an artefact for each measure. The column that quietly goes missing is the named owner. A measure owned by “IT” or “the security team” is owned by nobody, and an inspector who asks “who is accountable for supplier assessments” and receives a functional area rather than a person has found a gap. NIS2 pushes accountability upward: the management body must approve the risk-management measures and can be held liable for failures. That obligation only works if each measure resolves to a role, and each role resolves to a person whose sign-off is recorded. Encoding that accountability into the actual sign-off workflow is what turns a policy into a control the board can stand behind.

Where the baseline falls apart

Three failure modes recur. The evidence exists but is undated, so it proves the control existed at some point rather than that it runs. The control is described in the present tense in a policy but has never produced an artefact, which means it is aspirational. And the effectiveness measure — point (f) — is missing, so nothing in the programme tests whether the other nine work, and the first honest assessment happens during the incident that was supposed to be prevented. A baseline that names the control, the owner and the dated evidence for all ten, and tests itself, is auditable. A list of ten headings with a policy behind each is a document, and a document is not a control.

The measures were never the hard part. The hard part is that a supervisor does not grade the list; they grade whether the list is real.