NIS2 cybersecurity measures — Articles 20 and 21

The substantive obligations of NIS2 sit in Articles 20 and 21. Article 20 fixes the management-body accountability layer. Article 21 sets out the cybersecurity risk-management measures that essential and important entities must take, paragraph by paragraph: paragraph (1) frames the obligation in proportionate-and-state-of-the-art terms; paragraph (2) opens with an all-hazards chapeau and then lists the ten minimum measure categories; paragraph (3) layers in the supply-chain risk-assessment expectation; paragraph (4) requires self-corrective action; paragraph (5) authorises the Commission to adopt implementing acts that further specify the measures for certain entity types.

This page quotes the first subparagraph of Article 21(1), the Article 21(2) chapeau, each of the ten Article 21(2)(a)–(j) categories, and Article 21(4) verbatim from the published OJ text and explains how each lands in Modulos.

Quick decision

• In scope and looking for the binding measure baseline → Article 21(1) is the framing obligation; Article 21(2)(a)–(j) is the ten-category minimum. Read those first, then the Article 23 incident-reporting spoke and the scope and applicability spoke.
• Already running ISO/IEC 27001:2022 (with Amd 1:2024) → map the ISMS to Article 21(2) measure-by-measure rather than treating ISO certification as a discharge. Article 20 management-body duties and the Article 21(2)(d) + 21(3) supply-chain expectations typically need NIS2-specific evidence beyond a base ISMS.
• DNS / TLD / cloud / data-centre / CDN / managed-service / managed-security-service provider, online marketplace, search engine, social-networking platform, or trust service provider → Article 21(2) applies as written and Implementing Regulation (EU) 2024/2690 lays down the technical and methodological specification of the Article 21(2) measures for your entity type.
• Identified by the Member State under Article 2(2)(b)–(e) → check the national transposition, because Article 21(2) applies in the same form but additional national-level conditions may attach to the in-scope route.
• Found a gap → Article 21(4) requires the entity to take, without undue delay, all necessary, appropriate and proportionate corrective measures. Document the gap, the corrective action, and the timeline as evidence against the relevant requirement.

TL;DR

• Article 20 holds the management body accountable for approving the measures, overseeing their implementation, and being capable of being held liable under the national transposing law. Article 20(2) adds a management-body training duty.
• Article 21(1) is the framing obligation: appropriate and proportionate technical, operational and organisational measures, taking into account the state of the art and the cost of implementation.
• Article 21(2) opens with an all-hazards chapeau and then lists the ten minimum measure categories at (a)–(j). Each category is a programme-level obligation, not a single control.
• Article 21(3) layers in supply-chain risk assessment expectations including the results of Article 22(1) coordinated security risk assessments of critical supply chains.
• Article 21(4) requires self-corrective action without undue delay where an entity finds it does not comply with Article 21(2).
• Article 21(5) + Implementing Regulation (EU) 2024/2690 layer technical and methodological specification of the Article 21(2) measures for specific digital-infrastructure entity types and trust service providers.

Primary source

Directive (EU) 2022/2555 on EUR-Lex (CELEX 32022L2555) — Articles 20–22 · Commission Implementing Regulation (EU) 2024/2690 (technical and methodological specification for digital-infrastructure entities and trust service providers) · ENISA Technical Implementation Guidance (June 2025)

Article 20 — management-body accountability

NIS2 codifies management-body responsibility for cybersecurity at two levels. Article 20(1) requires that the management body approve the cybersecurity risk-management measures, oversee their implementation, and can be held liable for infringements of Article 21 by the entity. Article 20(2) requires Member States to ensure that members of the management bodies of essential and important entities follow training, and encourages essential and important entities to offer similar training to their employees on a regular basis. The training scope in Article 20(2) is identifying risks and assessing cybersecurity risk-management practices and their impact on the services provided by the entity.

In Modulos: ORF-336 (management body approval and oversight under Article 20(1)) and ORF-337 (management body cybersecurity training under Article 20(2)) carry these duties.

Article 21(1) — the framing obligation

The first subparagraph of Article 21(1) frames the obligation in broad, proportionate terms:

Member States shall ensure that essential and important entities take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services, and to prevent or minimise the impact of incidents on recipients of their services and on other services.

