Under the NIS2 Directive, Article 21 is where “we take security seriously” becomes “prove it.” Article 21 requirements set the minimum cybersecurity risk-management measures that in-scope organisations must implement and can evidence in practice.
EU member states may differ in how they transpose NIS2 into national law, but Article 21’s intent is consistent: risk-based, proportionate controls, supported by operational proof.
This guide translates Article 21 into practical actions, evidence examples, and a Minimum Viable Evidence Pack that SMEs can build without over-engineering.
TL;DR
NIS2 Article 21 requires in-scope organisations to implement appropriate and proportionate cybersecurity risk-management measures and prove they operate in practice. It covers 10 mandatory areas: risk, incidents, continuity, supply chain, secure development, testing, training, crypto, access/HR security, and MFA/secure communications. Readiness means three things: ownership, evidence, and an improvement cycle. Use the NIS2 Article 21 Readiness Assessment below to score your current controls and identify the gaps that need attention first.
If you want structured support, Sunbytes Compliance Readiness helps you build an evidence pack and a prioritised remediation roadmap aligned with Article 21.
Netherlands update: Cyberbeveiligingswet status in June 2026
For Dutch organisations, NIS2 is being transposed through the Cyberbeveiligingswet (Cbw). As of June 2026, the law should not be described as fully in force yet: the Tweede Kamer adopted the proposal on 15 April 2026, and the proposal was still being handled by the Eerste Kamer in June 2026.
The NCTV notes that the Eerste Kamer issued its report on 2 June 2026, the government answered the questions raised, and plenary treatment was expected next. Until the Cyberbeveiligingswet enters into force, NCTV states that there are no direct NIS2 or CER obligations for organisations under the Dutch implementation law, although some rights may already apply because of direct effect of certain NIS2 provisions. The practical implication is simple: do not claim final compliance under Dutch law yet, but do start building the Article 21 control evidence now.
What does NIS2 Article 21 require?
Article 21 requires “appropriate and proportionate” cybersecurity risk-management measures and the ability to demonstrate those measures are working in practice.
In plain terms, you’re expected to show security is managed as a repeatable process:
- Risks are identified and prioritised
- Controls are implemented and owned
- Controls are monitored and reviewed
- Decisions are documented (including trade-offs)
- Evidence can be produced quickly when requested
The 3 principles behind Article 21 (so you don’t overbuild)
NIS2 Article 21 is intentionally outcome-driven. Rather than mandating specific technologies or frameworks, it defines how organisations are expected to think about, manage, and evidence cybersecurity risk. Three principles underpin every control listed in Article 21 and understanding these principles is key to avoiding over-engineering.
Risk-based, not checklist-based
Article 21 expects decisions driven by your real threats and business impact, not generic templates. You should be able to explain why you chose a control level, or why you did not copy one from a template.
Security extends to your supply chain
You’re accountable for risks introduced by suppliers and service providers—especially those that support critical services. This is often where SMEs get caught off guard.
Evidence matters more than intent
Regulators and buyers don’t ask what you meant to do—they ask what you can prove: logs, tickets, test results, training completion, review notes.
What are the 10 mandatory cybersecurity risk-management measures in Article 21?
Article 21 defines ten minimum areas you must address. The goal isn’t “perfect maturity”—it’s a defensible baseline that’s owned, documented, and operating.
| Measure area | What “good enough” looks like (SME baseline) | Evidence examples buyers/regulators verify |
|---|---|---|
| 1) Risk analysis & security policies | Document top risks + agreed treatment | Risk register, policy approval, asset inventory |
| 2) Incident handling | You can detect, respond, and learn | IR plan, escalation matrix, incident tickets, PIR template |
| 3) Business continuity & crisis management | You can restore services | Backup policy, restore test results, RTO/RPO, DR runbook |
| 4) Supply chain security | You know your critical suppliers and expectations | Vendor inventory, security clauses, review checklist, comms process |
| 5) Secure acquisition/dev/maintenance | Security embedded into change and patching | SDLC gates, change records, patch SLAs, vuln process |
| 6) Effectiveness testing | Controls are tested and improved | Scan/pen test summary, KPI dashboard, action tracker |
| 7) Cyber hygiene & training | People know basic cyber behaviours | Training material, completion records, onboarding/offboarding checklist |
| 8) Cryptography/encryption | Data is protected where it matters | Encryption policy, configs, TLS settings, key approach |
| 9) Access control, asset mgmt, HR security | Access is lifecycle-controlled | JML process, access reviews, asset inventory, baseline configs |
| 10) MFA & secure communications | MFA on critical access + fallback comms | MFA configuration proof, admin hardening, emergency channel drill |
NIS2 Article 21 Readiness Assessment
Use this 10-question self-assessment to turn Article 21 into a first gap list. It is not a legal opinion or a formal audit. It is a practical way to see whether your current controls are documented, owned, and supported by evidence.
NIS2 Article 21 Readiness Assessment
Answer each question based on what you can prove today, not what is planned.
Use this output as a starting point for an internal readiness discussion. For a formal position, align the result with your national implementation rules, sector guidance, and legal counsel.
If the assessment returns multiple “Partly” or “No” answers, treat that as a prioritisation signal. The next step is not to write more policies. The next step is to confirm which gaps create the highest operational or compliance risk, assign owners, and turn them into a remediation plan.
Measure-by-measure: what it means and what evidence to prepare
Risk analysis & security policies
You must identify cybersecurity risks to critical systems/services and define how they’re managed. Evidence should show risks are prioritised and reviewed, not just described.
Evidence examples: risk assessment report, risk register, security policy (approved), asset/service inventory, review notes.
Incident handling
You need a workable incident response process: roles, escalation, actions, and learning loops. Regulators focus on preparedness: can your team actually execute it?
Evidence examples: IR plan, escalation matrix, incident log/tickets, post-incident review template, tabletop notes.
Business continuity & crisis management
You must maintain service availability during/after incidents. Backups that “run” aren’t enough—restore testing is the credibility marker.
Evidence examples: backup policy, restore test results, RTO/RPO definitions, DR runbook, crisis comms plan.
Supply chain security
You must manage third-party risks. For SMEs, a simple vendor inventory + criticality rating + baseline expectations goes a long way.
Evidence examples: vendor list with criticality, security addendum/clauses, vendor review checklist, incident comms procedure.
Secure system acquisition, development, and maintenance
Security must be part of how you buy, build, change, and patch systems—not bolted on later. SMEs don’t need heavyweight bureaucracy—just repeatable gates.
Evidence examples: secure SDLC notes, change management records, patch policy + SLAs, vulnerability intake/disclosure channel.
Effectiveness testing of cybersecurity measures
You must verify controls actually work. The emphasis is improvement over time, not constant pen testing everywhere.
Evidence examples: scan/pen test summaries, internal review notes, KPI dashboard (MFA coverage, patch SLA, restore tests), action tracker.
Cyber hygiene and staff training
Awareness needs to be consistent and role-appropriate. Evidence is simple: materials + attendance + onboarding/offboarding steps.
Evidence examples: training content, completion logs, phishing simulation report (optional), JML checklist.
Cryptography and encryption
Where appropriate, use cryptography to protect confidentiality and integrity—especially for sensitive data and admin traffic.
Evidence examples: encryption policy, TLS settings, encryption-at-rest proof, key management approach (high level).
Access control, asset management, and HR security
This is lifecycle control: least privilege + joiner/mover/leaver discipline + asset visibility.
Evidence examples: access review logs, JML process, asset inventory, endpoint baseline settings.
Multi-factor authentication and secure communications
MFA on critical systems and admin access is a baseline expectation. Also define secure channels and emergency communications.
Evidence examples: MFA enforcement screenshots/configs, admin hardening, break-glass controls, emergency channel drill notes.
“Minimum Viable Evidence Pack” for SMEs Under NIS2 Article 21
For SMEs, the NIS2 Article 21 requirement is about being able to demonstrate control in a credible, proportionate way. A Minimum Viable Evidence Pack is a focused set of policies, records, and technical proof that collectively show regulators you have implemented, operated, and reviewed the required cybersecurity risk-management measures.
Before building a full Article 21 evidence pack, many SMEs need a security baseline first: which controls already work, which gaps need remediation, and which actions should move into the next 30/60/90 days. Sunbytes CyberCheck supports that starting point by assessing your current posture and turning findings into a practical remediation roadmap.
Governance & Risk
Cybersecurity Risk Assessment Report
Identifies the most relevant cybersecurity risks to systems and services and prioritises them based on impact and likelihood. Shows that security decisions are risk-based rather than generic.
Information Security Policy (Management-Approved)
Defines security objectives, roles, and principles, with clear management approval. Demonstrates accountability and governance at executive level.
Risk Treatment or Remediation Plan
Links identified risks to mitigation actions, owners, and timelines. Shows that risks are actively managed, not just documented.
Asset Inventory (Systems & Data)
Lists critical systems, services, and data types. Provides the foundation for access control, risk analysis, and incident response.
Incident & Continuity Readiness
Incident Response Plan (With NIS2 Reporting Alignment)
Defines how incidents are detected, escalated, managed, and resolved, including decision roles and reporting triggers.
Incident Log or Incident Report Template
Provides a structured way to document incidents, root causes, and lessons learned. Can include records from tests or tabletop exercises.
Business Continuity / Backup Evidence
Shows that backups exist and can be restored. Typically includes backup policies and recent restore test results.
Technical & Operational Controls
Access Control & MFA Evidence
Demonstrates that access to critical systems is restricted and protected with multi-factor authentication. Screenshots or configuration records are usually sufficient.
Patch & Vulnerability Management Records
Shows how vulnerabilities and patches are identified, prioritised, and applied. Includes policies and sample logs or scan results.
Secure Configuration or Hardening Evidence
Documents baseline security configurations for systems or endpoints. Tool outputs or screenshots are acceptable for SMEs.
Encryption or Data Protection Evidence
Explains where encryption is applied (in transit and/or at rest) and why. Supported by policy and configuration examples.
Penetration Test or Security Assessment Summary
Provides evidence that security controls are tested for effectiveness. An executive-level summary is sufficient.
People & Awareness
Cybersecurity Awareness Training Materials
Slides, videos, or learning platform content show that staff receive guidance on basic cyber risks and expected behaviour.
Training Attendance Records
List of participants and completion dates demonstrate that training is delivered and completed, with dates and participants recorded.
Joiner / Mover / Leaver Access Checklist
Confirms that access rights are granted, changed, and revoked consistently throughout the employee lifecycle.
If you want to understand how these Article 21 evidence requirements fit into your broader NIS2 obligations, read our NIS2 Compliance Readiness for EU SMEs: Essential Guide + Practical Checklist to get a structured, end-to-end view of what to do next.
Three Common Gaps in Article 21 Readiness
Controls Exist but Are Not Documented
Security measures are often implemented informally: MFA is enabled, backups run, access is restricted, but nothing is written down. Without documentation, these controls are difficult to explain, review, or defend. Regulators assess what can be demonstrated, not what is assumed to exist.
Supplier Risks Are Not Assessed
Many organisations rely heavily on third parties but lack visibility into which suppliers are critical or how their risks are managed. Contracts may be silent on security, and incident scenarios involving suppliers are rarely considered. Under Article 21, this is a clear and recurring weakness.
No Proof of Effectiveness Testing
Even where controls exist and are documented, organisations often cannot show that they work. Backups are untested, incident plans are unexercised, and vulnerabilities are not reviewed systematically. Article 21 expects evidence of testing, review, and improvement — not static controls.
How to Prepare for Article 21 Without Over-Engineering
NIS2 Article 21 does not expect SMEs to build enterprise-grade security programmes. It explicitly requires appropriate and proportionate measures, taking into account risk exposure, size, and implementation cost. The challenge for most organisations is how to do just enough — and no more — while still being defensible.
A practical way to approach this is to translate Article 21 into four simple questions for each required measure:
- What must we implement?
- How do we prove it?
- Who owns it?
- How much effort does it realistically take?
A Practical Mapping: Measure → Evidence → Owner → Effort
This mapping turns Article 21 from legal text into an operational roadmap.
- Measure: What Article 21(2)(a)–(j) explicitly requires you to address.
- Evidence: What regulators, auditors, or customers can reasonably verify to confirm the measure is implemented and operating.
- Owner:The person accountable for maintaining the measure and its evidence. In SMEs, this is often one individual wearing multiple hats (e.g. IT Manager acting as Security Lead).
- Typical Effort: A realistic estimate of the work involved to reach a defensible baseline — not theoretical maturity.
This approach ensures that every requirement has a clear purpose, proof, and accountable owner, reducing duplication and unnecessary work.
Understanding the Effort Scale (SME Reality Check)
To avoid over-engineering, effort should be assessed consistently:
- S (Small): 1–5 working days
Primarily documentation, light configuration, or formalising what already exists. - M (Medium): 2–6 weeks
Process definition, tooling improvements, evidence setup, and basic testing. - L (Large): 6–12+ weeks
Cross-team coordination, architectural changes, new tooling, or repeated testing cycles.
For most SMEs, the majority of Article 21 measures fall into Small or Medium effort when approached pragmatically.
How Sunbytes Supports NIS2 Article 21 Compliance Readiness
Sunbytes takes an evidence-first, regulator-aligned approach to NIS2 Article 21 readiness. We focus on what authorities, auditors, and customers actually ask for: clear risk rationale, operational proof, and realistic prioritisation. Our Secure by Design work maps controls to ISO 27001 and NIS2 expectations so SMEs can move from scattered security activity to evidence they can review, improve, and explain.
If you are not sure where the real gaps are, start with Sunbytes CyberCheck to establish a baseline and remediation roadmap. If you already know the gaps and need to build audit-ready evidence, Sunbytes Compliance Readiness focuses on evidence packs, control ownership, and prioritised remediation aligned with NIS2 Article 21 requirements. Schedule a free call to discuss the right starting point.
For Dutch readers: what changed in June 2026?
The main change is timing clarity. The Cyberbeveiligingswet had passed the Tweede Kamer and was still under Eerste Kamer treatment in June 2026. That means Dutch organisations should avoid claiming final compliance with the national law before it enters into force, but they should still prepare the Article 21 evidence pack because the underlying security risks and buyer due diligence expectations already exist.
FAQs
Not necessarily “perfect,” but you should aim to cover all 10 measure areas at a baseline level—because Article 21(2) lists them as minimum areas.
A practical approach for SMEs:
- Week 1–2: establish owners + minimum policies + evidence folder structure
- Week 3–6: implement the highest-risk controls (MFA, backups/restore testing, vulnerability handling)
- Ongoing: improve maturity with measurable KPIs and periodic reviews
NIS2 explicitly frames measures as “appropriate and proportionate” and calls out factors like state-of-the-art, relevant standards, cost of implementation, your risk exposure, size, and potential impact of incidents.
In practice, “proportionate” usually means:
- You can justify why a measure is implemented in a certain way (risk-based)
- You have evidence it’s operating (not just a policy PDF)
- You prioritise controls that reduce likely/high-impact risks first
ISO 27001 can help a lot, but NIS2 readiness still depends on scope + the specific obligations + evidence of operation. NIS2 also emphasizes incident reporting timelines (Article 23) and supply-chain practices. Treat ISO as a strong foundation—then validate gaps against Article 21/23 and local transposition rules.
A policy explains intent. Evidence proves the control is real and repeatable.
Example: “We do backups” (policy) vs. restore test results + RTO/RPO + runbook + last 3 test tickets (evidence). Evidence-readiness is what procurement teams and auditors tend to ask for first
Let's start with Sunbytes
Let us know your requirements for the team and we will contact you right away.
