Article 21 of NIS2 Directive (EU) 2022/2555 sets out ten security measure categories that essential and important entities must implement. Ten categories are not easily project-managed as ten parallel workstreams. They have dependencies, sequencing logic, and a supervisory regime that makes some gaps more dangerous than others. This article organises the ten into five implementation pillars for programme management clarity, names the specific obligations within each, and sequences them by regulatory exposure and implementation complexity. The five-pillar framework is an analytical grouping to assist prioritisation. The Directive does not use the word "pillar."

What Article 21 actually requires: the full obligation set

NIS2 Article 21(2) requires essential and important entities to implement measures across ten categories: (a) risk analysis and information system security policies; (b) incident handling; (c) business continuity, backup management, disaster recovery, and crisis management; (d) supply chain security, including security-related aspects of relationships between entities and their direct suppliers or service providers; (e) security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure; (f) policies and procedures to assess the effectiveness of cybersecurity risk management measures; (g) cybersecurity hygiene practices and cybersecurity training; (h) policies and procedures regarding the use of cryptography and, where appropriate, encryption; (i) human resources security, access control policies and asset management; and (j) the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communications within the entity. [VERIFIED: NIS2 Directive (EU) 2022/2555, Article 21(2)(a)-(j).]

Article 21(1) requires that all measures are "appropriate and proportionate to the risks posed," accounting for "the state of the art" in cybersecurity. Proportionality means implementation cannot be a static checklist. The obligation is calibrated to actual risk profile, sector context, and the technical baseline at the time of assessment. The "state of the art" framing is a dynamic standard: as the technical baseline shifts, the obligation shifts with it.

Commission Implementing Regulation (EU) 2024/2690, which entered into force on 18 October 2024, provides binding technical and methodological requirements for Article 21 measures applicable to digital infrastructure, ICT service management, and digital provider entities. [VERIFIED: Commission Implementing Regulation (EU) 2024/2690, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202402690.] Entities within that scope must treat this regulation as legally binding alongside the Directive itself, not merely as guidance. Member state transposition adds a further layer: Germany's NIS2UmsuCG, enacted October 2024, France's ANSSI-driven NIS2 updates, and the Netherlands' Wbni amendment each carry sector-specific additions. [VERIFIED: BSI Act amendment (NIS2UmsuCG), https://www.bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/NIS2/nis2_node.html. ASSUMED: Netherlands Wbni amendment final scope; verify enacted provisions before relying on the Netherlands example.]

Pillar 1: Risk governance and policy (Article 21(2)(a) and (f))

The governance spine of a NIS2 programme sits in two categories: Article 21(2)(a), risk analysis and information system security policies, and Article 21(2)(f), policies and procedures to assess effectiveness. Together they define the framework that everything else plugs into.

A compliant risk analysis under Article 21(2)(a) requires identification of all in-scope network and information systems including cloud-hosted and third-party-managed; threat modelling across the entity's sector and operational profile; asset classification by criticality and impact of disruption; and a risk register with documented treatment decisions. ISO/IEC 27001:2022 provides a compatible methodology and ENISA's implementation guidance explicitly references it, though NIS2 does not mandate a specific standard. The choice of framework is at the entity's discretion provided the output meets the Directive's requirements.

Article 21(2)(f) is the element most absent in year-one NIS2 programmes. It requires documented processes to test whether security measures achieve their intended purpose: internal audit of control effectiveness, evidence of testing through penetration testing, red team exercises or equivalent, and a feedback loop into the risk register and policy set. Without this, an entity has a set of policies and a static control list. That is not a risk management system; it is a snapshot. A supervisory authority assessing an essential entity under Article 32 will ask for evidence of the effectiveness loop, not just the existence of the policies.

Pillar 2: Operational resilience (Article 21(2)(b) and (c))

Incident handling under Article 21(2)(b) requires incident classification and severity thresholds, detection and containment procedures, forensic evidence preservation, communication protocols, and post-incident review. The binding obligation that makes this pillar urgent is the notification timeline in Article 23: significant incidents must be notified to the relevant national competent authority within 24 hours as an early warning, followed by a detailed report within 72 hours and a final report within one month. [VERIFIED: NIS2 Directive (EU) 2022/2555, Article 23(3).] These timelines are independent of GDPR breach notification obligations. An incident that meets the Article 23 threshold must be notified on the NIS2 timeline even if no personal data is involved.

The practical implication: incident response procedures must be tested against the 24-hour early warning requirement. An entity that discovers a significant incident on a Friday evening must be able to produce a substantive early warning to its national competent authority by Saturday evening. Procedures that have not been exercised under that time pressure will not survive it. ENISA's Good Practices on Incident Management (2023) covers the procedural requirements in detail.