The remaining subparagraphs of Article 21(1) require, among other things, that the measures take into account the state of the art and, where applicable, relevant European and international standards, as well as the cost of implementation, and that the measures shall ensure a level of security of network and information systems appropriate to the risks posed.

The opening sentence of Article 21(2) (the chapeau) states verbatim:

The measures referred to in paragraph 1 shall be based on an all-hazards approach that aims to protect network and information systems and the physical environment of those systems from incidents, and shall include at least the following:

Article 21(2)(a) — policies on risk analysis and information system security

policies on risk analysis and information system security;

The (a) obligation is for entity-level policies — not a single control. Effective implementation typically pairs a risk-analysis methodology with one or more information-system-security policies, both approved at the management-body level (Article 20(1)) and reviewed periodically. ISO/IEC 27001:2022 Clause 6.1 (risk treatment) and the ISO/IEC 27002:2022 control catalogue cover much of the substance, but the policy formality and approval trail are what auditors and supervisory authorities will look for under Article 21(2)(a).

In Modulos: ORF-338 (organisation-level governance) and MRF-275 (AI-service execution).

Article 21(2)(b) — incident handling

incident handling;

The (b) obligation runs from detection through analysis, containment, eradication, recovery, and post-incident review. The incident-handling capability must connect operationally to the Article 23 reporting workflow (24-hour early warning, 72-hour incident notification, intermediate, final, and progress reports — see the incident-reporting spoke). ISO/IEC 27001 Clause 8.3 / Annex A.5.24 information-security-incident-management controls cover most of the technical substance.

In Modulos: ORF-339 (governance) and MRF-276 (AI-service execution).

Article 21(2)(c) — business continuity, including backup, disaster recovery, and crisis management

business continuity, such as backup management and disaster recovery, and crisis management;

The (c) obligation explicitly names backup management, disaster recovery, and crisis management as components of a business-continuity programme. The recovery-time-objective and recovery-point-objective decisions, regular tested backups, and a documented crisis-management plan are the typical evidence. Cross-link with the Article 23(4)(d) final report for incident-driven invocation of the BC/DR plan.

In Modulos: ORF-340 (governance) and MRF-277 (AI-service execution).

Article 21(2)(d) — supply chain security

supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers;

The (d) obligation deliberately scopes supply-chain security to the direct supplier and service-provider relationships of the entity. Article 21(3) then expands the assessment expectation: when considering which (d) measures are appropriate, entities take into account vulnerabilities specific to each direct supplier, the overall quality of products and cybersecurity practices of suppliers, secure development procedures, and the results of Article 22(1) coordinated security risk assessments of critical supply chains.

In Modulos: ORF-341 (governance) and MRF-278 (AI-service execution). Cross-link with the DORA Article 28–30 ICT third-party regime for financial-sector overlap.

Article 21(2)(e) — security in acquisition, development and maintenance

security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;

The (e) obligation covers the secure-engineering lifecycle: procurement security, secure development, secure maintenance, and a vulnerability-handling-and-disclosure process. The vulnerability-disclosure-and-handling element is specifically called out, including the relationship with the EU vulnerability-disclosure database maintained by ENISA under Article 12.

In Modulos: ORF-342 (governance) and MRF-279 (AI-service execution).

Article 21(2)(f) — policies and procedures to assess effectiveness

policies and procedures to assess the effectiveness of cybersecurity risk-management measures;

The (f) obligation is the meta-control: regular assessment of whether the (a)–(e) and (g)–(j) measures actually work. Typical implementation pairs an internal-audit / control-testing programme with management-body review under Article 20(1). ISO/IEC 27001 Clauses 9.1 (monitoring, measurement, analysis and evaluation) and 9.2 (internal audit) cover the substance.

In Modulos: ORF-343 (governance) and MRF-280 (AI-service effectiveness testing).

Article 21(2)(g) — basic cyber hygiene practices and cybersecurity training

basic cyber hygiene practices and cybersecurity training;

The (g) obligation pairs everyday hygiene practices (patching, hardening, configuration baselines, phishing awareness) with a structured cybersecurity-training programme. Article 20(2) management-body training is a distinct duty; the (g) training duty extends across the workforce.

In Modulos: ORF-344 (governance) and MRF-281 (operational cyber hygiene and role-based training).

Article 21(2)(h) — cryptography and encryption

