The CISO’s CIR 2024/2690 Audit File: 8 Documents You Must Own — and the Evidence Format Regulators Check

Most NIS2 guides list the ten measures in Article 21(2) and stop there. For a CISO facing an on-site inspection under Commission Implementing Regulation (EU) 2024/2690 — CIR 2024/2690 — that overview is not enough. Auditors do not ask whether your organisation has a risk management process. They request the risk register, examine whether it contains a cyber threat intelligence input and a single point of failure analysis, and check when management last formally accepted the residual risks. The gap between a policy that exists and a document that survives an audit is the detail of what each record must contain.

This guide identifies the eight documents a CISO is directly accountable for under CIR 2024/2690 Annex I — the specific Annex section that mandates each one, the mandatory content fields regulators look for, and the review trigger that keeps each document current. For organisations outside CIR scope, Article 21(2) of NIS2 Directive (EU) 2022/2555 creates equivalent obligations across the same document types; the CIR technical specificity does not apply, but the document structure remains the same [1].

Does CIR 2024/2690 Apply to Your Organisation?

CIR 2024/2690 applies to a defined list of entity types within NIS2 Annex I digital infrastructure and Annex II digital services. It does not apply to manufacturing, energy, water, healthcare, transport, or public administration entities — those sectors are bound directly by Article 21(2) of Directive (EU) 2022/2555 without the CIR technical layer [4].

Entity type	CIR 2024/2690 applies?	Basis for the 8 documents
DNS service providers, TLD registries	Yes	Art. 21(2) + CIR Annex I
Cloud computing service providers	Yes	Art. 21(2) + CIR Annex I
Data centre service providers	Yes	Art. 21(2) + CIR Annex I
Content delivery networks (CDNs)	Yes	Art. 21(2) + CIR Annex I
Managed service providers (MSPs) and MSSPs	Yes	Art. 21(2) + CIR Annex I
Online marketplaces, search engines, social networks	Yes	Art. 21(2) + CIR Annex I
Trust service providers	Yes	Art. 21(2) + CIR Annex I
Manufacturing, energy, water, healthcare, transport	No	Art. 21(2) NIS2 Directive only

If your organisation is outside CIR scope, the eight document types below remain required under Article 21(2) of the Directive [1]. The practical difference is that the CIR Annex I mandatory content fields — such as the specific risk register elements in §2.1.2 or the independence requirement for the §7.2 effectiveness audit — are not directly enforceable under this regulation. ENISA’s implementation guidance reflects the same structure and will serve as a benchmark regardless of formal CIR scope.

Why the CISO Owns These 8 Records

Article 20(1) of Directive (EU) 2022/2555 makes management bodies of essential and important entities directly responsible for approving cybersecurity risk-management measures and overseeing their implementation [3]. In practice, the CISO is the person who assembles, maintains, and presents the evidence that management has discharged that responsibility to regulators and auditors.

The accountability structure divides clearly across three functions:

• Management body: reviews and signs off on documents where CIR Annex I requires management approval; personally liable under Article 20(1) for oversight failures
• CISO: owns the document lifecycle — drafting, keeping current, evidencing reviews, and presenting to management and auditors on request
• Legal and compliance: advise on regulatory mapping but do not maintain the technical records

The eight documents below are the ones where a gap — missing mandatory content, a stale review date, or absent management sign-off — directly exposes the organisation to supervisory action. Essential entities face fines of up to €10 million or 2% of total global annual turnover under Article 34(4) [3]. Enforcement bodies calibrate penalties against the quality of the CISO’s documentation file. A complete, current, evidence-backed set of these records is the most direct influence a CISO has over where on the penalty range an inspection ends.

For a full review of management body accountability under NIS2, see our guide on Article 20 management liability.

Document 1 — ISMS Policy (CIR Annex §1)

The Information Security Management System policy is the apex document — it justifies the existence and structure of every other record in the CISO’s audit file. CIR Annex Section 1 requires two linked components: the overarching security policy (§1.1) and a roles and responsibilities framework (§1.2) [2].

What §1.1 must contain: the entity’s security management approach, stated security objectives, a commitment to continual improvement, a resource allocation plan covering staff, finances, processes and tools, and an employee acknowledgment mechanism. What §1.2 adds: documented role assignments, retention periods for each record type in the audit file, a list of topic-specific sub-policies, implementation indicators, and a maturity monitoring approach.

