NIS2 Requirements: The 10 Cybersecurity Risk Management Measures Explained

Last verified: March 2026. This guide covers Article 21 of Directive (EU) 2022/2555 (NIS2) and Commission Implementing Regulation (EU) 2024/2690 (CIR), which sets binding technical requirements for important and essential entities.

If you have determined that your organisation falls within NIS2’s scope, the next question is straightforward: what exactly do you have to do?

Article 21 of Directive (EU) 2022/2555 sets out ten mandatory cybersecurity risk management measures. Every in-scope entity — whether you are an energy company, a cloud provider, a mid-sized manufacturer, or a digital marketplace — must implement all ten. The only variable is how proportionate your implementation needs to be, based on your size, risk exposure, and the likelihood and severity of incidents.

This guide walks through every measure in plain English: what the law says, how Commission Implementing Regulation 2024/2690 (CIR) translates it into technical requirements, which documents you need to evidence compliance, and practical tips for organisations with limited security resources.

Article 21 at a Glance: The Legal Framework

Article 21(1) of NIS2 establishes the foundational principle: “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.”

Two principles shape how this works in practice:

• Proportionality — The scale and sophistication of your implementation should reflect your size, risk exposure, and the potential societal and economic impact of incidents. A 200-person manufacturing company and a pan-European cloud provider both have the same ten obligations, but the depth of documentation and control sophistication required differs significantly.
• All-hazards approach — You must address threats from any source: cyberattacks, hardware failures, natural disasters, insider threats, and supply chain compromises alike. NIS2 is not just about hacking — it covers anything that could disrupt your services or compromise the confidentiality and integrity of the information you handle.

For DNS providers, TLD registries, cloud computing services, data centres, CDN providers, managed service providers (MSPs), managed security service providers (MSSPs), online marketplaces, online search engines, and social networking platforms, Commission Implementing Regulation 2024/2690 goes further. Published in December 2024 and applicable from 18 January 2025, the CIR sets precise, binding technical and methodological requirements via its Annex — the closest thing NIS2 has to an ISO standard in regulatory form.

The 10 Article 21 Measures at a Glance

#	Measure	Article 21(2)	CIR Annex
1	Risk analysis and information security policy	(a)	1.1–1.2, 2.1
2	Incident handling	(b)	3.1–3.6
3	Business continuity and crisis management	(c)	4.1–4.3
4	Supply chain security	(d)	5.1–5.2
5	Security in acquisition, development, and maintenance	(e)	6.1–6.2
6	Assessing effectiveness of cybersecurity measures	(f)	7
7	Cybersecurity hygiene practices and training	(g)	8, 10
8	Cryptography and encryption	(h)	9
9	Human resources security, access control, and asset management	(i)	11, 12
10	Multi-factor authentication and secure communications	(j)	11.5–11.7

Measure 1: Risk Analysis and Information Security Policy

Article 21(2)(a) requires entities to maintain a risk analysis and information system security policy. This is the foundation on which all other measures rest — if you cannot demonstrate that you have systematically identified your risks, none of your controls can be shown to be proportionate to those risks.

What the Law Requires

You need two things: a documented methodology for assessing cybersecurity risks, and a top-level information security policy approved by senior management. The policy must define the scope of your information security management system (ISMS), assign responsibilities to named roles, and commit the organisation to continual improvement.

Under CIR Annex sections 1.1 and 1.2, entities must establish and document a risk assessment methodology that defines criteria for evaluating risk — likelihood scales, impact scales, and risk acceptance thresholds — and identifies all network and information systems within scope. Section 2.1 requires that the information security policy be formally approved at board or equivalent level. This is a deliberate design choice by the Commission: board approval creates direct management accountability and establishes the personal liability exposure that Article 20 describes.

ENISA’s Technical Implementation Guidance (sections 1.1, 1.2, and 2.1.1) recommends adopting a recognised framework such as ISO 27005, NIST SP 800-30, or OCTAVE as the basis for your methodology, and prescribes that the risk assessment be reviewed at least annually and after significant changes to the operational environment or threat landscape.

