NIS2 Article 21 Decoded: All 10 Security Measures, CIR 2024/2690 Sub-Requirements, and the Audit Evidence Checklist Competent Authorities Examine

Article 21 of Directive (EU) 2022/2555 lists ten categories of cybersecurity measures that every essential and important entity must implement. The list occupies a single page of the directive. The challenge is that “implement appropriate and proportionate measures” provides almost no implementation detail—and national competent authorities are now auditing against a far more granular technical standard than the directive text alone suggests.

Commission Implementing Regulation (EU) 2024/2690 (CIR) translates those ten measures into 13 Annex sections containing over 150 specific sub-requirements. This article maps every Annex section to its Article 21(2) letter, extracts the key sub-requirements for each, identifies where proportionality language appears, and sets out the ten-row evidence checklist that describes what auditors expect to find.

What Article 21 Actually Requires

Article 21(1) establishes the legal standard: entities must take “appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems” [1]. Proportionality considers the state of the art, applicable European and international standards, implementation costs, and—critically—the severity of incidents for users and other services.

Article 21(2) then lists the ten minimum measures using an “all-hazards approach.” The word “minimum” matters: these are a floor, not a ceiling. The ten measures are:

Letter	Measure
(a)	Policies on risk analysis and information system security
(b)	Incident handling
(c)	Business continuity, backup management, disaster recovery, and crisis management
(d)	Supply chain security, including the security of relationships with direct suppliers and 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)	Basic cyber 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
(j)	Multi-factor authentication or continuous authentication solutions, secured voice, video and text communications, and secured emergency communication systems within the entity, where appropriate

Article 21(3) adds a supply chain dimension: entities must evaluate the “overall quality of products and cybersecurity practices of their suppliers and service providers,” taking into account coordinated security risk assessments of critical supply chains conducted under Article 22(1) [1]. Article 21(4) requires prompt corrective action where non-compliance is identified.

Management bodies are personally involved. Under Article 20, management bodies must approve the cybersecurity risk-management measures taken under Article 21 and can be held personally liable for infringements. This is not a delegation-friendly obligation.

CIR 2024/2690: The Technical Layer—and Who It Binds

Adopted on 17 October 2024, Commission Implementing Regulation (EU) 2024/2690 exercises the mandate in Article 21(5) of the NIS2 Directive [2]. Its Annex translates the ten Article 21(2) measures into 13 thematic sections, each containing numbered sub-requirements.

The CIR is legally binding for nine specific entity categories: DNS service providers, top-level domain name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, providers of online search engines, and providers of social networking service platforms [2]. For essential and important entities outside those nine categories, competent authorities will apply their own technical guidance—but many member states and ENISA treat the CIR Annex as the de facto technical reference for all entities in scope.

The proportionality framework in Article 2(2) of the CIR requires entities to “take due account of the degree of their exposure to risks, their size and the likelihood of occurrence of incidents and their severity, including their societal and economic impact” [2]. Where a sub-requirement uses the phrase “where appropriate,” “where applicable,” or “to the extent feasible,” an entity that cannot implement it must document its reasoning in a comprehensible manner—a written justification file, not a verbal assertion [2].

The CIR Annex Mapped to Article 21(2)(a)–(j)

The CIR Annex contains 13 sections. They do not follow a one-to-one correspondence with the ten Article 21(2) letters: measure (a) expands into two sections (security policy and risk management), measure (c) incorporates business continuity, backup, and crisis into one section, and measure (i) splits across three sections (human resources security, access control, and asset management). The table below is the definitive mapping.