policies and procedures regarding the use of cryptography and, where appropriate, encryption;

The (h) obligation expects entity-level policies and procedures covering how cryptography is selected, deployed, and managed — algorithm choice, key management, certificate lifecycle, deprecation, and the "where appropriate" decision on encryption. ISO/IEC 27002:2022 cryptography controls (A.8.24) and key-management practices cover most of the technical substance.

In Modulos: ORF-345 (governance) and MRF-282 (cryptography and encryption controls).

Article 21(2)(i) — human resources security, access control, and asset management

human resources security, access control policies and asset management;

The (i) obligation combines three classical information-security topics in one paragraph: HR security (joiners / movers / leavers, background checks where appropriate), access-control policies (RBAC, least privilege, periodic access reviews), and asset management (inventories, ownership, classification). These map closely to ISO/IEC 27002:2022 controls in the A.5, A.6, A.8 family.

In Modulos: ORF-346 (governance) and MRF-283 (HR security, access control, and asset management).

Article 21(2)(j) — MFA, secured communications, and secured emergency communications

the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate.

The (j) obligation has three components: multi-factor or continuous authentication; secured voice / video / text communications within the entity; and secured emergency communication systems within the entity. The "where appropriate" qualifier applies — proportionality and the state-of-the-art clause in Article 21(1) are the calibration tools.

In Modulos: ORF-347 (governance) and MRF-284 (MFA and secured communications).

Article 21(3) — supply-chain risk assessment

Article 21(3) is not a separate measure category but a layer of assessment expectations on Article 21(2)(d). It directs entities, when considering which (d) measures are appropriate, to take into account:

• the vulnerabilities specific to each direct supplier and service provider;
• the overall quality of products and cybersecurity practices of suppliers and service providers, including their secure development procedures;
• the results of the coordinated security risk assessments of critical supply chains carried out in accordance with Article 22(1).

Modulos ORF-341 carries the governance side; MRF-278 carries the AI-service execution side; the AI-BOM and vendor-review evidence ladders attach to both.

Article 21(4) — corrective action without undue delay

Member States shall ensure that an entity that finds that it does not comply with the measures provided for in paragraph 2 takes, without undue delay, all necessary, appropriate and proportionate corrective measures.

In Modulos: ORF-348 (organisation-level corrective action governance) and MRF-285 (AI-service corrective action workflow). The corrective-measure record attaches as evidence to the requirement that captured the original non-compliance.

Article 21(5) — Implementing Regulation (EU) 2024/2690 overlay

Article 21(5) authorises the Commission to adopt implementing acts laying down the technical and methodological requirements of the Article 21(2) measures with regard to specific entity types. The implementing act referenced in the body of this page is Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024, which covers DNS service providers, top-level-domain name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, of online search engines and of social-networking services platforms, and trust service providers. The implementing act further specifies the cases in which an incident is considered significant for those entities for the purposes of Article 23 reporting.

In Modulos: ORF-349 (organisation-level applicability governance) and MRF-291 (AI-service significant-incident criteria execution).

How to operationalize Article 21 in Modulos

The OFF-15 / MFF-15 split keeps Article 20 (management-body accountability) and Article 21 (operational measures) traceable in separate evidence ladders:

Layer	Modulos surface	Coverage
Organization-level governance	OFF-15 with ORF-336–ORF-348 requirements	Art 20(1)–(2), Art 21(2)(a)–(j), Art 21(4)
Implementing-act governance	OFF-15 with ORF-349 requirement	Art 21(5) + Implementing Reg 2024/2690
AI-service implementation	MFF-15 with MRF-275–MRF-285 requirements	Art 21(2)(a)–(j), Art 21(4) execution
Implementing-act execution	MFF-15 with MRF-291 requirement	Implementing Reg 2024/2690 significant-incident criteria

A typical setup:

