NIS2 Risk Management Audit Checklist: 19 CIR 2024/2690 Controls Under Article 21(2)(a) — With the Evidence Type Each One Needs

Most NIS2 risk-management files don’t fail an audit because the policy is missing. They fail because when a supervisory authority or an internal auditor asks for the paper trail behind the policy, there isn’t one — no dated review, no sign-off page, no record that anyone outside IT ever saw the risk register. Article 21(2)(a) is nine words in the Directive: “policies on risk analysis and information system security.” Commission Implementing Regulation (EU) 2024/2690 turns those nine words into 19 specific, numbered technical requirements — and each one produces a different kind of evidence. Hand over a policy document when an auditor asked for a dated review record, and you haven’t answered the question; you’ve created a finding.

This is a control-by-control checklist: all 19 requirements, the evidence type each one actually needs, the five an auditor is most likely to ask for first, and why confusing a document with a record is the single most common way this specific measure gets marked non-compliant.

What “Risk Management” Means Under Article 21(2)(a) — and Where CIR 2024/2690 Actually Defines It

In plain terms: Article 21(2)(a) requires two things — a documented way of analysing risk, and a security policy that follows from it. CIR 2024/2690 is the regulation that spells out exactly what “documented” has to look like.

The Directive’s own text is short. Article 21(1) requires “appropriate and proportionate technical, operational and organisational measures,” and 21(2)(a) names the first of ten required measure categories as “policies on risk analysis and information system security” [1].

Here’s a correction worth making explicit, because it’s a mistake that shows up in a lot of compliance content: CIR 2024/2690 does not have an “Annex I” and “Annex II” covering different requirement tiers. It has one Annex — “Technical and methodological requirements,” introduced by the regulation’s own Article 2 — split into 13 numbered sections [3]. Two of those sections implement Article 21(2)(a) directly: Section 1 (Policy on the security of network and information systems) and Section 2 (Risk management policy). Between them they contain 19 numbered sub-requirements [4][5]. A separate section — Section 7, effectiveness assessment — implements a different measure, 21(2)(f), and covers auditing the risk-management program itself. It’s related but distinct enough that bundling it into a 21(2)(a) checklist would misstate which article it satisfies, so it gets its own short section below instead of inflating the count.

One scope caveat auditors will not volunteer: CIR 2024/2690 is legally binding only on the specific entity list named in Article 21(5) — DNS providers, TLD registries, cloud and data-centre operators, CDNs, managed (security) service providers, online marketplaces, search engines, social platforms, and trust service providers [1][3]. If your organisation sits outside that list, the 19 controls below are not law for you by name. In practice, national competent authorities and auditors use the same 13-section structure as the reference standard for judging whether a risk-management measure is “appropriate and proportionate” regardless of entity type — so treat it as the working checklist even where it isn’t the literal statute.

The 19 Controls: CIR 2024/2690 Sections 1 and 2, Mapped to Evidence Type

Three evidence classes recur through this table. A Document is an approved, static text — a policy or methodology that describes intent. A Record is a timestamped account that something specific happened — a review log, a sign-off, a meeting minute. An Artefact is a system-generated output — a report a compliance tool produced, not something a person wrote. The distinction matters because several of these 19 controls are worded as an ongoing activity (“review… regularly,” “report… to management”), and a document alone cannot prove an activity occurred.

Look at the split: 8 of the 19 are Documents, but 11 are Records or Artefacts — evidence that something specific happened on a specific date, not just that a policy exists. That ratio is the reason most risk-management files that look complete on a first read fall apart under an actual audit: teams write the eight documents, then treat the eleven activity-based requirements as automatically satisfied by the document’s existence. They aren’t.

The 5 Controls Supervisory Authorities Ask For First

No regulator publishes a literal “we check these five first” list, so treat this as a practical pattern rather than a citation — but it follows directly from how the powers are worded. For important entities, Article 33 gives authorities the power to request “evidence of implementation of cybersecurity policies, such as the results of security audits” and the underlying documentation behind them during ex-post supervision [2] — essential entities face the equivalent, more proactive ex-ante supervisory powers under Article 32. Germany’s BSI, acting as national competent authority, describes the same expectation in its own guidance: documentation has to be nachvollziehbar — traceable — showing that processes, responsibilities and measures are actually reviewed on a schedule, not just reviewed once and filed [6]. Both sources point the same direction: regulators aren’t verifying that a policy exists, they’re verifying that it’s alive. In practice, five controls come up first because each one is the fastest way to tell the difference:

• 2.1.1 — the management sign-off page. Not the framework document itself; the specific page or record showing a named person with the authority to accept risk actually did.
• 2.1.4 — the annual review record. A dated log showing the risk assessment and treatment plan were actually revisited, with a date that isn’t the same as the document’s creation date.
• 2.3.1 and 2.3.2 together — proof an independent review happened, by someone who qualifies as independent. Auditors ask for the reviewer’s name and their relationship to the team being reviewed, because 2.3.2 specifically requires segregation of authority or an equivalent impartiality measure.
• 1.2.3 — the security lead’s reporting record. A specific meeting minute or report showing the CISO (or equivalent) actually reported to the management body — an org chart showing a reporting line isn’t the same evidence.
• 2.2.2 — the compliance reporting artefact. Something a system or process produced, on its own, showing risk information reaching management — this is the one control on the list that a document literally cannot satisfy.

