← All guides
NIS212 min read26 June 2026

NIS2 Risk Assessment: Article 21 Requirements, All 10 Measure Categories, and How to Document It

A complete guide to NIS2 Article 21 cybersecurity risk assessments. Covers entity classification, all 10 mandatory measure categories, management body accountability under Art. 20, and how to document your risk assessment for your national competent authority.

NIS2 Article 21 is the core compliance obligation for Essential and Important Entities under the EU Network and Information Systems Directive 2.0 (Directive (EU) 2022/2555). It requires organisations to implement "appropriate and proportionate technical, operational and organisational measures" based on a risk assessment. Unlike a box-ticking checklist, Art. 21 is proportionality-based — the measures you implement must be calibrated to the risks you face.

This guide covers who NIS2 applies to, what Article 21 requires in each of the 10 mandatory measure categories, and how to document your risk assessment in a way that satisfies national competent authorities and avoids the significant fines NIS2 enables.

Who NIS2 applies to: Essential vs Important Entities

NIS2 applies to two tiers of entities:

Entity TypeSectorSize thresholdFine exposure
Essential Entity (EE)Annex I (energy, transport, banking, health, water, digital infrastructure, ICT services, public administration, space)>250 employees or >€50M turnover (or member state designation)€10M or 2% global turnover (Art. 34(3)(a))
Important Entity (IE)Annex II (postal, waste, chemicals, food, manufacturing, digital providers, research) + Annex I below EE threshold>50 employees or >€10M turnover€7M or 1.4% global turnover (Art. 34(3)(b))

For digital infrastructure and ICT service management sectors (including MSPs, MSSPs, cloud providers, DNS operators), the size threshold may be waived — all operators in these sectors may be in scope regardless of size.

Article 20: Management body accountability

Before covering Art. 21, Art. 20 needs to be understood. Management bodies (boards, executive teams) of Essential and Important Entities must:

  • Approve the cybersecurity risk management measures taken under Art. 21
  • Oversee their implementation
  • Be liable for infringements by the entity (Art. 20(2)) — member states are implementing personal liability provisions
  • Undergo cybersecurity training (Art. 20(2)) sufficient to identify risks and assess risk management practice

The practical implication: your Art. 21 risk assessment must be presented to and approved by the management body (not just the CISO). Minutes of that approval should be retained. Management body members cannot delegate away their personal accountability for NIS2 compliance.

Article 21: The 10 mandatory measure categories explained

Art. 21(2)(a) — Policies on risk analysis and information system security

This is the foundation. Art. 21(2)(a) requires a documented process for identifying, assessing, and treating cybersecurity risks, and documented information security policies approved by the management body.

What this means in practice:

  • A cybersecurity risk assessment methodology (ISO 27005, NIST SP 800-30, or equivalent)
  • A current risk register covering network and information systems in scope
  • An Information Security Policy (and subsidiary policies) approved by the board
  • Regular review of the risk assessment (at minimum annually, and when significant changes occur)

The risk assessment feeds all other Art. 21(2) categories — the measures you implement in each category must be proportionate to the risks identified.

Art. 21(2)(b) — Incident handling

Incident handling capability covering detection, classification, containment, eradication, recovery, and post-incident review. NIS2 is prescriptive about the notification dimension:

  • Art. 23(4)(a) — 24-hour early warning: Notify national CSIRT or competent authority within 24 hours of becoming aware of a significant incident
  • Art. 23(4)(b) — 72-hour incident notification: Full notification including initial assessment, severity, indicators of compromise
  • Art. 23(4)(c) — 1-month final report: Detailed description, root cause, cross-border impact, measures taken

"Significant incident" is defined in Art. 23(3): an incident causing or capable of causing severe operational disruption, financial loss, or significant damage to other persons. In practice, any breach affecting availability of essential services or impacting personal data at significant scale triggers the notification obligation.

Art. 21(2)(c) — Business continuity

Business continuity, backup management, disaster recovery, and crisis management. For Essential Entities in critical sectors (energy, health, transport, water), this means:

  • Documented BCP/DRP tested at planned intervals (not just written — tested)
  • Backup strategy with offsite/cloud backups isolated from production (ransomware resilience)
  • Defined RTO/RPO targets appropriate to the criticality of services
  • Crisis management process with defined roles for major cyber incidents

Art. 21(2)(d) — Supply chain security

One of the most significant additions in NIS2. Entities must address security risks in their ICT supply chains — this was a direct response to SolarWinds-type attacks. Requirements:

  • Identify direct ICT suppliers and service providers with access to your systems/data
  • Assess their cybersecurity posture (questionnaire, certifications, audit rights)
  • Include security requirements in supplier contracts (security standards, incident notification, audit rights)
  • Monitor critical suppliers on an ongoing basis

