The 10 NIS-2 Cybersecurity Risk Management Measures (Article 21)

Article 21 of Directive (EU) 2022/2555 is the operational core of NIS-2. While Article 20 makes the management body accountable and Article 23 sets the incident reporting clock, Article 21 is what auditors actually inspect: ten specific risk-management measures that every essential and important entity must implement, document, and prove operational.

The measures are deliberately technology-neutral and outcome-based. The Directive tells you what to achieve, not which tool to buy. This sounds permissive in theory and is unforgiving in practice: there is no checklist of approved products that constitutes compliance, and a vendor’s marketing claim that their tool “covers Article 21” is meaningless without the policy framework, the operational evidence, and the management body approval that surround it.

This article walks through all ten measures: what each requires, what evidence regulators expect, where Commission Implementing Regulation (EU) 2024/2690 adds binding specificity for digital infrastructure providers, and what the common nonconformities look like at audit. It is the technical companion to the NIS-2 compliance pillar; read that first if you need the broader scope and timeline context.

How Article 21 actually works: three principles before the list

Before walking the ten measures, three principles from Article 21(1) shape every implementation choice.

Proportionality. The depth and sophistication of controls must match the entity’s risk exposure, size, and the severity of potential incidents. A 60-person manufacturer is not held to the same control depth as a transmission system operator, but both must address all ten measures. Proportionality is not an excuse for absence; it is calibration of effort.

All-hazards approach. Article 21(2) requires protection “from all hazards” — cyber threats, but also physical attacks, environmental events, and human error. Backups stored only in the same data centre as production are not a defensible all-hazards control.

Evidence over intent. Article 21(2)(f) explicitly requires “policies and procedures to assess the effectiveness of cybersecurity risk-management measures.” You must measure your own controls. A policy that is written but not followed, monitored, or reviewed is not a control — it is a document. Auditors detect this immediately.

For digital infrastructure entities (DNS providers, TLD registries, cloud computing providers, data centres, CDN providers, MSPs, MSSPs, online marketplaces, search engines, social networks, trust service providers), Commission Implementing Regulation (EU) 2024/2690 translates Article 21 into more than 150 specific binding controls. For other in-scope sectors, the CIR is not directly binding but is increasingly used by national authorities as the interpretive baseline for what “appropriate and proportionate” means in practice.

A useful mental grouping: four domains

The ten measures are listed in Article 21(2) in regulatory order, not implementation order. For project planning, it helps to group them into four functional domains:

• Governance and risk (measures 1, 6) — the framework that holds everything together
• Operational resilience (measures 2, 3) — incident handling and business continuity
• Supply chain and lifecycle (measures 4, 5) — third parties and the systems lifecycle
• Technical and human controls (measures 7, 8, 9, 10) — the controls users and systems experience daily

This grouping is unofficial but matches how mature compliance programmes structure their work. The featured image accompanying this article on the live blog presents the same map visually.

Now to the ten measures themselves.

Measure 1 — Risk analysis and information system security policies

What Article 21(2)(a) requires: policies on risk analysis and information system security.

What it means in practice. A documented risk methodology, an information security policy approved by the management body, and a risk register that ties identified risks to mitigation actions, owners, and review cadence. The methodology must be defensible — ISO/IEC 27005 is the most common baseline, but any structured approach that produces consistent, repeatable results is acceptable.

Evidence regulators expect:

• Risk assessment methodology document (approved, versioned)
• Current risk register with risk owner, likelihood, impact, residual risk, and review date for each item
• Information security policy signed by the management body
• Records of periodic risk review (at least annually, plus on significant change)
• Risk treatment plan with named owners and timelines

Common nonconformities: risk register exists but has not been reviewed in 18+ months; methodology is generic boilerplate not adapted to the entity’s actual risk profile; risks identified but no treatment plan; treatment plan exists but no evidence of execution.

Measure 2 — Incident handling

What Article 21(2)(b) requires: incident handling.

What it means in practice. Procedures and capabilities for detection, analysis, containment, eradication, recovery, and post-incident review. This measure must be read together with Article 23, which imposes the 24/72/30-day reporting cascade — what you do internally must produce the data you have to report externally.

Evidence regulators expect:

• Incident response plan covering roles, escalation, containment, eradication, recovery, post-incident review
• Detection capability appropriate to the entity’s risk profile (SIEM, EDR, IDS/IPS, log monitoring)
• Defined incident severity classification with named decision-makers
• Incident register with classification, timeline, root cause, lessons learned
• Tabletop exercise records demonstrating the plan has been tested
• Mapping of internal incident classification to NIS-2 Article 23 reporting thresholds

Common nonconformities: plan exists on paper but no detection capability supports it; severity classification undefined or never used; no record of incidents (not because nothing happened, but because nothing was recorded); plan never tested.

For the full breakdown of detection, classification, and the Article 23 reporting workflow, see the NIS-2 incident reporting timeline.

Measure 3 — Business continuity and crisis management

What Article 21(2)(c) requires: business continuity, such as backup management and disaster recovery, and crisis management.

What it means in practice. A business impact analysis identifying critical services and their recovery requirements, documented continuity and disaster recovery plans, backup procedures with tested restore, and a crisis management capability that activates when incidents exceed normal operational handling.

Evidence regulators expect:

• Business impact analysis (BIA) with named critical services, recovery time objectives (RTO), and recovery point objectives (RPO)
• Business continuity plan (BCP) and disaster recovery plan (DRP)
• Backup policy specifying scope, frequency, retention, encryption, geographic separation
• Restore test records — not “we have backups” but “we restored backup X on date Y in Z hours, here is the report”
• Crisis management plan with activation criteria, decision authority, and communication procedures
• Tabletop or live exercise records, at least annually

Common nonconformities: backups configured but never restored; RTO/RPO undefined or aspirational; BCP exists but never exercised; crisis management plan does not name decision-makers.

The proportionality principle has practical bite here. A small important entity is not expected to maintain a fully redundant alternate site. It is expected to have a credible plan for what happens if its primary IT environment is unavailable for a week — including who decides, who communicates, and how the business operates in the interim.

Measure 4 — Supply chain security

What Article 21(2)(d) requires: supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.

What it means in practice. Risk assessment of direct suppliers, contractual security obligations, and continuous monitoring. This is consistently the hardest measure for SMEs and even mid-market organisations to evidence in audit, because it requires reaching beyond the perimeter you control.

The Directive specifically directs entities to take into account the results of EU-coordinated security risk assessments of critical supply chains, the technical and physical security qualities of suppliers, and the security practices of suppliers including their secure development procedures.

Evidence regulators expect:

• Supplier security policy
• Supplier inventory with risk classification (critical / important / standard, or equivalent)
• Risk assessment for each critical supplier — security questionnaire, certifications, audit reports
• Contractual security clauses (template) and evidence of inclusion in critical supplier contracts
• Monitoring procedure (review of supplier security disclosures, breach notifications, certification renewals)
• Records of supplier reviews

Common nonconformities: suppliers identified but not classified by risk; security questionnaires sent but never reviewed or followed up; contractual clauses absent from existing critical supplier contracts; “monitoring” defined as “we trust our suppliers.”

ENISA and the European Commission jointly publish coordinated risk assessments for specific supply chains (the 5G toolbox is the best-known example). In-scope entities should track these and reflect them in their own assessments where applicable.

Measure 5 — Security in network and information systems acquisition, development, and maintenance

What Article 21(2)(e) requires: security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.

What it means in practice. A secure development lifecycle (where the entity develops software), a vulnerability management programme, a documented patch management procedure with timelines, and a coordinated vulnerability disclosure policy if the entity operates services where external researchers can find vulnerabilities.

Evidence regulators expect:

• Secure development policy (if applicable) covering threat modelling, secure coding, security testing, and code review
• Vulnerability management procedure with scanning frequency, severity classification, and remediation timelines
• Patch management procedure differentiating critical / high / medium / low severity with maximum remediation windows
• Vulnerability scan reports and remediation evidence
• Coordinated vulnerability disclosure (CVD) policy and contact channel (where applicable)
• Records of penetration testing or security assessments at defined frequency

Common nonconformities: vulnerabilities scanned but not remediated within stated timelines; remediation timelines defined as “as soon as possible” without measurable thresholds; patch management ad-hoc rather than procedural; no CVD policy on a public-facing service.

The CIR 2024/2690 is particularly detailed here for digital infrastructure providers, requiring integration of security testing into the development lifecycle, secure handling of test data, and a mix of techniques (penetration testing, SAST, DAST, manual code review) at different lifecycle stages.

Measure 6 — Policies and procedures to assess effectiveness of cybersecurity risk-management measures

