NIS2 Article 21 Explained: The 10 Minimum Cybersecurity Measures Every In-Scope Organisation Must Implement

Article 21 of Directive (EU) 2022/2555 is the operational heart of NIS2. Everything else in the directive — the reporting timelines, the management-body accountability, the fines of up to €10 million or 2% of global turnover — ultimately depends on whether you have actually implemented the ten risk-management measures it requires. Auditors will not grade you on how well you have read the recitals. They will grade you on whether measure by measure, with documented evidence, you can show that your organisation has done what the directive says.

This is where most NIS2 programmes are thinnest. Teams treat Article 21 as a checklist of things their ISMS already covers. For organisations with a mature ISO 27001 certification, that is partly true — but only partly, and the gaps are in the places that matter most to regulators.

This guide works through all ten measures, what each actually demands in operational terms, how each maps to ISO 27001:2022 Annex A, and where the gaps typically sit. The aim is not to re-state the directive — the full text of Article 21 is short and readable — but to translate it into something a security team can build a programme against.

The principle that governs everything: proportionality

Before the ten measures, Article 21(1) sets the rule that reshapes how you apply them. Measures must be “appropriate and proportionate” to the entity’s risk exposure, size, likelihood of incidents, and the severity of potential impact. This is not a loophole that lets small organisations skip things — NIS2 does not exempt important entities from the ten measures. What it does mean is that the depth, sophistication, and evidencing of each measure should match the organisation’s scale and risk profile.

A 60-person important entity providing a digital service will not be held to the same implementation standard as a multinational essential entity operating critical infrastructure. But both are expected to have addressed all ten measures. Proportionality is about calibration, not exclusion.

This matters because organisations routinely misapply it in both directions. Small entities over-engineer — spending money on controls far above their risk profile because the directive uses strong language. Large entities under-engineer — arguing proportionality as a reason to defer the hard parts of supply chain security or management-body training. Regulators, in the limited enforcement actions seen so far across transposing member states, have pushed back on the second pattern much harder than the first.

Document your proportionality assessment. Not just a paragraph in the ISMS policy — a genuine written assessment that connects the risk profile of your organisation to the depth at which you implement each measure. When a regulator asks why your supply chain due diligence is lighter than a peer’s, the answer is in this document.

The ten measures, in operational language

1. Risk analysis and information system security policies

What the directive says: Policies on risk analysis and information system security.

What this actually means: You need a documented risk-management framework that covers both your IT systems and any operational technology you run. This is not just a register of risks; it is the governance structure, methodology, and review cadence that produce that register. The framework must be owned at a senior level, reviewed at a defined interval, and connected to decisions about controls.

The common gap: Organisations have a risk register but not a framework. The register has entries but no clear relationship to the selection of controls, to incident learnings, or to the cadence of management-body review. When an auditor asks how a given control was chosen, the answer is “we had it already” rather than “we assessed these risks against this methodology and selected these controls.”

Evidence to produce: Written risk-management policy, risk assessment methodology document, current risk register with defined review cadence, minutes of risk-review meetings, evidence that risk assessments inform control decisions.

2. Incident handling

What the directive says: Incident handling.

What this actually means: A documented capability to detect, triage, respond to, and recover from cyber incidents. This ties directly to Article 23’s reporting obligations — the 24-hour early warning, 72-hour incident notification, and one-month final report cadence. An incident-handling capability that cannot meet those reporting timelines does not satisfy Article 21.

The common gap: Teams have an IR plan but have never tested it end-to-end against the Article 23 timeline. When a real incident happens, the internal triage process takes longer than the 24-hour early warning window because legal approval, management sign-off, and cross-functional coordination were not pre-authorised.

Evidence to produce: Incident response plan, playbooks for major scenarios (ransomware, BEC, supply chain compromise), tabletop exercise records within the past 12 months, documented communication paths to the competent authority and CSIRT, runbooks for meeting the 24/72/30 reporting cadence.

3. Business continuity and crisis management

What the directive says: Business continuity, such as backup management and disaster recovery, and crisis management.

