NIS2 Data Retention Policy: 3 Mentions, No Number — What to Keep, How Long, and What Auditors Check

Search the official text of Commission Implementing Regulation (EU) 2024/2690 for the word “retention” and you get three hits. None of them is a number. Search for “retain” and you get zero. The closest the instrument comes to a duration is point 3.2.5 of its Annex, which tells you to keep logs “for a predefined period” — predefined by you [1].

So the obligation is not to hit a period someone else set. It is to set one, write it down in a named place, get it approved, and then actually honour it in both directions — including deleting on schedule. That is what a data retention policy is for under NIS2, and it is why an auditor asks for it before asking about your SIEM.

Does This Apply to You? Two Duties, Two Audiences

In plain terms: one group is bound by the detailed Annex text, everyone else in NIS2 scope is bound by the Directive’s broader wording and will be measured against the Annex anyway.

You are…	What binds you	What the retention duty looks like
A DNS provider, TLD registry, cloud or data centre service provider, CDN, managed service or managed security service provider, online marketplace, search engine, social platform, or trust service provider	CIR 2024/2690 directly — Article 1 names exactly these “relevant entities” [1]	Annex 1.1.1(h), 3.2.5 and 4.2.2(f) apply as written. Your policy must list documents and their retention durations.
Any other essential or important entity (energy, transport, health, water, manufacturing, public administration, and the rest)	Article 21(2) of Directive (EU) 2022/2555, via your national transposition [3]	No Annex text applies to you by force of the CIR. But the CIR is the Commission’s own statement of what Article 21(2) means, and supervisors read it that way. Treat it as the benchmark.

The distinction is narrower than it looks. Skip a retention decision in the first row and you have failed a written requirement. Skip it in the second and you have failed a reasonableness test — harder to prove, but also harder to defend, because you have no documented reasoning to point at.

What the Regulation Actually Says About Retention

Three mentions, in three different places, doing three different jobs:

• Annex 1.1.1(h) — the top-level security policy must “list the documentation to be kept and the duration of retention of the documentation” [1]. This is the clause that creates the obligation. It sits among the eleven mandatory contents of the policy, alongside 1.1.1(k), which requires the policy to “indicate the date of the formal approval by the management bodies”.
• Annex 4.2.2(f) — backup plans must include “retention periods based on business and regulatory requirements” [1].
• Recital 25 — the only recital using the word. It frames “retention and disposal” as security controls applied to assets by classification level, alongside encryption, access control, backups and logging [1]. Recitals do not create obligations, but this one tells you where the Commission thinks the number comes from: your asset classification, not a table in Brussels.

Then there is point 3.2.5, the log clause: “The relevant entities shall maintain and back up logs for a predefined period and shall protect them from unauthorised access or changes” [1].

ENISA’s Technical Implementation Guidance is where most people go next, and it is worth knowing what they will find. Its guidance on 3.2.5 says to define the log retention period “in accordance with business needs, the risk assessment results and legal requirements/obligations”, and that the period “should be in line with what is referred to in point 4.2.2 (f)”. Its guidance on 4.2.2 says: “Concerning retention periods consider what is referred to in point 3.2.5” [2]. The two clauses point at each other. Neither end supplies a figure.

And ENISA’s entire list of acceptable evidence under 3.2.5 is one line: “A retention period is set.” [2]

That is the bar. Not eighteen months, not twelve — a period, set, written down, and derived from something. The “NIS2 mandates 18 months of immutable logs” claim circulating in vendor material does not trace to the Directive or to the CIR; neither instrument contains any log duration at all. Our breakdown of the CIR logging controls walks through where those numbers actually come from.

One more clause makes the documentation point explicit. Article 2(2), second subparagraph, of the CIR says that where the Annex applies something “where appropriate”, “where applicable” or “to the extent feasible” and an entity decides it does not apply, “the relevant entity shall in a comprehensible manner document its reasoning to that effect” [1]. The regulation’s consistent answer to discretion is: exercise it, and show your working.

