NIS2 Documentation Requirements: Policies You Must Have

Why Documentation Matters Under NIS2

NIS2 exists to protect services that society depends on: energy, health, transport, water, digital infrastructure and a long list of others. The Directive is written around outcomes. It rarely tells you how to secure something. That flexibility is useful, but it shifts the burden onto you to show that what you chose was appropriate.

Documentation carries that burden in three ways.

One point from the earlier version of this article is worth keeping, because it’s the heart of the topic: documents and operating data do different jobs. A policy explains the rule and why you chose it. Logs, tickets and test results show the rule is being followed. You need both.

Gaps between the two are what supervisory findings are made of. When an authority’s findings escalate, the Directive allows binding instructions, orders and administrative fines; we cover that side in our guide to NIS2 fines and legal consequences.

What NIS2 Actually Requires (and Where Each Requirement Comes From)

A lot of NIS2 confusion comes from mixing up sources. A consultant’s policy template, an ENISA example and a line of the Directive all end up described as “NIS2 requirements”. They aren’t equal, and your documentation should reflect that.

The Directive’s own wording is deliberately technology-neutral. Article 21(1) asks for “appropriate and proportionate technical, operational and organisational measures”, based on an all-hazards approach. It doesn’t mandate a SIEM or any particular tool. The picture changes for entities covered by the Implementing Regulation: its Annex (point 3.2) requires documented monitoring and logging procedures, a list of logged assets and log retention for a predefined period.

Article 20: Management and Governance Documentation

Article 20 is short, and it changes who in your organisation owns cybersecurity. It requires three things of the management body.

For entities under the Implementing Regulation, the governance record gets more specific. The top-level policy on the security of network and information systems has to show the date of its formal approval by the management bodies (Annex 1.1.1(k)), be reviewed at least annually (1.1.2), and at least one person must report directly to the management bodies on network and information security (1.2.3). Implementing requirement

A correction to the earlier version of this article: NIS2 doesn’t say an unsigned policy is invalid or that regulators treat missing signatures as a governance failure. What matters is that approval is traceable, whether that’s a wet signature, an e-signature, a document-management workflow or dated minutes.

Article 21: Cybersecurity Risk-Management Documentation

Article 21(1) requires appropriate and proportionate measures, taking into account the state of the art, relevant standards and cost, and weighing your exposure to risk, your size, and the likelihood and severity of incidents. Article 21(2) then lists the minimum ground those measures must cover:

Two paragraphs after the list matter for documentation too. Article 21(3) says supplier decisions should consider each direct supplier’s specific vulnerabilities, the overall quality of their products and cybersecurity practices, including secure development procedures. Article 21(4) requires you to take corrective measures without undue delay when you find you’re not compliant, so a tracked corrective action log is worth having.

For entities covered by the Implementing Regulation, the Annex goes much further. The top-level security policy must list the topic-specific policies, list the documentation to be kept and how long it’s retained (Annex 1.1.1(h) and (i)), and risk assessments must be documented and reviewed at least annually (2.1.4). Where the Annex says a requirement applies “where appropriate”, “where applicable” or “to the extent feasible” and you decide it doesn’t, Article 2(2) requires you to document your reasoning in a comprehensible way. Implementing requirement

NIS2 Documentation Requirements Matrix

Use this as a working map between the legal obligation and the evidence you’d expect to show for it. “IR” refers to the Annex of Implementing Regulation (EU) 2024/2690, which binds only the digital provider types listed above; for everyone else it’s a detailed benchmark.

Read the columns carefully: “Typical documentation / evidence” is not a list of documents the Directive names. The owner and review-trigger columns are our recommendations unless the legal reference column says otherwise.

Swipe sideways to see all columns on smaller screens.

The Core NIS2 Policy Areas

You can structure your policy set however you like: one integrated security policy with standards underneath, or a handful of topic policies. What matters is that each Article 21(2) area is answered somewhere, by someone accountable. These are the questions we’d expect each area to answer. VISTA recommendation

Article 23: Incident Reporting Documentation

Article 23 applies to significant incidents, meaning incidents that have caused, or are capable of causing, severe operational disruption or financial loss for you, or considerable material or non-material damage to others. You notify your CSIRT or competent authority, and where appropriate you also tell the recipients of your services. The reporting runs in stages:

Timelines run from when you become aware of the significant incident. Trust service providers have a 24-hour deadline for the incident notification itself where trust services are affected. Always check your national law for portals, formats and authority contacts. Legal requirement

You can’t write any of this at hour 23. The documentation that matters is the set you prepare beforehand:

If you’re covered by the Implementing Regulation, “significant” is defined for you. Among other criteria, an incident qualifies if it causes or could cause direct financial loss above EUR 500,000 or 5% of annual turnover, whichever is lower, and repeated incidents with the same apparent root cause can count together if they happen at least twice in six months (IR Articles 3 and 4). The Annex also requires you to check for those recurring incidents quarterly (3.4.2(b)). Implementing requirement

We walk through each stage in more detail in our article on the NIS2 incident reporting timeline. And because a significant NIS2 incident and a GDPR personal data breach aren’t the same event, your playbook should route both questions in parallel; our piece on aligning NIS2 and GDPR compliance shows where the two overlap and where they don’t.

Documentation for Essential and Important Entities