Article 21(2)(c) requires that backup, disaster recovery, and business continuity plans are documented, tested, and capable of restoring operations within the entity's defined recovery time objectives. For critical infrastructure sectors, ENISA guidance recommends that backup systems are segregated from primary network and information systems to limit ransomware and supply chain compromise blast radius. A business continuity plan that cannot be executed without access to a system that may itself be compromised is not a functioning business continuity plan.

Pillar 3: Supply chain and third-party security (Article 21(2)(d) and (e))

Article 21(2)(d) supply chain security is operationally the most complex element of NIS2. It requires entities to assess the security practices of direct ICT suppliers and service providers and to address supplier-introduced vulnerabilities within the risk management framework. The Commission is separately empowered under Article 22 to issue targeted risk assessments of specific ICT service provider categories and to define supply chain security criteria. The practical programme has three components: a supplier security questionnaire covering the security posture of tier-one critical suppliers; contractual minimum security requirements in ICT procurement specifications; and ongoing monitoring of supplier security posture for the highest-criticality dependencies.

Article 21(2)(e) covers security in acquisition, development, and maintenance of network and information systems, including vulnerability handling and disclosure. For entities procuring off-the-shelf software, this translates to security requirements in RFP and RFQ documentation, vendor vulnerability disclosure policies, Software Bills of Materials (SBOMs) for critical dependencies, and patch management processes with defined SLAs. ENISA supply chain security guidance references SBOMs as a technical instrument; NIS2 does not use the term but the inference from the Article's scope is direct.

Pillar 4: People and access security (Article 21(2)(g), (i), and (j))

The training obligation in Article 21(2)(g) extends beyond annual security awareness sessions. ENISA's Cybersecurity Awareness Raising Good Practices (2022) specifies role-based training with verified completion, including specific modules for incident responders, system administrators, privileged account holders, and senior management. Board-level personnel are specifically in scope. Article 20(1) makes the management body accountable for approving cybersecurity risk management measures and overseeing their implementation; Article 20(4) requires management body members to follow training to be able to assess those risks, with entities also offering equivalent training to employees. The Cyber Resilience Officer is not the sole NIS2 accountability point. That is a structural change from NIS1.

Article 21(2)(j) MFA is binary for essential entities: it must be in place. Commission Implementing Regulation (EU) 2024/2690 requires MFA for all remote access, all privileged account access, and all access to critical network and information systems. Phishing-resistant MFA, specifically FIDO2/WebAuthn or hardware security keys, is the recommended implementation for high-privilege access. SMS-based OTP does not satisfy the "secured" standard for privileged access under the regulation's intent. NIST SP 800-63B Section 5.1.3 on phishing-resistant authenticators provides the technical basis, and ENISA has published equivalent guidance for the EU context. [INFERRED: the regulation does not name specific MFA methods; the conclusion that SMS OTP does not satisfy the "secured" standard follows from NIST SP 800-63B technical reasoning and ENISA guidance, not from explicit prohibition in the regulation text.]

Pillar 5: Cryptography and data protection (Article 21(2)(h))

