Most companies caught by NIS2 already do the things. Backups run. MFA is on. Someone patches. The gap is almost never the control itself, it is that nobody can show a supervisor a written, dated, approved procedure describing how the control works and who is responsible for it.
Article 21(2) of the directive lists ten areas, and the wording matters: it repeatedly asks for policies and procedures, not capabilities. Incident handling. Business continuity. Supply chain security. Access control and human resources security. Policies and procedures to assess whether the measures actually work. A tool that does the thing is not the same as a procedure that describes the thing.
This is a practical look at the documentation side of NIS2, written for European ops and IT teams. Full disclosure: we build Loopyback, an EU-hosted process documentation tool, so we are not neutral. We are also not a GRC platform, and the honest limits of that are further down.
What the directive asks for, in documentation terms
Article 21(1) sets the tone: measures must be appropriate and proportionate to the entity's size, exposure and risk. A 60-person logistics firm is not expected to produce what a bank produces. But proportionate is not the same as absent, and "we do it, we just never wrote it down" is the weakest possible position in an inspection.
Article 20 raises the stakes. Management bodies must approve the cybersecurity risk-management measures and oversee their implementation, and can be held liable for failures. Approval implies something to approve. That something is a document with a version, a date and a name on it.
Article 21(2)(g) adds basic cyber hygiene practices and cybersecurity training. Training that leaves no trace is training that did not happen, as far as evidence goes.
The four properties that turn a guide into evidence
A procedure only counts if it can answer four questions on the spot.
| Wiki page | Word file on a shared drive | Recorded step-by-step guide | |
|---|---|---|---|
| Who wrote it, and when | Usually visible | Often lost on copy | Captured at recording |
| Which version was approved | Rarely tracked | Filename versioning at best | Version history per guide |
| Is it still accurate | Unknown until someone checks | Unknown | Screenshots show the real interface, so drift is visible |
| Who has read it | No | No | Depends on the tool, ask |
The third row is the one people underestimate. A written procedure ages invisibly: the words still read fine two years after the admin panel changed. A screenshot-based guide fails loudly, because the screen in the guide no longer matches the screen in front of you. For an evidence file, loud failure is a feature.
Where documentation itself becomes a risk
There is a trap specific to security procedures. The guide that explains how to rotate a key, reset an account or access a production system is, by construction, a map of your controls. Two consequences.
It contains things that must not be in it. Recording an access-control procedure means screenshots of user lists, email addresses, roles, sometimes a token in a URL bar. Under the GDPR that is personal data processing; under NIS2 (21(2)(i)) it is also an access-control artefact. Redaction that happens before the screenshot leaves the browser keeps it out of the pipeline entirely. Redaction applied after upload does not, because the original already travelled.
Its hosting is a supply-chain question. Article 21(2)(d) covers security in the relationships with your direct suppliers. Your documentation vendor is a direct supplier holding a description of your security controls. That makes four questions reasonable, and you should put them to us too:
- Where is the content stored, and where are backups held?
- Who are the sub-processors, and is the list current?
- What is the transfer mechanism if any processing sits outside the EU?
- How is sharing controlled, and can public links be disabled at organisation level?
Our comparison of European SOP and documentation software goes through the hosting question tool by tool.
Common mistakes
Writing policies instead of procedures. "We maintain regular backups" is a policy. A procedure says who runs the restore test, on which system, how often, and what a successful result looks like. Article 21(2)(f) asks specifically about assessing effectiveness, which means the test needs its own written procedure.
Documenting only the happy path. The incident-handling procedure that matters is the one someone follows at 02:00 while stressed. If it does not include who to call and what to do when the primary contact does not answer, it will not survive first contact.
No approval trail. A perfect procedure that nobody in the management body ever signed off does not satisfy Article 20. Put approval date and approver in the document itself, not in an email thread.
Treating the documentation tool as the compliance system. It is not. A guide library holds procedures; it does not hold your risk register, your asset inventory or your incident log. Anyone selling you documentation software as NIS2 compliance is overselling, ourselves included. What it does is remove the most common excuse for procedures not existing, which is that writing them takes too long.
Letting language block comprehension. If the shift that follows the procedure does not read English, an English procedure is not an effective measure, whatever the file says.
Never revisiting. Procedures written for the audit and then abandoned drift within two quarters. Tie a review date to each one, and treat a failed review as an incident in its own small way.
FAQ
Does NIS2 apply to us?
It generally covers medium and large entities in the sectors listed in Annexes I and II, with national transposition adding detail. Size thresholds and sector scope vary by Member State, so the answer comes from your national implementing law, not from the directive alone.
How much documentation is enough?
Article 21(1) says proportionate. A workable floor: one written procedure for each of the ten areas in 21(2), each naming an owner, a review date and an approval. Depth follows your risk profile, not a template.
Can we reuse our ISO 27001 documentation?
Largely yes. The overlap with Annex A is substantial and supervisors recognise it. NIS2 adds emphasis on management accountability, supply chain and reporting timelines, so expect to extend rather than start over.
Do screenshots in security procedures create a GDPR problem?
They can. User lists, mailboxes and admin panels carry personal data, and a procedure stored for years outlives the records inside it. Redact before capture where the tool allows it, and keep a way to find screenshots when a deletion request arrives. Our guide on writing an SOP people actually follow covers the structure side.
---
Loopyback records a procedure once, redacts personal data before it leaves the browser, keeps version history, and publishes in 10+ languages from EU infrastructure in Belgium. Pricing starts at a free plan, €16 per month for individuals and €24 per seat for teams.
Founder of Loopyback
Suleyman is the founder of Loopyback, a Belgium based tool that turns workflows into step by step guides. He writes about documentation, SOPs and getting knowledge out of people's heads.