NIS2 Document Control Procedures: Versioning, Approval, and the Retention Period the Law Won’t Give You

Search the full text of the NIS2 Directive for the word “retention” and you get zero hits. Search Commission Implementing Regulation (EU) 2024/2690 — the act that actually spells out the technical requirements — for the word “version” and you also get zero. Neither instrument contains the phrase “document control” at all.

That absence is not a loophole. It is the design. The regulation hands you three binding obligations that only a document control system can discharge, then leaves every parameter — version scheme, approval routing, retention duration — for you to set and defend. This guide shows you which Annex points create those duties, what the binding text actually says versus what the recitals merely suggest, and how to derive a retention period an auditor will accept.

What the Law Actually Says About Document Control

In plain terms: NIS2 never mentions document control. Its implementing regulation creates the duty indirectly, through three lettered points buried inside the requirements for your top-level security policy. Get those three right and you have a defensible system. Miss them and you have a filing cabinet.

The chain runs like this. Article 21(2)(a) of Directive (EU) 2022/2555 requires “policies on risk analysis and information system security” [2]. For the entities covered by CIR 2024/2690 — its Article 1 names DNS service providers, TLD name registries, cloud computing and data centre service providers, content delivery network providers, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers — the Annex converts that one phrase into eleven mandatory policy elements at point 1.1.1 [1]. Three of those eleven are document control metadata.

If your entity is not on that Article 1 list — a hospital, an energy operator, a manufacturer — the CIR Annex does not bind you directly. It still matters, because it is the only place the Commission has written down what Article 21(2)(a) means in practice, and national authorities supervising other sectors have nothing more detailed to reason from. Treat it as the benchmark, and say in your own documentation that you have adopted it voluntarily. That framing costs nothing and answers the obvious question before it is asked.

Here is the word census over both official English texts, tag-stripped and whitespace-normalised, so you can reproduce it:

Term	Directive (EU) 2022/2555	CIR (EU) 2024/2690
retention	0	3 (none with a number)
version / versioning	1 / 0 (the single hit is a Member State publishing “a redacted version” of a peer review report — nothing to do with documents)	0 / 0
“document control”	0	0
approval	0	2
archiving	0	1 (cryptographic keys)

If you are a compliance officer, the practical consequence is that you cannot cite a NIS2 article for your retention schedule — you have to cite your own risk assessment instead, and write down why. If you are a CISO, it means the document control discipline your ISMS already runs is not redundant, but it needs re-anchoring to Annex point numbers rather than ISO clause numbers before an audit. If you run a smaller entity without a formal ISMS, it means the whole obligation collapses into one document you already have to write: the top-level policy.

Your Top-Level Policy Is the Document Control Register

In plain terms: most organisations write a standalone “document control procedure” and leave the top-level policy silent on documentation. The Annex asks for the opposite. The register belongs inside the policy.

Three of the eleven elements at point 1.1.1 are verbatim [1]:

• (h) “list the documentation to be kept and the duration of retention of the documentation”
• (i) “list the topic-specific policies”
• (k) “indicate the date of the formal approval by the management bodies of the relevant entities”

Read together, those three points describe a register: what documents exist, how long each is kept, which topic-specific policies sit underneath the top-level one, and when the management body signed. ENISA’s Technical Implementation Guidance confirms the reading — its first example of evidence for this section is a “documented policy on the security of network and information systems which contains the elements required by points 1.1.1 (a) to 1.1.1 (k)” [4]. The evidence is the policy itself, not a separate procedure filed beside it.

This is where most policy sets fail on inspection, and it is a cheap failure to fix. A standalone document control procedure is still useful — keep it — but the list and the retention durations have to appear in, or be explicitly incorporated by, the top-level policy. Our walkthrough of the top-level security policy covers the other eight elements; this is the register that closes the set.

Register column	What goes in it	Which Annex point it discharges
Document ID and title	Stable identifier that survives renaming	1.1.1(h), 1.1.1(i)
Type	Policy, procedure, plan, or record — records are evidence and are never revised, only superseded	1.1.1(h)
Owner	Named role, not a person’s name	1.1.1(g), read with point 1.2
Approver	Management body, or the level of management that signs topic-specific policies	1.1.1(k)
Retention duration	A stated period plus the reason for it	1.1.1(h)
Last review date	Within twelve months, or a documented reason why not	1.1.2

Versioning: The Word the Regulation Never Uses