What this actually means: This is where NIS2 gets specific where many frameworks are vague. The directive explicitly names backup management, disaster recovery, and crisis management. Cyber insurers and regulators have converged on broadly the same expectations: immutable or air-gapped backups, tested restore procedures, defined recovery time objectives (RTO) and recovery point objectives (RPO), and a crisis-management plan that sits above the incident response plan to handle business-level consequences.

The common gap: Backups exist but have not been restored from in the last 12 months. DR plans exist but have not been exercised. The crisis-management plan is either conflated with the incident response plan or is a separate document that was written once and never referenced again.

Evidence to produce: Backup policy specifying immutability/air-gap requirements, most recent successful test-restore record, DR test records, defined RTOs and RPOs per critical function, crisis-management plan with named roles, most recent crisis exercise record.

4. Supply chain security

What the directive says: Supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.

What this actually means: You are now responsible for the security posture of your direct suppliers to an extent that most compliance frameworks did not previously require. Article 21(3) explicitly requires entities to consider supplier-specific vulnerabilities, the overall quality of suppliers’ cybersecurity practices, and the results of any coordinated risk assessments the European Commission or the NIS Cooperation Group publishes under Article 22.

The common gap: This is the single biggest gap in almost every NIS2 programme. Organisations with a strong internal ISMS often have vendor-risk processes that are questionnaire-driven and one-off — a security assessment at onboarding, then silence. NIS2 expects ongoing oversight. It also expects you to have specifically addressed the supply chain in contracts, with enforceable cybersecurity clauses.

Evidence to produce: Supply chain security policy, tiered vendor classification, due-diligence records for critical suppliers, contractual cybersecurity clauses, continuous monitoring programme for high-tier suppliers, evidence that Commission/NIS Cooperation Group coordinated risk assessments are reviewed and acted on.

5. Security in acquisition, development and maintenance

What the directive says: Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.

What this actually means: Secure development life cycle practices for anything you build or substantially modify, and vulnerability management for everything you run. The explicit inclusion of “disclosure” is significant — it means a vulnerability disclosure programme is effectively required, not optional.

The common gap: Vulnerability management has often been confined to infrastructure scanning. NIS2 expects coverage across the full lifecycle: secure coding, security testing in CI/CD, third-party dependency scanning, a patch-management programme with defined SLAs by severity, and a published coordinated vulnerability disclosure (CVD) process.

Evidence to produce: Secure development policy, SAST/DAST/SCA in the pipeline, dependency scanning records, vulnerability management policy with severity-based SLAs, CVD policy published externally, recent patching records, procurement security requirements.

6. Policies and procedures to assess effectiveness

What the directive says: Policies and procedures to assess the effectiveness of cybersecurity risk-management measures.

What this actually means: Measure, test, and review whether your controls are actually working. This is an audit-your-own-programme requirement. NIS2 is not satisfied by the existence of controls — it expects evidence that you have a systematic way of confirming those controls are operating as intended and are effective at managing the risks they address.

The common gap: Organisations have internal audit, but internal audit is scheduled annually and covers a sampled set of controls. NIS2 expects a continuous-assurance posture: KPIs on control effectiveness, evidence of corrective actions where controls fall short, and a review cadence that catches drift before an incident does.

Evidence to produce: Internal audit plan with coverage mapped to Article 21, KPI dashboards for major control areas, corrective-action records, management-review minutes that reference control-effectiveness data.

7. Basic cyber hygiene and training

What the directive says: Basic cyber hygiene practices and cybersecurity training.

What this actually means: A baseline hygiene standard — patching, configuration management, access control, awareness — applied consistently across the organisation, with a training programme that keeps people current. The explicit reference to training connects to Article 20’s requirement that management-body members receive cybersecurity training.

The common gap: Training is often annual, generic, and untested. NIS2 does not prescribe frequency or content, but regulators in the member states that have acted so far have signalled clearly that annual click-through training without testing is not enough to satisfy proportionality for most essential entities.

Evidence to produce: Training programme with defined frequency and content, completion records, phishing simulation results, management-body training records (distinct from general staff training), hygiene baseline document.

