NIS2 Evidence Collection: Which of ENISA’s 662 Examples Bind You

Commission Implementing Regulation (EU) 2024/2690 runs to thirteen Annex chapters of binding cybersecurity requirements. The word evidence appears in it exactly twice. ENISA’s companion guidance, published eight months later, contains 198 blocks headed EXAMPLES OF EVIDENCE holding 662 individual items.

That gap between two and 662 is where most evidence-collection programmes go wrong. Teams either treat ENISA’s list as a statutory checklist and drown in it, or dismiss it as advisory and arrive at a supervisory request with a folder of PDFs that prove nothing happened after the approval date. Both readings are wrong, and the regulation itself explains why.

Who the Regulation Binds, and What the Directive Asks For

CIR 2024/2690 is directly binding only on the eleven entity types named in Article 21(5) of the Directive: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers. If you are a hospital, a water utility or a manufacturer, the Annex is not law for you. It remains the most detailed articulation of Article 21(2) the Commission has produced, and national supervisors read it, so treat it as the benchmark rather than the statute.

The Directive is what binds everyone. Read Article 32(2) closely and you find the documentation-versus-evidence distinction written into the law, split across three separate supervisory powers that most commentary collapses into one.

Power	What the text says	What satisfies it	What fails
Art. 32(2)(e)	“requests for information necessary to assess the cybersecurity risk-management measures adopted by the entity concerned, including documented cybersecurity policies“	The policy set itself. Your ISMS policy, topic-specific policies, risk methodology.	Nothing much. This is the easy request, and it is the only one most organisations prepare for.
Art. 32(2)(f)	“requests to access data, documents and information necessary to carry out their supervisory tasks”	Being able to hand over the underlying material on demand, including material you did not choose to feature.	A curated pack. This power is about access, not presentation.
Art. 32(2)(g)	“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“	Artefacts generated by the control operating: logs, dated review records, approvals, test results.	The policy that says you do the thing. A policy is the subject of this request, never the answer to it.

Point (g) is doing something specific. It asks for evidence of implementation, and then it asks for the evidence underneath the evidence. An audit report alone does not close it out; the report is a conclusion, and the supervisor is entitled to what the auditor looked at.

Important entities face identical wording. Article 33(2)(d), (e) and (f) reproduce the three powers word for word, including “the respective underlying evidence.” The essential-versus-important asymmetry lives elsewhere in the article: Article 33(2) has no ad-hoc-audit limb, and where Article 32(2)(b) permits “regular and targeted” audits, Article 33(2)(b) says only “targeted.” Fewer occasions to ask, the same things asked for. Our guide to what to expect in a first NIS2 audit covers how the two supervisory models differ in practice.

Where the 662 Evidence Examples Come From

The binding regulation almost never says what proof looks like. Both of its uses of the word are narrow and identical in form: point 3.5.4 requires entities to “log incident response activities in accordance with the procedures referred to in point 3.2.1, and record evidence,” and point 6.10.2(b) requires them to “perform, where appropriate, vulnerability scans, and record evidence of the results of the scans, at planned intervals.” That is the whole of it. Everywhere else the Annex specifies an outcome and leaves the artefact to you.

ENISA filled that space in June 2025 with its 170-page Technical Implementation Guidance. Against almost every Annex point it sets out guidance, then a block headed EXAMPLES OF EVIDENCE. Counting programmatically over the v1.0 PDF gives 198 such blocks and 662 top-level items. They are not evenly spread, and the shape of that distribution is itself useful.

Annex chapter	Art. 21(2) point	Evidence blocks	Evidence items
6 — Acquisition, development and maintenance	(e)	40	200
11 — Access control	(i), (j)	26	87
3 — Incident handling	(b)	28	82
4 — Business continuity and crisis management	(c)	17	55
1 — Policy on the security of network and information systems	(a)	10	35
2 — Risk management policy	(a)	13	35
10 — Human resources security	(i)	12	31
12 — Asset management	(i)	16	31
5 — Supply chain security	(d)	9	26
13 — Environmental and physical security	(c), (e), (i)	12	25
9 — Cryptography	(h)	4	23
8 — Basic cyber hygiene and training	(g)	8	19
7 — Effectiveness of risk-management measures	(f)	3	13

Two things fall out of that table. Thirteen Annex chapters map onto only ten points of Article 21(2) — chapters 1 and 2 both serve point (a), and chapters 10, 11 and 12 all serve point (i) — so a control set organised by the Directive’s ten measures will not line up cleanly with the evidence a CIR-literate assessor asks about. And chapter 7, the measure whose entire job is assessing whether the other measures work, carries the thinnest evidence guidance in the document: three blocks, thirteen items. The one obligation that is purely about proof is the one ENISA says least about.

