NIS2 in Practice: What Security Leaders Need to Know About Article 21 Technical Measures

Published June 16, 2026

Article 21 of NIS2 asks whether your security measures are appropriate, proportionate, and operating — a higher bar than owning a firewall and a policy PDF. A practical walk-through of the ten Article 21(2) measures, where mid-market teams fall short, and how an existing ISO 27001 programme maps onto them.

If you run security for a mid-market organisation that falls under NIS2 — a regional energy supplier, a logistics operator, a healthcare provider, a managed service provider — you have probably already answered the first question: are we in scope? For most essential and important entities, the answer is yes.

The harder question is the one Article 21 actually asks: can you show that your security measures are appropriate, proportionate, and operating? That is a different bar from "do we have a firewall and a policy PDF." This piece walks through what Article 21 requires in practice, where mid-market teams most often fall short, and how an existing ISO 27001 programme maps onto it — and where it does not.

A note on how NIS2 actually applies before we start: NIS2 is a Directive ((EU) 2022/2555), so its obligations bite on your organisation through your Member State's national transposition law, not through the Directive text directly. The article references below are to the Directive — your national implementation is the instrument that enforces them, and is where any country-specific detail lives.

Article 21 is a risk-management obligation, not a checklist

Article 21(1) requires essential and important entities to take "appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems." Two words carry the weight:

Appropriate and proportionate. Article 21(1) ties the expected level of measures to the entity's degree of exposure to risk, its size, the likelihood of incidents, and their severity — including societal and economic impact. A 200-person regional utility is not held to the same control depth as a pan-European bank, but it is held to a standard proportionate to the disruption its failure would cause.
All-hazards approach. The measures in Article 21(2) must protect network and information systems against a broad spectrum of threats — not only cyberattacks, but physical and environmental hazards, system failures, and human error.

And it does not stop at the security team. Article 20 makes management bodies responsible for approving the cybersecurity risk-management measures and overseeing their implementation, and provides that they can be held liable for infringements (Art. 20(1)); management must also follow training (Art. 20(2)). For mid-market entities, this is the change that most often surprises the board: NIS2 puts cybersecurity accountability on the leadership table, in writing.

The ten measures of Article 21(2), in plain terms

Article 21(2)(a)–(j) lists the minimum measures every in-scope entity must implement. In plain language:

(a) Risk analysis and information system security policies — a documented, maintained basis for every other control.
(b) Incident handling — detection, response, and the ability to feed the Article 23 reporting timeline (below).
(c) Business continuity — backup management, disaster recovery, and crisis management.
(d) Supply chain security — including the security of relationships with direct suppliers and service providers.
(e) Security in acquisition, development and maintenance — including vulnerability handling and disclosure.
(f) Policies and procedures to assess the effectiveness of the risk-management measures.
(g) Basic cyber hygiene practices and cybersecurity training.
(h) Cryptography and, where appropriate, encryption.
(i) Human resources security, access control policies, and asset management.
(j) Multi-factor authentication (or continuous authentication), secured voice, video and text communications, and secured emergency communication systems where appropriate.

Read them together and a pattern emerges: Article 21 is asking for a running management system, not a binder. Measure (f) is the tell — you must be able to assess whether your own controls work.

On reporting, Article 23 sets the cadence for significant incidents: an early warning within 24 hours (Art. 23(4)(a)), an incident notification within 72 hours (Art. 23(4)(b)), and a final report within one month of that notification (Art. 23(4)(d)). The clock and the hand-offs are why incident handling (b) has to be rehearsed, not just documented.

Where mid-market teams most often fall short

Three measures consistently expose gaps in mid-market programmes:

Supply chain security (d). This is now a board-level control. Article 21(3) requires entities to take into account vulnerabilities specific to each direct supplier and the overall quality of the products and cybersecurity practices of their suppliers and service providers. Most mid-market teams have contracts but not a defensible, evidenced supplier-risk process.
Effectiveness assessment (f). Having controls is not the same as demonstrating they operate. This is where "we have a policy" meets an auditor's "show me the last time it worked."
Incident handling tied to the clock (b). The 24/72-hour reporting cadence assumes detection and decision-making that many smaller teams have not rehearsed.

Cross-mapping Article 21 to ISO 27001:2022 Annex A

If you already run an ISO/IEC 27001:2022 programme, you are not starting from zero — Annex A covers most of the technical ground Article 21 demands. The table below maps each measure to the most relevant Annex A controls (illustrative anchors, not an exhaustive crosswalk).

(a) Risk analysis & infosec policy — A.5.1 policies; Clause 6.1.2 risk assessment
(b) Incident handling — A.5.24–A.5.28 incident management
(c) Business continuity, backup, crisis — A.5.29, A.5.30 ICT readiness; A.8.13 backup
(d) Supply chain security — A.5.19–A.5.22 supplier relationships
(e) Secure acquisition/dev, vuln handling — A.8.25–A.8.29 secure development; A.8.8 vulnerability mgmt
(f) Effectiveness assessment — Clause 9 monitoring, internal audit, management review
(g) Cyber hygiene & training — A.6.3 awareness/training; A.8.7 malware protection
(h) Cryptography — A.8.24 use of cryptography
(i) HR security, access control, asset mgmt — A.6.1–A.6.6; A.5.15–A.5.18; A.5.9–A.5.11
(j) MFA & secured communications — A.8.5 secure authentication; A.5.14 information transfer

The catch: an ISO 27001 certificate is a strong foundation, not automatic NIS2 compliance. Three gaps remain even for certified entities:

Incident reporting timelines — ISO 27001 does not impose the statutory 24/72-hour external reporting cadence that Article 23 does.
Governance and personal accountability — the Article 20 management-body obligations go beyond ISO's leadership clause.
Proportionality to societal impact — under Article 21(1), your scope and risk treatment must reflect the disruption your failure would cause to the broader economy, not just to your own organisation.

From measures to evidence

The practical shift NIS2 demands is from having controls to evidencing them continuously. Competent authorities and auditors will expect to see live mapping between obligations and operating controls, an effectiveness-assessment trail (measure f), and a supplier-risk process you can defend. Treating Article 21 as documentation rather than a running system is the single most common — and most expensive — mistake.

Where CORTEX AI fits

Most teams already hold the raw material for NIS2 compliance inside an existing ISO 27001 programme — the work is connecting obligations to operating controls and keeping that mapping current. See how CORTEX AI approaches NIS2 Article 21 and its cross-mapping to ISO 27001 — explore the approach.