8. Cryptography and encryption

What the directive says: Policies and procedures regarding the use of cryptography and, where appropriate, encryption.

What this actually means: A cryptography policy that covers key management, algorithm selection, encryption at rest and in transit for sensitive data, and certificate management. The “where appropriate” qualifier invites proportionality, but it does not excuse the absence of a policy.

The common gap: Organisations encrypt data at rest in cloud services by default and consider the measure met. They often have no cryptography policy, no inventory of cryptographic use, no key-management standard, and no plan for algorithm obsolescence — which matters increasingly as the post-quantum transition begins.

Evidence to produce: Cryptography policy, key-management procedures, algorithm and certificate inventory, TLS configuration standards, encryption-at-rest and in-transit records, crypto-agility plan.

9. Human resources security, access control and asset management

What the directive says: Human resources security, access control policies and asset management.

What this actually means: Joiner/mover/leaver processes with defined security checkpoints, role-based access control with periodic reviews, privileged access management for administrative accounts, and an asset inventory that is current and authoritative.

The common gap: Asset management. Most organisations have multiple partial asset inventories — a CMDB maintained by IT, a SaaS inventory maintained by finance, a cloud-resource list pulled from each hyperscaler — none of which are reconciled. NIS2 expects a single, current view of what you have, because you cannot protect assets you do not know about.

Evidence to produce: Joiner/mover/leaver procedure, access-control policy, access-review records, PAM deployment evidence, asset inventory with defined ownership and classification, reconciliation records between sources. If your organisation is starting to deploy AI agents as operational identities, this is also where your AI agent identity management controls live.

10. Multi-factor authentication, secure communications, and emergency communications

What the directive says: 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 this actually means: MFA is expected to be broadly deployed. “Where appropriate” invites proportionality, but in practice this means MFA on all remote access, email, administrative accounts, and cloud consoles. The secure-communications requirement is often overlooked — the directive expects entities to have thought about whether sensitive voice/video/text communications are adequately protected, and to have an emergency communications capability that continues to function when primary systems are compromised.

The common gap: MFA exists but has coverage gaps — SMS fallback in places where it should not be, service accounts exempted, legacy authentication protocols still permitted for compatibility. Secure communications and emergency communications are rarely documented at all.

Evidence to produce: MFA policy, MFA coverage report (by system, by account type, by authentication method), emergency communications plan with tested alternatives, policy on use of secure-messaging platforms for sensitive operational communications.

The ISO 27001:2022 cross-mapping

The single most common question from organisations with a mature ISMS: how much of Article 21 is already covered by ISO 27001:2022 certification? The honest answer is: most of it, but not all, and the gaps matter.

The table below maps each Article 21 measure to the relevant Annex A control groups in ISO 27001:2022. Where there is clear overlap, the measure is substantially addressed by existing ISMS controls. Where there is a partial match, the ISMS covers the concept but NIS2 typically expects deeper or more specific implementation. Where the mapping is marked weak, this is where ISO 27001-certified organisations consistently fall short.

Read across the rows, the pattern is clear: ISO 27001-certified organisations start the NIS2 journey with most of the foundational plumbing in place. The gaps cluster around three themes — supply chain oversight, asset management, and management-body accountability. These are also the areas where regulators in transposing member states have focused their early enforcement attention.

If you are ISO 27001:2022 certified and planning for NIS2, the efficient path is a gap assessment focused on those three themes rather than a full parallel programme. Most of your Annex A controls will map cleanly. The work is in depth and evidencing, not in breadth.

Where NIS2 goes beyond ISO

Three obligations in NIS2 do not have an equivalent in ISO 27001 and require discrete work regardless of ISMS maturity:

Management-body accountability (Article 20). Members of management bodies must approve and oversee the implementation of Article 21 measures, and they must receive cybersecurity training. This includes personal liability in several transposing member states. An ISO 27001 certificate does not satisfy this. You need named individuals, documented training, and recorded oversight decisions.