What Article 21(2)(f) requires: policies and procedures to assess the effectiveness of cybersecurity risk-management measures.

What it means in practice. Internal audit, KPI tracking, and periodic management review. NIS-2 demands measurement, not just implementation. This is the measure that turns a documentation set into an operating system.

Evidence regulators expect:

• Internal audit programme with annual schedule
• Internal audit procedure
• Internal audit reports covering the ten Article 21 measures over a defined cycle (typically 1-3 years)
• KPI dashboard or report tracking key security metrics (e.g., incident count and severity, patch compliance, training completion, supplier review status)
• Management review meeting minutes at defined frequency (at least annually) with documented decisions
• Corrective action register tracking findings to closure

Common nonconformities: internal audit performed once at certification and never repeated; KPIs defined but not reviewed; management review held but no minutes or decisions recorded; corrective actions opened but never closed.

This measure is also where the Article 20 management body accountability becomes operationally visible. The management review meeting is the moment where the management body sees the evidence, asks questions, and approves direction — without it, “the board approved” is an empty statement.

Measure 7 — Basic cyber hygiene practices and cybersecurity training

What Article 21(2)(g) requires: basic cyber hygiene practices and cybersecurity training.

What it means in practice. Foundational practices that reduce the attack surface across the organisation: acceptable use, password management, mobile device policy, anti-phishing awareness, and recurring training with completion records. Article 20 separately requires training for the management body itself, and the Italian transposition (D.Lgs. 138/2024) is explicit that this training is non-delegable.

Evidence regulators expect:

• Acceptable use policy and signed acknowledgement records
• Password policy aligned with current guidance (NIST SP 800-63B is the most cited reference)
• Mobile device / BYOD policy
• Phishing simulation programme with results tracked over time
• Training plan covering all employees, with role-specific modules where relevant
• Training completion records (who, what, when, with refresh frequency)
• Specific evidence of management body training

Common nonconformities: training delivered once at onboarding and never refreshed; phishing simulation absent or run once for compliance theatre; management body never completed any training; password policy still requiring 90-day rotation against current guidance.

For the detailed approach to building and evidencing a NIS-2-aligned training programme, see NIS-2 cybersecurity training requirements.

Measure 8 — Cryptography and encryption policies

What Article 21(2)(h) requires: policies and procedures regarding the use of cryptography and, where appropriate, encryption.

What it means in practice. A documented cryptography policy governing data at rest, data in transit, key management, and algorithm choice. “Where appropriate” does not mean “optional”; it means scoped to where it provides real risk reduction. Sensitive personal data, authentication credentials, and data crossing untrusted networks are appropriate by default.

Evidence regulators expect:

• Cryptography policy specifying approved algorithms, key lengths, and protocols
• Key management procedure (generation, storage, rotation, destruction)
• Inventory of where encryption is applied (at-rest databases, backups, mobile devices, in-transit traffic)
• TLS configuration evidence for public-facing services
• Records of cryptographic asset reviews (algorithm deprecation, certificate expiry monitoring)

Common nonconformities: policy references obsolete algorithms (3DES, SHA-1, RSA-1024); keys generated and never rotated; no inventory of encrypted vs unencrypted data; certificates expiring without monitoring.

The post-quantum transition is now a recurring audit topic. Mature programmes have at least an awareness statement on quantum-resistant cryptography migration even if implementation is years away.

Measure 9 — Human resources security, access control, and asset management

What Article 21(2)(i) requires: human resources security, access control policies, and asset management.

What it means in practice. Three intertwined controls: HR security covering the employee lifecycle, access control governing who can access what under what conditions, and asset management providing the inventory that makes the other two possible.

Evidence regulators expect:

• HR security procedures (background checks where lawful, onboarding, role changes, offboarding with access revocation)
• Access control policy with role-based access and least privilege principles
• Privileged access management (PAM) for administrative accounts
• Access review records (periodic recertification of who has access to what)
• Asset inventory (hardware, software, data, services) with owner and classification
• Joiners-movers-leavers process records demonstrating access changes track HR events

Common nonconformities: former employees retain access months after departure; access review either absent or rubber-stamped; asset inventory exists but is incomplete or outdated; privileged accounts shared rather than individually attributed.

The single most common audit finding in this measure is the gap between HR records and IT access records: someone left the organisation in HR’s system three months ago but their account is still active. Reconciling these two registers is unglamorous and high-impact.

