NIS2 Article 21: All 10 Risk Management Measures Explained

Article 21 of NIS2 is roughly two pages of EU legal text that determines two years of compliance work for the ~160,000 European entities now in scope. Most explanations either paraphrase it word-for-word — low value, since EUR-Lex is a click away — or compress it to a checklist that loses the proportionality principle.

This article does neither.

For each of the 10 measures you'll get:

• what the directive actually requires
• what it means in practice for an SME
• the minimum evidence pack to prove compliance
• the common pitfall that catches most companies.

Compliance leads, CISOs, and IT leads at EU entities in NIS2 scope are the intended audience.

If you're not sure whether you're in scope, start with the complete NIS2 and DORA compliance guide.

Remember as always that this is not legal advice. National guidance continues to evolve. Verify against your competent authority's published materials before audit.

The 10 measures at a glance

#	Measure (Art. 21(2))	What it means in one line
1	Risk analysis & information system security policies	Documented risk methodology + approved security policy set
2	Incident handling	Defined process for detection, response, classification, reporting
3	Business continuity	Backups, recovery, crisis management — tested, not just documented
4	Supply chain security	Due diligence on direct suppliers/providers + contractual security clauses
5	Secure acquisition, development & maintenance	Vulnerability handling and disclosure across the IT lifecycle
6	Effectiveness assessment	Periodic measurement of whether controls actually work
7	Cyber hygiene & training	Basic practices + role-appropriate training
8	Cryptography & encryption	Documented crypto policy; encryption "where appropriate"
9	HR security, access control, asset management	Joiners/movers/leavers, least privilege, asset inventory
10	MFA, secured comms, emergency comms	MFA (or continuous auth) + secured voice/video/text + emergency channels

These ten don't stand alone.

Article 21(1) wraps them in a proportionality principle that determines how much of each you actually have to implement. That's the next section, and it's the most important paragraph of this article.

The proportionality principle (Article 21(1)) - the most important paragraph

What the directive actually says

Article 21(1) requires "appropriate and proportionate technical, operational and organisational measures" to manage risks to network and information systems and to prevent or minimise the impact of incidents.

Five proportionality factors are explicit in the directive.

When assessing whether measures are proportionate, due account must be taken of:

1. The entity's degree of exposure to risks
2. The entity's size
3. The likelihood of incidents occurring
4. The severity of incidents, including their societal and economic impact
5. The state of the art and, where applicable, relevant European and international standards, balanced against the cost of implementation

What proportionality means in practice

A 60-person SaaS provider does not implement controls at the same scale as a 5,000-person hospital chain.

Proportionality is not an opt-out — every entity must address every measure. It scales the depth of implementation, not the coverage.

The five factors create a defensible argument for what "appropriate" means in your context — if you've documented your reasoning. Without documentation, you have no defence against a regulator who thinks your implementation is too thin.

How to actually use it

Build a proportionality memo: one to two pages mapping each of the five factors to your context, with conclusions per measure.

Update it annually or on material change to the business. This becomes the evidence document an auditor or competent authority asks for when they want to know why your controls look the way they do.

The proportionality memo is the most under-appreciated artefact in NIS2 compliance, and the one that converts "minimum viable" from a marketing slogan into a legally defensible position.

The 10 measures, decoded

Each measure follows the same internal template:

1. What the directive requires
2. What it means in practice
3. The minimum evidence pack
4. And the common pitfall.

Measure 1 — Risk analysis and information system security policies (Art. 21(2)(a))

What it requires: Documented policies covering both a risk analysis methodology and information system security as a coherent set of policies.

What it means in practice: Two distinct artefacts that often get conflated. A risk methodology — how you identify, assess, treat, and review information security risks. ISO 27005 is the canonical reference; NIST SP 800-30 is also widely accepted.

Separately, produce a security policy set — typically a master policy plus 8-12 sub-policies covering acceptable use, access control, incident response, BCM, supplier security, cryptography, HR security, and asset management.

Minimum evidence pack:

1. Risk management methodology document, approved by management body
2. Master information security policy, signed and dated, version-controlled
3. Latest risk register output or risk treatment plan, reviewed annually
4. Evidence of management body review at least annually

Common pitfall: Buying a policy template pack from a GRC vendor, dropping in the company name, never updating. Auditors spot it instantly — the language doesn't match the company's actual controls.

Measure 2 — Incident handling (Art. 21(2)(b))

What it requires: Documented procedures for detecting, responding to, classifying, and reporting cybersecurity incidents.

What it means in practice: This measure is tightly coupled with Article 23 NIS2 (incident reporting). The procedure must produce the 24-hour early warning, the 72-hour notification, and the 30-day final report on demand. NIST SP 800-61 Rev. 2 remains the practical baseline for the response process.

Minimum evidence pack:

1. Incident response plan with classification matrix and escalation tree
2. Tabletop exercise records, at least annual
3. Roster of incident response roles with named owners and out-of-hours contacts
4. Logs of past incidents and lessons-learned reports

Common pitfall: A plan that exists on paper but has never been exercised. The first tabletop typically reveals that "the team" doesn't know who calls the CSIRT, what information goes in the early warning, or where the contact list lives at 02:00.

For the reporting mechanics see our article NIS2 Incident Reporting: The 24-72-30 Day Timeline.

Measure 3 — Business continuity (Art. 21(2)(c))

What it requires: Business continuity measures including backup management, disaster recovery, and crisis management.

What it means in practice: Three distinct sub-disciplines, often confused. Backups are technical: 3-2-1 rule, immutable snapshots, periodic restore tests. Disaster recovery is technical recovery of services within an RTO and RPO. Crisis management is the organisational decision-making process during a major incident — who declares a crisis, who speaks to media, who notifies regulators.

Minimum evidence pack:

• Business Impact Analysis (BIA) with documented RTO and RPO per critical service
• Backup policy plus most recent restore test results
• DR plan with last test date
• Crisis management plan with roles and escalation criteria

Common pitfall: Backups that have never been restored. Or DR plans that assume the office is accessible during the disaster the plan is supposed to address. A regulator's first probe will be "show me your last restore test" — if the answer is "we don't run them," the conversation goes downhill fast.

Measure 4 — Supply chain security (Art. 21(2)(d))

What it requires: Security in the relationships between the entity and its direct suppliers or service providers, including security-related aspects of those relationships.

What it means in practice: This is one of NIS2's biggest changes from NIS1. You must identify your direct suppliers and providers, assess their security posture, and embed security requirements in contracts. The directive specifically mentions ICT product and service supply chains as a focus.

Minimum evidence pack:

1. Supplier register with security tier classifications
2. Due-diligence questionnaire results for critical suppliers
3. Standard security clauses in supplier contracts, or addenda for legacy contracts
4. Annual review log

Common pitfall: Treating "supply chain" as IT vendors only. A managed service provider, a SaaS HR platform, or a payroll processor are all in scope under Article 21(2)(d). Many SMEs have 50+ SaaS vendors and have inventoried five.

For the deeper treatment see our article NIS2 Supply Chain Obligations: What Suppliers Must Know.

Measure 5 — Security in acquisition, development and maintenance (Art. 21(2)(e))

What it requires: Security across the lifecycle of network and information systems — acquisition, development, and maintenance — including vulnerability handling and disclosure.

What it means in practice: Two operational components. Secure SDLC if you develop software — threat modelling, secure coding standards, SAST and DAST, dependency management. Vulnerability management for everything else — asset inventory feeding vulnerability scanning, patching SLAs by severity, an exception process. The "vulnerability handling and disclosure" wording also implies a coordinated vulnerability disclosure (CVD) process; publishing a security.txt file on your domain is a low-effort baseline.

Minimum evidence pack:

1. Vulnerability management policy with severity-based remediation SLAs
2. Latest vulnerability scan results and remediation tickets
3. Secure development standards if applicable
4. CVD policy and a published security.txt

Common pitfall: Patching SLAs that exist only on paper. CISA KEV catalogue entries sit exploitable in production for 90+ days because the change window is "every other Wednesday" and the asset owner is on parental leave.