Article 21(2)	CIR Annex Section(s)	Topic
(a)	Sections 1 + 2	Security policy + Risk management policy
(b)	Section 3	Incident handling
(c)	Section 4	Business continuity, backup, disaster recovery, crisis management
(d)	Section 5	Supply chain security
(e)	Section 6	Security in ICT product and service acquisition, development and maintenance
(f)	Section 7	Effectiveness assessment policies
(g)	Section 8	Cyber hygiene practices and cybersecurity training
(h)	Section 9	Cryptography and key management
(i)	Sections 10 + 11 + 12	Human resources security; Access control; Asset management
(j)	Section 11 (in part)	MFA and continuous authentication; secured communications
CIR addition	Section 13	Physical and environmental security (not named in Article 21 text)

Inside Each Measure: CIR Sub-Requirements and Proportionality Flags

(a) Risk Analysis and Security Policies—CIR Sections 1 and 2

Section 1 requires a management-approved policy on network and information system security that covers: the organisation’s approach to security; defined security objectives; a commitment to continual improvement; resource allocation; communication to employees; assigned roles and responsibilities; a list of topic-specific policies; and monitoring indicators with the management approval date [2]. Sub-requirement 1.1.2 mandates annual review or review following a significant incident or operational change. Sub-requirement 1.2.3 requires that at least one person reports directly to management on security matters—not the general IT function, a designated security function [2].

Section 2 adds the risk management framework. Sub-requirement 2.1.2 specifies the full methodology: establish risk tolerance; maintain risk criteria; identify risks using an all-hazards approach that includes third-party risks and single-points-of-failure; analyse threat likelihood and impact; evaluate and prioritise treatment options; continuously monitor implementation; assign ownership with timelines; and justify accepted residual risks in writing [2]. Sub-requirement 2.3.2 requires independent review by individuals with audit competence who are not in the authority line of the area being reviewed—for micro-entities, alternative impartiality measures are permitted.

Proportionality flag: The all-hazards approach must scale to the entity’s risk exposure and size. Micro-entities may substitute formal internal audit with “alternative impartiality measures” for independence reviews [2].

(b) Incident Handling—CIR Section 3

Section 3 requires an incident handling policy that covers: categorisation of incidents; escalation and communication plans; assigned roles with response manuals, escalation charts, and contact lists [2]. The monitoring and logging sub-requirements (3.2.1–3.2.7) are the most operationally demanding: monitoring must be “automated and continuous or in periodic intervals per business capabilities”; logs must be maintained for a predefined retention period; and logs must cover (where appropriate) network traffic, user account creation and modification, system access, authentication events, privileged access activities, configuration changes, security tool outputs, system resource usage, physical access, and environmental events [2].

Sub-requirement 3.3.1 requires a simple mechanism allowing employees, suppliers, and customers to report suspicious events. Sub-requirement 3.4.2 requires quarterly review of recurring incidents against the aggregation rule in Article 4 of the CIR—two incidents within six months, same root cause, collectively meeting the financial threshold, become a single significant incident [2].

Remember that Article 23 incident notification obligations run in parallel: early warning within 24 hours, incident notification within 72 hours, intermediate report on request, final report within one month. The incident handling policy must integrate those timelines explicitly.

Proportionality flag: Monitoring may be “continuous or periodic” depending on business capabilities. The frequency of post-incident reviews can be adjusted by risk level.

(c) Business Continuity—CIR Section 4

Section 4 covers business continuity, backup, disaster recovery, and crisis management in one integrated section. Sub-requirement 4.1.3 mandates a business impact analysis assessing severe disruption potential before continuity requirements can be meaningfully set. The BC/DR plan must include recovery order, specific recovery objectives, required resources including off-site backups, and conditions for plan activation [2].

Backup sub-requirements (4.2.1–4.2.6) are specific: backup copies must be stored at “sufficient distance from the main site” (either online with appropriate access controls or offline); integrity checks must be performed regularly; and recovery procedures must be tested at planned intervals with documented results [2]. The recovery test documentation is what auditors examine—untested backups provide no assurance.

Crisis management (4.3.1–4.3.4) adds a separate requirement to implement a process for managing CSIRT or competent authority communications during crises, distinguishing obligatory communications (statutory incident reports) from non-obligatory ones [2]. See also our NIS2 business continuity guidance for sector-specific considerations.