In plain terms: nothing in NIS2 or its implementing regulation requires version numbers. ENISA asks for change logs instead. You should still run version control — but for evidentiary reasons, not because a rule says so.

The count is stark. Across CIR 2024/2690’s roughly 114,500 characters of English text, “version” appears zero times [1]. Across ENISA’s 170-page implementation guidance, “version control” appears exactly once — and that single occurrence sits in the evidence list for secure development, alongside “code reviews” and “project management tools” [4]. It is about source code. It is never asked of a policy.

What ENISA asks of policies instead is a change log. The phrase appears fifteen times across the guidance, and for the policy review requirement at Annex point 1.1.2 it is the lead evidence item: “Review comments or change logs for the policy on the security of network and information systems and topic-specific policies” [4].

The mechanism matters more than the vocabulary. A version number on its own proves nothing — it is a label. What an inspector can actually test is whether you can reconstruct the document as it stood on a given date, and show what changed and why. A version number is the cheapest index into that history, which is why every mature system uses one. But the thing being evidenced is the change record, not the numeral.

If your document control discipline comes from ISO 27001, that instinct is sound and you can keep it: clause 7.5.3 requires documented information to address “c) distribution, access, retrieval and use; d) storage and preservation, including the preservation of legibility; e) control of changes (e.g. version control); and f) retention and disposition” [5], and clause 7.5.2 requires documents to be identified, formatted, reviewed and approved [6]. That is a complete document control specification, and it maps cleanly onto the Annex. The trap is the reverse direction: do not tell a national authority that clause 7.5.3 is what NIS2 requires. It is what you have chosen as your method of meeting Annex points 1.1.1(h) and 1.1.2, which is a different and much stronger claim. The same logic governs your ISMS scope statement and your Statement of Applicability — both are ISO artefacts doing NIS2 work, and both should say so on their face.

Field in the version block	What it proves to an inspector
Version number and date	An index into the history — on its own, nothing more
Summary of changes	The ENISA change log evidence item for point 1.1.2
Reason for change	Ties the update to a risk assessment result, incident, or legal change, as ENISA’s review guidance expects
Approved by and approval date	Point 1.1.1(k) for the top-level policy; the approval record ENISA expects for every update
Supersedes	Establishes which version was in force on the date of an incident
Next review due	Makes the 1.1.2 annual cycle auditable in one glance

Approval: What Is Binding, What Is a Recital, and Who Actually Signs

In plain terms: the binding text requires the management body to approve the top-level policy and to record the date. The widely quoted rule that topic-specific policies may be signed at a lower level comes from a recital, not an article — it is persuasive, not obligatory.

Start with the Directive. Article 20(1) obliges Member States to ensure that management bodies “approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation and can be held liable for infringements” [2]. That is a “shall”, and personal liability attaches to it.

The implementing regulation then adds two binding requirements. Point 1.1.1(k) requires the policy to “indicate the date of the formal approval by the management bodies”. Point 1.1.2 requires that the policy “shall be reviewed and, where appropriate, updated by management bodies at least annually and when significant incidents or significant changes to operations or risks occur”, and that “the result of the reviews shall be documented” [1].

Now the part that is routinely misreported. The two-tier approval rule — board signs the top-level policy, an appropriate level of management signs the topic-specific ones — appears in Recital 9 of CIR 2024/2690: the policy “should be approved by the management bodies of the relevant entities. The topic-specific policies should be approved by an appropriate level of management” [1]. Recitals explain the legislator’s intent; they do not create obligations, and the operative Annex never repeats the second sentence. ENISA carries it into its guidance as an instruction — “Make sure that the topic-specific policies are approved by an appropriate level of management” — and lists as evidence that updates to topic-specific policies are “approved by an appropriate level of management and a record is kept” [4].

The practical effect is not that you can ignore it. Delegating topic-specific approval is the sensible design and it is what the regulator expects to see. The effect is on how you write it down: a delegation scheme is your documented choice, justified by reference to Recital 9 and ENISA’s guidance, rather than a rule you are reciting. That distinction is exactly the kind of thing that separates a policy set that survives questioning from one that does not.

One more ENISA instruction is worth lifting out, because no competing guide mentions it and it belongs squarely in a document control procedure: “Make sure that the policy includes detailed guidance on the procedures for managing policy exceptions” [4]. Exceptions are documents too. They need an owner, an approver, an expiry date and a retention period like everything else.

