A NIS2 evidence pack is the documentation your organisation uses to prove that Article 21 cybersecurity risk-management measures are not only written down, but implemented. For EU SMEs, the problem is scattered evidence: one access review in a spreadsheet, one supplier check in procurement, one incident procedure in IT, and no single view that connects those records to Article 21.
If you have not assessed your current posture yet, start with a NIS2 gap analysis before collecting evidence and know which Article 21 measures are red or amber. If not, start with the gap analysis first, then use this article to build the evidence pack.
This guide is general compliance guidance. Always validate legal interpretation with your counsel or competent authority.
TL;DR
A NIS2 evidence pack is a controlled set of dated, owned, reviewable documents that proves your organisation has implemented Article 21 measures. A minimum viable pack should cover all 10 Article 21 measure areas with Tier 1 evidence. Tier 2 evidence makes the pack stronger for a regulator review, enterprise customer due diligence, or board-level assurance.
- Tier 1 evidence proves that the measure exists and is implemented.
- Tier 2 evidence proves that the measure is tested, reviewed, and maintained.
- A missing evidence folder for one Article 21 measure should be treated as a NIS2 documentation gap.
What the NIS2 evidence pack is — and the minimum viable principle
A NIS2 evidence pack is a structured collection of documents, logs, approvals, test records, and review outputs mapped to Article 21 cybersecurity risk-management measures.
“Minimum viable” does not mean weak. It means the smallest set of evidence that can defend the statement: “This measure exists, has an owner, has been approved where needed, and has been applied in practice.”
A signed information security policy is better evidence than ten unsigned drafts. A dated access review with an owner is better than a screenshot of user accounts with no context. A supplier assessment with findings and follow-up actions is better than a vendor contract that says “security obligations apply” but never proves they were checked.
The minimum viable evidence pack should follow three rules:
- Every Article 21 measure has at least one Tier 1 evidence file.
- Every file has a date, owner, version, and review cycle.
- Every policy is backed by at least one implementation record where possible.
Who should have your NIS2 evidence pack — and what they will do with it
The primary user is the CTO, CISO, IT security lead, or technical owner building the evidence pack. This person needs a practical map: what to collect, where to store it, how to label it, and which gaps to close first.
The secondary user is the compliance officer, board member, or audit owner preparing for a regulatory interaction. This person needs to know whether the organization can produce evidence quickly when a competent authority, customer, or internal board asks for it.
Your evidence pack should be available to at least four internal groups:
- IT/security: to maintain technical evidence and control records.
- Compliance/legal: to check regulatory mapping and document retention.
- Procurement: to maintain supplier security evidence.
- Management body: to review risk decisions, approve measures, and track remediation.
For suppliers to larger enterprises, the evidence pack also has a commercial use. Enterprise customers may request NIS2 evidence during vendor due diligence, especially where Article 21(2)(d) supply chain security applies.
Evidence requirements per Article 21 measure: Tier 1 and Tier 2
The table below separates evidence into two levels.
- Tier 1 is the minimum viable evidence. It proves that a measure exists and has been applied at least once.
- Tier 2 is recommended evidence. It proves that the measure is reviewed, tested, improved, and ready for a stricter audit or enterprise customer review.
ENISA’s 2025 technical implementation guidance also uses “examples of evidence” to help organisations translate NIS2 requirements into proof records. Those examples are guidance, not binding legal text, but they are useful when designing an evidence model.
The NIS2 minimum viable evidence pack — Article 21 evidence table
| Article 21 area | Measure | Tier 1 minimum evidence | Tier 2 recommended evidence | What a regulator or customer will check |
|---|---|---|---|---|
| Article 21(2)(a) | Risk analysis and information system security policies | Signed information security policy. Dated cyber risk assessment. Risk owner list. | Risk treatment plan. Residual risk acceptance records. Annual policy review record. | The policy has an owner, review date, and management approval. Risk assessment is current and linked to remediation actions. |
| Article 21(2)(b) | Incident handling | Incident response procedure. Incident severity criteria. Evidence of one tabletop exercise or test. | Incident log, near-miss log, post-incident reviews, Article 23 notification templates. | The procedure names who decides, who reports, and how timelines are tracked. For deadlines and notification steps, use the NIS2 Article 23 incident reporting timeline.” |
| Article 21(2)(c) | Business continuity and crisis management | Business continuity plan for critical services. Backup policy. Recovery time objectives. | Business impact analysis. BCP test results. Crisis communication plan. Disaster recovery test record. | Evidence covers the systems in NIS2 scope, not only generic IT. Test results are dated and assigned to owners. |
| Article 21(2)(d) | Supply chain security | Supplier security assessment policy. Supplier inventory. Evidence of at least one supplier review. | Supplier risk classification. Contractual security clauses. Annual review record for critical suppliers. | Supplier reviews are not theoretical. At least one named supplier has been assessed, with findings and follow-up actions. |
| Article 21(2)(e) | Security in acquisition, development, and maintenance | Secure development or procurement procedure. Security requirements in one recent project or purchase. | Secure software development lifecycle documentation. Code review record. Vulnerability scan result. Remediation evidence. | Security is part of acquisition or delivery, not added after launch. Evidence shows one real project followed the process. |
| Article 21(2)(f) | Policies to assess effectiveness of measures | Control effectiveness review procedure. Evidence of one completed control review. | Internal audit report. Security KPI dashboard. Remediation status report. | The organisation can show whether controls work, not only that controls exist. Findings have owners and due dates. |
| Article 21(2)(g) | Basic cyber hygiene and cybersecurity training | Cyber hygiene policy. Staff security training record. MFA or password guidance. | Phishing simulation results. Role-based training for admins and developers. Training completion dashboard. | Training records match the employee list. Admins and high-risk roles receive more specific training than general staff. |
| Article 21(2)(h) | Cryptography and encryption | Cryptography or encryption policy. List of encrypted systems or data categories. | Key management procedure. Certificate inventory. Encryption review record. | Encryption decisions are documented by system or data type. Key ownership and renewal responsibilities are clear. |
| Article 21(2)(i) | Personnel security, access control, and asset management | Access control policy. Asset inventory. Joiner-mover-leaver procedure. Evidence of one access review. | Quarterly access review records. Privileged access log. Background screening policy where lawful and relevant. | Access rights match job roles. Leavers are removed. Privileged accounts have stricter review evidence. |
| Article 21(2)(j) | Multi-factor authentication and secure communications | MFA policy. MFA coverage report for critical systems. Secure communication procedure. | Exception register. Continuous authentication assessment. Emergency communication test. | MFA is enforced where risk requires it. Exceptions are approved, time-limited, and reviewed. |
How to organise your NIS2 evidence pack: a recommended folder structure
Organise a NIS2 evidence pack by Article 21 measure, not by department. Each folder should contain dated, owned, version-controlled evidence that proves a control exists, has been applied, and has a review cycle.
An evidence pack fails when it is hard to inspect. A regulator, customer, or board member should not need to search email inboxes, Slack threads, Jira tickets, SharePoint folders, and screenshots to understand your control posture.
Organise the pack by Article 21 measure, not by department. Auditors and customers ask: “Show me your access control evidence” or “Show me supplier security evidence.” They do not ask: “Show me what IT, HR, and procurement each stored separately.”
Use this folder structure as a practical starting point:
| Folder | Purpose | Example files |
|---|---|---|
| Folder | Purpose | Example files |
| 00_scope_and_entity_classification | Defines which entities, services, systems, and locations are in scope | NIS2 scope statement, entity classification, critical service list |
| 01_risk_analysis_and_security_policy | Maps Article 21(2)(a) | Security policy, risk assessment, risk treatment plan |
| 02_incident_handling | Maps Article 21(2)(b) | Incident response plan, severity matrix, tabletop exercise record |
| 03_business_continuity | Maps Article 21(2)(c) | BCP, backup policy, RTO/RPO register, BCP test evidence |
| 04_supply_chain_security | Maps Article 21(2)(d) | Supplier inventory, supplier assessment, contract security clauses |
| 05_secure_development_and_acquisition | Maps Article 21(2)(e) | SSDLC procedure, procurement security checklist, scan evidence |
| 06_control_effectiveness | Maps Article 21(2)(f) | Internal control review, audit findings, remediation tracker |
| 07_cyber_hygiene_and_training | Maps Article 21(2)(g) | Training records, cyber hygiene policy, phishing test report |
| 08_cryptography_and_encryption | Maps Article 21(2)(h) | Encryption policy, key management procedure, certificate register |
| 09_access_asset_and_personnel_security | Maps Article 21(2)(i) | Access review, asset inventory, JML procedure |
| 10_mfa_and_secure_communications | Maps Article 21(2)(j) | MFA report, exception register, secure communication procedure |
| 11_gap_analysis_and_remediation | Connects evidence gaps to action | Gap report, risk-ranked register, remediation roadmap |
Use a naming convention that makes inspection easy: [Article21-area]_[document-type]_[owner]_[version]_[date]
Example: A21-2i_AccessReview_ITSecurity_v1_2026-05-20.pdf
Avoid file names like:
final_policy.pdf
new_new_access_review.xlsx
supplier_security_latest.docx
Those names create work during an audit. They also make version control hard. Building your NIS2 evidence pack and not sure what is missing? Sunbytes can review your current documentation against Article 21 Tier 1 evidence requirements, identify missing proof records, and turn the result into a remediation-ready evidence target list. Prepare your NIS2 evidence pack with Sunbytes.
What Dutch organisations should prepare before the Cyberbeveiligingswet enters into force
For Dutch organisations, the evidence pack has an extra practical function: aantoonbaarheid. In English, the closest term is demonstrability. Aantoonbaarheid means your organisation can show that a duty has been met with evidence. For NIS2 readiness, that means a policy alone is not enough. The organisation should be able to produce records that show the policy was approved, applied, reviewed, and updated.
The Netherlands is implementing NIS2 through the Cyberbeveiligingswet. NCTV states that the Cyberbeveiligingswet will replace the current Wbni once it enters into force. It also advises organisations not to wait, but to start preparing with the ten duty-of-care measures now.
Until the Cyberbeveiligingswet formally enters into force, Dutch organisations should treat this period as readiness time: define scope, assign control owners, and prepare evidence for the duty-of-care measures.
For Dutch SMEs, essential entities, and important entities, this means the evidence pack should answer four questions before a regulator or customer asks:
- Which Article 21 measures apply to the systems and services in scope?
- What evidence proves each measure is implemented?
- Who owns each evidence file?
- When was the evidence last reviewed?
What makes NIS2 evidence weak or invalid
Weak evidence usually has one of five defects.
- First, it has no date. An undated policy may prove that someone once drafted a document. It does not prove that the organisation reviewed it in the current risk context.
- Second, it has no owner. If a supplier assessment exists but no function owns the follow-up actions, the evidence stops at observation. It does not prove control.
- Third, it has no approval where approval is needed. Risk acceptance, information security policy approval, and board-level governance records should not sit only inside IT.
- Fourth, it is not mapped to Article 21. A folder full of useful documents still creates work if no one can tell which measure each document supports.
- Fifth, it proves design but not implementation. A policy says what should happen. An access review, test result, incident log, or supplier review proves that something did happen.
A minimum viable evidence pack should remove those five defects before adding more documents.
How to build the evidence pack after your gap analysis
Do not start by collecting every security document your company has. Start with the gap analysis output. A practical sequence works better:
- Confirm the NIS2 scope: entities, services, systems, locations, and suppliers.
- Map every Article 21 measure to a responsible owner.
- Identify existing Tier 1 evidence.
- Mark missing or weak evidence as red or amber.
- Build the folder structure before collecting new files.
- Close Tier 1 gaps first.
- Add Tier 2 evidence where customer, regulator, or board risk is higher.
- Set review dates for each evidence file.
This sequence prevents a common failure: building a large archive that still cannot answer the first audit question. For example, if Article 21(2)(i) is amber, do not collect every HR policy first. Ask for the access control policy, latest access review, joiner-mover-leaver procedure, privileged access list, and evidence that at least one review led to an access change. That gives your IT security lead a defensible starting set.
Once Tier 1 is complete, move to Tier 2: quarterly review cadence, privileged access monitoring, exception register, and management reporting.
How Sunbytes supports NIS2 evidence pack preparation
Sunbytes supports NIS2 evidence pack preparation as part of Cybersecurity Compliance Readiness.
The work starts with evidence mapping: what Article 21 requires, what evidence already exists, what is missing, and which gaps create the highest audit or customer risk. The output is not a loose recommendation list. It should be a controlled evidence target list: document name, Article 21 mapping, owner, status, review date, and next action.
For companies that need support after the documentation review, Sunbytes can help translate missing evidence into delivery work. That may include access review records, supplier assessment workflows, secure development documentation, incident response exercises, or remediation tracking.
Why Sunbytes?
Sunbytes is a Dutch technology company, headquartered in the Netherlands with a delivery hub in Vietnam. We are ISO 27001 certified, and engagements can operate under a signed DPA with a documented audit trail. For 15 years, we have helped clients worldwide Transform · Secure · Accelerate by turning strategy into delivery work with security built into the process.
- CyberSecurity Solutions help companies reduce risk without slowing down delivery through practical security services and compliance readiness. For this article’s topic, that means reviewing current documentation against Article 21 evidence requirements, identifying missing proof records, and helping teams prepare an evidence pack that is structured, dated, owned, and audit-ready.
- Digital Transformation Solutions help teams build and modernize digital products with senior engineering support across custom development, QA/testing, maintenance, and support. For NIS2 evidence preparation, this matters when missing controls need to become real delivery work: secure development records, test evidence, system documentation, or remediation tasks
- Accelerate Workforce Solutions help companies scale capability and capacity through recruitment and workforce support when internal teams need extra execution power. For NIS2 readiness, this can support the people side of remediation when your security, compliance, or engineering teams need additional capacity to close evidence gaps on time.
Contact Sunbytes about NIS2 evidence pack preparation.
FAQs
A NIS2 evidence pack is a structured set of documents and records that proves your organisation has implemented NIS2 cybersecurity risk-management measures. For Article 21, it should map evidence to each measure area, including risk analysis, incident handling, business continuity, supply chain security, secure development, control testing, cyber hygiene, encryption, access control, and MFA.
A minimum viable evidence pack covers all Article 21 measure areas with Tier 1 evidence. That usually means a dated policy or procedure, an owner, and at least one implementation record for each measure. If one measure has no evidence, treat it as a documentation gap.
Yes, but it should be mapped carefully. ISO 27001 documentation can support many NIS2 evidence areas, such as risk management, access control, supplier security, incident response, and control effectiveness. The gap is often not the existence of documents, but whether they are mapped to Article 21, current, approved, and easy to produce.
The evidence pack should include incident handling evidence under Article 21(2)(b), but detailed Article 23 reporting evidence should sit in the incident reporting article or playbook. For reporting deadlines and notification stages, use the NIS2 Article 23 incident reporting timeline.
For an organisation that has already run a gap analysis and has existing security documentation, a Tier 1 evidence pack may take 4–8 weeks to assemble and clean up. Starting from scratch can take 8–16 weeks because some evidence must be created through action first, such as supplier reviews, BCP tests, access reviews, or incident exercises.
Evidence becomes weak when it is undated, unsigned where approval is needed, inaccessible, unmapped to Article 21, or not backed by implementation records. A policy may show intent. A dated test result, access review, supplier assessment, or incident exercise record shows practice.
For the Dutch version, yes. “Aantoonbaarheid” is the practical standard: your organisation should be able to demonstrate compliance with documents and records. In the English version, define it once as “demonstrability” and then keep the main article focused on Article 21 evidence.
Let’s start with Sunbytes
Let us know your requirements for the team and we will contact you right away.