Proportionality flag: Redundancy requirements apply “where appropriate”—specifically 4.2.4 on partial redundancy of systems, facilities, and personnel [2].

(d) Supply Chain Security—CIR Section 5

Section 5 requires a documented supply chain security policy governing all direct supplier and service provider relationships [2]. Sub-requirement 5.1.2 defines the minimum supplier selection criteria: secure development practices; capability to meet cybersecurity specifications; quality, resilience, and embedded cybersecurity of ICT products; and the ability to diversify supply sources to limit vendor lock-in [2].

Sub-requirement 5.1.4 sets out what must appear in supplier contracts, including (where appropriate): cybersecurity requirements; employee training and certification requirements; background verification requirements; an obligation on the supplier to notify the entity without undue delay upon an incident; audit rights or the right to receive audit reports; vulnerability handling obligations; and cybersecurity specifications for subcontractors [2]. The phrase “without undue delay” for supplier incident notification mirrors the language in Article 23 for the entity itself.

Sub-requirement 5.1.3 requires entities to consider coordinated supply chain risk assessments conducted under Article 22(1) of the NIS2 Directive—specifically, ENISA and member state cooperation group assessments of critical supply chains [1]. See our supply chain security article for the practical procurement process.

Proportionality flag: Contract requirements apply “where appropriate via service level agreements,” allowing lighter treatment for low-criticality suppliers [2].

(e) Systems Acquisition, Development and Maintenance—CIR Section 6

Section 6 addresses the security of ICT products and services throughout their lifecycle. Sub-requirement 6.1.1 requires entities to manage ICT supplier risks and obtain assurance that ICT products and services achieve the required cybersecurity protection levels [2]. This explicitly references EU cybersecurity certification schemes under Regulation (EU) 2019/881 (the Cybersecurity Act) as a mechanism for obtaining that assurance.

The broader scope of measure (e) in Article 21(2) encompasses secure development practices, configuration and change management, security testing, patch management, network segmentation, malware protection, and vulnerability handling. Entities should maintain documented processes for each of these, even where a single CIR sub-requirement addresses them briefly.

Proportionality flag: European cybersecurity certification is referenced as one option for assurance, not a mandatory mechanism. Risk-based procurement criteria suffice for most entities.

(f) Effectiveness Assessment—CIR Section 7

This is the measure most organisations underinvest in. Section 7 requires policies defining what to measure, how to measure it, who is responsible, how results are analysed, and when the cycle repeats [3]. The key discipline is the distinction between activity metrics (firewall rules deployed, training sessions completed) and effectiveness metrics (mean time to detect, percentage of assets with current patches). Auditors under Article 21(2)(f) will ask for the measurement methodology and results, not just a statement that measurements exist.

Proportionality flag: Frequency of effectiveness reviews can be adjusted proportionately, but at minimum annually or after significant incidents.

(g) Cyber Hygiene and Training—CIR Section 8

Section 8 requires basic cyber hygiene practices across all personnel and role-specific training with documented effectiveness assessment [3]. The CIR names specific hygiene practices: zero-trust principles; software update discipline; device configuration hardening; network segmentation; identity and access management basics; and user awareness covering multi-factor authentication, safe email and web use, phishing and social engineering recognition, and secure remote working [2].

Training must be delivered at induction and at planned intervals thereafter. Phishing resistance training—using simulated phishing to test awareness—is increasingly standard in competent authority expectations, though not named in the CIR text itself. The training tracker and evidence of completion are the audit artefacts.

Proportionality flag: Role-specific training depth scales with the access and responsibilities of the individual. Board-level training is required under Article 20 independently of Article 21(g).

(h) Cryptography—CIR Section 9