The mandatory element most organisations omit: a management approval date that is current. CIR §1.1 requires evidence that the management body has reviewed and approved the policy. A policy signed three years ago with no subsequent update record fails this test during a current inspection.

Review trigger: Annual minimum, or immediately following a significant incident or material operational change [2].

Document 2 — Risk Register (CIR Annex §2)

The risk register is the most technically demanding of the eight. CIR Annex Section 2 requires three elements that a standard asset-risk-control matrix does not include and that most commercial templates miss [2].

First, cyber threat intelligence as a mandatory input (§2.1.2). The risk identification process must incorporate CTI — not just internal threat modelling. The register must document which CTI sources the organisation uses and demonstrate that their outputs informed the risk analysis cycle.

Second, single point of failure identification is a named deliverable in §2.1.2. The register must include an explicit SPOF analysis — a structured list of systems or processes whose failure would cause significant disruption, with corresponding treatment decisions for each.

Third, residual risk justification must be documented “in a comprehensible manner” (§2.1.2(j)), and the management body must formally accept residual risks with that acceptance recorded with documented authority. An informal decision or email chain does not constitute CIR-compliant residual risk acceptance under §2.1.1.

For a comparison of CIR §2 requirements against ISO 27005:2022 — including the five gaps ISO 27005 leaves open — see our NIS2 vs ISO 27005 analysis.

Review trigger: Annual minimum, plus event-triggered review following any significant incident or material change to the threat landscape [2].

Document 3 — Business Continuity and Disaster Recovery Plans (CIR Annex §4)

CIR Annex Section 4 separates business continuity into three sub-areas with distinct documentation requirements. Each is a separate deliverable, not sections of a single document [2].

§4.1 (Business Continuity Plan) requires a BCP built from a documented Business Impact Analysis. The BCP must specify: purpose, scope, roles and responsibilities, communication channels, activation conditions, the order in which operations are restored, specific recovery procedures per operational area, and required resources. The BIA is not an optional input — it is the mandatory evidential basis for BCP content. A plan written without a documented BIA fails §4.1.

§4.2 (Backup and Redundancy) requires documented backup schedules, integrity verification records, recovery test results, and redundancy configuration records for critical systems, key personnel, and communication channels. Test reports are part of the required record — an untested backup policy does not satisfy §4.2.

§4.3 (Crisis Management) adds a separate document covering crisis roles, communication procedures with national authorities, information management during a crisis event, and test results. This is distinct from the BCP and is frequently absent in organisations that treat crisis management and incident response as the same function.

For a detailed breakdown of Article 21(2)(c) requirements, see our NIS2 business continuity guide.

Review trigger: Planned intervals; testing mandatory following significant incidents [2].

Document 4 — Supplier Register (CIR Annex §5)

Most organisations maintain a vendor list. The CIR Annex §5.2 supplier register is not a vendor list — it is a structured record with specific mandatory fields that static spreadsheets typically do not contain [2].

CIR §5.2 requires two data types for each direct supplier: a designated contact point and a list of the ICT products and services that supplier provides to your organisation. Section §5.1 (the supply chain security policy) adds the contractual framework: requirements for cybersecurity clauses, audit rights, incident notification obligations, vulnerability handling commitments, and subcontracting disclosure — all cross-referencing entries in the supplier register.

The register must be actively maintained. Monitoring records — SLA compliance reports, incident reviews involving suppliers, and risk assessments triggered by supplier changes — are expected alongside the register itself. A spreadsheet with no update history since it was first compiled does not comply with §5.2’s requirement that the register be kept current.

Review trigger: Continuous — update on any supplier change, contract renewal, or security incident involving a direct supplier [2].

Document 5 — Network Architecture Documentation (CIR Annex §6)

CIR Annex §6.7 (Network Security) and §6.8 (Network Segmentation) define the network architecture record — and it is more than a topology diagram [2].

§6.7 requires: network architecture documentation covering the full environment, access control definitions for network resources, remote access procedures with authentication and authorisation requirements per user class, and — critically — transition plans for migration to modern communication protocols. This last requirement is consistently absent in competitor guidance and in most CISOs’ documentation files, but it is explicitly required by the CIR. Organisations running legacy protocols must document a migration roadmap, not merely acknowledge the gap.

