Key Takeaway: Article 21 is the operational heart of NIS2. It lists 10 mandatory risk management measures that every essential and important entity must implement and prove they actually operate. The measures are stated at a high level on purpose: proportionality is built in, but evidence is not optional. If you cannot show a regulator what you do for each of the 10 measures, you are non-compliant.
Most NIS2 readers skip straight to Article 23 (incident notification) because the deadlines are dramatic. But Article 21 is what regulators audit. It is the list your security programme has to map to. In the first NIS2 enforcement cases of 2026, every fine cited deficiencies mapped to one or more Article 21 measures.
This article walks through each of the 10 measures in Article 21(2)(a) through (j) in plain language. For each measure you will see: what the directive actually requires, what proportionate implementation looks like, what evidence to prepare for a supervisor, and the common pitfalls that cause even well-funded organizations to fall short.
First: the proportionality principle
Article 21(1) sets the frame for all 10 measures. It requires measures that are "appropriate and proportionate" to:
- The entity's exposure to risks
- Its size
- The likelihood of occurrence of incidents and their severity
- The economic and societal impact of incidents
What proportionality does not mean: Proportionality does not mean "do less." It means "do what is commensurate with your risk." A small important entity must still address all 10 measures. It just addresses them at a depth appropriate to its scale. Skipping a measure entirely because "we are small" is not proportionality. It is non-compliance.
1 Policies on risk analysis and information system security
Article 21(2)(a) requires policies on risk analysis and information system security. This is the foundation on which everything else rests. Without a documented risk management framework, you cannot defend any of the other nine measures as proportionate.
What implementation looks like
A written information security policy, approved by the management body, that sets the risk appetite, governance structure, and responsibilities. A risk assessment methodology (ISO 27005 or NIST SP 800-30 are both acceptable starting points). A current risk register listing identified risks, their treatment, and residual risk ratings.
Evidence to collect
- Signed and dated management-approved information security policy
- Risk assessment methodology document
- Current risk register with treatment decisions and owners
- Evidence of periodic policy review (at least annually)
Common pitfall
Policies exist on paper but are generic, unsigned, or more than two years old. Regulators treat stale or unsigned policies as absent policies. A policy that has not been reviewed in the post-NIS2 era is very likely inadequate.
2 Incident handling
Article 21(2)(b) requires incident handling. This means a documented, practised process for detecting, triaging, responding to, containing, and recovering from security incidents. Article 23 (notification) is separate but dependent: you cannot notify an incident properly if you have not handled it properly.
What implementation looks like
An incident response plan with severity classification, named roles (incident commander, technical lead, communications lead, legal), runbooks for the most likely incident types (ransomware, credential theft, data leak, third-party breach), and a tested escalation path to the Article 23 24-hour reporting contact.
Evidence to collect
- Incident response plan document
- Tabletop exercise records (at least annual)
- Incident log showing classification and response actions
- Evidence of integration between detection tooling and response process
Common pitfall
A detailed plan that has never been exercised. Incident response capability is demonstrated by use, not by document length. Regulators will ask when the plan was last tested and what the findings were.
3 Business continuity and crisis management
Article 21(2)(c) requires business continuity, including backup management and disaster recovery, and crisis management. The NIS2 emphasis is on continuity of services to which the directive applies, not generic business continuity. If you are a cloud provider, this means your cloud service. If you are a hospital, this means clinical services.
What implementation looks like
A business continuity plan tied to a business impact analysis. Defined recovery time objectives (RTO) and recovery point objectives (RPO) for each critical service. A backup strategy that includes offline or immutable copies, because online backups alone do not survive ransomware. A crisis management framework that activates above a defined severity threshold and includes management, legal, and communications leads.
Evidence to collect
- Business impact analysis for critical services
- Business continuity and disaster recovery plans
- Backup architecture documentation, including offline/immutable controls
- Restore test results (at least annual, ideally quarterly for critical systems)
Common pitfall
Backups that have never been restored in a test. The 2024-2026 ransomware wave has repeatedly shown organizations discovering during an actual incident that their backups are incomplete, corrupted, or connected to production in a way that lets the attacker reach them.
4 Supply chain security
Article 21(2)(d) requires supply chain security, specifically addressing security-related aspects of the relationships between the entity and its direct suppliers or service providers. This is the most commonly under-implemented measure and a rising thematic focus for 2026 supervision.
What implementation looks like
A supplier inventory tiered by criticality and by access. Security clauses in contracts with critical suppliers (incident notification, audit rights, minimum security standards). A due diligence process for new critical suppliers. Ongoing monitoring of supplier security posture (questionnaires, certifications, or third-party ratings). Concentration risk awareness for single points of failure.
Evidence to collect
- Supplier inventory with tiering methodology
- Sample security clauses and examples of signed contracts
- Due diligence evidence for top-tier suppliers
- Annual supply chain risk review report
Common pitfall
Procurement and security are disconnected. Procurement signs contracts without security input. Security does not know which contracts carry which data flows. Start by connecting those two functions through a single supplier register both can access.
5 Security in acquisition, development, and maintenance of systems
Article 21(2)(e) requires security in network and information systems acquisition, development, and maintenance, including vulnerability handling and disclosure. This is NIS2's secure-by-design mandate. It applies both to systems you build and to systems you buy.
What implementation looks like
Security requirements in procurement. Security gates in software development lifecycles (SSDLC) for code you write. A vulnerability management programme with clear severity-based patching SLAs. A coordinated vulnerability disclosure (CVD) policy published on your website with a security contact. Penetration testing or independent security assessment for high-impact systems.
Evidence to collect
- SSDLC documentation and examples of security review records
- Vulnerability management policy with patching SLAs
- Vulnerability scan reports and remediation tracking
- Published CVD policy and log of handled disclosures
- Recent penetration test reports
Common pitfall
Vulnerability scanning exists but patching SLAs are either undefined or chronically missed. Regulators accept that 100% patching is impossible, but expect you to measure against a defined target, report drift, and have a documented risk-acceptance process for exceptions.
6 Policies and procedures to assess effectiveness
Article 21(2)(f) requires policies and procedures to assess the effectiveness of cybersecurity risk management measures. This is the audit loop. You must not only implement the other measures, but systematically check that they actually work, and feed the findings back into your risk assessment.
What implementation looks like
An internal audit schedule for the information security programme. Defined key performance indicators (KPIs) and key risk indicators (KRIs). Periodic management reviews of the programme. Independent assessment (internal audit function, external auditor, or certified third-party attestation such as ISO 27001 or SOC 2). Documented findings with owners and remediation timelines.
Evidence to collect
- Audit plan and last 12 months of audit reports
- KPI/KRI dashboard with trending
- Management review meeting minutes
- Remediation tracker for open findings
Common pitfall
Measurement exists but never triggers change. A regulator will look at repeat findings: items that have appeared in two consecutive audits without resolution are a red flag that your effectiveness assessment is cosmetic rather than operational.
7 Basic cyber hygiene practices and cybersecurity training
Article 21(2)(g) requires basic cyber hygiene practices and cybersecurity training. Crucially, this measure applies to everyone, but the directive singles out management-level training in Article 20(2). Board and senior management must receive regular training so they can identify risks and assess the adequacy of cybersecurity measures.
What implementation looks like
Annual security awareness training for all staff with completion tracking. Role-based training for higher-risk roles (developers, IT admins, finance, procurement). Specific NIS2-focused training for the management body. Phishing simulation programme with measurable improvement over time. A published set of cyber hygiene guidelines (passwords, device use, data handling, remote work) that all staff can reach.
Evidence to collect
- Training curriculum with coverage of NIS2 themes
- Completion records (LMS reports) for the last 12 months
- Management-body training attendance list
- Phishing simulation results with trend analysis
- Published staff cyber hygiene guidelines
Common pitfall
Skipping management training because "the board is busy." Article 20(2) makes management training a personal obligation for members of the management body. Lack of evidence of their training is a direct finding against named individuals.
8 Cryptography and encryption policies
Article 21(2)(h) requires policies and procedures regarding the use of cryptography and, where appropriate, encryption. This is explicit recognition that encryption is a foundational control, not an optional one, and that unmanaged or outdated cryptography is itself a risk.
What implementation looks like
A cryptographic policy covering approved algorithms, key lengths, key management (generation, storage, rotation, destruction), encryption-at-rest for sensitive data, encryption-in-transit (TLS 1.2+ with strong cipher suites), and a roadmap for post-quantum cryptography (PQC) readiness as NIST-approved algorithms start to mature.
Evidence to collect
- Cryptographic policy document
- Key management procedure
- Inventory of cryptographic use across critical systems
- PQC awareness or inventory readiness documentation
Common pitfall
Implicit rather than documented cryptography. Most organizations encrypt well in practice, but cannot produce a written policy explaining which algorithms are approved, where encryption is applied, and who manages keys. The policy is what regulators will ask for first.
9 Human resources security, access control, and asset management
Article 21(2)(i) requires human resources security, access control policies, and asset management. These three topics are grouped because they share a common purpose: ensuring that the right people have the right access to the right assets, and only for as long as necessary.
What implementation looks like
Joiner/mover/leaver processes that reliably provision and de-provision access. Role-based access control with least privilege, periodically reviewed. Privileged access management for administrators. An asset inventory covering hardware, software, data, and cloud resources. Background screening proportionate to role risk. Disciplinary process for security violations.
Evidence to collect
- JML procedure documentation
- Access review results (at least annual)
- Asset inventory and refresh cadence evidence
- Privileged access control evidence (vault, session recording, break-glass)
- HR screening policy for sensitive roles
Common pitfall
Leaver access persists long after departure. Orphaned accounts, shared service accounts with ancient passwords, and former contractors still in directory groups are the most common Article 21(2)(i) findings. An access review that reconciles the directory against HR departure records catches this efficiently.
10 Multi-factor authentication and secure communications
Article 21(2)(j) requires 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. This is the most specific technical measure in Article 21 and the one regulators most easily audit with yes/no questions.
What implementation looks like
MFA on all external-facing accounts (email, VPN, remote access, SaaS, admin consoles). Phishing-resistant MFA (FIDO2, smart cards, or equivalent) for privileged accounts where possible. Encrypted communications for sensitive collaboration (Signal, Wickr, or enterprise equivalents). A defined emergency communication channel that works even when primary systems are compromised.
Evidence to collect
- MFA coverage report (percentage of accounts enrolled)
- Evidence of phishing-resistant MFA for privileged accounts
- Encrypted communications policy
- Emergency out-of-band communication plan
Common pitfall
MFA exists but a small number of legacy or service accounts are exempted. Attackers target exactly these exceptions. Regulators ask for the list of MFA exceptions, their justification, and when they will be retired. "We do not track that" is the wrong answer.
The Article 21 evidence pack: what to have ready
The single most useful document you can prepare for NIS2 supervision is a combined evidence pack mapping each of the 10 measures to specific artifacts, owners, and last-review dates. Supervisors who visit with an Article 21 checklist work faster and reach more favorable conclusions when you hand them a structured index rather than a disorganized document library.
Recommended evidence pack structure
- A cover index mapping each Article 21 measure (a-j) to the relevant artefact or artefacts.
- Information security policy, signed and dated by a member of the management body.
- Risk assessment methodology plus current risk register.
- Incident response plan plus the last tabletop exercise report.
- Business continuity plan, BIA, and most recent restore test evidence.
- Supplier register, tiering, and sample contract clauses.
- Vulnerability management policy, scan results, and patching metrics.
- Internal audit schedule, reports, and remediation tracker.
- Training records for all staff and specifically for the management body.
- Cryptographic policy and key management procedure.
- Access control policy and last access-review report.
- MFA coverage report, including privileged accounts and documented exceptions.
Mapping Article 21 to existing frameworks
If you already hold ISO 27001 certification, you are a substantial part of the way to Article 21 compliance. The 10 measures map closely to ISO 27001 Annex A controls, and an Annex A statement of applicability (SoA) can be reused to evidence most of Article 21 with small additions around supply chain, training of the management body, and incident notification.
Other frameworks that map usefully: NIST Cybersecurity Framework 2.0 (excellent functional mapping), SOC 2 Type II (strong evidence for measures 2, 3, 5, 6, 9), and national frameworks such as the German BSI IT-Grundschutz or the Dutch BIO. Use what you already have. Regulators accept framework-based evidence when the mapping is explicit.
Frequently asked questions
What does Article 21 of NIS2 require?
Article 21 requires essential and important entities to implement appropriate and proportionate technical, operational, and organisational measures to manage cybersecurity risks. It lists 10 mandatory areas: risk analysis, incident handling, business continuity, supply chain security, secure development, effectiveness assessment, cyber hygiene and training, cryptography, access control and asset management, and MFA with secure communications.
Do all 10 Article 21 measures apply to small important entities?
Yes. Every in-scope entity must address every measure. Proportionality applies to the depth of implementation, not to which measures you cover. A small important entity might have a two-page cryptographic policy where a large essential entity has ten pages with detailed key management standards, but both must exist.
Does Article 21 require ISO 27001 certification?
No. ISO 27001 is not mandatory under NIS2. Certification is one way of demonstrating compliance but the directive is framework-neutral. Organisations without ISO 27001 can evidence Article 21 through their own documented risk management programme, as long as the 10 measures are addressed and the evidence is dated and owner-attributed.
Is MFA mandatory under NIS2 Article 21?
Effectively yes. Measure 10 requires MFA or continuous authentication solutions where appropriate. Given the 2024 to 2026 threat landscape, 'where appropriate' covers essentially all external-facing accounts, administrative accounts, and accounts with access to sensitive data. Regulators treat missing MFA on these classes as a finding.
Where do Article 21 measures end and Article 23 incident notification begin?
Article 21 governs preventive and detective controls. Article 23 governs what you report to authorities when a significant incident happens. They interact closely: a weak Article 21 often produces an Article 23 failure, because you did not detect the incident in time or did not classify it correctly. Regulators audit both in the same visit.
Who is accountable for Article 21 compliance inside the organisation?
Article 20 places accountability on the management body. The board must approve the risk management measures, oversee their implementation, and evidence competence through training. Day-to-day execution is usually delegated to a CISO or equivalent, but the sign-off chain ends with the statutory directors. Supervisors verify the approval trail during inspections.
How often must Article 21 measures be reviewed and tested?
At least annually, with event-triggered reviews after significant incidents, major system changes, or material shifts in the threat landscape. Effectiveness assessment under measure (f) is not a one-off exercise. Most supervisors expect a documented testing schedule covering backup restores, incident exercises, access reviews, and penetration tests.
Need help building your Article 21 evidence pack?
We build audit-ready Article 21 evidence packs mapped to your existing controls, with a gap roadmap prioritized by enforcement risk. Done in weeks, not quarters.
Book a gap assessmentRelated articles
MFA under Article 21
A detailed look at measure 10: where MFA is mandatory, which factor types to use, and how to prepare a clean coverage report.
Board training under Article 20
The training obligation for management bodies and the personal liability that sits behind it.
Inventory of critical assets
The first practical step that supports risk analysis, incident handling, and supply chain mapping.
NIS2 compliance checklist 2026
End-to-end implementation guide covering scoping, classification, and all 10 measures.