Now the calibration that matters. ENISA states plainly that the document “is not legally binding and is only of an advisory character,” and goes further in its own disclaimer: the guidance “is not able to define whether an entity needs to have all or just some of the ‘evidence’ listed (although requiring all the ‘evidence’ listed here would be a very strict approach to supervision).” Read that as written. ENISA is telling supervisors that demanding all 662 items would be unusually strict, and telling entities that no one at EU level has decided which subset is enough. That decision sits with your national competent authority. Our summary of the ENISA technical guidance covers how the document is structured; the point here is what its non-binding status does and does not buy you.

Retention: The Regulation Sets No Periods, It Makes You Set Them

The word “retention” appears three times in CIR 2024/2690 and not one instance is a number.

The first that matters is point 1.1.1(h). Among the eleven mandatory elements of your top-level security policy, alongside objectives, roles and the date of formal management approval, the policy must “list the documentation to be kept and the duration of retention of the documentation.” The regulation’s answer to “how long must we keep this?” is that you write the schedule, put it in the policy, and get management bodies to approve it.

The second is point 4.2.2(f), which requires backup plans to specify “retention periods based on business and regulatory requirements.” The third is point 3.2.5: entities “shall maintain and back up logs for a predefined period.” Predefined by whom is not stated, and ENISA’s guidance on 3.2.5 points readers to 4.2.2(f) while its guidance on 4.2.2 points back to 3.2.5. The cross-reference is circular and neither end supplies a figure. What ENISA does supply, as the single evidence item under 3.2.5, is the bar: “A retention period is set.”

So the failure mode is not choosing twelve months when a supervisor wanted eighteen. It is having no documented basis for whichever number you chose. ENISA’s guidance names the inputs — business needs, risk assessment results, and legal requirements or obligations — and adds an instruction organisations routinely skip: “Delete data when the retention period ends.” A schedule you exceed is evidence of an unmanaged process, the same as one you undershoot. For the logging specifics, see our breakdown of what CIR 2024/2690 actually requires for logging and retention windows.

Version Control Is the Evidence That You Kept Doing It

A policy PDF proves a moment. Article 32(2)(g) asks about a practice, and the difference between the two is version history.

The Annex makes this concrete in point 1.1.2: the security 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. The result of the reviews shall be documented.” That last sentence is the whole obligation in miniature. Doing the review is not the requirement. Being able to show the review happened is.

ENISA’s evidence items under 1.1.2 read exactly like a description of a version-controlled repository: “Review comments or change logs for the policy on the security of network and information systems and topic-specific policies”; an “Up-to-date policy”; and “Evidence that any updates to the policy … and any policy exceptions, are approved by management bodies and a record is kept.” The same pattern recurs across the Annex. Point 12.4.1 requires entities to “record changes to the entries in the inventory in a traceable manner.” Point 6.4.2 requires that changes to systems are documented and assessed before implementation, and 6.4.3 covers the emergency path: where the change procedure could not be followed, document “the result of the change, and the explanation for why the procedures could not be followed.”

Then there is the cadence trap. Across the whole Annex, the phrase “at least annually” appears three times — at 1.1.2 for the security policy, at 2.1.4 for risk assessment results and the risk treatment plan, and at 10.1.3 for the assignment of personnel to security roles. The phrase “at planned intervals” appears thirty times. ENISA recommends annual cycles in roughly two dozen further places, but those are recommendations, and the binding text keeps handing the interval back to you.

Which produces a result compliance officers should sit with: outside those three clauses, the review frequency you write down becomes the standard you are measured against. Commit to quarterly access reviews in your access control policy and a supervisor comparing policy to records is entitled to find nine months of silence non-compliant — not against the regulation, which said only “at planned intervals,” but against your own documented interval. Setting an ambitious cadence you cannot evidence is worse than setting a modest one you can.

Matching the Evidence Format to the Requirement

Classifying all 662 ENISA evidence items by artefact type shows what a supervisory request actually pulls on. Logs and dated records dominate at roughly 170 items, policy and procedure documents follow at about 146, then reports (68), plans (64), training and awareness records (43), configuration or system output (32), minutes and approval records (31), registers and inventories (30), contracts and clauses (23), and test results (10). Items often fit more than one class, so these are proportions rather than a clean partition — but the ordering is the finding. The single largest category is the one that cannot be produced retrospectively.

A workable rule is to read the verb in the Annex clause and let it select the artefact.

Clause verb	Example	Artefact that answers it	What makes it audit-grade
“shall lay down” / “shall establish”	1.1.1 policy elements	Approved document	Formal approval date by management bodies, per 1.1.1(k)
“shall document”	6.4.3 emergency changes	Decision record with reasoning	Names the decision-maker and the justification, not just the outcome
“shall record evidence”	3.5.4, 6.10.2(b)	Raw output, retained	Timestamped, tamper-protected, retained for your defined period
“shall review … at planned intervals”	2.1.4, 11.2.x	Dated review record	Interval matches your policy; gaps are explained, not hidden
“shall maintain” / “keep up to date”	5.2 supplier registry, 12.4.1 inventory	Live register with change history	Changes traceable to who and when
“shall test”	4.1.4, 3.5.5	Test plan plus results plus corrective actions	Results documented and findings tracked to closure — the pattern 4.2.6 sets for backup testing