1. Requirements — each Article 21(2) sub-paragraph is recorded as a requirement on the OFF-15 organisation project and on the MFF-15 AI-service project. Fulfilment tracks through Not fulfilled → Fulfilled (with optional Out of scope).
2. Controls — implemented measures (risk-assessment methodology, incident-handling runbook, BC/DR plan, vendor due-diligence policy, secure-SDLC standard, internal-audit programme, cyber-hygiene baseline, cryptography policy, RBAC implementation, MFA rollout) are documented as named controls and mapped to one or more requirements. Where an ISO 27001 ISMS already documents the substance, the ISMS controls can be reused rather than duplicated.
3. Evidence — design documents, risk-assessment artefacts, incident postmortems, BC/DR test records, supplier reviews, internal-audit reports, training records, and management-body approval minutes are recorded once and linked to multiple controls.
4. Readiness + fulfilment attestation — a requirement becomes ready for review once all linked controls are in a final state; the requirement owner then attests fulfilment for the project scope.
5. Corrective action (Article 21(4)) — when a self-identified gap is recorded, the corrective measure, owner, and timeline attach as evidence to the requirement that captured the gap.

Cross-framework mapping (preview)

NIS2 Article 21 cluster	ISO/IEC 27001:2022 (Amd 1:2024)	ISO/IEC 27002:2022	DORA (Regulation (EU) 2022/2554)	EU AI Act
Article 21(2)(a) policies	Clause 5.2 (policy), 6.1 (risk treatment)	A.5.1 (policies)	Art 6 (ICT RMF), 2024/1774 (RMF RTS)	Art 9 (RMS)
Article 21(2)(b) incident handling	Clause 8.3 / Annex A.5.24	A.5.24 / A.5.25	Arts 17–19, 2025/301 / 2025/302	Art 73 (serious incident reporting)
Article 21(2)(c) continuity	Clause 8.1, A.5.29 / A.5.30	A.5.29 (BC during disruption), A.5.30 (ICT readiness for BC)	Arts 11–12 (resilience and continuity)	(not directly mapped)
Article 21(2)(d) supply chain + Art 21(3)	Clause 8.1	A.5.19, A.5.20, A.5.21, A.5.22	Arts 28–30, 2024/1773 (TPP policy RTS), 2025/532 (subcontracting RTS)	Art 25 (value-chain and provider reclassification)
Article 21(2)(e) acquisition / development / maintenance	Clauses 8.1	A.8.25–A.8.31 (secure development family)	Arts 8–11 (ICT systems, vulnerabilities)	Art 15 (cybersecurity, robustness) for high-risk AI
Article 21(2)(f) effectiveness assessment	Clauses 9.1, 9.2	(control-testing programme)	Arts 13, 24–27 (testing)	Art 15 (continuous evaluation)
Article 21(2)(g) hygiene + training	(training programme)	A.6.3 (information-security awareness)	(workforce competence under RMF)	Art 4 (AI literacy obligations on providers / deployers)
Article 21(2)(h) cryptography	Annex A.8.24	A.8.24 (cryptography)	Implementing Reg 2024/1774 (technical controls)	(not directly mapped)
Article 21(2)(i) HR / access / assets	(HR, access, asset management family)	A.5.x / A.6.x / A.8.x	(access control under RMF)	(not directly mapped)
Article 21(2)(j) MFA / secured comms	Annex A.5.17 (authentication information), A.8.5	A.5.17 / A.8.5	(technical controls under RMF)	(not directly mapped)

For the pairwise treatment with DORA see NIS2 vs DORA.

Related pages

NIS2 overview

Framework structure, dates, OFF-15 / MFF-15 split

Scope and applicability

Article 2 scope, Article 3 essential / important classification

Incident reporting (Article 23)

Significance test, staged timelines, trust-service derogation

Operationalizing in Modulos

Practical rollout sequence for OFF-15 and MFF-15

NIS2 vs DORA

Where each applies and how the Article 21 measures compare to DORA's RMF

Source attribution

Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2) is published in the Official Journal of the European Union L 333, 27.12.2022, pp. 80–152. The first subparagraph of Article 21(1), the Article 21(2) chapeau, each of the Article 21(2)(a)–(j) sub-paragraphs, and Article 21(4) on this page are quoted verbatim from that OJ text for legal-citation purposes. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 is published in OJ L 2024/2690 of 18.10.2024.

Disclaimer

This page is for general informational purposes and does not constitute legal advice. NIS2 takes effect in each Member State through national transposing law; the binding measure baseline and the supervisory authority's interpretation of Article 21(2) "appropriate and proportionate" are determined by that national law. For binding interpretation in your jurisdiction, consult the published EUR-Lex text, the relevant ISO/IEC standards, and qualified counsel.