What to Keep: The Record Classes the CIR Creates

The CIR’s thirteen Annex chapters generate records whether or not you have named them, and 1.1.1(h) makes naming them your job. Below, each class is mapped to the point that creates it and to what actually sets its period. The “practical default” column is our own starting point for a mid-sized entity, not a legal requirement — treat it as a first draft to argue with.

Record class	Created by	What sets the period	Practical default
Security policy, with board approval date	Annex 1.1.1, incl. (k)	Annual review cycle under 1.1.2	Current + 2 prior versions
Policy review records and management review minutes	Annex 1.1.2 — “the result of the reviews shall be documented”	Proving an unbroken annual cadence	3 years
Risk assessment, treatment plan, residual-risk acceptances	Annex 2.1	Showing how a current control was justified	Current + 2 prior cycles
Compliance review reports to management bodies	Annex 2.2.1	Reporting cadence you set	3 years
Incident records and significance classifications	Annex 3.4; evidence trail	The recurring-incident test — see below	Rolling 6 months minimum; 3 years for notified incidents
Logs, across the twelve categories in 3.2.3	Annex 3.2.3 and 3.2.5	Detection lag, investigation depth, storage cost	Set explicitly; see the logging article
Backup sets and restore-test results	Annex 4.2.2(f); recovery testing under 4.2.6	Recovery objectives, plus regulatory requirements	Per your RPO/RTO derivation
Supplier assessments and security clauses	Annex 5	Contract term plus the limitation period after it	Contract + 3 years
Vulnerability handling and security test results	Annex 6.5, 6.10	Remediation evidence for the finding it raised	3 years
Cryptographic key lifecycle records	Annex 9 — see the ten Annex 9 controls	Lifetime of data encrypted under the key	Key lifetime + data lifetime
Access reviews, authorisations, privilege changes	Annex 11 — mirrored in an ISO 27001 access control policy	Review cadence and joiner/mover/leaver proof	2 years
Asset inventory, disposal and destruction records	Annex 12.2, 12.5	Proving the asset actually left safely	Asset life + 1 year
Training and awareness records	Annex 8	Employment period plus national HR law	Employment + national minimum

If that table looks absurd for your size, collapse it. Four classes — policies and approvals, risk and incident records, logs, and HR and asset records — with one period each on one page satisfies 1.1.1(h) better than thirteen rows nobody maintains. Our documentation requirements guide covers which records a CISO owns personally.

How Long: Four Anchors That Turn “Predefined” Into Defensible

A number with a derivation behind it survives challenge. A number copied from a blog does not. Four anchors, in the order you should apply them.

Anchor 1 — the regulation’s own clocks. Article 23(4) of the Directive runs 24 hours to early warning, 72 hours to incident notification, and a final report “not later than one month after the submission of the incident notification”, with a progress report plus a later final report where the incident is still running [3]. That gives you a hard floor: any record you need to produce that final report must survive at least a month past the notification.

The sharper floor is less well known. Annex 3.4.2(b) requires entities to “assess the existence of recurring incidents as referred to in Article 4 of this Regulation on a quarterly basis”, and CIR Article 4 aggregates individually minor incidents into one significant incident where they “have occurred at least twice within 6 months”, share the same apparent root cause, and collectively cross the Article 3(1)(a) threshold of EUR 500 000 or 5 % of annual turnover, whichever is lower [1]. You cannot run a quarterly six-month lookback on records you have already deleted. That is a rolling six-month minimum for classified incident records and the log data behind them — derived from the text, not from a benchmark.

Anchor 2 — your own review cycle. Annex 1.1.2 requires the policy to be reviewed by management bodies at least annually, and “the result of the reviews shall be documented” [1]. To show an auditor a cadence rather than a single event, you need the current cycle and at least one prior one. For governance records, two annual cycles is the natural floor.

Anchor 3 — other law that names a number. Point 4.2.2(f) says “business and regulatory requirements” [1] — an explicit deferral to rules outside the CIR: sectoral supervision, national transposition, accounting and employment law, contractual commitments. Where one of those names a figure, it wins over anything you derive, and it is the layer most likely to differ between the member states you operate in.