Note that NIS2 explicitly contemplates ENISA assessments of specific ICT products and services (Art. 24) — if your sector uses specific ICT products identified as high-risk, you may need to replace or mitigate them.

Art. 21(2)(e) — Security in acquisition, development, and maintenance

Security must be embedded in the procurement and development lifecycle:

  • Vulnerability disclosure and patch management (CVEs addressed within risk-appropriate timeframes)
  • Secure development practices (SAST/DAST, code review, OWASP guidance)
  • Change management with security review for significant changes
  • Security requirements in procurement specifications

Art. 21(2)(f) — Policies and procedures to assess effectiveness

You must have a way to verify that your cybersecurity measures are actually working. This includes:

  • Penetration testing — independent testing of critical systems at defined intervals
  • Security audits and assessments
  • Security metrics and KPIs reported to management
  • Monitoring of control effectiveness over time

Art. 21(2)(g) — Cyber hygiene and cybersecurity training

All personnel must receive basic cybersecurity training. For management bodies: Art. 20(2) requires training sufficient to identify risks and assess management practices. For technical staff: role-appropriate training on current threats and defensive techniques.

Art. 21(2)(h) — Cryptography and encryption

Use of cryptography and, where appropriate, encryption. This means:

  • Encryption of sensitive data at rest (AES-256 or equivalent)
  • Encryption in transit (TLS 1.2+; TLS 1.3 recommended)
  • Documented key management procedures
  • No use of deprecated algorithms (MD5, SHA-1, DES, RC4)

Art. 21(2)(i) — Human resources security, access control, and asset management

Three interconnected requirements:

  • HR security: Background checks for personnel in sensitive roles; joiners/movers/leavers access process; termination procedures
  • Access control: Least privilege, RBAC, privileged access management, regular access reviews
  • Asset management: Inventory of hardware, software, cloud services, and data assets within NIS2 scope

Art. 21(2)(j) — Multi-factor authentication and secure communications

Art. 21(2)(j) explicitly names MFA as a required measure — one of the most direct technology mandates in NIS2. Specifically:

  • MFA or continuous authentication for all access to critical systems, cloud infrastructure, and administrative interfaces
  • Secure voice, video, and text communications within the organisation
  • Secure emergency communications during incidents

Documenting the NIS2 risk assessment

The risk assessment document should cover:

  1. Scope: which network and information systems are in scope (tied to entity sector/activity)
  2. Methodology: how risks are identified, scored, and ranked
  3. Risk register: per risk — threat, likelihood, impact, risk level, treatment, owner, target date
  4. Per Art. 21(2) category: gaps identified, current state, required measures, implementation status
  5. Treatment roadmap: phased implementation plan with owners and dates
  6. Management approval: documented approval by management body (Art. 20)

National competent authorities are beginning to request risk assessment documentation during supervisory activities. Entities should treat this as a living document reviewed at least annually and updated following significant changes or incidents.

NIS2 vs ISO 27001: can they be aligned?

NIS2 Art. 21(2)ISO 27001:2022 equivalentKey difference
(a) Risk analysis + IS policiesClauses 6.1.2, 6.1.3, 5.2NIS2 links risk to sector-specific criticality
(b) Incident handlingA.5.24–A.5.28NIS2 has mandatory 24h/72h regulatory notification
(c) Business continuityA.5.29–A.5.30, A.8.13NIS2 emphasises crisis management for essential services
(d) Supply chain securityA.5.19–A.5.22NIS2 more prescriptive on ICT supply chain; ENISA assessments
(e) Acquisition + developmentA.8.25–A.8.32, A.8.8NIS2 links to EU product security (Cyber Resilience Act)
(f) Effectiveness assessmentClauses 9.1, 9.2, 9.3NIS2 includes pen testing explicitly
(g) Cyber hygiene + trainingA.6.3, Clause 7.2NIS2 Art. 20(2) extends to management body explicitly
(h) CryptographyA.8.24Closely aligned
(i) HR security + access control + asset mgmtA.5.9–A.5.16, A.6.1–A.6.5, A.8.2Closely aligned
(j) MFA + secure communicationsA.8.5, A.8.20NIS2 explicitly names MFA; ISO 27001 leaves method open

ISO 27001-certified organisations have a significant head start on NIS2 compliance. The main gaps are typically: mandatory 24h/72h incident notification (ISO 27001 doesn't prescribe timeframes); management body accountability under Art. 20; supply chain specificity under Art. 21(2)(d); and MFA as an explicit requirement under Art. 21(2)(j).

Use the NIS2 Risk Assessment Generator to build an Art. 21 risk register covering all 10 measure categories. Pair it with the NIS2 Compliance Checklist Generator for a complete NIS2 compliance package, and the Incident Response Plan Generator for the Art. 21(2)(b) incident handling requirement.