NIS2 compliance cannot be demonstrated by a policy library alone. A regulator, auditor or management body may need to understand not only what an organisation intended to do, but also whether its cybersecurity measures were approved, implemented, tested and improved over time.
That distinction makes evidence management a central part of NIS2 readiness. Policies describe the expected approach. Evidence shows that people followed it, controls operated, exceptions were governed and material weaknesses reached the right decision-makers.
Directive (EU) 2022/2555, known as NIS2, does not prescribe one universal folder of documents for every regulated entity. It establishes outcomes and minimum areas that essential and important entities must address through appropriate and proportionate technical, operational and organisational measures. The exact records expected from an entity depend on its risk profile, services, sector, size, national implementing law and, in some cases, sector-specific EU rules.
This guide explains how businesses can build practical NIS2 compliance documentation, what evidence may support Articles 20, 21 and 23 of the Directive, and how to organise a defensible evidence pack without creating unnecessary bureaucracy. It is designed as a documentation and assurance guide—not as another general implementation roadmap or audit checklist.
1. Does NIS2 require specific compliance documentation?
NIS2 does not contain a single exhaustive schedule titled “documents every entity must maintain”. Instead, it creates duties that are difficult to perform or demonstrate without reliable records.
Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee their implementation and follow relevant training. Article 21 requires appropriate and proportionate risk-management measures covering at least ten specified areas. Article 23 establishes staged reporting for significant incidents. Supervision provisions allow competent authorities to request information and access data, documents or other evidence needed for their tasks.
As a result, documentation should support three questions:
What decision, process or control was required?
Who approved, owned or performed it, and when?
What evidence shows that it operated and produced the intended result?
National legislation may define additional documents, registration information, audit requirements, reporting forms or retention periods. Organisations operating in several Member States should therefore maintain a jurisdiction register instead of assuming that one evidence pack satisfies every national procedure.
Certain DNS, cloud, data-centre, managed service, managed security, online marketplace, online search, social networking and trust service providers are also subject to Commission Implementing Regulation (EU) 2024/2690. For those entities, the Regulation and ENISA’s supporting technical guidance provide more detailed requirements and examples. Other entities may use that material as a reference, but should not present it as automatically binding outside its legal scope.
2. Documentation, records and evidence: what is the difference?
These terms are often used interchangeably, but separating them improves assurance.
Category
Purpose
Examples
Governing documents
Define what the organisation expects and who is responsible
Policies, standards, procedures, governance charters and control descriptions
Operational records
Show that a process or control was performed
Access reviews, vulnerability tickets, backup logs, supplier assessments and training records
Decision evidence
Shows how risks, exceptions and priorities were considered
Management minutes, risk acceptance, investment approvals and escalation records
Effectiveness evidence
Shows whether measures work as intended
Test results, restoration exercises, metrics, audits and verified remediation
Regulatory records
Support registration, notification and supervisory engagement
Scope analysis, authority correspondence, incident reports and information requests
A policy is not proof that the process operates. A screenshot is not necessarily reliable evidence if its source, date, scope and owner are unclear. A test report has limited value if no one owns the findings or verifies their closure.
Strong evidence connects design with operation. It should allow a reviewer to trace a requirement to a control, the control to its owner, the owner to operational records and any failure to a documented decision or corrective action.
3. Build a NIS2 evidence map before collecting files
Collecting everything creates cost, confusion and additional security risk. A better approach begins with an evidence map.
An evidence map links each applicable obligation to the entity’s controls and records. It can be maintained in a governance, risk and compliance platform or a controlled spreadsheet, provided ownership, versioning and access are appropriate.
Evidence-map field
What to record
Legal or control reference
Applicable NIS2 article, national provision, implementing rule or internal control requirement
Expected outcome
The risk or service outcome the measure should achieve
Control description
How the organisation addresses the outcome
Owner and operator
Who is accountable and who performs the activity
Evidence source
System, repository or process producing the record
Frequency or trigger
Monthly, quarterly, annually, after change or after an incident
Reviewer
Who assesses completeness and effectiveness
Retention and protection
How long evidence is kept and how access and integrity are protected
Status and exceptions
Current result, open gaps, accepted risk and remediation
The map should reflect the services and systems in scope. A generic template can accelerate the work, but it should not become the basis for unsupported declarations. Where a control does not apply, the organisation should record the reason rather than leaving an unexplained blank.
4. Scope and applicability records
An organisation cannot build credible NIS2 compliance documentation without first establishing which entities and services are covered. Scope evidence is especially important for corporate groups, cross-border operations and businesses whose activities cross several sectors.
A documented applicability file may include:
a list of relevant legal entities and establishments;
services and activities mapped to Annex I or Annex II of NIS2 and corresponding national provisions;
employee and financial data used for size classification;
analysis of partner and linked enterprises where relevant to SME calculations;
size-independent rules and any specific designation decisions;
jurisdiction and competent-authority mapping;
interaction with sector-specific EU legislation, such as DORA;
legal advice or internal interpretation supporting uncertain classifications;
review triggers for acquisitions, new services, restructuring and legislative change.
The purpose is not to produce a long legal memorandum for every entity. It is to make the conclusion reproducible. A reviewer should be able to see what facts were considered, which version of the law was used and who approved the result.
Scope documentation should also identify the network and information systems supporting covered services. Legal entity boundaries do not always match technical boundaries. Shared identity platforms, cloud tenants, data centres or managed providers may support several companies and services, making dependency evidence important.
5. Governance and management-body evidence
Article 20 makes management involvement a substantive requirement. Evidence should show more than the presence of cybersecurity on an annual agenda.
5.1 Approval of cybersecurity risk-management measures
Approval evidence can include board or management-body minutes, resolutions, decision papers and approved policy sets. The record should identify what was approved, the scope of the decision, material risks, known limitations, required resources and the reporting mechanism used to oversee implementation.
Where a large package is approved, a controlled index can identify all included documents and their versions. This avoids uncertainty about whether a policy was actually part of the decision.
5.2 Oversight of implementation
Oversight records may include periodic dashboards, risk committee minutes, programme status reports, overdue-action escalations and decisions concerning residual risk. Reporting should enable informed challenge.
Useful indicators connect controls with service outcomes. Examples include the proportion of critical services covered by tested recovery plans, overdue remediation for critical vulnerabilities, privileged access awaiting review, critical suppliers without current assurance and high-risk audit findings past their agreed date.
Raw activity counts are weaker. The number of alerts processed or employees trained may be relevant, but it does not by itself show whether the organisation can protect and recover its services.
5.3 Management training
Training evidence should record the audience, date, subject matter, facilitator and completion. The content should help management understand its responsibilities, the entity’s threat and risk profile, significant-incident escalation, risk acceptance and oversight expectations.
An attendance list alone may not demonstrate that training was suitable. Agenda materials, learning objectives, exercises or confirmation of understanding provide stronger context.
5.4 Accountability and delegated responsibility
An organisation should maintain a current responsibility model. This can include governance terms of reference, role descriptions, RACI matrices, escalation paths and authority for risk acceptance.
Operational tasks may be delegated to security teams, technology owners or providers. Documentation should still show how the management body receives assurance and how material matters are escalated. Outsourcing a control does not outsource the regulated entity’s responsibility for managing its risk.
6. Risk-analysis and treatment evidence
Article 21 begins with policies on risk analysis and information-system security. A defensible evidence trail demonstrates that risk management affects decisions and investment.
Core documentation may include:
the approved cybersecurity risk methodology;
risk criteria, impact scales and likelihood definitions;
a service, process, information and technology inventory;
risk assessments and a current risk register;
treatment plans with owners, resources and deadlines;
risk acceptance and exception records;
reassessment after material change or an incident;
links between risks, controls, suppliers and continuity priorities.
The risk register should not be an isolated spreadsheet owned only by the security team. Material risks need accountable business owners and a route to management. Treatment records should make clear whether the organisation is reducing, avoiding, transferring or accepting the risk.
Exceptions require particular care. A patching exception, unsupported system or delayed access review should identify the affected service, reason, compensating measures, approver, expiry date and review. Open-ended exceptions weaken both security and evidence quality.
7. Evidence for the Article 21 risk-management areas
The following examples illustrate records that may support the ten minimum areas in Article 21. They are not a universal statutory checklist.
Article 21 area
Examples of useful evidence
Risk analysis and system-security policies
Methodology, risk register, policy approvals, review history and exception records
Incident handling
Response plan, severity criteria, incident tickets, communication logs, exercise reports and lessons learned
Business continuity, backup and crisis management
Business impact analysis, recovery objectives, continuity plans, backup monitoring, restoration results and crisis exercises
Supply-chain security
Supplier inventory, risk tiering, due diligence, security clauses, assurance reports, monitoring and exit plans
Secure acquisition, development and maintenance
Security requirements, architecture reviews, secure-development records, change approvals, vulnerability tickets and patch evidence
Assessment of effectiveness
Control testing, penetration tests, audits, metrics, findings and verified remediation
Cyber hygiene and training
Baseline standards, update and configuration records, role-based training, simulations and follow-up actions
Cryptography and encryption
Cryptographic policy, approved standards, key and certificate inventories, rotation logs and exception decisions
Human resources security, access and assets
Screening where lawful, joiner-mover-leaver records, access reviews, privileged-account evidence and asset inventories
MFA and secure communications
Coverage reports, enrolment and recovery controls, exception records, authentication tests and emergency communication exercises
Evidence must remain proportionate. A small important entity and a multinational essential entity may address the same legal area with different operating models and documentation depth. The key question is whether the record is sufficient to demonstrate the control in the context of the entity’s risk.
8. Incident-reporting documentation
Article 23 requires essential and important entities to notify significant incidents through a staged process. The Directive provides for an early warning without undue delay and within 24 hours of awareness, an incident notification within 72 hours, and generally a final report within one month of the incident notification. Intermediate or progress reports may also be required.
Incident evidence should support both response and the reporting decision. Useful records include:
the time and source of initial detection;
the point at which the organisation became aware of the incident;
technical and business severity assessments;
the significant-incident assessment and its approver;
affected services, systems, users and other persons;
suspected malicious or unlawful activity;
indicators of compromise and cross-border implications where available;
containment, mitigation and recovery actions;
copies of regulatory submissions and acknowledgements;
customer, contractual, data-protection and law-enforcement communications;
decision logs showing what was known and unknown at each stage;
root-cause findings, lessons learned and corrective actions.
8.1 Preserve a reporting timeline
The reporting clock can begin before a complete forensic conclusion is available. A reliable timeline is therefore essential. Systems should use synchronised time sources, and the incident lead should record material decisions as they occur.
The evidence should distinguish facts, assumptions and pending investigation. Early notifications can be qualified. A clear record of uncertainty is more credible than retrospective notes that imply the organisation knew everything at the start.
8.2 Document non-reporting decisions
Not every security event meets the threshold of a significant incident. When an event is assessed as non-reportable, the organisation should retain a proportionate record of the facts, criteria and decision. This helps demonstrate consistency and enables later reassessment if the impact changes.
National law, authority guidance and the Commission Implementing Regulation for specified digital and ICT entities may provide additional thresholds and procedural detail. Reporting templates and contact information should be maintained for every relevant jurisdiction.
9. Supply-chain and supplier evidence
Supplier documentation should show that the organisation understands which relationships could affect its covered services and applies scrutiny proportionate to the risk.
An evidence set may contain:
a supplier inventory linked to services and information assets;
inherent-risk and criticality classifications;
due-diligence questionnaires and supporting documents;
independent assurance reports and certifications, with scope and exceptions reviewed;
security requirements in contracts and statements of work;
incident-notification and cooperation provisions;
subcontracting, location and concentration-risk information;
access granted to supplier personnel and periodic access reviews;
performance, vulnerability and incident monitoring;
reassessment records following change or an incident;
continuity, substitution and secure-exit plans.
A certificate should not be stored without analysis. Its scope, period, exclusions and relationship to the delivered service matter. Similarly, a completed questionnaire is a supplier statement, not independent proof. Higher-risk suppliers may require interviews, technical evidence, independent reports or contractual verification rights.
Documentation should also record the organisation’s response to deficiencies. Accepting a supplier risk without an owner, expiry date or compensating measure creates an unmanaged exception.
10. Business continuity, backup and recovery evidence
Continuity documentation should connect business priorities with technical recovery capability.
The evidence chain may begin with business impact analysis and service dependency maps. These should support recovery time and recovery point objectives, response priorities, backup architecture, alternative procedures and supplier arrangements.
Operational evidence can include:
current continuity, disaster-recovery and crisis-management plans;
protected backup configuration and monitoring;
restoration tests showing which data and systems were recovered;
actual recovery duration compared with approved objectives;
test limitations, failures and remediation;
exercise attendance, decisions and lessons learned;
emergency contacts and out-of-hours escalation checks;
evidence that critical providers participated where relevant.
A successful backup job is not the same as a successful recovery. Evidence should demonstrate that required data can be restored into an operable service under plausible conditions.
Testing should vary scenarios. Tabletop exercises are useful for decisions and communication, while technical restoration tests provide evidence of recovery capability. More complex entities may use integrated exercises involving suppliers, facilities and business teams.
11. Security-control and technical evidence
Technical evidence is often abundant but difficult to interpret. The objective is not to export every log. It is to retain records that demonstrate scope, operation, review and response.
Examples include:
approved secure-configuration baselines and compliance reports;
vulnerability scan coverage and remediation tickets;
patch status linked to criticality and exceptions;
endpoint, network and cloud monitoring coverage;
identity and privileged-access reviews;
MFA coverage and bypass exceptions;
encryption, key and certificate management records;
change approvals and security testing;
secure-development and dependency-scanning results;
asset inventory completeness checks;
alert investigations and response outcomes.
Tool screenshots should be used carefully. Prefer repeatable reports or system exports with the source, timestamp, query scope and responsible reviewer recorded. Evidence should be protected from unauthorised modification, particularly when it may support an investigation.
12. Evidence that measures are effective
Article 21 includes policies and procedures to assess the effectiveness of cybersecurity risk-management measures. This means documentation should go beyond implementation status.
An effectiveness file can combine:
defined control objectives and success criteria;
control self-assessments;
technical testing and independent review;
security and resilience metrics;
internal and external audit reports;
incidents and near misses indicating control performance;
trends and recurring weaknesses;
corrective actions with owners and deadlines;
proof that high-risk remediation was independently verified.
Metrics should be interpreted. For example, “98% of critical systems patched on time” requires a defined population, a reliable inventory, treatment of exceptions and information about the remaining 2%. A positive average can conceal exposure in a critical service.
Management reporting should distinguish control design, implementation and effectiveness. A control can be well designed but inconsistently operated, or widely deployed but ineffective against a realistic threat.
13. How to assemble a NIS2 evidence pack
An evidence pack is a controlled view of relevant records, not a permanent duplicate of every operational file.
1. Start with an index
The index should identify the requirement, document or evidence item, owner, version or period, source location, access classification and review status. It should also identify unavailable evidence and open remediation.
2. Use service-based navigation
Regulatory obligations apply to entities, but operational impact occurs through services. Organising evidence around covered services helps reviewers understand dependencies, risks, controls and recovery priorities.
3. Select representative periods and samples
Evidence should show operation over time. One access review performed immediately before an assessment does not demonstrate a mature quarterly process. Samples should cover the relevant period, locations and technologies.
4. Preserve source and context
Each item should make clear where it came from, who produced or approved it, the date, scope and meaning. Remove unexplained screenshots, unlabeled exports and drafts that could be mistaken for approved records.
5. Record gaps honestly
Do not create evidence retrospectively to imply that an activity occurred. Where evidence is missing, document the gap, immediate risk response, owner and remediation date. Transparent remediation is more defensible than an unreliable record.
6. Perform quality review
Legal, security, risk and service owners should check consistency. The asset inventory should agree with vulnerability coverage. Supplier classification should drive assurance. Recovery objectives should match test reports. Management minutes should reflect the material risks shown in dashboards.
14. Evidence quality principles
A practical evidence standard can be expressed through seven characteristics:
relevant: it supports a defined requirement or control;
authentic: its origin and ownership can be established;
complete: it includes the scope and context needed for interpretation;
accurate: it reflects what actually occurred;
timely: it covers the required period and was produced at the appropriate time;
protected: access, integrity and confidentiality are controlled;
retrievable: authorised teams can find it when required.
These principles help teams decide whether a proposed record adds assurance or merely volume.
15. Retention, confidentiality and evidence security
NIS2 does not establish one universal retention period for every type of compliance record. Retention should be determined using national requirements, limitation periods, sector rules, contractual duties, audit cycles, incident-investigation needs and the organisation’s risk.
Evidence may contain sensitive architectural details, vulnerabilities, personal data, credentials, supplier information or legal advice. It should be classified and protected accordingly. Collecting material for an assessment does not justify placing unrestricted copies in a shared folder.
The organisation should define:
approved repositories and access roles;
version control and approval status;
retention and defensible disposal;
legal hold and investigation procedures;
integrity protection and backup;
secure transfer to auditors or authorities;
handling of personal and privileged information;
return or deletion of assessment copies.
Data minimisation matters. Evidence should be sufficient for its purpose without exposing unnecessary personal data, secrets or complete security configurations.
16. Common NIS2 documentation mistakes
16.1 Treating policies as proof of operation
Policies establish intent. They need corresponding reviews, logs, tests, decisions and corrective actions.
16.2 Collecting screenshots without context
A screenshot may not show the source, date, population, filters or reviewer. Use controlled exports and explanatory notes where possible.
16.3 Building the evidence pack only before an audit
Last-minute collection produces gaps and inconsistent records. Evidence generation should be embedded into normal control operation.
16.4 Keeping expired exceptions open
Exceptions should have owners, compensating measures and expiry dates. Repeated extensions require appropriate challenge and escalation.
16.5 Storing sensitive evidence too broadly
Centralisation improves retrieval but can create a valuable target. Use classification, least privilege, logging and secure transfer.
16.7 Ignoring contradictory records
An approved policy may claim quarterly reviews while operational records show annual activity. Resolve discrepancies instead of presenting them as separate truths.
16.8 Equating certification with complete NIS2 evidence
ISO/IEC 27001 certification can provide useful governance and control records. It does not automatically demonstrate legal scope, national notification procedures or every NIS2 outcome. The certification scope and statement of applicability must be understood.
17. NIS2 compliance documentation checklist
Use this checklist as a planning aid. Adapt it to the entity, national law and risk profile.
[ ] Applicability and jurisdiction analysis is documented and approved.
[ ] Covered services, systems, data, people, facilities and suppliers are mapped.
[ ] Management approval of risk-management measures is traceable.
[ ] Management oversight and cybersecurity training records are current.
[ ] Roles, escalation paths and risk-acceptance authority are defined.
[ ] Risk methodology, assessments, register and treatment plans are maintained.
[ ] Policies are version-controlled, approved and linked to operating procedures.
[ ] Incident records preserve awareness, decisions, actions and reporting timelines.
[ ] Non-reporting decisions for material events use documented criteria.
[ ] Continuity and recovery documentation is linked to critical services.
[ ] Backup and restoration evidence demonstrates recoverability.
[ ] Supplier inventory, classification, due diligence and monitoring are current.
[ ] Security clauses and supplier-exit arrangements reflect criticality.
[ ] Vulnerability, patch, configuration and change records show control operation.
[ ] Access, privileged accounts and MFA exceptions are reviewed.
[ ] Cryptographic keys and certificates are governed and monitored.
[ ] Training evidence is role-based and includes effectiveness indicators.
[ ] Control testing and audits produce owned, time-bound remediation.
[ ] High-risk findings have verified evidence of closure.
[ ] Evidence retention, access, integrity and secure transfer are defined.
[ ] The evidence index identifies missing or outdated records.
[ ] Evidence is reviewed after major incidents, changes and regulatory updates.
18. How this guide fits with implementation and audit work
Documentation should emerge from real controls. Organisations that are still designing their programme can use TTMS’s practical guide to implementing NIS2 for a broader implementation perspective. For a general overview of business duties, see cybersecurity obligations of businesses under NIS2.
An implementation programme creates and operates controls. An evidence programme makes their ownership, decisions and results demonstrable. An audit or assessment then evaluates whether the measures and evidence satisfy the applicable criteria. These activities support one another but should not be confused.
19. Why TTMS?
Building a NIS2 evidence model requires an understanding of regulation, governance and the technology that generates operational records. TTMS can support organisations in mapping applicable requirements to services, controls, owners and evidence sources, then integrating those records into practical workflows.
Support may include evidence-readiness assessments, governance and responsibility design, control mapping, documentation frameworks, supplier assurance, incident and continuity exercises, technical-control verification and remediation planning.
The objective is not to create documents for their own sake. It is to help the organisation establish records that reflect working security measures and provide management with reliable assurance.
Engagement scope should be tailored to the entity’s legal position, national requirements, risk profile and existing management systems. Legal conclusions should be confirmed by appropriately qualified advisers, while technical and organisational evidence should support those conclusions accurately.
20. Prepare a defensible NIS2 evidence pack
Organisations should not wait for an authority request or audit notice before locating their records. Start with the services in scope, the decisions management must make and the controls protecting those services. Then identify which reliable records demonstrate operation and effectiveness.
Contact TTMS to discuss a NIS2 documentation and evidence-readiness assessment tailored to your organisation.
For authoritative background, consult the European Commission overview of the NIS2 Directive, ENISA’s NIS2 implementation resources and the official text of Directive (EU) 2022/2555 on EUR-Lex.
21. Frequently asked questions about NIS2 compliance documentation
What documentation is required for NIS2 compliance?
NIS2 does not prescribe one universal document pack. Covered entities need records sufficient to demonstrate management approval and oversight, appropriate and proportionate risk-management measures, significant-incident reporting and compliance with applicable national procedures. Typical evidence includes scope analysis, governance decisions, risk records, policies, operational control records, supplier assurance, continuity tests, incident files, metrics, audits and remediation.
Is a policy enough to prove NIS2 compliance?
No. A policy describes the intended approach. Evidence of operation may include approvals, system records, reviews, test results, incidents, exceptions and corrective actions. A reviewer should be able to connect the policy to actual controls and accountable owners.
Does NIS2 require an information security management system?
NIS2 requires a governed set of appropriate and proportionate cybersecurity risk-management measures. National law may expressly require an information security management system, and an ISMS is a practical way to organise policies, risk management, controls and improvement. Organisations should verify the terminology and detailed requirement in each relevant jurisdiction.
Does ISO 27001 certification provide sufficient evidence?
ISO/IEC 27001 certification can provide valuable evidence, but it is not automatic proof of complete NIS2 compliance. The certification scope, exclusions and statement of applicability matter. Legal scope, management duties, national registration and incident-reporting procedures still require specific assessment.
How long should NIS2 evidence be retained?
There is no single NIS2 retention period covering every record. The organisation should define retention using national law, sector obligations, audit cycles, limitation periods, contractual duties, investigation needs and risk. Sensitive evidence should be disposed of securely when retention is no longer justified.
Should every security log be placed in the evidence pack?
No. The pack should provide a controlled view of relevant evidence. Operational logs may remain in their source systems, with an index describing ownership, scope, retention and retrieval. Export only what is necessary and protect sensitive technical information.
What evidence should the management body receive?
Management should receive information enabling approval and effective oversight: material risks, measure implementation, significant incidents, control failures, critical supplier exposure, effectiveness results, overdue high-risk actions and decisions requiring acceptance or investment.
How should incident-reporting decisions be documented?
Record awareness time, affected services, severity and impact, applicable thresholds, known and unknown facts, the decision-maker and the basis for reporting or not reporting. Keep copies of notifications, acknowledgements and subsequent updates. Follow applicable national procedures.
What supplier evidence is useful for NIS2?
Useful records include supplier criticality, due diligence, assurance reports, contractual security provisions, access reviews, monitoring, incident cooperation, continuity arrangements and exit plans. Evidence depth should reflect the supplier’s access and potential impact on covered services.
How often should the NIS2 evidence pack be reviewed?
Set a risk-based schedule and update records through normal operations. Additional review should follow material incidents, acquisitions, major system or service changes, new critical suppliers, significant control failures and legal updates.
Who should own NIS2 compliance documentation?
Ownership is distributed. Legal or compliance teams may maintain the requirements map, while security, IT, service owners, procurement, HR and continuity teams own operational records. A central coordinator should manage the evidence index, quality checks and escalation without becoming the artificial owner of every control.
Read more