Anchor 4 — the GDPR ceiling. Article 5(1)(e) of Regulation (EU) 2016/679 requires personal data to be kept “no longer than is necessary for the purposes for which the personal data are processed”, and Article 5(2) makes you responsible for demonstrating it [4]. Because NIS2 sets no floor, it can never justify exceeding that ceiling. What it does supply is the purpose: security monitoring and incident handling are legitimate purposes, and a documented, risk-derived period is exactly the kind of reasoning Article 5(2) asks for. The two regimes compose rather than conflict — our GDPR and NIS2 governance article works through the overlaps.

Worked example. Authentication and privileged-access logs. Anchor 1 gives a rolling six months from the recurrence test. Anchor 2 is silent. Anchor 3 says nothing in your sector, but your cyber-insurance policy requires twelve months of authentication logs. Anchor 4 caps you at what you can justify. Result: twelve months, of which the first three are queryable and the rest archived, with the derivation recorded as “insurance requirement, exceeds CIR-derived six-month floor, purpose-limited to incident investigation”. That sentence is the compliance artefact. The number alone is not.

Why Auditors Ask — and What They Actually Request

In plain terms: the supervisor is not checking whether your number is right. There is no right number. They are checking whether a decision was made, by someone with authority, on a stated basis, and whether reality matches it.

The Directive spells out what they may ask for. Under Article 32(2), competent authorities supervising essential entities have the power to make “requests for information necessary to assess the cybersecurity risk-management measures adopted by the entity concerned, including documented cybersecurity policies” (point e), “requests to access data, documents and information necessary to carry out their supervisory tasks” (point f), and “requests for evidence of implementation of cybersecurity policies, such as the results of security audits carried out by a qualified auditor and the respective underlying evidence” (point g) [3]. Article 32(3) adds a constraint that works in your favour: when using those powers the authority “shall state the purpose of the request and specify the information requested” [3].

Read together, that is a retrieval test: a bounded, purpose-stated request you can only answer quickly if your schedule tells you what exists, where it lives, and whether it is still supposed to be there.

The half nobody prepares for is deletion. ENISA’s guidance on 3.2.5 includes the instruction “Delete data when the retention period ends” [2]. The CIR reinforces it elsewhere: Annex 12.2.2 requires the asset-handling policy to cover the full life cycle “including acquisition, use, storage, transportation and disposal” and to provide rules on “the irretrievable deletion and destruction of the assets”, and Annex 12.5 requires assets to be deposited, returned or deleted on termination of employment, with the deposit, return and deletion documented [1]. A schedule you overshoot is evidence of an unmanaged process in exactly the way a schedule you undershoot is — and over-retention adds GDPR exposure that under-retention does not.

Retention failures are not their own penalty category. They surface as infringements of Article 21 or 23, which is where the fines attach [3]:

Entity type	Maximum administrative fine for infringing Article 21 or 23
Essential entities	At least EUR 10 000 000 or at least 2 % of total worldwide annual turnover in the preceding financial year, whichever is higher (Art 34(4))
Important entities	At least EUR 7 000 000 or at least 1,4 % of total worldwide annual turnover in the preceding financial year, whichever is higher (Art 34(5))

These are the ceilings member states must make available, not typical outcomes. The more immediate consequence of a missing schedule is narrower: you cannot evidence a measure you cannot retrieve, and Article 20(1) puts the management bodies who approved the measures on the hook for infringements of Article 21 [3].

Writing the Policy: Structure, Approval, and the Deletion Half

The schedule does not need to be a standalone document, and arguably should not be. Annex 1.1.1(h) locates the list inside the top-level security policy, so the cleanest structure is a retention schedule annexed to that policy and approved with it. Five steps:

1. Enumerate. Walk the thirteen CIR Annex chapters and list every record each one generates. Effort: medium — a half-day with the control owners.
2. Classify. Attach each class to an asset classification level, per Recital 25’s framing. This is what lets you defend different periods for different records instead of one blanket number.
3. Derive. Apply the four anchors and write one sentence of reasoning per class. Effort: low per class, and it is the step that turns the schedule into evidence.
4. Approve. Take it to the management bodies with the policy and record the approval date — 1.1.1(k) requires the date to appear in the policy itself.
5. Enforce both ends. Configure the deletion, and keep the deletion records. Review annually under 1.1.2 and document the result.

Role	Owns	The question to answer
CISO / IT security manager	Steps 1, 2 and 5 — enumeration, classification, technical enforcement	Can I produce any listed record, and prove the unlisted ones were deleted?
Compliance officer / legal	Step 3 — the derivation and the Anchor 3 sweep across jurisdictions	Does every period have a stated basis, and does it survive the GDPR ceiling?
Management body	Step 4 — approval and the annual review	Did we approve this, is the date in the policy, and did we review it this year?
Owner of a small entity	All of it, compressed	Is there one page, dated, signed, with four classes and four periods on it?

Frequently Asked Questions

Does NIS2 require 18 months of log retention?
No. Neither Directive (EU) 2022/2555 nor CIR 2024/2690 states any log retention duration. Point 3.2.5 of the CIR Annex requires logs to be kept “for a predefined period” and leaves the period to the entity [1]. Figures like 6, 12 or 18 months are practitioner conventions or sector-specific rules, not NIS2 requirements.

Where in the regulation is the data retention policy actually required?
Annex point 1.1.1(h) of CIR 2024/2690: the policy on the security of network and information systems must “list the documentation to be kept and the duration of retention of the documentation” [1]. Point 4.2.2(f) adds backup retention periods “based on business and regulatory requirements”.

Can NIS2 justify keeping personal data longer than GDPR allows?
No. NIS2 sets no minimum retention period, so it cannot be cited as a legal obligation to exceed the storage-limitation principle in Article 5(1)(e) of the GDPR [4]. It can supply the security purpose that justifies a period, but the period still has to be necessary for that purpose and documented under Article 5(2).

What is the shortest retention period I can defend?
For classified incident records and the logs behind them, the text supports a rolling six months as a floor: Annex 3.4.2(b) requires a quarterly assessment of recurring incidents, and CIR Article 4 defines those as incidents occurring at least twice within six months with the same apparent root cause [1]. Below that you cannot perform an assessment the regulation requires.

Is keeping data longer than the schedule safer?
No. ENISA’s guidance on point 3.2.5 instructs entities to “delete data when the retention period ends” [2], and the CIR requires an asset-handling policy covering irretrievable deletion and destruction (Annex 12.2.2) [1]. Retaining beyond your own schedule shows the schedule is not enforced, and adds GDPR exposure on top.

The Short Version

The retention duty in NIS2 is a documentation duty wearing a numbers costume. Retention appears in three places in the CIR and carries no figure in any of them, because the figure is meant to fall out of your asset classification, your risk assessment, the regulation’s own reporting and recurrence clocks, whatever sector law binds you, and the GDPR ceiling above all of it. Write the derivation down, annex it to the policy, get it dated and approved, then delete on time and keep the proof. An auditor asking about retention is asking whether a decision exists — cheap to answer if you wrote it down a year ago, expensive if you did not.

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.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex (Articles 1–4 and the Annex, including points 1.1.1, 1.1.2, 3.2.3, 3.2.5, 3.4.2, 4.2.2, 12.2.2 and 12.5)
2. Technical Implementation Guidance on cybersecurity risk management measures, version 1.0 — ENISA, June 2025 (guidance and examples of evidence for points 1.1.1, 1.1.2, 3.2.5, 4.2.2 and 12.2.2). Publication record: ENISA publications
3. Directive (EU) 2022/2555 (NIS2) — EUR-Lex (Articles 20, 21, 23, 32 and 34)
4. Regulation (EU) 2016/679 (GDPR) — EUR-Lex (Article 5(1)(e) storage limitation and Article 5(2) accountability)