§6.8 adds segmentation documentation: zone definitions, the access policies governing traffic between zones, and DMZ configurations where applicable. For MSPs and MSSPs managing multi-tenant environments, §6.8 requires evidence that client network segments are isolated from one another — directly affecting shared management platforms and remote access tooling.

What auditors check is not the architecture diagram in isolation, but the combination of architecture document, access control matrix, remote access exception register, and evidence of a protocol review cycle. Each element is a separate auditable item.

Review trigger: Following any material change to network architecture; after any security incident involving network access or lateral movement [2].

Document 6 — Incident Log (CIR Annex §3)

CIR Annex §3.2 and §3.4 define two linked components of the incident log — the monitoring record and the classification framework — and both are separately auditable [2].

§3.2 (Monitoring and Logging) specifies what must be captured: network traffic events, user account creation and deletion, access events across systems, privileged account activities, configuration changes, and physical access events. The CIR does not mandate a fixed retention period — it requires that retention periods be predefined and documented. The predefinition itself is an auditable record; organisations that store logs without a documented retention policy do not satisfy §3.2 regardless of log coverage.

§3.4 (Event Assessment) adds the classification layer most SIEM deployments omit. Events must be assessed against predefined categorisation criteria to determine whether they constitute incidents and, if so, their severity level. Those predefined criteria must be documented separately from the log output and aligned with the entity’s definition of a significant incident under Article 23 of the Directive.

A common audit gap: producing SIEM output as the incident log without accompanying categorisation criteria or evidence that events were assessed rather than merely stored. The log without the assessment framework fails §3.4 regardless of how comprehensive the raw data is.

For the thresholds that make an incident significant under Article 23, see our guide on NIS2 significant incident thresholds.

Review trigger: Continuous logging; retention periods and categorisation criteria reviewed annually and following any reclassification of a significant incident [2].

Document 7 — Training Records (CIR Annex §8)

CIR Annex Section 8 requires two distinct training records that are maintained separately but both sit in the CISO’s governance file [2].

§8.1 covers the general cyber hygiene and awareness programme: awareness documentation, training materials, employee attendance logs, and training effectiveness assessments. Attendance logs alone do not satisfy §8.1 — evidence of effectiveness, such as pre/post assessments or phishing simulation metrics, is required alongside participation records.

§8.2 covers management body members specifically, with the separate legal basis of Article 20(2) of the Directive: management body members must receive training to assess cybersecurity risks and their business impact on the organisation. The records from §8.2 belong in the CISO’s governance file — distinct from HR-maintained employee training records — and connect directly to the management accountability chain under Article 20(1). Organisations that maintain a single training tracker for all staff and management body members will not satisfy the distinction §8.2 requires.

Review trigger: Annual programme review for §8.1; §8.2 management training records updated following each training session attended by management body members [2].

Document 8 — Audit and Effectiveness Reports (CIR Annex §7)

CIR Annex Section 7 requires three linked records that together constitute the audit trail for cybersecurity measure effectiveness. Each is a separate deliverable [2].

§7.1 (Effectiveness Measurement Programme) defines how effectiveness is monitored: the KPIs, measurement procedures, and named responsibilities. This is routinely conflated with the risk register but covers operational performance metrics rather than risk outcomes, and must be documented as a programme with accountabilities assigned.

§7.2 (Independent Review) is the record most often missing from organisations that rely solely on internal self-assessments. CIR §7.2 requires that the security approach — including personnel, processes, and technologies — be reviewed by someone independent of the systems under review. Results must be formally reported to management, with corrective actions or residual risk acceptance decisions documented. The independence requirement means a CISO cannot audit their own controls under §7.2, and an internal review team that manages the systems being assessed does not satisfy it either.

§7.3 (Management Review) documents the management body’s assessment of the cybersecurity programme — the formal governance record an auditor uses to verify that senior leadership is actively engaged in oversight, not merely notified of incidents after the fact.

Review trigger: §7.1 monitored continuously; §7.2 independent review at minimum annually for essential entities; §7.3 management review aligned to the ISMS annual cycle and management body meeting schedule [2].

Quick Reference — All 8 Documents