Document	Who approves	Source and status
Top-level security policy	Management body	CIR Annex 1.1.1(k) and Directive Art. 20(1) — binding
Every update to the top-level policy	Management body, with a record kept	CIR Annex 1.1.2 (binding) as read by ENISA guidance
Topic-specific policies and their updates	An appropriate level of management	CIR Recital 9 and ENISA guidance — persuasive, not binding
Policy exceptions	Management body, per ENISA	ENISA guidance — persuasive
Annual review outcome	Management body; result documented	CIR Annex 1.1.2 — binding

Retention: The Number the Regulation Will Not Give You

In plain terms: there is no NIS2 retention period. Any guide quoting one is quoting itself. Your job is to derive a number from named inputs and record the derivation.

The word “retention” appears three times in CIR 2024/2690 and never with a figure [1]. Point 1.1.1(h) tells you to state the duration. Point 4.2.2(f) asks for backup “retention periods based on business and regulatory requirements”. A recital mentions retention among asset-protection measures. Separately, point 3.2.5 requires entities to “maintain and back up logs for a predefined period” — predefined by you.

The guidance does not close the gap either. ENISA’s advice on point 3.2.5 sends the reader to point 4.2.2(f); its advice on backups sends the reader back toward the log retention discussion. The complete evidence bullet ENISA offers for log retention is five words: “A retention period is set.” [4]

Two consequences follow, and the second one is the one people miss.

First, figures presented as NIS2 retention requirements — five years for incident records, three years for risk assessments, and similar — are not in the Directive or the Regulation. They may be perfectly sensible periods, and national law or sector rules may independently impose them, but they do not have the status their presentation implies. Practitioner guidance reaches the same conclusion from the other direction: retention “should be determined using national requirements, limitation periods, sector rules, contractual duties, audit cycles, incident-investigation needs and the organisation’s risk” [7]. Of the three widely circulated NIS2 documentation guides we read while researching this piece, none cited a single Annex point number, and one presented durations of this kind as requirements.

Second, ENISA pairs the instruction to set a period with an instruction almost nobody implements: “Delete data when the retention period ends” [4]. A schedule you overshoot is evidence of an unmanaged process in the same way a schedule you undershoot is. Keeping everything forever is not the safe option.

Here is the derivation to write into your register. Each row produces a candidate duration; the retained period is the longest candidate, and the reason you write down is the row that produced it.

Input	Where it comes from	What you record
Legal and regulatory obligations	National NIS2 transposition, sector law, company law, tax law	The instrument and the period it imposes
Limitation periods	National civil and administrative law	How long a claim could still be brought
Supervisory cycle	Directive Art. 32(2) audit and inspection powers	Enough history to answer an inspection covering prior periods
Risk assessment result	Your own assessment, per CIR Annex 2.1	The investigation window the risk implies
Contractual duties	Customer and supplier agreements	The longest contractual retention you have accepted
Data protection limits	GDPR storage limitation	The ceiling — where personal data is involved, this caps the others

That last row is the one to argue carefully. Because NIS2 sets no floor, it can never justify retaining personal data longer than data protection law allows. The two regimes compose rather than conflict: NIS2 supplies a legitimate security purpose, the purpose sets the duration, and storage limitation caps it. Testing that the schedule is actually applied is a natural line item for your internal audit checklist, and the documents themselves are catalogued in our guide to the eight records a CISO has to be able to produce.

Retention is the one element of document control large enough to be a policy in its own right, and the derivation above is the short version. For the full schedule across every record class, the board-approval step that turns it into a binding artefact, and the deletion half most teams never implement, see our dedicated guide to building a NIS2 data retention policy.

Why Document Control Bites: Article 32(2)(f) and (g)

In plain terms: the enforcement mechanism is not a document control rule. It is the supervisor’s power to ask for anything and expect it on demand.

Article 32(2) lets competent authorities subject essential entities to on-site inspections, regular and targeted security audits, ad hoc audits where a significant incident or an infringement justifies one, and security scans. Two of its points do the real work here [3]:

• 32(2)(f) — “requests to access data, documents and information necessary to carry out their supervisory tasks”
• 32(2)(g) — “requests for evidence of implementation of cybersecurity policies, such as the results of security audits carried out by a qualified auditor”

Point (g) is the sharper one, because “evidence of implementation” is not the policy. A current, signed policy proves you wrote a policy. Proving implementation means producing the approval record, the review minutes, the change log showing the control was in force on the relevant date, and the retained artefacts the policy said you would keep. Without a register, every such request becomes a search. Our evidence collection guide covers what that corpus looks like in practice.

