NIS2 Article 21 requirements: the ten measures, the controls behind them and the evidence for each

What NIS2 Article 21 requires

Article 21 of the NIS2 Directive, Directive (EU) 2022/2555, requires Member States to ensure that essential and important entities take “appropriate and proportionate technical, operational and organisational measures”. The measures serve to manage the risks to the entities’ network and information systems and to prevent or minimise the impact of incidents. Paragraph 2 lists ten measures, points (a) to (j), that these “shall include at least”, based on “an all-hazards approach” that also protects “the physical environment of those systems”. Paragraph 1 asks for security appropriate to the risks, given the state of the art, relevant standards and the cost of implementation. Proportionality is judged by the entity’s exposure to risks, its size and the likelihood and severity of incidents. Under paragraph 4, an entity that finds it does not comply takes corrective measures “without undue delay”.

Member States had until 17 October 2024 to transpose the directive into national law (Article 41). The directive’s obligations therefore reach a company through the national act that transposes it. On 20 January 2026 the Commission proposed targeted amendments to the directive (COM(2026) 13) that, in its words, “will simplify compliance”. The amendments change no obligation until they are adopted. Whether a company is an essential entity, an important entity or neither depends on its sector under Annexes I and II and on its size. For some types, the classification also depends on criteria that apply regardless of size (Articles 2 and 3). That classification is a legal assessment for the company’s legal department.

Implementing Regulation 2024/2690 and the ENISA guidance

Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 sets out the technical and methodological requirements of the ten measures in a 13-section Annex. It binds only the “relevant entities” of its Article 1. These are DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed and managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers. Where a relevant entity does not apply a requirement qualified “where appropriate”, “where applicable” or “to the extent feasible”, Article 2(2) asks it to document why “in a comprehensible manner”. Any company can keep the same record.

ENISA’s Technical Implementation Guidance (version 1.0, published on 26 June 2025) follows the Annex requirement by requirement. The guidance says that, “beyond the relevant entities to the regulation”, it may give indications “which may be considered useful by other public or private bodies for improving their cybersecurity”. Other essential and important entities can therefore use the Annex as a reference, although the Regulation does not bind them. Each requirement comes with guidance, tips and indicative examples of evidence. Relevant entities “may choose alternative methods to fulfil a requirement or use different evidence to demonstrate compliance”. A separate Excel table maps every requirement to ISO/IEC 27001:2022, NIST Cybersecurity Framework 2.0 and other standards.

A NIS2 checklist: measures, controls and evidence

Each row maps a point of Article 21(2) to its Annex sections, technical controls that implement it in a company of 200 to 2,000 staff and the evidence an auditor can ask to see.

Directive (EU) 2022/2555, Article 21(2); Implementing Regulation (EU) 2024/2690, Annex and its table of contents (eur-lex.europa.eu); ENISA Technical Implementation Guidance v1.0 (26 June 2025). Rows (a) to (c) shorten ENISA’s examples of evidence for Annex sections 1 to 4; the other evidence and all controls are our summary.

Our cyber resilience service delivers a NIS2 compliance map with the gaps listed and a plan to close them. Tell us which of the ten measures you can evidence today and which you cannot.

Policies, risk analysis and effectiveness: points (a) and (f)

Section 1 of the Annex turns point (a) into a security policy that states “the date of the formal approval by the management bodies” (point 1.1.1(k)). The policy is reviewed by the management bodies “at least annually” (1.1.2). At least one person reports directly to them on security (1.2.3). Section 2 requires a risk management framework (2.1.1) whose risk identification follows “an all-hazards approach” and covers single points of failure (2.1.2(d)). The section also requires a review of the risk assessment and treatment plan “at planned intervals and at least annually” (2.1.4). ENISA’s examples of evidence include a “Risk register”, a “Documented risk treatment plan” and a “Record of approval of residual risks by management bodies” or by the persons accountable for those risks (2.1.1).

For point (f), section 7 has the entity decide what it measures, how and when, and who evaluates the results (7.2). In technical terms, that means a few metrics read from systems, such as critical vulnerabilities closed within the set time or multi-factor coverage of administrative access. The results go to the management bodies (2.3.3), and each gap becomes a corrective measure under Article 21(4), with an owner and a date.

Incident handling, continuity and suppliers: points (b), (c) and (d)

Section 3 details point (b): an incident handling policy, a simple way for employees, suppliers and customers to report suspicious events (3.3.1) and response procedures tested at planned intervals (3.5.5). Logs cover, where appropriate, authentication events, privileged access and changes to critical configuration and backup files (3.2.3), and are protected from unauthorised access or changes (3.2.5). The reporting deadlines are in our guide to NIS2 incident reporting.

For point (c), section 4 lists a business continuity and disaster recovery plan (4.1), a business impact analysis (4.1.3), integrity checks of backup copies (4.2.3), regular recovery tests (4.2.6) and crisis management (4.3). Among ENISA’s examples of evidence are “Records of regular tests in which data is restored from backups.” Our guide to NIS2 backup and business continuity requirements covers each point. We found no use of the word immutable in the regulation; what immutable backup protects against explains where such a copy helps.