Article 23 reporting cadence. The 24-hour early warning, 72-hour incident notification, interim reporting at CSIRT request, and 1-month final report cadence is a specific operational capability. It requires pre-authorised communication paths, pre-defined thresholds for what constitutes a reportable incident, and tested runbooks. ISO 27001’s incident-management controls do not prescribe these timelines.

Supply chain obligations under Article 21(3). The requirement to consider Commission and NIS Cooperation Group coordinated risk assessments is new. These assessments have begun to be published, and entities are expected to act on them. This creates an ongoing obligation that is not present in the ISO model.

The proportionality trap

A final observation on where NIS2 programmes go wrong. The proportionality principle invites organisations to scale their implementation to their risk profile. Some take this as an invitation to argue that most of the directive does not really apply to them.

This is a mistake. Competent authorities, in the limited guidance and enforcement actions that have emerged since the October 2024 transposition deadline, have been consistent: proportionality scales the depth of implementation, not the scope. You are still expected to have addressed every one of the ten measures. You are still expected to have a supply chain programme, a crisis-management plan, a vulnerability-disclosure policy, a cryptography policy, and management-body training.

The trap is treating proportionality as exemption. The way to implement proportionality correctly is to document, for each measure, the level of implementation you have chosen and why — connecting that decision back to your risk assessment under measure (a). When regulators ask “why is your programme lighter here than a peer’s?”, the defensible answer is a written proportionality rationale grounded in your own risk profile. The indefensible answer is “we didn’t think it applied.”

Frequently asked questions

Does Article 21 apply if I’m only an “important” entity, not “essential”? Yes. The ten measures apply identically to both categories. The differences between essential and important entities are in supervision regime (proactive vs reactive) and in the maximum level of fines, not in the substantive obligations under Article 21.

What’s the deadline for Article 21 compliance? Under NIS2 itself, the obligations entered into force with national transposition, which was due by 17 October 2024. Most member states have now transposed, though some are still completing secondary legislation. If your organisation is in scope in a transposed jurisdiction, the obligations are already live. The full NIS2 compliance timeline by member state is tracked in our main NIS2 guide.

Is my ISO 27001:2022 certification enough? It’s a strong foundation — typically 70–80% of the control breadth — but it is not sufficient on its own. The gaps cluster around supply chain, asset management, management-body accountability, and the Article 23 reporting capability. Expect three to six months of focused additional work to close the gaps.

What does “where appropriate” mean for MFA? In practice, regulators have interpreted it as requiring MFA on all remote access, email, administrative accounts, and cloud consoles — with hardware-backed or phishing-resistant MFA strongly preferred for privileged access. Arguing that MFA is not appropriate anywhere has not been a successful posture.

How is effectiveness actually assessed under measure (f)? There is no prescribed methodology. What regulators have signalled is that they expect to see KPIs, test results, audit findings, and corrective actions — evidence that the organisation has a systematic way of confirming controls are working. Internal audit alone, run annually, is unlikely to satisfy the expectation for essential entities.

Does the UK Cyber Security and Resilience Bill impose the same measures? The UK Bill, currently progressing through Parliament with Royal Assent expected in late 2026, broadly aligns with NIS2 but is not identical. It uses the NCSC’s Cyber Assessment Framework (CAF) as its substantive basis rather than a direct transposition of Article 21. Organisations operating in both the UK and EU will need to satisfy both regimes, with the core security outcomes largely overlapping.

The practical takeaway

Article 21 is the measure by which your NIS2 programme will be judged. The ten measures are not a checklist — they are ten outcomes, each of which requires documented implementation proportionate to your risk profile, and each of which must be evidenced when a competent authority asks.

If you take three things from this piece: map your existing controls to the ten measures and identify your gaps precisely; pay particular attention to supply chain (21d) and asset management (21i), because these are the gaps that trip up even ISO-certified organisations; and document your proportionality rationale for each measure, so that the depth of implementation you have chosen is defensible.

The companion piece to this guide — our NIS2 compliance checklist for UK and EU businesses — covers scope determination, the Article 23 reporting cadence, and management-body obligations. Together they form the core of what a security team needs to build a defensible NIS2 programme.