Documents You Need

• Information Security Policy — board-approved, signed, dated, defining ISMS scope, security objectives, and assigned responsibilities
• Risk Assessment Methodology — documented criteria for likelihood, impact, risk scoring scales, and risk acceptance thresholds
• Risk Register — live inventory of identified threats, assigned likelihood and impact scores, treatment decisions, and residual risk status

SME tip: A proportionate risk assessment for a 100-person entity does not require a dedicated GRC platform. A structured spreadsheet risk register, combined with a two-page methodology statement and a board-approved policy, satisfies Article 21(2)(a) provided it is reviewed annually and demonstrably used to drive control decisions. See our Risk Assessment Methodology and Risk Register templates.

Measure 2: Incident Handling

Article 21(2)(b) requires entities to have policies and procedures for handling security incidents. This is not just about responding to incidents when they happen — it is about having pre-defined workflows, escalation paths, and notification processes that can be activated immediately under time pressure.

What the Law Requires

You must be able to detect, classify, respond to, and recover from incidents. Critically, you must have operational capability to meet NIS2’s incident notification deadlines: a 24-hour early warning to your national CSIRT or competent authority, a 72-hour incident notification with a preliminary assessment, and a final report within one month of becoming aware of the incident.

CIR Annex section 3 is the most detailed in the entire regulation. It covers six sub-areas:

• 3.1 — Incident detection capabilities: centralised log management, monitoring tooling (SIEM or equivalent), and alert thresholds for significant events
• 3.2 — Incident classification criteria: documented thresholds for what constitutes a “significant incident” under Article 23(3), including criteria for number of affected users, financial damage estimates, service disruption duration, and cross-border impact
• 3.3 — Incident response procedures: documented playbooks covering containment, eradication, evidence preservation, and recovery sequencing
• 3.4 — Internal escalation and communication: who is notified in what sequence, within what timeframe, and through which channels during an active incident
• 3.5 — External notification obligations: procedures for notifying the CSIRT, competent authority, and — where Article 23(4) applies — affected users and downstream service recipients
• 3.6 — Post-incident review and lessons learned: documented root cause analysis and control improvement recommendations, completed within the one-month final report window

Documents You Need

• Incident Handling Policy — defines scope, incident classification criteria, roles and responsibilities, escalation path, and retention requirements for incident records
• Incident Log — a running record of all security events, their classification, response actions taken, and resolution status
• Notification Forms — pre-structured templates for the 24-hour early warning, 72-hour notification, and final report, aligned with ENISA’s reporting format guidance

Key risk: The 24-hour early warning window catches most organisations unprepared. Your incident detection capability — even basic centralised log collection and alerting — must be operational before an incident occurs, not assembled in response to one. Our incident notification forms template set includes all three regulatory reporting forms with completion guidance.

Measure 3: Business Continuity and Crisis Management

Article 21(2)(c) covers business continuity, backup management, disaster recovery, and crisis management. The goal is to ensure that essential services can be restored following a disruptive event, and that your organisation knows in advance how to manage a major incident that escalates beyond normal operational capacity.

What the Law Requires

You need a documented understanding of which systems and services are critical — a Business Impact Analysis — a strategy for maintaining or restoring them under defined recovery time and recovery point objectives, an actionable Business Continuity Plan, and a Crisis Management Plan for scenarios that exceed normal incident response resources.

CIR Annex section 4 maps to these requirements:

• 4.1 — Business Impact Analysis: identifying critical functions and the systems that support them, mapping internal and external dependencies, defining maximum tolerable downtime for each critical service, and quantifying the financial and operational impact of unavailability
• 4.2 — Business continuity strategy and plans: recovery time objectives (RTO) and recovery point objectives (RPO) for each critical system, backup architecture requirements (the 3-2-1 rule — three copies, two media types, one offsite — as the minimum), and alternative processing or cloud failover arrangements
• 4.3 — Crisis management plans: command and control structure during a major incident, internal and external communications protocols, stakeholder and media management procedures, and coordination mechanisms with national authorities under Article 23