Section 9 requires: selection of cryptographic algorithms and key lengths appropriate to data sensitivity; key management processes covering generation, storage, rotation, and destruction; and a scheduled review of cryptographic practices against current best practice [3]. The reference to “appropriate, where appropriate, encryption” in Article 21(2)(h) is deliberate: encryption is not universally mandatory, but where data sensitivity or transmission risk warrants it, absence of encryption requires documented justification.

For entities handling personal data, GDPR Article 32(1)(a) independently requires encryption as a security measure; the NIS2 obligation under Article 21(2)(h) is separate and applies to NIS security generally. See also our cryptography and encryption guide for key management implementation detail.

Proportionality flag: Algorithm selection must be “appropriate to data sensitivity”—a low-risk internal system does not require the same cryptographic strength as a public-facing service processing personal health data.

(i) HR Security, Access Control, and Asset Management—CIR Sections 10–12

Three CIR sections implement the single Article 21(2)(i) measure, reflecting the substantive breadth of HR security, access control, and asset management as distinct disciplines.

Section 10 (human resources security) requires: a disciplinary process for security policy violations; background verification of employees, suppliers, and service providers proportionate to their duties; and raised awareness of the consequences of security policy misuse [3]. Criminal record checks are mentioned as one form of background verification appropriate to duties—not a universal requirement.

Section 11 (access control) is the most sub-requirement-dense section. It requires: a documented access control policy; access rights management with periodic review; privileged account management; segregated administration systems; unique identification for all users; authentication controls; and MFA or continuous authentication for critical systems and remote access [3]. CIR Section 11.7 is the primary implementation vehicle for the MFA element of Article 21(2)(j); the remaining obligations under (j)—secured voice, video and text communications and emergency communication systems—are addressed through the cyber hygiene and network security requirements of the CIR rather than through Section 11 alone.

Section 12 (asset management) requires: a comprehensive asset inventory; classification by sensitivity, risk, and security requirements; lifecycle security handling including secure disposal; and removable media controls [2]. Sub-requirement 12.1.3 specifies the fields a comprehensive inventory should include: unique identifier, owner, description, location, type, processed information type and classification, last update or patch date, risk assessment classification, and end-of-life date. An asset register without these fields will be flagged in audit.

See our dedicated guides on access control policy requirements for implementation detail.

Proportionality flag: Background verification applies “where appropriate” and proportionate to the duties of the individual [3]. Micro-entities may apply simpler access control models where risk justifies it.

(j) MFA and Secured Communications—CIR Section 11 (in part)

Article 21(2)(j) requires the use of MFA or continuous authentication, secured voice, video and text communications, and secured emergency communication systems “where appropriate” [1]. The phrase “where appropriate” does not reduce this to optional; it requires a risk-based determination of where MFA and secured communications are necessary.

The CIR implements the MFA element through access control Section 11, sub-requirement 11.7: MFA or continuous authentication for critical systems and remote access [3]. Communications security is addressed partly through cyber hygiene (secure communications as a user practice) and partly through the network security requirements in the CIR.

Phishing-resistant MFA methods (FIDO2 hardware keys, certificate-based authentication) provide stronger assurance than SMS-based one-time passwords, which remain vulnerable to SIM-swap attacks. For high-risk roles and systems, competent authorities increasingly expect phishing-resistant methods. See our MFA requirements guide for implementation choices.

Proportionality flag: Article 21(2)(j) applies “where appropriate.” Entities that do not deploy MFA for a specific system or communication channel must document the risk-based reasoning [2].

The 10-Row Audit Evidence Checklist

The following table sets out what competent authorities examine for each of the ten Article 21(2) measures. Evidence listed as “primary” is typically requested first; “secondary” artefacts are examined where primary evidence is incomplete or a deeper review is triggered.