Ownership splits along familiar lines, and the split is worth agreeing before an audit rather than during one.

Role	Owns	Effort
Board / management bodies	Approval records and dates (1.1.1(k), 1.1.2), review of role assignments (10.1.3)	Low, but non-delegable
Compliance officer	The retention schedule (1.1.1(h)), the interval register, compliance review reporting (2.2.1)	Medium
CISO / IT security	Logs, scan and test results, change and access records, inventory traceability	High, and mostly automatable
Internal audit or independent reviewer	Independent review under 2.3, reported to management bodies	Medium

Closing the Gap in Four Steps

Current state to required state, in the order that produces the most defensible position soonest.

1. Write the retention schedule into the policy (effort: low). Point 1.1.1(h) is a discrete, closeable gap that most organisations have open. List the document classes, give each a duration and a basis, and get it approved.
2. Inventory your own intervals (effort: low). Extract every “quarterly,” “annually” and “periodically” you have already committed to across your policy set. That list, not the regulation, is your review calendar.
3. Wire the trail: approval, version, timestamp (effort: medium). Every controlled document needs an approver, a date and a change history. In practice a version-controlled system satisfies point 12.4.1’s “traceable manner” by construction; the harder part is the policy set, which often lives in a shared drive.
4. Rehearse the Article 32(2)(g) request (effort: high). Pick one control. Produce the policy, the review records for the last twelve months, the underlying operational evidence, and the approval trail — within one working day, without asking anyone to reconstruct anything. Whatever you cannot produce is your real gap. Our guide to running a NIS2 gap analysis sets out the wider method.

The organisations that struggle at audit are rarely the ones with weak controls. They are the ones whose controls ran fine and left nothing behind. For the specific documents a CISO is expected to hold, see our breakdown of the core records CIR 2024/2690 requires; for how a third-party assessor approaches the same material, see NIS2 third-party audits.

Frequently Asked Questions

Do we have to produce all 662 ENISA evidence examples?

No, and ENISA says so itself: the guidance “is not able to define whether an entity needs to have all or just some of the ‘evidence’ listed,” and notes that requiring all of it “would be a very strict approach to supervision.” The subset that applies to you is a matter for your national competent authority, which is why the honest answer to scoping questions is always jurisdictional.

How long does NIS2 require us to keep records?

The Directive sets no retention period, and CIR 2024/2690 sets none either. Point 1.1.1(h) requires your security policy to state the documentation kept and its retention duration; point 4.2.2(f) requires backup retention “based on business and regulatory requirements”; point 3.2.5 requires logs to be kept for “a predefined period.” The obligation is to define, document and then honour a period, not to hit a figure the EU has published.

Is CIR 2024/2690 binding on us?

Directly, only if you are one of the eleven entity types listed in Article 21(5) — broadly the digital infrastructure, ICT service management and digital provider categories. Other entities are bound by Article 21(2) as transposed into national law. The Annex remains the most detailed available expression of those measures, and supervisors use it, so plan against it while being precise about its legal status in your own documentation.

Does an ISO 27001 certificate satisfy the evidence requirement?

It helps, and Article 32(7)(g) requires authorities to take due account of adherence to approved certification mechanisms when deciding on enforcement. It does not close out Article 32(2)(g), which asks for the results of audits and “the respective underlying evidence.” A certificate is a conclusion; the request reaches past it.

Are important entities held to a lower evidence standard than essential entities?

No. Article 33(2)(d), (e) and (f) reproduce the essential-entity evidence powers word for word. What differs is frequency and trigger: important entities face ex-post supervision, Article 33(2) has no ad-hoc audit limb, and it permits “targeted” rather than “regular and targeted” audits. Fewer occasions to be asked, the same standard when you are.

Sources

• Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex. Annex points 1.1.1, 1.1.2, 2.1.4, 3.2.5, 3.5.4, 4.2.2, 6.4.2, 6.4.3, 6.10.2, 10.1.3, 12.4.1.
• Directive (EU) 2022/2555 (NIS2) — EUR-Lex. Articles 21(2), 21(5), 32(2), 32(7), 33(2).
• Technical Implementation Guidance on cybersecurity risk management measures, version 1.0 (June 2025) — ENISA. Non-binding guidance; source of the 198 evidence blocks and 662 evidence items counted in this article.

Counting method: figures for evidence blocks, evidence items and clause-phrase frequencies were produced by text extraction over the published ENISA v1.0 PDF and the EUR-Lex HTML of CIR 2024/2690, then split on the documents’ own bullet and heading markers. Sub-bullets were excluded. Figures are reproducible against those two sources and describe version 1.0 of the guidance.

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.