Documents You Need

• Business Impact Analysis (BIA) — critical services inventory, dependency mapping, RTO and RPO targets per service, and impact quantification
• Business Continuity Strategy — backup architecture decisions, redundancy options, and cloud failover or alternative site arrangements
• Business Continuity Plan (BCP) — step-by-step recovery procedures for priority failure scenarios
• Crisis Management Plan — command hierarchy, communications tree, authority notification procedures, and escalation triggers

Testing requirement: Plans that are never tested are not credible evidence of compliance. Build a BC testing programme — at minimum, a tabletop exercise annually and a technical backup restore test quarterly. Document the results and update plans based on findings. Evidence of testing is one of the first things a supervisory authority will ask for.

Measure 4: Supply Chain Security

Article 21(2)(d) addresses supply chain security, including the security-related aspects of the relationships between each entity and its direct suppliers or service providers. This is one of the most operationally complex measures because it extends NIS2’s requirements beyond your own perimeter and into your entire vendor ecosystem.

What the Law Requires

You must assess the cybersecurity posture of your critical suppliers, include binding security requirements in supplier contracts, and monitor supplier security on an ongoing basis. The focus is on ICT product and service providers whose compromise could cascade into your own services — software vendors, cloud platforms, managed service providers, and IT hardware suppliers are the priority categories.

CIR Annex section 5 specifies:

• 5.1 — Supplier classification and assessment: a documented methodology for categorising suppliers by criticality and risk, including a pre-onboarding security assessment for critical and important-tier suppliers covering their security policies, incident response capability, data access controls, and subcontractor management
• 5.2 — Contractual security requirements: minimum security clauses covering data protection obligations, incident notification timelines to your organisation, right-to-audit provisions, security certification requirements where proportionate, and responsibilities for patch management and vulnerability disclosure

Documents You Need

• Supplier Security Policy — tiering methodology, assessment requirements per tier, and minimum security expectations by supplier category
• Supplier Security Clauses — contractual annexe covering NIS2-relevant obligations including incident notification to your organisation, right to audit, access control requirements, and data handling standards
• Supplier Directory — a register of all in-scope ICT suppliers, their criticality tier, last assessment date, contract clause status, and security certifications held

Practical reality: You cannot conduct full security audits of every supplier. Tier your suppliers into critical, important, and standard categories, and apply proportionate due diligence accordingly. A security questionnaire assessment is sufficient for most important-tier suppliers; critical-tier suppliers may warrant independent audit verification or mandatory certification (e.g., ISO 27001). See our supply chain security guide for a worked tiering methodology and questionnaire template.

Measure 5: Security in Acquisition, Development, and Maintenance

Article 21(2)(e) requires entities to address security in the acquisition, development, and maintenance of network and information systems, including vulnerability handling and disclosure. This applies whether you buy commercial off-the-shelf software, commission bespoke development, or build capabilities in-house.

What the Law Requires

Security must be embedded in how you select, procure, develop, and maintain ICT systems — not added retrospectively. For development organisations, this means integrating security requirements into the software development lifecycle (SDLC), including secure coding practices, vulnerability scanning, and change management controls. For organisations that primarily buy and operate commercial systems, the focus falls on procurement security requirements and disciplined patch management.

CIR Annex section 6 covers two dimensions:

• 6.1 — Security in ICT product and service acquisition: minimum security requirements in procurement specifications, evaluation of vendor security practices during supplier selection, patch management SLA requirements in contracts, and explicit prohibitions on procuring or retaining unsupported (end-of-life) software or hardware
• 6.2 — Security in development and testing: secure development principles (OWASP Top 10 as an appropriate baseline), static and dynamic application security testing (SAST/DAST) for security-relevant applications, enforced segregation of development, testing, and production environments, and a formal change management process that includes security impact assessment for significant system changes

Documents You Need