The following table summarises the CIR Annex reference, the NIS2 Article 21(2) basis, the review trigger, and whether the management body must formally sign off on each document [1] [2]:

Document	CIR Annex ref	Art. 21(2) basis	Review trigger	Management sign-off
ISMS Policy	§1.1–1.2	(a)	Annual / significant incident	Yes — current approval date required
Risk Register	§2.1.1–2.1.2	(a)	Annual / incident / threat landscape change	Yes — residual risk formal acceptance
BCP + DRP	§4.1–4.3	(c)	Planned intervals / post-incident testing	Yes — BIA and plan approval
Supplier Register	§5.1–5.2	(d)	Continuous / supplier change	Indirect (policy approval)
Network Architecture	§6.7–6.8	(e)	Material network change / post-incident	No (operational record)
Incident Log	§3.2 + §3.4	(b)	Continuous / criteria reviewed annually	No (operational record)
Training Records (§8.1 + §8.2)	§8.1–8.2	(g)	Annual / post-session (management)	Indirect (programme approval)
Audit / Effectiveness Reports	§7.1–7.3	(f)	Annual / management review cycle	Yes — §7.2 findings presented to management

What Happens When an Auditor Finds Documentation Gaps

National competent authorities conducting supervisory activities under Article 32 can request any of these eight documents at any time — during on-site inspections, targeted security audits, or information requests made in the course of an incident investigation. The absence of a document, a stale review date, missing management sign-off, or a record lacking mandatory content fields each constitutes a measurable gap [3].

Article 21(4) of the Directive requires entities to take corrective action without undue delay when gaps are identified. Article 34(4) sets the maximum fine for essential entities at €10 million or 2% of total global annual turnover, whichever is higher [3]. The calibration of where within that range a penalty lands is influenced by the seriousness of the gap, whether it was ongoing, and whether the entity had taken preventive measures before the inspection — all factors that the CISO’s documentation file directly evidences.

The practical implication: a CISO who cannot produce a current, signed-off, evidence-complete audit file when an inspector requests it is not facing a documentation correction exercise. They are presenting the maximum possible discretionary enforcement exposure.

For the full structure of NIS2 penalties — including the distinction between Article 32 supervisory measures and Article 34 fines — see our NIS2 penalties and enforcement guide.

Frequently Asked Questions

Do non-CIR entities — manufacturing, healthcare, energy — need these 8 documents?
Yes. Article 21(2) of Directive (EU) 2022/2555 applies to all essential and important entities regardless of sector [1]. The CIR Annex I adds mandatory technical content specifications for digital infrastructure and service entities. Other sectors face the same eight document types under the general proportionality standard in Article 21(1), with ENISA implementation guidance serving as the practical benchmark for what content is expected.

How long must the incident log be retained?
CIR Annex §3.2 requires that retention periods be predefined and documented by the organisation — no fixed minimum is set by the regulation itself [2]. National implementing legislation may impose specific periods. The compliance obligation is to document your chosen retention periods with a reasoned basis, then apply them consistently. The predefinition and its rationale are auditable records in their own right.

Does ISO 27001 certification satisfy the §7.2 independent review requirement?
An ISO 27001 certification audit involves independent review and substantially overlaps with §7.2. However, ISO 27001 does not currently qualify as a cyber-posture certificate under the EU cybersecurity certification framework that would formally substitute for CIR obligations. The §7.2 independent review and an ISO 27001 surveillance audit can be structured together, but must produce separate documented outputs for NIS2 purposes.

Is the CISO personally liable for documentation gaps?
Article 20(1) makes the management body — not the CISO personally — directly liable under the Directive for oversight failures. The CISO’s personal liability under national employment or company law is a separate matter determined by member state law and contractual terms. Enforcement bodies can seek temporary management bans under Article 32 for repeated or severe failures; the CISO’s documentation file is the primary evidence that determines whether such measures are sought [3].

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] Article 21, Directive (EU) 2022/2555 — Cybersecurity Risk-Management Measures. nis2resources.eu.

[2] CIR 2024/2690 Annex I — Technical and Methodological Requirements. advisera.com.

[3] NIS 2 Documents: Required List (Directive + CIR 2024/2690). nisd2.eu.

[4] CIR 2024/2690: Cybersecurity Requirements for EU Digital Infrastructure. advisera.com.