A NIS2 compliance checklist is useful only when it shows what your company can demonstrate with evidence. A policy name is not enough. A scan report is not enough. For EU SMEs preparing for NIS2, the practical question is: can your team prove that the required cybersecurity controls exist, operate, and are reviewed?
NIS2 Article 21 requires essential and important entities to take appropriate and proportionate technical, operational, and organisational measures to manage cybersecurity risks. For SMEs, that means turning broad legal requirements into evidence: policies, risk assessments, incident records, supplier reviews, access logs, testing reports, and management approval.
This checklist turns the 10 Article 21(2) measure areas into 40 control checkpoints. Use it as a self-assessment before a formal NIS2 gap analysis, customer security review, board update, or compliance readiness assessment.
TL;DR
NIS2 compliance requires EU SMEs to demonstrate 40 practical control checkpoints across the 10 Article 21(2) cybersecurity risk-management measures. This checklist covers risk policy, incident handling, business continuity, supply chain security, secure development, control effectiveness, cyber hygiene, cryptography, access control, asset management, and MFA or secure communications.
The 10 Article 21(2) measures this checklist covers:
- Risk analysis and information system security policies: 4 controls
- Incident handling: 4 controls
- Business continuity and crisis management: 4 controls
- Supply chain security: 4 controls
- Security in system acquisition, development, and maintenance: 4 controls
- Assessing the effectiveness of cybersecurity measures: 4 controls
- Basic cyber hygiene and cybersecurity training: 4 controls
- Cryptography and encryption: 4 controls
- Human resources security, access control, and asset management: 4 controls
- Multi-factor authentication and secure communications: 4 controls
If your result includes RED or AMBER controls, move those items into a gap register and prioritise them through a structured NIS2 gap analysis.
What NIS2 Article 21 requires and who this checklist is for
NIS2 Article 21 is the main risk-management article in the Directive. It requires in-scope organisations to apply cybersecurity measures that are appropriate to their risk, size, exposure, and service impact.
For an EU SME, this does not mean copying an enterprise security programme. It means proving that the organisation has identified its risks, assigned ownership, implemented baseline controls, and can show evidence when a regulator, customer, insurer, or board member asks.
This checklist is for:
- EU SMEs that already know or suspect they fall under NIS2.
- CTOs, IT Managers, CISOs, Compliance Managers, and founders preparing evidence.
- Companies asked by customers, suppliers, auditors, or investors to show NIS2 readiness.
- Dutch or wider EU organisations that need a practical evidence baseline before a formal review.
This checklist is not a legal opinion. NIS2 is implemented through national law, so sector scope, supervisory authority, registration details, and enforcement process can differ by Member State. Use this checklist as a readiness tool, then confirm national requirements with a qualified NIS2 adviser.
If you still need to confirm whether NIS2 applies to your company, start with a scope test before using this checklist.
How this NIS2 compliance checklist connects to Article 20 governance
NIS2 readiness is not only an IT task. Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee implementation, and follow training.
That affects the evidence your company should prepare. If the board approves a risk treatment plan, there should be a dated approval record. If management receives a cybersecurity KPI report, there should be a report pack or meeting note. If board members complete NIS2 training, there should be training evidence.
For the governance side of NIS2, connect this checklist to your management accountability workstream.
How to use this checklist
Score each control as RED, AMBER, or GREEN. The score is based on evidence, not intention.
| Score | Meaning | What to do next |
|---|---|---|
| RED | The control is missing, undocumented, or not assigned to an owner. | Add it to the gap register and prioritise remediation. |
| AMBER | The control exists partly, but evidence is outdated, incomplete, or not reviewed. | Define the missing evidence and owner. |
| GREEN | The control exists, operates in practice, and has current evidence. | Keep the evidence in your NIS2 evidence pack and review it on schedule. |
For each control, collect the minimum evidence listed in the table. Do not rely on verbal confirmation. NIS2 readiness depends on what your organisation can demonstrate.
A good self-assessment process has five steps:
- Confirm which systems, services, suppliers, and data are in scope.
- Score each control as RED, AMBER, or GREEN.
- Assign an owner for every RED and AMBER control.
- Place each gap into a risk-ranked register.
- Convert the register into a remediation roadmap and evidence pack.
If the checklist shows many RED or AMBER items, the next step is not to write more policy. The next step is a structured assessment that determines severity, ownership, sequence, and evidence requirement.
The NIS2 compliance checklist: 40 controls
This section maps the 10 Article 21(2) cybersecurity risk-management areas into 40 practical controls. Each control includes minimum evidence to help your team assess whether the control can be demonstrated.
Art.21(2)(a) Policies on risk analysis and information system security
| Control to demonstrate | Minimum evidence | Status | |
|---|---|---|---|
| 1 | A written information security policy exists, has been approved by management, and has been reviewed in the past 12 months. | Signed information security policy with review date and management approval. | RED / AMBER / GREEN |
| 2 | A formal risk assessment methodology has been defined and documented. | Risk assessment methodology document, either standalone or embedded in the security policy. | RED / AMBER / GREEN |
| 3 | A risk assessment has been conducted for in-scope systems and services, with findings documented. | Risk assessment report dated within the past 12 months. | RED / AMBER / GREEN |
| 4 | A risk treatment plan exists, with accepted residual risks documented and approved by management. | Risk treatment plan with owner, due date, status, and management sign-off for residual risk acceptance. | RED / AMBER / GREEN |
Art.21(2)(b) Incident handling
| Control to demonstrate | Minimum evidence | Status | |
|---|---|---|---|
| Control to demonstrate | Minimum evidence | Status | |
| 5 | An incident response procedure exists and includes the 24-hour early warning and 72-hour incident notification timelines required by Article 23. | Incident response procedure with Article 23 timelines stated. | RED / AMBER / GREEN |
| 6 | Roles and responsibilities for incident response are documented and assigned to named individuals or roles. | RACI matrix, escalation tree, or incident role matrix. | RED / AMBER / GREEN |
| 7 | The organisation has run at least one incident tabletop exercise, walkthrough, or test in the past 12 months. | Exercise record with date, scenario, participants, decisions, and lessons learned. | RED / AMBER / GREEN |
| 8 | An incident log is maintained for significant incidents and near-misses. | Incident register showing date, category, severity, owner, status, and closure record. | RED / AMBER / GREEN |
NIS2 Article 23 creates a short reporting window. The organisation needs evidence that the reporting path has been tested before a significant incident occurs.
Art.21(2)(c) Business continuity and crisis management
| Control to demonstrate | Minimum evidence | Status | |
|---|---|---|---|
| Control to demonstrate | Minimum evidence | Status | |
| 9 | A business continuity plan exists for critical services in scope of NIS2. | BCP identifying critical services, recovery procedures, system owners, and dependencies. | RED / AMBER / GREEN |
| 10 | Recovery time objectives and recovery point objectives are documented for critical services. | RTO/RPO record within the BCP, disaster recovery plan, or IT recovery document. | RED / AMBER / GREEN |
| 11 | The BCP has been tested in the past 12 months. | BCP test record with date, test type, participants, outcomes, and follow-up actions. | RED / AMBER / GREEN |
| 12 | A crisis communication plan exists and names internal and external parties to notify during a significant incident. | Crisis communication plan or BCP section with contact list, escalation path, and message approval process. | RED / AMBER / GREEN |
Art.21(2)(d) Supply chain security
| Control to demonstrate | Minimum evidence | Status | |
|---|---|---|---|
| Control to demonstrate | Minimum evidence | Status | |
| 13 | A supply chain security policy exists for suppliers with access to systems, data, or critical services. | Supply chain security policy approved by management. | RED / AMBER / GREEN |
| 14 | Critical suppliers have been identified and assessed for cybersecurity risk in the past 12 months. | Supplier risk register and completed security assessment records for critical suppliers. | RED / AMBER / GREEN |
| 15 | Contractual security requirements are in place for suppliers with access to in-scope systems or data. | Security clauses, DPA, security schedule, or contractual control requirements for critical suppliers. | RED / AMBER / GREEN |
| 16 | A process exists for monitoring supplier security posture on an ongoing basis. | Supplier review schedule, reassessment records, or supplier risk register with review dates. | RED / AMBER / GREEN |
Supplier security is one of the easiest areas to under-document. If a critical supplier has access to customer data, production systems, or core infrastructure, your evidence should show when the supplier was reviewed, what was checked, and what contractual controls apply.
Art.21(2)(e) Security in network and information systems acquisition, development, and maintenance
| Control to demonstrate | Minimum evidence | Status | |
|---|---|---|---|
| 17 | A secure development or system acquisition procedure exists for software, systems, and infrastructure changes. | Secure development policy, procurement security procedure, or change control standard. | RED / AMBER / GREEN |
| 18 | Security requirements are documented in major procurement and development projects. | Security requirements in procurement documents, project backlog, architecture decision record, or security user stories. | RED / AMBER / GREEN |
| 19 | Vulnerability scanning is conducted regularly on in-scope systems, with findings tracked and remediated. | Recent vulnerability scan results and remediation tracking record. | RED / AMBER / GREEN |
| 20 | Penetration testing or equivalent security testing has been conducted on critical systems, with findings documented and remediation tracked. | Penetration test report or security assessment report, dated within the agreed risk cycle, with retest evidence for critical and high findings. | RED / AMBER / GREEN |
A scan report alone is not enough evidence. The organisation should also show who reviewed findings, how severity was decided, which owner accepted the fix, and whether high-risk findings were retested.
Art.21(2)(f) Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
| Control to demonstrate | Minimum evidence | Status | |
|---|---|---|---|
| 21 | An internal audit or security assessment programme exists to verify whether cybersecurity controls work. | Internal audit schedule, control assessment plan, or security review programme. | RED / AMBER / GREEN |
| 22 | At least one internal security audit or assessment has been conducted in the past 12 months, with findings presented to management. | Recent audit or assessment report with evidence of management review. | RED / AMBER / GREEN |
| 23 | A corrective action process exists for tracking and resolving audit findings. | Corrective action register showing open findings, owners, due dates, closure dates, and evidence links. | RED / AMBER / GREEN |
| 24 | Cybersecurity KPIs or control metrics are tracked and reported to management. | Security KPI report, management dashboard, or recurring board/leadership reporting pack. | RED / AMBER / GREEN |
This is the point where many SMEs move from “we have security controls” to “we can prove control effectiveness.” The difference matters during customer due diligence, insurance review, board reporting, and regulatory supervision.
Art.21(2)(g) Basic cyber hygiene practices and cybersecurity training
| Control to demonstrate | Minimum evidence | Status | |
|---|---|---|---|
| 25 | Staff have completed cybersecurity awareness training in the past 12 months. | Training completion records with staff name, date, and content covered. | RED / AMBER / GREEN |
| 26 | Management body members have completed NIS2-specific cybersecurity training. | Board or management training completion records mapped to Article 20(2). | RED / AMBER / GREEN |
| 27 | An acceptable use policy exists for systems, data, and devices. | Acceptable use policy approved by management and acknowledged by staff. | RED / AMBER / GREEN |
| 28 | A process exists for managing patches and software updates on critical systems. | Patch management procedure and recent patch activity evidence. | RED / AMBER / GREEN |
Management training should not be hidden inside general awareness training. NIS2 links management accountability to cybersecurity risk oversight, so board or senior leadership training should have its own record.
Art.21(2)(h) Policies and procedures regarding cryptography and encryption
| Control to demonstrate | Minimum evidence | Status | |
|---|---|---|---|
| 29 | A cryptography policy exists and states which data must be encrypted at rest and in transit. | Cryptography policy naming encryption scope, standards, and ownership. | RED / AMBER / GREEN |
| 30 | Personal data and sensitive business data are encrypted at rest on critical systems. | Storage encryption configuration, cloud control attestation, system setting record, or security assessment confirmation. | RED / AMBER / GREEN |
| 31 | Data in transit between systems is encrypted using current protocols. | TLS configuration record, certificate inventory, or network assessment confirming encryption in transit. | RED / AMBER / GREEN |
| 32 | Cryptographic keys are managed through documented procedures. | Key management procedure, key rotation record, HSM/KMS usage evidence, or access control record for key administrators. | RED / AMBER / GREEN |
Encryption evidence should be technical. A policy says what should happen. Configuration records, system attestations, and review logs show whether it happens.
Art.21(2)(i) Human resources security, access control policies, and asset management
| Control to demonstrate | Minimum evidence | Status | |
|---|---|---|---|
| Control to demonstrate | Minimum evidence | Status | |
| 33 | An access control policy exists defining how access is granted, reviewed, changed, and revoked. | Access control policy approved by management. | RED / AMBER / GREEN |
| 34 | Access reviews for critical systems have been conducted in the past 12 months. | Access review records showing system, reviewer, date, findings, and access changes. | RED / AMBER / GREEN |
| 35 | A joiners, movers, and leavers procedure exists to revoke or adjust access when staff leave or change roles. | JML procedure and recent evidence, such as access revocation logs for a leaver. | RED / AMBER / GREEN |
| 36 | An inventory of critical assets exists and is maintained. | Asset inventory covering systems, applications, data stores, owners, classification, and review date. | RED / AMBER / GREEN |
Access reviews are stronger when they result in actual changes. Keep records of removed accounts, changed roles, disabled dormant users, and management approval for exceptions.
Art.21(2)(j) Multi-factor authentication, continuous authentication, and secure communications
| Control to demonstrate | Minimum evidence | Status | |
|---|---|---|---|
| Control to demonstrate | Minimum evidence | Status | |
| 37 | MFA is deployed for remote access to in-scope systems. | MFA configuration evidence for VPN, remote administration, cloud admin, or equivalent remote access paths. | RED / AMBER / GREEN |
| 38 | MFA is deployed for administrative access to critical systems and infrastructure. | Admin MFA policy, identity provider configuration, privileged access record, or security assessment confirmation. | RED / AMBER / GREEN |
| 39 | MFA or continuous authentication is deployed for email and productivity systems handling sensitive data. | Microsoft 365, Google Workspace, or identity provider policy evidence. | RED / AMBER / GREEN |
| 40 | An exception process exists for systems where MFA, continuous authentication, or secure communication controls are not yet deployed. | Exception register with risk acceptance, owner, compensating control, and remediation timeline. | RED / AMBER / GREEN |
A temporary exception is still a risk decision. It should have an owner, expiry date, compensating control, and remediation plan. Open-ended MFA exceptions should be treated as AMBER or RED, depending on exposure.
RED or AMBER controls in your checklist results? A checklist identifies what is missing. A structured NIS2 readiness assessment determines how serious each gap is, which controls need evidence first, and what should move into the remediation roadmap.
Sunbytes helps EU SMEs turn checklist results into a practical NIS2 readiness path: gap report, risk-ranked register, remediation roadmap, board summary, and evidence pack structure. Start with a NIS2 compliance readiness assessment.
What to do with your NIS2 compliance checklist results
After completing the checklist, do not treat all gaps equally. A missing incident reporting procedure is not the same as an outdated training record. A supplier contract without security clauses is not the same as a missing certificate inventory.
Use the table below to decide the next step.
| Checklist result | What it means | Next step |
|---|---|---|
| RED controls | Critical gaps exist. The control is missing, undocumented, or not owned. | Start a structured assessment to prioritise remediation. |
| AMBER controls | The control exists partly, but the evidence is incomplete, outdated, or unreviewed. | Identify what documentation is missing and prepare NIS2 evidence pack |
| Mostly GREEN controls | Controls exist and evidence is available. | Organise evidence by Article 21 measure and keep review dates current. |
| Mixed RED, AMBER, and GREEN results | The most common outcome for SMEs. Some controls work, others need ownership or proof. | Sequence remediation over 12 weeks. Explore NIS2 implementation roadmap. |
How to turn the NIS2 compliance checklist into a gap register
A gap register should include more than the name of the missing control. For each RED or AMBER item, record:
- Control number and Article 21(2) measure area
- Current score
- Missing evidence
- Risk impact
- Owner
- Target date
- Remediation action
- Management approval status
- Link to supporting evidence
This makes the gap register usable by security, compliance, leadership, and delivery teams. It also prevents the checklist from becoming a static document that is completed once and forgotten.
How to build the evidence pack after scoring NIS2 compliance checklist
A NIS2 evidence pack should be organised by measure area. For each control, keep the latest approved document, technical evidence, review date, owner, and next review date. For example, access control evidence should sit near asset inventory evidence because reviewers often need to check whether access rules match the systems in scope. Supplier evidence should sit near procurement and contract records because reviewers need to see both the assessment and the contractual control.
Evidence should be easy to verify. If a reviewer needs five conversations to understand whether a control exists, the evidence pack is not ready.
How Sunbytes supports NIS2 compliance readiness
Sunbytes helps EU SMEs move from checklist results to evidence-ready NIS2 preparation. The work is structured around what your team needs to demonstrate: gaps, owners, remediation sequence, management approval, and proof.
Sunbytes is ISO 27001 certified. Engagements can operate under a signed DPA with documented audit trail. For NIS2 readiness, that matters because the work should produce records your management team, auditor, customer, or regulator can review.
- CyberSecurity Solutions help reduce risk without slowing delivery. For NIS2 readiness, the focus is practical: confirm scope, map Article 21 control gaps, assess evidence maturity, and prepare a risk-ranked remediation plan.
- Digital Transformation Solutions: Sunbytes can support remediation where the gap sits inside software delivery, QA/testing, maintenance, technical documentation, or architecture decisions.
- Accelerate Workforce Solutions: Sunbytes support teams that need recruitment or workforce support to scale the capability needed for ongoing compliance work.
The checklist is the baseline. The output should be a gap register, remediation plan, and evidence pack that your team can maintain after the assessment. Discuss NIS2 compliance readiness with Sunbytes.
FAQs
This checklist covers the 10 cybersecurity risk-management measure areas in NIS2 Article 21(2) and maps them into 40 practical control checkpoints. It is a readiness checklist, not a legal certification. National implementation rules, sector guidance, supervisory expectations, and company-specific risk may require extra controls.
Move all RED and AMBER items into a gap register. Assign an owner, risk rating, target date, and evidence requirement for each gap. If several RED items appear across incident handling, access control, supplier security, or business continuity, run a structured NIS2 gap analysis before starting remediation.
The same NIS2 Article 21 control areas apply, but Dutch organisations should check how NIS2 is implemented through Dutch law and which authority applies to their sector. For the Dutch version of this article, add Wbni context, competent authority references, and Dutch-specific incident reporting notes.
ISO 27001 can provide a strong control framework and evidence structure, but it does not automatically prove NIS2 compliance. NIS2 has specific obligations around management accountability, incident reporting, supply chain security, and national implementation rules. Map ISO 27001 evidence to NIS2 Article 21 instead of assuming one replaces the other.
Review the checklist at least annually, and sooner after major changes such as new critical suppliers, system launches, cloud migrations, security incidents, or management changes. Controls that support incident handling, access control, supplier monitoring, and vulnerability management should have shorter review cycles because their evidence changes more often.
If an SME is in scope of NIS2, it should be able to assess all 10 Article 21(2) measure areas. The depth of each control should be proportionate to the organisation’s size, risk exposure, systems, and sector. A smaller organisation may have lighter evidence than a large enterprise, but it still needs clear ownership and proof.
Ownership is usually shared. The CTO, IT Manager, CISO, or security lead may own technical controls. Compliance or risk may own evidence structure. Management must approve and oversee the risk-management measures. The checklist should have one accountable owner to prevent gaps from being split across teams without follow-up.
Sunbytes’ NIS2 Readiness Checklist
Download Sunbytes’ NIS2 Readiness Checklist to assess your current state and identify priority gaps.