• ICT Acquisition and Development Security Policy — procurement security requirements, SDLC security controls, change management process with security gates, and patch management obligations and SLAs
• Security Requirements Appendix — a template contractual annexe for ICT procurement specifying minimum security standards: patch response SLAs, vulnerability disclosure notification obligations, and secure configuration baseline requirements

Measure 6: Assessing Effectiveness of Cybersecurity Risk Management

Article 21(2)(f) requires entities to maintain policies and procedures to assess the effectiveness of cybersecurity risk management measures. This closes the Plan-Do-Check-Act cycle: you must not only implement controls but demonstrate that you are measuring whether they actually work.

What the Law Requires

You need a defined measurement programme — Key Performance Indicators (KPIs) and Key Risk Indicators (KRIs) that give management genuine visibility into your security posture. This connects directly to Article 20’s board oversight requirement: boards cannot discharge their NIS2 governance responsibility without reliable, regular security metrics.

CIR Annex section 7 requires entities to:

• Define measurable criteria for evaluating the effectiveness of each implemented control category
• Conduct periodic reviews of the entire risk management programme — at minimum annually, and after significant incidents or material operational changes
• Produce documented assessment reports for management review, including trend analysis and recommended remediation actions
• Incorporate audit results, penetration testing findings, vulnerability assessment outcomes, and BC exercise results into the periodic effectiveness review

Documents You Need

• Measurement Methodology — defines which KPIs and KRIs are tracked, measurement frequency, data sources, responsible owners, and reporting format
• Measurement Report — periodic management summary of security posture against defined metrics, trend analysis, and recommended improvement actions

Practical starting point: If you are building your measurement programme from scratch, begin with five to eight core metrics: patch compliance rate, mean time to detect (MTTD), mean time to respond (MTTR), phishing simulation failure rate, critical vulnerability age, backup restore test success rate, and access review completion rate. These provide an immediate picture of operational security health without requiring a dedicated metrics platform.

Measure 7: Cybersecurity Hygiene Practices and Training

Article 21(2)(g) requires entities to promote cybersecurity hygiene practices and training — at the organisational level (baseline configurations and operational discipline) and at the individual level (employee awareness and role-specific technical training).

What the Law Requires

This measure operates at two distinct levels. Article 20(2) separately mandates that management bodies — your board, executive team, or equivalent — must receive cybersecurity training sufficient to identify risks and assess security management practices. Article 21(2)(g) then extends the training obligation across all staff. The distinction matters: management training is a governance and liability control, while staff training is an operational risk control. Both are required and both must be evidenced.

CIR Annex sections 8 and 10 cover:

• Section 8 — Cyber hygiene: defined baseline configurations for endpoints and servers, hardening standards aligned to CIS Benchmarks or equivalent, endpoint protection requirements, software inventory management to identify and remediate unsupported software, and clear desk and screen lock policies
• Section 10 — Training and awareness: a role-based training programme with at minimum general security awareness for all staff annually, technical security training for IT and security personnel covering the current threat landscape and defensive techniques, and management-level briefings covering NIS2 governance obligations, personal liability under Article 20, and incident response decision-making responsibilities

Documents You Need

• Cybersecurity Training Plan — annual training schedule by role, content summaries, delivery method (e-learning, instructor-led, phishing simulations), and completion tracking records
• HR Security Policy — background verification standards for security-sensitive positions, security obligations in employment contracts and acceptable use policies, and off-boarding procedures covering access revocation timelines and device return

Management liability alert: If a significant breach occurs and you cannot evidence that your management body received cybersecurity training, Article 20 personal liability applies with greater force. Annual board training, with documented attendance, is one of the lowest-cost risk mitigations available. Retain training records for the duration of supervisory scrutiny periods.

Measure 8: Cryptography and Encryption

Article 21(2)(h) requires policies on the use of cryptography and, where appropriate, encryption. This is a technical control with direct documentation requirements — you need both a policy specifying your approved cryptographic standards and demonstrable evidence that those standards are implemented across your systems.

What the Law Requires