Measure 6 — Policies to assess effectiveness (Art. 21(2)(f))

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

What it means in practice: This is the measure that closes the loop. You don't just implement controls — you measure whether they work. Three layers: monitoring via control telemetry (logging, alerting, dashboards), internal audit through periodic review of control design and operation, and independent testing via penetration tests or red teaming.

Minimum evidence pack:

1. Control effectiveness metrics (KPIs/KRIs) reviewed at management body level
2. Internal audit plan and most recent audit report
3. Penetration test report from the last 12-24 months
4. Remediation tracking for findings

Common pitfall: "Effectiveness" reduced to "we have the control" rather than "we have evidence the control works." A documented MFA policy with 60% rollout coverage is not effective MFA. The regulator will ask for the rollout metric.

Measure 7 — Basic cyber hygiene and training (Art. 21(2)(g))

What it requires: Basic cyber hygiene practices and cybersecurity training.

What it means in practice: Two parts. Cyber hygiene covers patching, MFA, password management, email filtering, endpoint protection — the unglamorous fundamentals.

Training must be role-appropriate: awareness training for everyone, deeper training for IT and security staff, and tailored briefings for the management body to satisfy Article 20(2) obligations.

Minimum evidence pack:

1. Annual training completion records for every employee, including management body
2. Phishing simulation results with trend analysis
3. Onboarding security training records
4. Targeted training records for elevated-privilege roles

Common pitfall: Annual 30-minute video that 100% of staff click through in 11 minutes. Regulators ask for evidence of effectiveness — phishing click-through rates, time-to-report, completion follow-up — not completion percentages alone.

For the management body angle see our article NIS2 Board-Level Accountability: Personal Liability Explained.

Measure 8 — Cryptography and encryption (Art. 21(2)(h))

What it requires: Policies and procedures regarding the use of cryptography and, where appropriate, encryption.

What it means in practice: A documented cryptographic policy covering approved algorithms and key lengths (typically aligned to ENISA recommendations or NIST SP 800-131A), key management lifecycle (generation, storage, rotation, revocation, destruction), encryption-at-rest and in-transit standards, and specific deployments (TLS minimum versions, full-disk encryption, database encryption).

The "where appropriate" wording is significant — it ties back to the proportionality principle. You must justify where you do and don't apply encryption.

Minimum evidence pack:

1. Cryptographic policy
2. Key management procedure
3. TLS configuration evidence (e.g. SSL Labs A or A+ on public endpoints)
4. Encryption coverage report — which systems, which state of data

Common pitfall: Treating "encrypt everything" as the answer. A regulator will ask why a specific dataset is or isn't encrypted, and the answer must trace to the proportionality memo and the risk analysis — not "we just turned it on."

Measure 9 — HR security, access control, asset management (Art. 21(2)(i))

What it requires: Human resources security, access control policies, and asset management.

What it means in practice: Three classical ISMS disciplines bundled together. HR security covers pre-employment screening (proportionate and lawful under GDPR), security clauses in employment contracts, and the joiners/movers/leavers process. Access control covers least privilege, role-based access, periodic access reviews, and privileged access management. Asset management covers hardware and software inventory, ownership, classification, and lifecycle.

Minimum evidence pack:

1. Joiners/movers/leavers procedure with execution evidence (Day-1 access provisioning logs, Day-0 deprovisioning logs)
2. Access review records, typically quarterly for privileged access and annual for standard access
3. Hardware and software asset register
4. Data classification policy with applied examples

Common pitfall: Leavers who retain access weeks after departure. The deprovisioning gap is the single most common audit finding in this measure. SaaS sprawl makes it worse — IT offboards from AD but forgets the 30 third-party tools the leaver had access to.

Measure 10 — MFA, secured comms, and emergency comms (Art. 21(2)(j))

What it requires: Multi-factor authentication or continuous authentication solutions, secured voice/video/text communications, and secured emergency communication systems within the entity, where appropriate.