This is one of the most misunderstood points. The earlier version of this article described “additional documents required for essential entities”. The Directive doesn’t set extra documents for them. Articles 21 and 23 apply to essential and important entities alike. What differs is how you’re supervised and the maximum fines.

Classification itself belongs in your documentation. Record which legal entities are in scope, under which sector and which national law, and how you applied the size rules. Scope is also where overlaps get decided: financial entities covered by DORA, for example, follow DORA’s ICT risk rules where they apply, which our guide to the difference between NIS2 and DORA covers in depth. If you’re still working out whether you’re in scope at all, our NIS2 compliance checklist starts with exactly that question.

NIS2 Documentation for Digital Infrastructure and ICT Service Providers

If you’re a DNS service provider, TLD name registry, cloud computing, data centre or content delivery network provider, managed service provider, managed security service provider, online marketplace, online search engine, social networking platform or trust service provider, your documentation bar is set at EU level by Implementing Regulation (EU) 2024/2690. A few of its requirements are unusually concrete:

These providers also fall under the jurisdiction of the Member State where they have their main establishment in the EU (Article 26(1)(b)), and have to provide registration information under Article 27. ENISA’s technical implementation guidance, published in June 2025, gives examples of evidence for each Annex requirement, which makes it a practical cross-check when you build your evidence register. ENISA guidance

ISO 27001 and NIS2 Documentation Overlap

If you run an ISMS, you’re starting well ahead. The Implementing Regulation itself says its technical requirements are based on European and international standards such as ISO/IEC 27001, ISO/IEC 27002 and ETSI EN 319 401. But an ISO 27001 certificate isn’t a NIS2 compliance certificate, and the gaps tend to show up in the same places.

A correction worth making here: the earlier version said Article 21(2)(d) requires “continuous” third-party monitoring rather than questionnaires. The Directive doesn’t say that. The Implementing Regulation requires supplier practices to be monitored and re-evaluated at planned intervals and when significant changes or supplier-related incidents occur (Annex 5.1.6). How often and by what means is a risk-based choice you should document. If you want an ISMS that’s built with NIS2 mapping in mind from the start, our ISO 27001 audit and certification team can help align the two.

NIS2 Documentation for Non-EU Organisations

The earlier version of this article said that under Article 26, serving EU markets means you must comply wherever you’re headquartered. That’s too broad. The actual position has three parts:

• EU establishments are in scope under local law. Entities generally fall under the jurisdiction of the Member State where they’re established (Article 26(1)). A non-EU group’s EU subsidiary in a covered sector is treated like any other EU entity.
• Certain digital providers need an EU representative. If you’re one of the provider types in Article 26(1)(b), such as a cloud, data centre, managed service or DNS provider, and you offer services in the EU without being established there, Article 26(3) requires you to designate a representative in the EU. Keep the appointment on file.
• Everyone else mostly meets NIS2 through contracts. In-scope EU customers must manage supply chain risk, and IR entities must put security clauses in supplier contracts, including incident notification and audit rights. Expect questionnaires, contract riders and evidence requests.

NIS2 Policy Review and Maintenance

The Directive itself sets no policy review frequencies. The earlier version of this article presented a “minimum review frequency” table as if it were required; it wasn’t. The Implementing Regulation does set a few, and it uses event triggers heavily. Here’s how the two fit together.

Version Control, Evidence and Audit Trail

Two more corrections here. First, the earlier version said Articles 31 and 32 “require a complete lifecycle history” of documents. They don’t. They’re supervision provisions: they give authorities the power to inspect, audit and request information and evidence. Second, NIS2 sets no minimum retention periods, so the old suggestion of fixed periods such as five years for incident records had no legal basis and we’ve removed it.

What the rules do say: IR entities must define the documentation to be kept and its retention period in their top-level policy (Annex 1.1.1(h)), keep logs for a predefined period and protect them from tampering (3.2.5), and set backup retention based on business and regulatory requirements (4.2.2(f)). Everyone else should set retention periods using national law, contractual obligations, limitation periods and, for anything containing personal data, the GDPR’s storage-limitation principle.

What every controlled document should carry

That last item isn’t just tidy practice for IR entities: the top-level policy must be communicated to, and acknowledged by, relevant employees and interested external parties (Annex 1.1.1(f)).

We’d also keep one more document that many teams skip: an evidence register. It’s a single table linking each NIS2 obligation to the policy that addresses it and the place its operating evidence lives. When a request arrives, it turns a scramble into a lookup. It also reflects how we think about the whole topic:

Common NIS2 Documentation Mistakes

These are the patterns we see most often when reviewing NIS2 documentation sets.

NIS2 Documentation Readiness Checklist

Work through these with your security, risk and compliance leads. A tick should mean you could hand over the evidence today, not that it’s planned.

Frequently Asked Questions About NIS2 Documentation

From a Folder of Policies to a System You Can Evidence

NIS2 documentation isn’t a deliverable you finish. It’s the written side of a risk-management system that has to keep working: approved by management, tied to real risks, tested, and updated when things change.

If you’re starting out, begin with scope and the top-level policy, then the risk assessment, then incident reporting. If you already have an ISMS, start with the gaps in Article 20, Article 23 and supplier management. Either way, build the evidence register as you go, because that’s the document that will make the first supervisory request feel routine.

Continue Your NIS2 Research