You must define which encryption standards are approved within your organisation, how encryption keys are managed throughout their lifecycle, and where encryption is mandatory. The “where appropriate” qualifier does not mean optional. ENISA guidance makes clear that encryption of personal data and sensitive business data at rest and in transit is expected as a baseline for all NIS2 entities regardless of size or sector.

CIR Annex section 9 requires:

• A documented cryptography policy specifying approved algorithms: AES-256 for symmetric encryption, RSA-2048 or higher for asymmetric encryption, ECDSA P-256 or P-384 for digital signatures, and TLS 1.2 minimum (TLS 1.3 strongly preferred) for transport-layer security
• Key management procedures covering key generation using approved entropy sources, secure storage (hardware security modules or equivalent for high-value keys), rotation schedules, escrow arrangements where required for operational continuity, and cryptographically secure destruction at end of life
• Mandatory encryption of sensitive data at rest — databases containing personal data, backup media, portable storage devices, and laptops — and in transit via TLS for all web services and API communications and VPN or equivalent for remote access sessions
• Formal prohibition and technical disablement of deprecated algorithms and protocols: MD5, SHA-1, DES, 3DES, RC4, TLS 1.0, TLS 1.1, and SSLv3

Documents You Need

• Encryption and Cryptography Policy — approved algorithms reference table, key management lifecycle procedures, minimum encryption standards by data classification level, prohibited technologies list, and exception management process with compensating controls

See our NIS2 encryption requirements guide for a full breakdown of approved algorithms and implementation guidance by use case, including a reference table of compliant cipher suites for TLS configurations.

Measure 9: Human Resources Security, Access Control, and Asset Management

Article 21(2)(i) groups three operationally distinct but conceptually related areas: human resources security, access control policies, and asset management. Together they form the backbone of your identity and access management programme and your organisational asset visibility.

What the Law Requires

For HR security: manage the full employee security lifecycle from pre-employment vetting through to access revocation on departure. For access control: implement least-privilege principles, conduct regular access rights reviews, and maintain privileged access management (PAM) controls for administrative accounts. For asset management: maintain a current inventory of all network and information system assets — the foundation for risk assessment accuracy and incident response capability.

CIR Annex sections 11 and 12 address these in detail:

• Section 11 (Access Control) — Role-based access control (RBAC) framework defining access by job function; user account lifecycle management covering joiners (provisioning within defined SLAs), movers (access adjustment on role change), and leavers (revocation within 24 hours of departure); privileged access management using dedicated privileged accounts separate from standard user accounts; periodic access reviews — at least annually for all users, at least quarterly for privileged accounts; and session management controls including automatic lockout after inactivity
• Section 12 (Asset Management) — Comprehensive asset inventory covering hardware (servers, endpoints, network devices, OT equipment), software (licensed applications and open source components), cloud services (IaaS, PaaS, SaaS subscriptions), and data assets; asset classification by criticality and data sensitivity (public, internal, confidential, restricted); and asset lifecycle management from procurement approval through secure decommissioning and verified data destruction

Documents You Need

• Access Control Policy — RBAC framework, account provisioning and de-provisioning procedures with SLAs, PAM requirements for administrative accounts, and access review schedule
• Authentication Policy — password complexity and rotation standards, session management requirements, and privileged account controls (this policy also underpins Measure 10)
• Asset Register — live inventory of all in-scope assets with owner, classification level, physical or logical location, and lifecycle status

See our NIS2 access control guide for implementation guidance including a joiner-mover-leaver workflow template and an access review checklist structured for NIS2 supervisory scrutiny.

Measure 10: Multi-Factor Authentication and Secure Communications

Article 21(2)(j) requires the use of multi-factor authentication or continuous authentication solutions, and secured voice, video, and text communications, as well as secured emergency communication systems. This is the most technically specific obligation in Article 21, and the area where many organisations discover their largest gap on first assessment.

What the Law Requires

MFA is not optional for NIS2 entities. The Directive requires it for remote access, privileged administrative access, and — depending on your risk assessment — for all staff accessing systems that process or transmit sensitive data. Continuous authentication (behaviour-based or risk-adaptive authentication) is listed as an alternative or supplement, but most organisations will implement MFA as the primary control and use risk-based mechanisms as an enhancement layer for high-sensitivity scenarios.