Notice what all five have in common: none of them can be produced retroactively in a hurry. A policy can be drafted overnight; a dated review log covering the last twelve months cannot. That’s exactly why these five get asked for first — they’re the fastest test of whether the risk-management program predates the audit notice or was assembled for it.

Document vs Record vs Artefact — Why the Distinction Decides Whether You Pass

I’ve seen compliance folders built by capable teams fail this exact point: every one of the 8 Document-type controls above is present, well-written, and formally approved — and the file still comes back with findings, because none of the 11 Record or Artefact requirements have anything behind them. The policy says risk assessments happen annually; there’s no log showing one happened this year. The policy names an independent reviewer; there’s no report the reviewer produced.

The reason this distinction is worth treating as a formal category, not just a writing style choice, is that CIR 2024/2690’s own wording tells you which type each control needs. Controls phrased as a state (“a policy is in place,” “roles are defined”) are satisfied by a Document. Controls phrased as a recurring or one-time action (“reviewed… regularly,” “reported to management,” “reviews performed at intervals”) can only be satisfied by a Record — dated proof the action occurred — because a document describing the intent to review something is not evidence that the review happened. Controls that describe a mechanism producing its own output (“a compliance reporting system”) need an Artefact: the actual report, dashboard, or export the mechanism generated.

BSI’s own framing backs this up directly: acceptable evidence includes “internal documentation and reports,” “certifications,” “evidence of training,” and “audit reports or internal control procedures” [6] — a mix of all three types, explicitly, not documents alone. And a recognised certification doesn’t shortcut this: BSI is explicit that an ISO 27001 or IT-Grundschutz certificate “must be checked regarding the statutory measure catalogue and possibly supplemented” [6] — meaning the certificate itself is treated as one Document-type artefact among several, not a substitute for the Record-type evidence Sections 1 and 2 separately require. If your risk-management file is organised by topic (“risk policy,” “roles,” “reviews”) instead of by evidence type, it’s worth a five-minute pass just asking, for each of the 19 rows above: is what’s actually in this folder a Document, or does this control need a Record or Artefact instead?

What CIR Section 7 Adds — Auditing the Risk Management Program Itself

Section 7 of the same CIR Annex is easy to confuse with Sections 1 and 2 because it’s also about assessment — but it implements a different NIS2 measure, Article 21(2)(f) (“policies and procedures to assess the effectiveness of cybersecurity risk-management measures”), not 21(2)(a) [1][4]. Where Section 2 requires you to manage risk, Section 7 requires you to have a separate, defined process for checking whether your risk-management measures are actually working — three sub-requirements: a policy and process to assess effectiveness (7.1), the assessment methods and testing themselves (7.2), and a requirement to review that assessment policy on the same regular-plus-post-incident cadence as everything else (7.3) [4]. In effect, Section 7 is the audit of the audit: it’s what stops the 19 controls above from becoming a one-time exercise nobody revisits. It’s worth building alongside Sections 1 and 2 rather than after them, but it belongs to a different article letter and a different evidence set, which is why it isn’t one of the 19 in this checklist.

Frequently Asked Questions

Does satisfying all 19 controls guarantee I’ll pass a NIS2 audit? No. Article 21 requires “appropriate and proportionate” measures assessed against your specific risk exposure, size and sector — a supervisory authority evaluates proportionality, not just checklist completion. Treat this as the reference structure your evidence should follow, not a pass/fail certification.

Is CIR 2024/2690 legally binding on my organisation specifically? Only if you fall within the Article 21(5) entity list — DNS, cloud, data centre, CDN, MSP/MSSP, marketplace, search engine, social platform, or trust service provider [1][3]. Outside that list, national transposition law and your own risk-based judgment govern what “appropriate and proportionate” requires, though authorities commonly reference the same 13-section structure as a working standard.

What if my national competent authority hasn’t published its own NIS2 audit checklist yet? CIR 2024/2690 is an EU regulation, directly applicable without national transposition — the 19 controls above apply at the CIR level regardless of whether your specific country’s authority has issued its own supplementary 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.

Sources

1. Directive (EU) 2022/2555 (NIS2), Article 21 — nis-2-directive.com
2. Directive (EU) 2022/2555 (NIS2), Article 33 — nis-2-directive.com
3. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex
4. CIR 2024/2690 Annex mapping — OpenKRITIS, openkritis.de
5. CIR 2024/2690 Annex, Technical and methodological requirements — Advisera
6. Bundesamt für Sicherheit in der Informationstechnik (BSI), FAQ zu NIS-2 — bsi.bund.de

Further reading: how to run the underlying risk assessment this checklist audits, how to structure the internal audit cycle that produces the independent-review evidence in controls 16–19, and the full Article 21 measure-by-measure guide covering the other nine measures beyond 21(2)(a).