Point (d) maps to section 5: a supply chain security policy, contracts that cover, where appropriate, incident notification, audit rights and vulnerability handling (5.1.4), and a registry of direct suppliers (5.2). Article 21(3) adds that entities consider the vulnerabilities specific to each direct supplier and the overall quality of its products and cybersecurity practices, including secure development. What customers ask their IT suppliers is in our guide to NIS2 supply chain requirements.

Acquisition, development and maintenance: point (e)

Under section 6, patches are applied “within a reasonable time after they become available” and tested first (6.6.1). A patch is skipped only when its disadvantages outweigh the security benefits, with documented reasons (6.6.2). Point 6.10.2 asks entities to “perform, where appropriate, vulnerability scans, and record evidence of the results of the scans, at planned intervals”. The same point also asks them to address “without undue delay” vulnerabilities critical to their operations and to lay down a disclosure procedure. A /.well-known/security.txt file in the RFC 9116 format tells outsiders where to report.

The network architecture is documented (6.7.2(a)), and service providers connect only after an authorisation request and for a set period (6.7.2(h)). The administration network is separate from the operational one (6.8.2(f)). In a VMware estate that means a management network for vCenter, the ESXi hosts and the servers’ management controllers, closed to user subnets.

Cyber hygiene, training and cryptography: points (g) and (h)

Recital 89 of the directive gives examples of basic cyber hygiene: “zero-trust principles, software updates, device configuration, network segmentation, identity and access management or user awareness”. Section 8 calls for an awareness programme “scheduled over time, so that the activities are repeated and cover new employees” (8.1.2(a)). The section also calls for regular security training for staff whose roles need security skills (8.2.1), such as administrators and developers.

For point (h), section 9 requires a cryptography policy that sets the type and strength of cryptographic measures by asset classification. The policy also sets the protocols, algorithms and cipher strength to use, and key management from generation to destruction (9.2). Technically that means TLS on services and management interfaces, encrypted laptops and backups, backup keys stored away from the backup server, and a certificate inventory with expiry alerts.

Access control, assets and MFA: points (i) and (j)

Point (i) draws on sections 10 to 13. They ask for background checks “to the extent feasible” (10.2.1) and procedures for leavers and role changes (10.3). They also ask for access based on “need-to-know, least privilege and separation of duties” (11.2.2(a)) and for “a register of access rights granted” (11.2.2(e)). Access reviews are documented (11.2.3), administrators work from dedicated accounts with separate credentials (11.3.2(b), 11.6.2(f)), and the asset inventory is “complete, accurate, up-to-date and consistent” (12.4.1).

For point (j), point 11.7.1 asks for multiple authentication factors or continuous authentication “where appropriate, in accordance with the classification of the asset to be accessed”. We found no requirement in the Annex that names secured voice, video and text communications or emergency communication systems. Start with remote access, email and the administration interfaces of hypervisors, backup and network devices, with phishing-resistant methods for administrators, as our guide to phishing-resistant MFA explains. Keep a crisis channel that works while the directory service and email are down.

Our cyber resilience service sets up zero-trust access with multi-factor authentication and privileged access management. Describe in the form below how administrators and remote users sign in today and which systems still accept a password alone.

Management approval, supervision and fines

Article 20(1) requires management bodies to approve the risk-management measures and oversee their implementation, and they can be held liable for infringements of Article 21. Under Article 20(2) their members must follow training. Evidence includes minutes recording the approval and, in ENISA’s words, “training records; workshop and seminar attendance; and continuous learning materials”.

Recital 122 describes the supervision of essential entities as “comprehensive ex ante and ex post” and that of important entities as “light, ex post only”. For essential entities, Article 32(2) lets the authorities use inspections, “regular and targeted security audits”, security scans and requests for information and evidence. Authorities act on an important entity ex post, when given evidence, indication or information that it allegedly does not comply (Article 33(1)). Article 33(2) provides targeted audits but not regular ones. The recital adds that important entities should “not be required to systematically document compliance”. Under Article 33(2), the authority can still request “documented cybersecurity policies” and “evidence of implementation of cybersecurity policies”.

Article 34 requires Member States to provide fines for essential entities that infringe Article 21 or 23. The maximum must be at least EUR 10 million or 2 per cent of the total worldwide annual turnover in the preceding financial year of the undertaking to which the entity belongs, whichever is higher. For important entities the figures are EUR 7 million or 1.4 per cent.

General information on EU law as of October 2026, not legal advice for an individual case.

What we do

Under our cyber resilience service, our engineering partner Vixen.UNO audits infrastructure, access, backups and compliance with NIS2 requirements. After the project you have a NIS2 compliance map with the gaps listed and a plan to close them. The compliance map is a technical assessment. The legal opinion on compliance is prepared by your legal department, and we do not issue compliance certificates. Implementation covers zero-trust access, network segmentation, multi-factor authentication, privileged access management, an incident response plan and Veeam-based backup with regular test restores, in agreed maintenance windows with a rollback plan. For your supplier register, our security and compliance page lists the documents we sign.

FAQ