Measure	Primary Evidence	Secondary Evidence / Common Gaps
(a) Risk analysis & policies	Current risk assessment with date; management sign-off; topic-specific policy list	Evidence of annual review; independent review report; risk treatment plan with owner and deadline
(b) Incident handling	Incident handling policy; incident log for the past 12 months; CSIRT notification records	Monitoring and logging configuration; post-incident review reports; recurring-incident analysis
(c) Business continuity	BC/DR plan with activation conditions; business impact analysis; backup schedule	Backup test results with date; DR test results; off-site backup documentation; crisis plan with CSIRT comms
(d) Supply chain security	Supply chain security policy; supplier directory with criticality classification	Supplier contracts containing Article 21 cybersecurity clauses; evidence of coordinated supply chain risk assessment review
(e) Systems acquisition & development	Secure development policy; patch management procedure with SLA timelines	Configuration management records; security test results; vulnerability scan outputs; change approval log
(f) Effectiveness assessment	Measurement methodology document; most recent effectiveness report	KPI trend data; evidence that results informed policy revision or risk treatment update
(g) Cyber hygiene & training	Training completion tracker; training content for last 12 months	Role-specific training records for privileged users; phishing simulation results; induction security training evidence
(h) Cryptography	Cryptography and encryption policy; key management procedure	Evidence of algorithm review against current best practice; encryption-in-transit and at-rest configuration evidence
(i) HR, access control, assets	Access control policy; asset inventory with classification; privileged account list	Access review results with date; background verification procedure; user termination de-provisioning records; asset disposal records
(j) MFA & communications	MFA configuration records for critical systems and remote access; communications security policy	Risk-based justification where MFA is not deployed; secured communications platform configuration; emergency communications test records

Two patterns emerge consistently in NIS2 audits. First, policies exist but review cycles do not: a policy dated 2023 with no documented review will fail the annual-review requirement even if the policy content is sound. Second, technical controls exist but evidence does not: a firewall may enforce network segmentation correctly, but without a configuration record or last-review date, there is nothing for an auditor to examine.

Applying the Proportionality Test: Three Scenarios

Proportionality under Article 2(2) of the CIR is not a binary exemption—it is a continuous calibration based on four factors: exposure to risks, entity size, likelihood of incidents, and societal and economic impact [2]. The following scenarios illustrate how the same measure produces different implementation expectations.

Scenario 1 — Large essential entity (DNS provider). A DNS provider with 10 million managed domains is directly bound by the CIR and is classified as high exposure, high societal impact. All CIR sub-requirements apply without qualification. Independent reviews (sub-requirement 2.3.1) must be conducted by external audit-competent parties, not internal staff. Logging must be continuous, not periodic. Backup distance requirements must be documented with specific geographic or logical separation.

Scenario 2 — Medium important entity (manufacturing). A manufacturing company with 500 employees qualifies as an important entity under Annex II. The CIR Annex is the de facto technical reference applied by most national competent authorities. Proportionality permits periodic (rather than continuous) monitoring where business capabilities are limited, simplified access review cycles (semi-annual rather than quarterly), and relies on the existing ISO 27001 certification as partial evidence for multiple measures. The risk treatment plan and annual review are still required.

Scenario 3 — Micro-entity (small important entity). A water utility with fewer than 10 employees may be in scope as an important entity under Annex II despite its size. The CIR permits micro-entities to use “alternative impartiality measures” for independence reviews instead of formal internal or external audit. Simplified asset inventories suffice where the asset count is low. However, backup testing, incident handling policy, and supply chain contract requirements cannot be proportionality-reduced to zero—they scale in scope, not disappear.

The practical takeaway: document the proportionality reasoning explicitly. Where a CIR sub-requirement is marked “where appropriate” and the entity has chosen not to implement it, the reasoning must be recorded in a form the competent authority can review [2]. “We are small” is not sufficient; “Given our size of 8 employees, single-site operation, and risk assessment showing low likelihood of the relevant threat category, we have determined that [measure X] is not applicable and have implemented compensating control [Y]” is.

