Tier B · can be used in your compliance program
NIS2 document management for essential and important entities
Document-lifecycle controls for the new EU directive on network and information security.
By Giuseppe Marchi · Microsoft SharePoint MVP · intranet.ai
The NIS2 Directive (EU 2022/2555) raised the bar on documented security policies, incident-handling procedures, and supply-chain documentation for essential and important entities across the European Union. The product provides document-lifecycle capabilities — templates, sequential approval, audit log, retention with expiration — that organizations can use as part of their NIS2 documentation program. It is not positioned as a NIS2-certified solution, and NIS2 itself does not have a product-certification scheme; what matters is whether the entity can demonstrate documented controls under enforcement review.
What NIS2 introduces on the documentation front
NIS2 applies to two categories of organizations:
- Essential entities in sectors including energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, public administration, and space.
- Important entities in additional sectors including postal and courier services, waste management, manufacturing of critical products, digital providers, and research.
Article 21 of the Directive lays out the cybersecurity risk-management measures these entities must have in place. The implication for documentation: each of the measures in Article 21 — risk analysis, incident handling, business continuity, supply-chain security, network security, access control, cryptography, HR security, asset management — needs to be documented. Article 23 adds incident-reporting obligations with their own supporting procedures and evidence.
Article 24 further requires entities to supervise the implementation of their measures and to be able to demonstrate compliance to the relevant competent authority — which means the documentation has to be current, approved, accessible, and defensible on demand.
For essential and important entities that are already ISO 27001 certified, the overlap is substantial — much of what NIS2 asks for is already in the ISMS. For entities that are not yet ISO 27001 certified, NIS2 may be the pressure that drives the first formal document-management program for security-relevant documented information.
How the product’s capabilities support NIS2 documentation
Templates for policy consistency. Every security-relevant document — risk-analysis reports, incident-response runbooks, supplier-security procedures, business-continuity plans — starts from a governed template. Cross-organizational consistency is the default, not an occasional best effort.
Sequential approval with audit evidence. Security-relevant documents typically need approval from multiple roles — CISO, CIO, DPO, legal — before they’re effective. Sequential approval with role-based routing enforces the sign-off chain; the audit log records it. When the supervisory authority asks “how was this procedure approved and by whom,” the answer is trivial to produce.
Expiration reminders for periodic review. NIS2 expects documented measures to be reviewed and updated as circumstances change. Expiration metadata on each document triggers automatic review prompts to the document’s owner. Review becomes an operational pattern, not a once-every-audit scramble.
Data stays inside your tenant. For entities whose critical information is governed by national-security, data-residency, or sector-specific restrictions, the fact that the product runs inside the customer’s Microsoft 365 tenant is directly relevant. Documents describing critical systems stay inside the Microsoft infrastructure the entity has already committed to, not in a third-party DMS platform with its own data-residency policy.
Integrates with the broader Microsoft 365 security stack. Purview retention, Defender-series security, Entra identity — the entity’s existing security investments apply uniformly. The product doesn’t introduce a parallel security surface to monitor.
A CISO’s view — what NIS2 documentation looks like in practice
Consider a European energy operator designated as an essential entity under NIS2. The CISO maintains a body of documented security policies and procedures covering the Article 21 measures:
- Risk-analysis methodology and the latest risk assessment.
- Incident-response playbook and escalation procedures.
- Supply-chain security assessment criteria and supplier evaluations.
- Network-segmentation architecture and firewall-change procedures.
- Access-control policies and access-review procedures.
- Cryptography standards and key-management procedures.
- Business-continuity and disaster-recovery plans.
- Asset management and configuration procedures.
Under NIS2 enforcement pressure, every one of these documents needs to be current, approved by authorized parties, and retrievable on demand. With docs365.ai:
- Each document type is a library with its own template, approval flow (typically: CISO authors/reviews, senior management approves), and review cadence.
- The audit log on each document produces the approval evidence. The Power BI dashboard (Enterprise plan and above) shows the overall review-cadence adherence across the NIS2-relevant documentation corpus.
- When a supervisory authority asks for the current state of a specific procedure, the public area produces it. When they ask for the evolution of that procedure over time, the version history and archive produce that too.
- Supply-chain security documentation benefits particularly from the product’s structured approach — supplier evaluations, vendor-security questionnaires, and supplier-incident documentation all fit the same lifecycle discipline.
This is the NIS2-documentation operational pattern the product enables.
What NIS2 specifically does not demand
A specific software product. A formal certification. A particular technology stack. What it demands is that the entity can demonstrate adequate documented controls and can evidence their approval and review under enforcement scrutiny. That demonstration is exactly what the product’s audit log, versioning, and archive produce.
Article 21 — The 10 measures and their documentation footprint
Article 21 lists ten cybersecurity risk-management measures. Each one generates a documentation requirement. The table below maps each measure to the documents it demands and to the specific product capability that covers that requirement.
| # | Article 21 Measure | What needs to be documented | docs365.ai capability |
|---|---|---|---|
| 1 | Risk analysis and information security policies | Risk methodology, risk register, approved security policies, annual review records | Template library for policy documents; sequential approval capturing CISO + management sign-off; expiration reminders for annual review |
| 2 | Incident handling | Incident-response plan, escalation matrix, post-incident review reports, CSIRT notification procedures | Runbook template with structured sections; approval flow for plan changes; versioned archive showing procedure evolution over time |
| 3 | Business continuity | BCP and DRP documents, backup procedures, crisis-communication procedures, test records | Dedicated template per plan type; expiration-triggered review cycle; version history showing test iterations |
| 4 | Supply-chain security | Vendor risk assessment framework, supplier security questionnaires, contractual clauses register, third-party incident log | Supplier-evaluation templates; library per vendor category; structured lifecycle applied uniformly across the supplier portfolio |
| 5 | Network and information system security | Network architecture diagrams, firewall-change procedures, patch-management policy, vulnerability-management process | Technical-document templates with controlled publishing; approval required before any updated diagram or procedure becomes effective |
| 6 | Access control and asset management | Access-control policy, asset inventory procedures, access-review records, privileged-access procedures | Policy templates with role-based approval routing; automatic review reminders; audit log capturing each approval event |
| 7 | Cryptography and encryption | Cryptography standards, key-management procedures, encryption scope documentation | Standards documents under full lifecycle control; approval chain ensures cryptography decisions are formally authorized |
| 8 | HR security and personnel security | Onboarding/offboarding procedures, security-awareness training records, acceptable-use policy, NDA register | HR-procedure templates; publishing workflow ensures effective versions are always current; expiration triggers re-training cycles |
| 9 | Multi-factor authentication and access security | MFA policy, authentication standards document, exception register | Policy template with formal approval; exception-handling procedure under the same lifecycle discipline |
| 10 | Security of network and information systems acquisition, development, and maintenance | Secure SDLC policy, procurement security requirements, change-management procedures | Technical-policy templates with sequential approval; archive retains superseded versions for audit trail |
Two practical observations for CISOs working through this list. First, measures 1, 2, and 3 generate the highest documentation volume and the most frequent review cycles. Those three are where a governed document system pays the most visible return. Second, measures 4 and 8 often surprise organizations — supply-chain documentation and HR-security documentation are typically less mature than the network-security documentation, yet they’re areas where supervisory authorities focus significant scrutiny.
NIS2 vs ISO 27001 — documentation overlap
For organizations that are already ISO 27001 certified, the NIS2 documentation scope is not a blank sheet. The Article 21 measures map directly to Annex A control domains. The table below shows the primary mappings; it is not exhaustive, but it captures the areas where existing ISMS documentation can be adapted rather than built from scratch.
| Article 21 Measure | ISO 27001:2022 Annex A controls (primary) | Overlap assessment |
|---|---|---|
| Risk analysis and information security policies | 5.1 (Policies), 6.1.2 (Information security risk assessment) | High — ISO 27001 ISMS scope document and risk assessment methodology directly satisfy NIS2 evidence requirements |
| Incident handling | 5.24–5.28 (Incident management controls) | High — ISO 27001 incident-management procedure maps well; NIS2 adds the mandatory CSIRT reporting timeline |
| Business continuity | 5.29–5.30 (Business continuity) | High — ISO 27001 BCP/DRP documentation is directly reusable |
| Supply-chain security | 5.19–5.22 (Supplier relationships) | Medium-High — ISO 27001 supplier-security section exists but NIS2 demands deeper contractual and incident-reporting specificity |
| Network and information system security | 5.31 (Legal requirements), 8.20–8.23 (Network controls) | Medium — ISO 27001 technical controls exist but NIS2 expects more explicit network-architecture documentation |
| Access control and asset management | 5.9–5.14 (Asset management), 5.15–5.18 (Access control) | High — strong existing overlap; access-review records from ISO 27001 internal audits satisfy NIS2 evidence needs |
| Cryptography and encryption | 8.24 (Cryptography) | High — ISO 27001 cryptography policy directly applicable |
| HR security and personnel | 6.1–6.8 (People controls) | Medium — ISO 27001 HR security controls exist; NIS2 elevates security-awareness requirements for specific roles |
| Multi-factor authentication | 5.17 (Authentication), 8.5 (Secure authentication) | Medium — ISO 27001 addresses authentication; NIS2 Article 21(2)(j) makes MFA explicit for network access |
| Security of systems acquisition | 8.25–8.33 (Secure development) | Medium — ISO 27001 secure SDLC controls apply; NIS2 extends the expectation to procurement and third-party systems |
The practical implication: an ISO 27001 certified entity working on NIS2 compliance should audit the gaps, not rebuild the documentation program. The gaps most commonly found in practice are: supply-chain incident-reporting procedures, explicit MFA policy documents, and the formal management-accountability chain that NIS2 Article 20 requires.
For entities using docs365.ai with an existing ISO 27001 ISMS, the typical approach is to import existing policy documents into governed libraries, apply the approval and expiration lifecycle to them, and then fill the identified gaps with new documents using the available templates.
FAQ
Is the product NIS2 certified? NIS2 does not have a product-certification scheme. Entities demonstrate compliance through their documented measures and the evidence of their implementation. The product provides capabilities that entities use in their NIS2 documentation program.
We’re ISO 27001 certified already. What changes under NIS2? NIS2 draws heavily from the same control categories as ISO 27001 Annex A, so the overlap is substantial. Where NIS2 goes further is in supply-chain scrutiny, executive-management accountability, and reporting obligations. The documentation for those additional areas fits the same product lifecycle.
Does the product handle NIS2 incident reporting? The product provides the documented-procedure side — the incident-response playbook, the escalation procedures, the post-incident review documents. The actual incident-reporting workflow to the national CSIRT or authority is a separate operational process; the product doesn’t automate the regulatory filing itself.
What’s the timeline pressure? The NIS2 transposition deadline for EU member states was October 2024. National transpositions are now live across most member states, with enforcement ramping over 2025 and 2026. Essential and important entities who haven’t yet moved their documentation to a governed system are under real pressure.
Which sectors fall under NIS2 essential vs important entities? Essential entities include operators in energy (electricity, oil, gas, district heating, hydrogen), transport (air, rail, water, road), banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure (DNS providers, TLD registries, IXPs, cloud providers, data centers, CDNs, trust service providers, electronic communication networks), public administration, and space. Important entities cover postal and courier services, waste management, manufacture of critical products (medical devices, computers, motor vehicles, electrical equipment, machinery), food production and distribution at scale, digital providers (online marketplaces, search engines, social networks), and research organizations. The distinction matters because essential entities face stricter supervisory conditions, including proactive ex-ante supervision; important entities are subject to ex-post supervision triggered by evidence of non-compliance.
What are the penalties for NIS2 non-compliance? Article 34 sets the maximum administrative fines: essential entities face fines up to €10 million or 2% of global annual turnover (whichever is higher); important entities face fines up to €7 million or 1.4% of global annual turnover. Beyond financial penalties, Article 32 allows supervisory authorities to issue binding instructions, mandate security audits, suspend certifications, and — for essential entities — temporarily prohibit named management personnel from holding management roles. The personal liability angle for senior management is one of the most significant enforcement changes compared to NIS1.
How does NIS2 interact with GDPR for organizations subject to both? NIS2 and GDPR operate in parallel, not as a single unified framework. Many incidents that trigger NIS2 reporting obligations (significant incidents affecting service availability) will also trigger GDPR breach notification (if personal data is involved). The timelines differ: NIS2 requires an early warning within 24 hours and a full notification within 72 hours to the competent authority and CSIRT; GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach. In practice, organizations subject to both need coordinated incident-response procedures that satisfy both reporting chains simultaneously. The incident-response playbook and escalation procedures should explicitly address the dual-reporting scenario. That is a document the product’s template and approval lifecycle can help keep current and formally authorized.
Related pages
- ISO 27001 document control → — the closest adjacent standard.
- How governance works → — audit, versioning, expiration, archive.
- Audit log → — feature detail.
Ready to start?
Book a free assessment — 30 minutes, no cost. We’ll walk through the Article 21 documentation scope relevant to your entity type and identify where the product’s capabilities would change the evidence shape under enforcement review.
Ready to align your NIS2 documentation?
Thirty minutes. No cost. No obligation. We'll walk through your current library and identify where this product would change the evidence shape.