Article 21(2)(h) requires that cryptographic measures are appropriate to risk. The "state of the art" standard in Article 21(1) means this obligation is not satisfied by implementing what was current in 2020 and leaving it there. NIST finalised FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024; FIPS 206 (FN-DSA) followed in October 2024. NIST IR 8547 (November 2024) formally initiates deprecation of RSA, ECDH, ECDSA, DSA, and finite-field Diffie-Hellman. For NIS2 entities whose data has a confidentiality lifetime extending beyond 2030, harvest-now-decrypt-later is a documentable risk under Article 21(1). An entity that has not assessed this exposure has a gap in its risk analysis, not merely in its technical controls. [VERIFIED: NIST FIPS 203-206, August-October 2024; NIST IR 8547, November 2024, https://doi.org/10.6028/NIST.IR.8547.]

For EU digital infrastructure entities and trust service providers, ETSI TS 119 312 V1.4.1 (Electronic Signatures and Trust Infrastructures: Cryptographic Suites) is the primary EU technical reference for algorithm selection in qualified trust services under eIDAS. ETSI TR 103 619 on quantum-safe cryptography provides the standards body's technical framing for the PQC transition. These documents are the EU equivalent of the NIST FIPS publications for the purposes of Article 21(2)(h) compliance in regulated digital infrastructure. [VERIFIED: ETSI TS 119 312 V1.4.1, August 2022; ETSI TR 103 619, 2022.]

The practical first step in Pillar 5 is a Cryptographic Bill of Materials (CBOM): a structured inventory of all cryptographic assets, algorithms, key sizes, protocols, certificates, and libraries, mapped to the systems and data they protect with confidentiality lifetime estimates. NIST NCCoE SP 1800-38B provides the methodology. Without a CBOM, an entity cannot calculate where the post-quantum risk is concentrated in its specific estate, and cannot construct a proportionate migration programme. For the full treatment of the NIS2 and PQC intersection, including how HNDL sits within the Article 21 risk management framework, see our analysis at NIS2 and post-quantum cryptography: the gap in your cyber resilience plan.

Management accountability and the supervisory framework

Article 20 imposes a management body accountability obligation that is separate from and in addition to Article 21's technical measures. Under Article 20(1), management bodies must approve the cybersecurity risk management measures and oversee their implementation. Under Article 20(4), management body members must follow training sufficient to identify and assess cybersecurity risks and evaluate their management. Under Article 20(2), management bodies can be held personally liable for infringements of the risk management obligations. [VERIFIED: NIS2 Directive (EU) 2022/2555, Article 20(1), (2), and (4).] This is the first EU cybersecurity instrument to impose that personal management accountability at board level explicitly.

Enforcement differs by entity category. Essential entities are subject to proactive supervisory assessment under Article 32, including ex-ante inspections, security audits, spot checks, targeted security scans, and requests for evidence of compliance. Essential entity programmes must be audit-ready at any point. Important entities face Article 33 enforcement: supervisory activity is triggered by evidence of non-compliance, not initiated proactively. [VERIFIED: NIS2 Directive (EU) 2022/2555, Articles 32 and 33.] Sanctions are substantial: essential entities face fines of up to EUR 10 million or 2% of total global annual turnover, whichever is higher; important entities face up to EUR 7 million or 1.4%. [VERIFIED: NIS2 Directive (EU) 2022/2555, Article 34(4) and (5).]

UK position: different regime, same direction

UK organisations operating under UK law are not subject to NIS2. The applicable UK regime is the Network and Information Systems (NIS) Regulations 2018 (SI 2018/506), which transposed NIS1 (Directive (EU) 2016/1148), not NIS2. The UK NCSC provides compliance guidance for the 2018 Regulations. [VERIFIED: SI 2018/506, https://www.legislation.gov.uk/uksi/2018/506/contents; NCSC NIS guidance, https://www.ncsc.gov.uk/collection/nis-directive.]

The UK Cyber Security and Resilience Bill, announced in the King's Speech in July 2024, is intended to expand the scope and strengthen the obligations of the 2018 Regulations. [ASSUMED: verify the Bill's enacted status and final obligations as of the article's July 2026 publication date. As of the knowledge cutoff for this article, the Bill was in pre-legislative consultation. If enacted, update this paragraph to describe the actual obligations rather than the prospective Bill.] UK organisations that supply ICT services to EU essential entities under NIS2 Annex I or II may face contractual requirements driven by their EU clients' Article 21(2)(d) supply chain security obligations, regardless of direct NIS2 applicability.

Sequencing implementation: where to start in 2026

For a Cyber Resilience Officer beginning or continuing implementation, risk-based sequencing rather than pillar order gives the right priority:

Pillar 1 (governance foundation) and Pillar 4 (MFA, binary requirement) first. These are prerequisites for credible implementation of everything else. An Article 32 assessment that finds no risk register and no MFA on privileged access is not a partial compliance finding; it is a foundational gap.

Pillar 2 (incident handling) second, specifically because the 24-hour early warning obligation under Article 23 creates immediate legal exposure for any gap. A significant incident that occurs before incident handling procedures are tested produces regulatory exposure independent of what caused the incident.

Pillar 3 (supply chain) third: high operational complexity and long lead times mean starting early is the only way to achieve meaningful coverage. Supplier security questionnaires and contractual requirements cannot be deployed at the week before an audit.

Pillar 5 (cryptography and PQC) fourth. The CBOM is the immediate action. Migration is multi-year. Starting the CBOM now is the only way to have a defensible Pillar 5 position when supervisory assessment arrives.

For an essential entity, the six documents a supervisory authority is most likely to request are: the risk register with documented treatment decisions; the full set of security policies; the CBOM or equivalent cryptographic asset inventory; evidence of MFA deployment across remote and privileged access; the incident response plan with tested procedures; and supply chain security questionnaire results for tier-one critical suppliers. Having these six documents production-ready before the first supervisory contact is the minimum audit-readiness standard.

The quantum risk dimension of Pillar 5 is addressed in full at NIS2 and quantum risk: identifying the cyber resilience gap. That article covers the HNDL threat model within the Article 21 framework and the three actions that close the PQC gap within the NIS2 compliance posture.