Measure 10 — Multi-factor authentication, secure communications, and emergency communications

What Article 21(2)(j) requires: 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.

What it means in practice. MFA on remote access, privileged accounts, and email at minimum. Secured voice and video where the risk profile justifies it. An emergency communication channel that works when the primary one is compromised — because the primary channel will be exactly the one the incident is about.

Evidence regulators expect:

• MFA policy specifying scope and approved factors
• Technical evidence of MFA enforcement (logs, configuration screenshots, IdP policies)
• Coverage report (% of accounts with MFA enabled, broken down by category)
• Secure communication policy where applicable (encrypted messaging, secure conferencing)
• Documented out-of-band emergency communication procedure with tested contact lists and channels
• Records of emergency communication tests

Common nonconformities: MFA enabled on the corporate IdP but not on legacy systems; SMS-based MFA still used for privileged access (against current guidance); emergency communication procedure exists but contact lists are 18 months out of date; no out-of-band channel — the emergency procedure assumes the corporate email works.

This is one of the measures where ENISA and the CIR 2024/2690 push hardest. For digital infrastructure providers, MFA on remote access and administrative interfaces is no longer “where appropriate” — it is required.

Mapping Article 21 to your documentation set

The ten measures translate into a documentation footprint that, for most organisations, looks like 60-80 distinct artefacts: policies, procedures, plans, registers, templates, and reports. The structure of the Docply NIS-2 Total Kit is built directly on this mapping — eight bundles that group the documentation by Article 21 measure cluster:

• Bundle 1 — Governance and Setup maps to Measures 1 and 6 (governance scaffolding)
• Bundle 2 — Risk Management maps to Measure 1 (risk methodology and outputs)
• Bundle 3 — Cybersecurity Operations maps to Measures 5, 7, 8, 9, 10 (the technical and human controls)
• Bundle 4 — Business Continuity and Crisis maps to Measure 3
• Bundle 5 — Supply Chain Security maps to Measure 4
• Bundle 6 — Effectiveness and Audit maps to Measure 6
• Bundle 7 — Incident Management maps to Measure 2 (and Article 23)
• Bundle 8 — Corrective Actions and Training maps to Measures 6 and 7

For the full documentation checklist organised by bundle, with priority and Article 21 mapping, see the NIS-2 documentation checklist.

The audit posture: what regulators look for first

After two years of advising organisations through NIS-2 readiness assessments, three patterns recur in what regulators and external auditors examine first.

First, governance evidence. Management body approval records, training records, and risk acceptance decisions. This is the fastest way to assess whether the organisation is operating Article 21 or just hosting it.

Second, incident response evidence. The incident register, tabletop exercise records, and the mapping to Article 23 reporting thresholds. An organisation that cannot show incidents (because none have occurred or none have been recorded) gets pushed harder on detection capability.

Third, supply chain evidence. The supplier inventory, the risk classification, and the contractual clauses in critical supplier contracts. This is the measure most likely to surface significant gaps, and auditors know it.

If your programme is strong on these three and proportionate elsewhere, you are in defensible shape. If it is weak on these three, the rest is unlikely to compensate.

How Docply fits in

Each of the ten Article 21 measures requires a specific set of policies, procedures, and templates to evidence implementation. The Docply NIS-2 Total Kit provides 77 audit-ready documents covering all ten measures, organised into the eight bundles above and customisable to your entity’s actual scope. Drafted by a regulatory consultant, written in audit-ready language, lifetime updates included.

Three sample documents are downloadable from the NIS-2 Total Kit page — including a risk assessment methodology and an access control policy, two of the foundational artefacts for Measures 1 and 9.

---

Each Article 21 measure requires specific policies, procedures and templates. Get them all in one kit. 77 audit-ready documents covering all ten measures across eight bundles. Lifetime updates included. See the NIS-2 Total Kit →

---

Sources and further reading

• Directive (EU) 2022/2555, Article 21 — full text on EUR-Lex: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2555
• Commission Implementing Regulation (EU) 2024/2690 — technical and methodological requirements: https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
• ENISA Technical Implementation Guidance on cybersecurity risk-management measures (June 2025): https://www.enisa.europa.eu/publications/nis2-technical-implementation-guidance
• ISO/IEC 27001:2022 — Information security management systems requirements
• NIST SP 800-63B — Digital identity guidelines: authentication and lifecycle management

Last updated: 25 May 2026.