CIR Annex sections 11.5, 11.6, and 11.7 specify:

• 11.5 — MFA requirements: mandatory for all remote access sessions (VPN, RDP, SSH), all privileged accounts and cloud management console access; approved authentication factors include TOTP (RFC 6238), hardware security keys (FIDO2/WebAuthn), and authenticator application push notifications; SMS-only OTP is explicitly discouraged for high-privilege accounts due to SIM-swapping and SS7 vulnerabilities; phishing-resistant MFA (FIDO2/WebAuthn) is required for the most sensitive access scenarios
• 11.6 — Secure communications: encrypted channels for all voice and text communications carrying confidential or sensitive information; prohibition of unencrypted management protocols: plain HTTP, FTP, Telnet, SNMP v1/v2c must be replaced by HTTPS, SFTP or SCP, SSH, and SNMPv3 respectively
• 11.7 — Emergency communication systems: a documented out-of-band communication method pre-configured for use during major incidents when primary systems are unavailable or compromised — for example, an alternative email domain, an encrypted messaging platform (FIDO2-secured), or a physical emergency contact list with agreed check-in protocols

Documents You Need

• Authentication Policy — MFA requirements by account type and access scenario, approved authentication methods, phishing-resistant MFA mandate for high-privilege contexts, and exception management process with compensating controls
• Secure Communications Policy — approved communication tools by data classification level, prohibited unencrypted protocols, requirements for external communications involving sensitive data, and emergency communication procedures including out-of-band contact arrangements

See our NIS2 MFA requirements guide for a full breakdown of compliant MFA implementations by system type, including guidance on deploying phishing-resistant FIDO2/WebAuthn for high-privilege access scenarios.

How to Prioritise Your NIS2 Implementation

Attempting to implement all ten measures simultaneously is a common programme management mistake — it produces shallow coverage everywhere rather than deep, demonstrable compliance anywhere. A risk-based sequencing approach is both more operationally effective and more defensible to a supervisory authority if you are assessed before your programme is complete.

Risk-Based Prioritisation Matrix

Priority	Measure	Rationale	Target Timeframe
Immediate	1 — Risk Analysis & ISMS Policy	Foundation for all other measures; required to demonstrate proportionality of any control decision	0–4 weeks
Immediate	2 — Incident Handling	Legal 24-hour notification obligation begins the moment an incident occurs; must be operational before that	0–6 weeks
Immediate	10 — MFA	Highest-impact, lowest-cost control; directly addresses credential compromise, the most common attack vector	0–3 weeks
Short-term	8 — Cryptography	Many organisations have undocumented encryption gaps; straightforward to formalise and technically enforce	4–8 weeks
Short-term	9 — Access Control & Assets	Access reviews and asset inventory underpin risk assessment accuracy and incident response effectiveness	4–10 weeks
Short-term	7 — Training	Management personal liability applies from day one; training records are immediately useful in supervision	2–8 weeks
Medium-term	3 — Business Continuity	BIA and plan development require extensive stakeholder input but follow a predictable project structure	8–16 weeks
Medium-term	4 — Supply Chain	Supplier classification and contract updates require legal review and supplier cooperation timelines	8–20 weeks
Medium-term	5 — Acquisition & Development	SDLC security integration requires IT team alignment and phased rollout across existing workflows	8–20 weeks
Ongoing	6 — Effectiveness Assessment	Measurement programme matures over time; establish baseline metrics in parallel with all other measures	Parallel, ongoing

This sequence prioritises the measures where enforcement risk is highest — incident handling creates a hard legal deadline from the moment an incident occurs — and where technical controls deliver the most immediate risk reduction: MFA eliminates the most common credential-based attack pathway; encryption closes data exposure gaps that can trigger GDPR notifications in parallel with NIS2 proceedings.

Resource-intensive measures that require extensive cross-functional coordination — supply chain security, business continuity planning — are deferred to a second wave without leaving critical detection, response, or notification gaps.

