
NIS2 Audit Readiness: From Documentation to Continuous Evidence
NIS2 gives supervisory authorities the right to request evidence at any time. Not at your next audit. Not with advance notice. Any time. What this means for your evidence management – and why most organizations aren't prepared for it.
NIS2 Audit Readiness: From Documentation to Continuous Evidence
Most organizations treat compliance evidence like tax returns: collect it once a year, prepare it, submit it, file it. An ISMS under ISO 27001 operates on a three-year cycle – certification, surveillance audit, re-certification. In between: internal audits on schedule. That works as long as nobody asks in between cycles.
NIS2 asks in between cycles. The evidence obligation under NIS2 isn't periodic – it's permanent. This article shows what that concretely means, why the shift from audit preparation to continuous evidence is the most underestimated part of NIS2 compliance – and how to make the transition.
Jump to:
- What NIS2 requires in terms of evidence
- The audit preparation problem
- What continuous evidence concretely means
- The five evidence categories
- Building it in practice
What NIS2 Requires in Terms of Evidence {#what-nis2-requires}
The evidence obligation under NIS2 doesn't stem from a single provision but from the interplay of several:
Article 21 – Risk Management Measures: The ten measures from Article 21(2) must not only be implemented but demonstrated to be effective. "Appropriate, proportionate and effective technical, organisational and operational measures" – the word "effective" is the critical difference from a pure implementation obligation.
Articles 32 and 33 – Supervision and Enforcement: Supervisory authorities gain expanded powers. For essential entities: proactive supervision including on-site inspections, security audits, and evidence requests – without specific cause. For important entities: reactive supervision, but with the same authority to request evidence once a trigger exists.
Article 23 – Reporting Obligations: The three-stage reporting regime creates its own evidence requirements: every report must be factually accurate, timely, and traceably documented. The final report after one month is a comprehensive evidence package of the entire incident response.
What authorities can request: Evidence of cybersecurity strategy implementation. Results of security audits. Data, documents, and information required to fulfill supervisory tasks. Evidence of risk management measure implementation.
In short: NIS2 doesn't ask "do you have a process?" It asks "can you prove right now that your process works?"
The Audit Preparation Problem {#audit-preparation-problem}
Most organizations – including those with a mature ISMS – operate evidence management in "audit preparation" mode. This means:
Cyclical rhythm: Evidence is collected when an audit is approaching. Internal audit once a year, external audit per certification cycle. In between: documentation is maintained, but evidence isn't actively kept ready.
Retrospective assembly: When the auditor arrives, the search begins: Where's the current risk report? When was the last management review? What measures were implemented after the last audit? Who approved the last supplier assessment? The evidence usually exists – but it's scattered, inconsistently formatted, and not immediately retrievable.
Trust-based interim: Between audits, there's trust that processes run as documented. Spot checks are rare. Actual effectiveness isn't continuously verified but retrospectively assessed at the next audit.
This model works under ISO 27001. It doesn't work under NIS2.
The difference:
| Property | ISO 27001 Audit Model | NIS2 Evidence Model |
|---|---|---|
| Rhythm | Planned (annual/triennial) | On demand, any time |
| Trigger | Audit calendar | Authority request, incident, routine check |
| Preparation time | Weeks to months | Days |
| Expected state | "We were compliant at audit time" | "We are compliant now" |
| Evidence format | Audit report, management review | Current artifacts with metadata |
| Consequence of gaps | Minor nonconformity, corrective action | Order, fine, personal liability |
The critical implication: NIS2 doesn't require you to be compliant by the next scheduled audit. NIS2 requires you to be compliant now – and prove it at any time.
What Continuous Evidence Concretely Means {#continuous-evidence}
Continuous evidence doesn't mean "being constantly audited." It means: the proof of your compliance is retrievable, current, and verifiable at any point in time.
Three properties every piece of evidence must have:
-
Current: The evidence reflects today's state – not the state from the last audit. A risk report from six months ago is a historical document, not evidence of current risk posture.
-
Verifiable: The evidence contains metadata that confirm its validity: Who created it? When? In what context? Is it approved? By whom? These metadata aren't optional – they're what distinguishes a document from evidence.
-
Retrievable: The evidence can be assembled and presented within hours – not weeks. Not "we need to check with the responsible person" or "it's somewhere in SharePoint."
What this means in practice:
Instead of an annual risk report: a living risk inventory updated with every change, with the last update date immediately visible.
Instead of a list of completed training: evidence of who completed which training when – including executive management – with validity dates and automatic reminders on expiration.
Instead of a folder of supplier questionnaires: an overview of all supplier assessments with status, date of last assessment, next planned assessment, and results of any event-triggered re-assessments.
Instead of an archived incident response plan: evidence that the plan was tested – when, with which scenario, with what results, and what improvements were derived.
The Five Evidence Categories {#five-categories}
Not every piece of evidence has the same structure. For systematic evidence management under NIS2, five categories can be distinguished:
1. Governance Evidence
What: Policies, strategies, frameworks – the documented foundation of your cybersecurity.
Examples: Information security policy, risk management framework, incident response plan, supplier security policy, cryptography policy.
NIS2 requirement: Must exist, be current, be approved by executive management, and be known to employees. Regular review must be demonstrable.
Common gap: The documents exist, but the last review was two years ago. Or: executive management approval isn't documented.
Update rhythm: At least annually or upon significant changes. Approval with date and signature.
2. Operational Evidence
What: Proof that governance documents are actually implemented – that processes aren't just described but lived.
Examples: Completed risk assessments, completed supplier assessments, completed patch management cycles, completed training, penetration test results, management review minutes.
NIS2 requirement: Regular and traceable. Not "we do this" but "here's proof we did it – when, by whom, with what result."
Common gap: Processes run, but documentation is patchy. Or: individual owners keep their evidence in personal folders that others can't access.
Update rhythm: Continuous, per the respective process cycle.
3. Effectiveness Evidence
What: Proof that implemented measures are actually effective – not just that they exist.
Examples: Tabletop exercise results (with documented improvements), incident response KPIs (response times, escalation times), security audit results, vulnerability scan results with trends, patch velocity metrics.
NIS2 requirement: Explicitly required under Article 21(2)(f) – "policies and procedures to assess the effectiveness." The authority doesn't want to know that you have a process. It wants to know whether it works.
Common gap: By far the most frequent gap. Most organizations can demonstrate that measures are implemented. Very few can demonstrate they're effective. Tabletop exercises aren't conducted or documented. KPIs aren't collected. Effectiveness assessment amounts to "no incidents = everything works."
Update rhythm: At least semi-annually for exercises, continuous for metrics.
4. Incident Evidence
What: Documentation of incident response – from detection through final report.
Examples: Triage protocols, situation reports (versioned), decision logs, regulatory submissions (all three stages), communication logs (internal and external), technical analyses, post-incident reviews, final reports.
NIS2 requirement: Complete, versioned, traceable. The final report after one month must contain comprehensive documentation of the entire incident response – including root cause analysis and measures taken.
Common gap: Incident evidence is reconstructed after the fact rather than documented in real time. Or: different artifacts reside in different systems and can't be consolidated.
Update rhythm: Real time during the incident, consolidation within 30 days.
5. Supply Chain Evidence
What: Documentation of the security assessment and monitoring of suppliers and service providers.
Examples: Supplier risk classification, assessment results (initial and ongoing), contractual security agreements, monitoring results, documentation of event-triggered re-assessments, evidence of supplier incident communication.
NIS2 requirement: Consideration of the "specific vulnerabilities of each individual supplier" and the "overall quality of cybersecurity practices" (Art. 21(2)(d)). This goes beyond an annual checklist.
Common gap: Supplier evidence is outdated (last assessment 18 months ago), incomplete (only critical suppliers assessed), or not retrievable (results sit with procurement, not security).
Update rhythm: Continuous monitoring, event-triggered re-assessments, at least annual full assessment of critical suppliers.
Evidence Is Not the Same as Documentation
A common misconception: more documents means better evidence management. The opposite is true.
A document becomes evidence only through context:
- Who created it? (Accountability)
- When was it created or last updated? (Currency)
- Is it approved? By whom? (Authorization)
- How long is it valid? (Scope)
- Where does it reside? Who has access? (Retrievability)
- Which version is current? (Versioning)
Without this metadata, a 50-page risk assessment is worth less than a one-page summary with clear accountability, date, and approval.
The practical consequence: It's not about documenting more. It's about structuring what already exists so it can serve as evidence at any time – with the right metadata, in a central location, in a consistent format.
Building It in Practice {#building-it}
Phase 1: Inventory (Week 1–2)
Before building anything new, capture what already exists. Most organizations have significantly more evidence than they think – it's just scattered and not labeled as such.
For each of the five evidence categories:
- What evidence already exists?
- Where does it reside? (ISMS tool, SharePoint, email, local folders?)
- How current is it?
- Does it have the required metadata?
- Who's responsible?
The result is an inventory matrix: five categories, current coverage, gaps.
Phase 2: Consolidation (Week 3–6)
Centralize existing evidence. Not necessarily in a new tool – but in a central location with a consistent structure:
- Every piece of evidence gets metadata: Owner, creation date, validity date, approval status, version.
- Link to the requirement: Which NIS2 measure does this evidence cover? (Reference to Art. 21(2)(a-j))
- Status tracking: Current / Review due / Expired / Missing.
Phase 3: Close Gaps (Month 2–4)
Now address the gaps from Phase 1. Typical priorities:
-
Build effectiveness evidence: This is almost always the largest gap. Plan and document tabletop exercises. Define and collect KPIs for core processes. Conduct the first effectiveness assessment.
-
Update supply chain evidence: Renew outdated assessments. Build monitoring capability. Review contractual foundations.
-
Prepare incident evidence structures: Templates for real-time documentation. Structures for versioned situation reports. Archival process for completed incidents.
Phase 4: Automation (Month 3–6)
Identify which evidence can be automatically generated or updated:
- Training records from the LMS
- Patch status from vulnerability management
- Access logs from IAM
- Supplier monitoring from the Trust Center platform
- Incident logs from the incident management system
Automation reduces manual effort and increases currency. Not everything needs to be automated – but everything that can be, should be.
Phase 5: Test (Month 4–6)
The ultimate test: simulate an authority request.
Scenario: The supervisory authority requests evidence within five business days covering:
- Your current risk posture and the risk management measures in place
- The effectiveness of your incident management capability
- The current status of your supplier security
- Executive management training records
Can you deliver that? In five days? Complete, current, verifiable?
If yes: you're prepared. If no: you now know what's missing.
Internal Control and External Communication
An ISMS manages internal security: identify risks, implement measures, assess effectiveness, continuously improve. That's essential and remains so.
The evidence obligation under NIS2 adds an external dimension: the ability to show third parties – supervisory authorities, customers, partners – at any time that internal control is working. Not with an audit report from yesterday, but with current, verifiable evidence.
These are two different tasks. Internal control needs an ISMS. External communication needs a layer that structures evidence, keeps it current, and makes it available on demand – a Trust Center that bridges the gap between internal governance and external evidence obligations.
Sources
- Directive (EU) 2022/2555 (NIS2 Directive) – Full Text – Article 21(2)(f) on effectiveness assessment, Articles 32 and 33 on supervisory powers.
- BSI – NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) – § 30 BSIG on risk management measures, §§ 61–65 on supervision and enforcement.
- ENISA – Implementing Guidance on NIS2 Security Measures – Implementation guidance including evidence requirements.
- ISO/IEC 27001:2022 – Information Security Management Systems – Requirements for internal audits, management reviews, and continual improvement as comparison baseline.
- BSI – Orientierungshilfe NIS-2 für die Wirtschaft – Guidance on practical implementation.
Related Reading
- ISO 27001 Is Not NIS2 Compliance: What's Actually Missing
- NIS2 Compliance Checklist: What Your ISMS Covers and What It Doesn't
- NIS2 Supply Chain Security: Why Annual Vendor Assessments Are No Longer Enough
- NIS2 Incident Reporting: How to Actually Meet the 24-Hour Deadline
- Incident Response Plan vs. Incident Management System: What NIS2 Actually Requires
- You're NIS2-Affected — Now What?