What it means in practice: Three concrete requirements often handled separately. MFA (or continuous authentication) — minimum standard for privileged access; expanding to all access in mature SMEs. Secured comms — encrypted email and messaging for sensitive communications, secured video conferencing for board-level discussions. Emergency comms — an out-of-band channel for use during a major incident, when primary email or Teams may be compromised. Often overlooked.

Minimum evidence pack:

1. MFA coverage report — percentage of identities, broken down by privileged versus standard
2. Secured comms platform list (Signal, encrypted email, etc.) with usage policy
3. Emergency communication plan with documented out-of-band channel
4. Incident response plan referencing the emergency comms channel

Common pitfall: No emergency comms channel. During the major-incident tabletop, the team realises they're using the same compromised email system they're trying to discuss the breach on. The out-of-band channel must be set up before the incident.

What about the Implementing Regulation?

Most aggregator content gets this wrong. Commission Implementing Regulation (EU) 2024/2690 specifies technical and methodological requirements for the Article 21(2) measures — but it applies only to specific entity types: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, online marketplace providers, online search engine providers, social networking platform providers, and trust service providers.

For other essential and important entities, the Implementing Regulation is reference material rather than directly binding — though national competent authorities may use its specifications as a benchmark for what "appropriate and proportionate" looks like in practice.

The practical advice: even if your entity type isn't in scope of the Implementing Regulation, treat its specifications as the standard regulators will trend toward. The network security baseline in the Annexes is particularly useful for SMEs as a reference for what "good" looks like.

Cross-cutting pitfalls

Five things that catch SMEs across multiple measures:

1. Documentation that isn't dated, versioned, or signed. Auditors discount undated documents.
2. Policies disconnected from practice. Written controls that don't match what staff actually do.
3. No proportionality memo. Leaving the regulator to decide what "appropriate" means in your context.
4. Tabletops that have never been run. Incident response, business continuity, and crisis management plans untested.
5. Treating Article 21 as a one-time project. The directive implies periodic review; member state guidance often makes it explicit.

Frequently asked questions

Are all 10 measures mandatory or can I skip ones that don't apply? All apply. Proportionality scales the depth of implementation, but coverage of every measure is non-negotiable.

Does Article 21 require a specific framework like ISO 27001? No. ISO 27001 covers most of Article 21 if implemented well, but it is not required.

What's the difference between Article 21 and Article 23? Article 21 is risk management measures; Article 23 is incident reporting. They're tightly coupled but distinct.

How often do I need to review Article 21 measures? At least annually. Member states may impose more frequent reviews for essential entities.

Does Article 21 apply to my US parent company? Article 21 binds the EU entity. US parent company practices matter only insofar as they affect the EU entity's compliance posture.

If I'm DORA-regulated, do I still have to comply with Article 21? Largely no. DORA is lex specialis for financial entities under Article 4 NIS2. See our article NIS2 vs DORA.

What evidence does my national CSIRT actually look at? Varies by country. Guidance is still maturing across the EU. The evidence packs in this article are a defensible baseline.

The bottom line

Three takeaways:

1. Article 21 is a coherent system, not 10 standalone tickboxes. The measures interlock — incident handling needs effectiveness assessment needs business continuity needs supply chain visibility.
2. Proportionality is your friend, but only if you document it. The memo is non-negotiable.
3. Evidence beats documentation. Auditors don't reward paper, they reward operating controls.

If you're scoping where to start, our article the complete NIS2 and DORA compliance guide walks through a 10-step roadmap. If you're trying to figure out which obligations apply at all, our article NIS2 vs DORA is the next read.

---

Sources & further reading

• Directive (EU) 2022/2555 — NIS2 — Articles 20, 21(1), 21(2)(a) through (j), 23
• Commission Implementing Regulation (EU) 2024/2690 — technical and methodological requirements for specific entity types
• ISO/IEC 27001:2022 and ISO/IEC 27005:2022 — referenced standards
• NIST SP 800-30, NIST SP 800-61 Rev. 2, NIST SP 800-131A — alternative frameworks
• ENISA — cryptographic guidelines and NIS2 implementation reference
• CISA — Known Exploited Vulnerabilities catalogue