Use our NIS2 compliance checklist to track progress across all ten measures and build your evidence library as you go. For the full document set covering every policy and template referenced in this guide, see our NIS2 document template library.

Frequently Asked Questions

Are all 10 Article 21 measures mandatory for every NIS2 entity?

Yes. All ten measures listed in Article 21(2) are mandatory for every in-scope entity. The proportionality principle governs how extensively each measure is implemented — not whether it is implemented. An entity that has skipped any of the ten measures is not NIS2 compliant, regardless of how thoroughly it has addressed the others. During supervisory assessment, the absence of any required measure will be recorded as a compliance gap.

Does the CIR 2024/2690 apply to my organisation?

The CIR directly binds a specific subset of NIS2 entities: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers (MSPs), managed security service providers (MSSPs), online marketplace operators, online search engine operators, social networking service providers, and trust service providers. Outside these categories, the CIR’s Annex is not directly binding — but it represents the most authoritative available interpretation of “appropriate and proportionate” under Article 21, and supervisory authorities across EU member states are using it as a reference benchmark when assessing other entity types.

What is the difference between Article 21 and Article 23?

Article 21 covers the ongoing preventative security controls that constitute your cybersecurity risk management programme. Article 23 covers incident notification — the reactive obligation to report significant incidents to your national CSIRT or competent authority within defined timeframes: 24 hours for an early warning, 72 hours for a preliminary incident notification, and one month for a final report. Measure 2 (incident handling) is the operational bridge between the two: the response procedures and notification workflows built under Article 21 are what enable you to meet the Article 23 deadlines in practice.

Does NIS2 require ISO 27001 certification?

No. ISO 27001 certification is not mandated by NIS2. However, certification provides strong third-party evidence of compliance with several Article 21 measures — particularly Measures 1, 6, 7, 9, and 10. Some EU member states and competent authorities have indicated they will accept current ISO 27001 certification as partial evidence of NIS2 compliance. See our NIS2 vs ISO 27001 comparison for a detailed mapping table showing where the frameworks align and where NIS2 imposes requirements that ISO 27001 does not fully address.

How does the proportionality principle work in practice?

Proportionality means that a 60-person important entity in a low-risk sector does not need the same depth of documentation or technical control sophistication as a large essential entity operating critical national infrastructure. Supervisory authorities assess proportionality by examining: entity size and resource availability, sensitivity of data processed, potential cross-border impact of incidents, and the degree to which other organisations depend on the entity’s services. The risk assessment (Measure 1) is where proportionality is formally justified — a documented assessment that identifies low residual risks and applies appropriately lighter controls is defensible. Claiming proportionality without any documented risk assessment is not.

How many documents do I need to comply with all 10 measures?

A fully documented NIS2 programme requires approximately 15–20 core policy documents and operational registers. The essential set includes: Information Security Policy, Risk Assessment Methodology, Risk Register, Incident Handling Policy, Incident Log, three Notification Form templates (24h/72h/1-month), Business Impact Analysis, Business Continuity Strategy, Business Continuity Plan, Crisis Management Plan, Supplier Security Policy, Supplier Security Clauses, Supplier Directory, ICT Acquisition Policy, Security Requirements Appendix, Measurement Methodology, Measurement Report template, Cybersecurity Training Plan, HR Security Policy, Encryption Policy, Access Control Policy, Authentication Policy, Asset Register, and Secure Communications Policy. Our template library covers every document in this set, pre-structured for NIS2 compliance.

Sources

• Directive (EU) 2022/2555 of the European Parliament and of the Council (NIS2 Directive), Articles 20, 21, 23. EUR-Lex: eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022L2555
• Commission Implementing Regulation (EU) 2024/2690 laying down technical and methodological requirements (CIR). EUR-Lex: eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R2690
• ENISA Technical Implementation Guidance for NIS2 Security Measures (June 2025). European Union Agency for Cybersecurity: enisa.europa.eu/publications/technical-implementation-guidance-nis2