Physical Security: The Obligation CIR Added That Article 21 Does Not Name

CIR Annex Section 13 addresses physical and environmental security: protection against theft, fire, flood, telecommunication and power failures, unauthorised access, and damage or interference, using an all-hazards approach [2]. The specific examples in sub-requirement 13.1.1 include: flooding detection systems; fire compartments with fire-resistant materials, temperature and humidity sensors, automated fire detection and suppression, and fire drills; overvoltage protection and emergency power supply; and continuous redundant air conditioning for data centres.

Section 13 is an addition by the CIR that has no direct equivalent in the text of Article 21(2)(a)–(j). It reflects the Commission’s assessment that physical security is inseparable from cybersecurity for digital infrastructure entities. For entities directly bound by the CIR, this section is legally enforceable [4]. For other entities, competent authorities may reference it as part of the “state of the art” standard in Article 21(1).

Frequently Asked Questions

Does CIR 2024/2690 apply to my organisation if I am not in one of the nine listed entity categories?
The CIR is legally binding only for nine entity categories (DNS providers, TLD registries, cloud computing providers, data centre providers, CDN providers, managed service providers including managed security service providers, online marketplace providers, search engine providers, and social networking platform providers) [2]. However, most national competent authorities and ENISA treat the CIR Annex as the technical reference standard for all entities subject to Article 21—the NIS2 Directive’s obligation to apply “state-of-the-art” measures effectively incorporates the CIR’s specificity even where it is not formally binding on your entity type.

What happens if we use the phrase “where appropriate” to decline a sub-requirement?
Article 2(3) of the CIR permits non-implementation of “where appropriate” sub-requirements only where the entity documents its reasoning comprehensibly. The documentation must explain why the sub-requirement is not appropriate, applicable, or feasible given the entity’s specific risk profile and circumstances. It must be retained and available for competent authority inspection. Blanket assertions that a measure is not applicable without documented risk-based reasoning will not satisfy the standard [2].

How do the CIR significant incident thresholds relate to Article 21?
They are separate but connected. The significant incident thresholds in Article 3 of the CIR (financial loss exceeding €500,000 or 5% of annual turnover; trade secret exfiltration; death; considerable health damage; or malicious access enabling severe disruption) determine when Article 23 notification obligations are triggered [2]. The Article 21 measures are the controls that prevent incidents from reaching those thresholds—and the incident handling sub-requirements in CIR Section 3 require quarterly review of whether recurring incidents are aggregating toward the financial threshold under Article 4 [2].

What is the relationship between Article 21 and ISO 27001?
ISO 27001:2022 certification is not a substitute for NIS2 compliance, but it provides significant overlap. The CIR Annex aligns with many ISO 27001:2022 Annex A controls, and competent authorities may treat an existing ISO 27001 certification as evidence for multiple Article 21 measures. The gap between ISO 27001 and NIS2 lies primarily in the incident notification requirements (Article 23), management body accountability (Article 20), and supply chain security specifics (Article 21(3))—none of which are fully addressed by the ISO standard alone.

Is there guidance from ENISA on implementing the CIR Annex?
Yes. ENISA published its Technical Implementation Guidance on Cybersecurity Risk Management Measures in June 2025 [5]. The guidance mirrors the CIR Annex structure and provides practical implementation examples and evidence artefacts that can be shown to auditors, as well as mappings to ISO 27001, NIST CSF, and other frameworks. The document is non-binding but represents current best practice as assessed by the EU’s cybersecurity agency.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• [1] NIS2 Directive (EU) 2022/2555, Article 21 — NIS2Resources.eu
• [2] Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
• [3] CIR 2024/2690: NIS2 Technical Measures — nisd2.eu
• [4] NIS2 Implementing Act (EU) 2024/2690: Mapping — OpenKRITIS
• [5] ENISA Technical Implementation Guidance on Cybersecurity Risk Management Measures (June 2025) — ENISA