A Document Control Procedure You Can Stand Up This Quarter

Five steps, in dependency order. Effort ratings assume a policy set already exists.

#	Step	Closes	Effort
1	Inventory every policy, procedure, plan and record, and assign each a stable ID and a named owner role	1.1.1(h), 1.1.1(i)	Medium
2	Derive a retention duration per document class using the six inputs above, and write the reason beside each	1.1.1(h)	Medium
3	Insert the register and the retention durations into the top-level policy, or incorporate them by explicit reference	1.1.1(h), 1.1.1(i)	Low
4	Add a version block to every document, and take the top-level policy to the management body for formal approval with a dated resolution	1.1.1(k), 1.1.2	Low
5	Schedule the annual review, define the exception procedure, and set the deletion trigger that fires when a retention period ends	1.1.2, ENISA guidance	High

To turn that into a gap analysis, put three columns beside each step: what exists today, what the Annex point requires, and the smallest change that closes the distance. Steps 3 and 4 are usually a single afternoon each and close the two failures an inspector notices first — a policy with no register, and a policy with no approval date.

The thread running through all five steps is worth naming, because it changes how you write every document in the set. NIS2 does not tell you what good document control looks like. It tells you to decide, write the decision down inside the top-level policy, have the right people sign it, and be able to produce the result on request. Every parameter the regulation declines to set — the version scheme, the approver for a topic-specific policy, the number of months you keep an artefact — becomes a documented judgement rather than a compliance box. That is more work than following a rule, and it is also more defensible, because a judgement with its reasoning attached survives a question that a copied number cannot.

Frequently Asked Questions

Does NIS2 require a separate document control procedure?

No. Neither the Directive nor CIR 2024/2690 uses the phrase. The binding requirements are Annex points 1.1.1(h), 1.1.1(i), 1.1.1(k) and 1.1.2, and all four are discharged through the top-level security policy. A separate procedure is a reasonable way to operationalise them, but it is your choice of method, not a legal requirement.

What retention period should I set for compliance records?

There is no correct answer supplied by the legislation, because neither instrument states one. Derive it from national law, limitation periods, your supervisory cycle, your own risk assessment, contractual duties, and — where personal data is involved — the storage limitation ceiling. Record which input produced the number. The documented derivation is the compliance artefact, not the number.

Do version numbers have to follow a particular scheme?

No scheme is specified anywhere in the Directive, the Implementing Regulation, or ENISA’s guidance. What ENISA actually asks for at point 1.1.2 is review comments or change logs. Use whatever scheme lets you show what a document said on a given date and why it changed.

Can the CISO approve the security policy instead of the board?

Not for the top-level policy. Directive Article 20(1) places approval of the risk-management measures with the management body, and Annex point 1.1.1(k) requires the policy to carry the date of that formal approval. Topic-specific policies are a different matter — Recital 9 and ENISA’s guidance both point to approval at an appropriate level of management, which is where delegation to the CISO properly sits.

We are ISO 27001 certified. Is our clause 7.5 process enough?

It is a strong starting position and it covers the substance. What it does not do by itself is demonstrate the mapping. Re-anchor your document control procedure so each control names the Annex point it discharges, and make sure the retention list and the topic-policy list actually appear in the top-level policy — ISO does not require them to live there, and the Annex effectively does.

How This Article Was Verified

Every Annex point, article number and recital quoted above was checked against the official English text rather than against secondary commentary. The word counts are reproducible: we retrieved the EUR-Lex HTML of both instruments, stripped the markup, normalised whitespace, and counted word matches over 275,570 characters of the Directive and 114,551 of the Implementing Regulation. The ENISA figures come from the published 170-page PDF of the Technical Implementation Guidance v1.0, text-extracted and searched the same way. Where a rule exists only in a recital or in ENISA guidance, the article says so and labels it non-binding, because on a question like this the difference between “the law requires” and “the regulator expects” is the whole answer.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex (Annex points 1.1.1, 1.1.2, 3.2.5, 4.2.2; Recital 9)
2. Directive (EU) 2022/2555 (NIS2) — EUR-Lex (Articles 20 and 21)
3. NIS2 Directive Article 32 — Supervisory and enforcement measures in relation to essential entities
4. ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0, June 2025 (PDF)
5. ISO 27001 Clause 7.5.3 Control of Documented Information — High Table
6. ISO 27001 Clause 7.5 Documented information — Advisera
7. NIS2 Compliance Documentation: What Evidence Should Businesses Prepare? — TTMS

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.