NIS2 Continuous Improvement: The CIR Fixes 4 Review Deadlines and Leaves 38 for You to Justify

Commission Implementing Regulation (EU) 2024/2690 tells you to review your network and information system security policy at least annually. It tells you to refresh your risk assessment results and risk treatment plan at least annually. It tells you to re-check who is assigned to which security role at least annually. Then, across roughly three dozen further requirements, it stops naming dates altogether. It says “at planned intervals” and leaves the interval to you.

I counted them. Parsing ENISA’s verbatim reproduction of the Annex, exactly three requirement points fix “at least annually” in binding text — 1.1.2 (the security policy), 2.1.4 (risk assessment and treatment plan) and 10.1.3 (assignment of personnel to security roles). Exactly one fixes a quarterly cadence: 3.4.2(b), the check for recurring incidents. Thirty-eight more impose a recurring review, test, update or retraining duty with no frequency attached at all[1][2].

That imbalance is the design of a NIS2 continuous improvement programme, and most published cadence tables hide it. Four cadences are given to you. Thirty-eight you choose — and under Article 32(2)(g) a supervisor can ask for the evidence that you chose them deliberately and then actually kept them[5].

Does This Apply to You?

Two layers bind, and they bind different populations. The Directive’s obligation is universal; the Implementing Regulation’s detail is not.

Your entity	What binds you	What CIR 2024/2690 is to you
DNS, TLD registry, cloud, data centre, CDN, MSP, MSSP, online marketplace, search engine, social platform, trust service provider	Article 21(2)(f) and the full CIR Annex, directly applicable EU law	Binding text. The review points below are obligations, not suggestions.
Every other essential or important entity (energy, health, transport, water, manufacturing, public administration, and the rest)	Article 21(2)(f) plus your member state’s transposing law	Not binding. It is the Commission’s own reading of what Article 21(2) requires, and the closest thing to a published benchmark your auditor has.

Article 1 of the Implementing Regulation lists its addressees explicitly, and the list is the eleven digital categories above[1]. If you are a hospital or a water utility, do not tell an auditor the CIR “requires” anything of you. Use it as the interpretive reference it is — and note that national authorities are converging on the same shape anyway. In its draft Risk Management Measures guidance, Ireland’s NCSC gives continuous improvement its own named measure, RMM005 — “assess effectiveness and improve cybersecurity risk management measures”[6].

What the Regulation Actually Fixes — and What It Leaves Blank

The census below is the part no cadence table publishes. Everything in the “binding” column is a date you cannot negotiate. Everything in the last row is a date you have to invent and then justify.

Cadence	Annex points	What has to happen
At least annually (binding)	1.1.2	Management bodies review and, where appropriate, update the security policy. “The result of the reviews shall be documented.”
At least annually (binding)	2.1.4	Review and, where appropriate, update the risk assessment results and the risk treatment plan.
At least annually (binding)	10.1.3	Review who is assigned to each security role and the human resources committed to it.
Quarterly (binding)	3.4.2(b)	Assess whether incidents are recurring within the meaning of Article 4 of the Regulation.
“At planned intervals” — you set the number	38 further points, including 2.2.3, 2.3.4, 3.1.3, 3.5.5, 4.1.4, 5.1.6, 6.5.3, 6.10.2, 7.3, 8.1.3, 11.2.3, 11.3.3, 12.1.3	Compliance monitoring, independent review, incident-response testing, continuity testing, supplier review, security-testing policy review, vulnerability scanning, effectiveness-policy review, awareness refresh, access-rights review, privileged-access review, asset reclassification.

ENISA’s Technical Implementation Guidance does supply numbers for many of those thirty-eight — but as bullets the document itself labels indicative and non-exhaustive, sitting underneath the binding text rather than inside it[2]. Those numbers are not uniformly annual, and that detail is what kills the “review everything once a year” habit. Under one single “planned intervals” point, 6.7.3, ENISA’s guidance spans four cadences: monitor networks for real-time threats continuously, scan for new vulnerabilities weekly, review firewall rules monthly, assess the entire network annually. Elsewhere it recommends reviewing change-management procedures and the security-testing policy “at least once every two years” (6.4.4, 6.5.3), vulnerability-monitoring channels “at least biannually” (6.10.4), and configurations “at least monthly” (6.3.3)[2].

So the guidance does not hand you an annual default. It hands you a worked example of the real rule: match the interval to how fast the thing underneath it moves.

How to Choose an Interval You Can Defend

Where the text says “at planned intervals”, the interval is a risk decision, and it is auditable as one. The Annex says so directly in one place: point 6.5.2(a) requires entities to “establish, based on the risk assessment carried out pursuant to point 2.1, the need, scope, frequency and type of security tests”[2]. Frequency is an output of the risk assessment, not an input to it. Ireland’s NCSC uses almost the same construction in its draft guidance, RMM005.SA01: “Based on a risk analysis, define the need and the frequency of security test types”[6].

ENISA’s guidance sketches the ladder that follows from that: measures countering real-time threats run continuously; measures countering the shifting threat landscape — vulnerability management, incident-response plans — run roughly twice a year; overall effectiveness of the whole measure set runs annually; and everything runs again on an event[2].

In practice, three questions decide the number:

1. How fast does the underlying thing change? Access rights change every time somebody moves team. Cryptographic policy changes when the state of the art moves, which is years, not months. Annex point 9.3 ties the cryptography review explicitly to “the state of the art in cryptography” — that is a trigger, not a calendar.
2. How long can a failure sit undetected before it hurts? This is the real driver. If a stale privileged account can persist for eleven months without anyone noticing, an annual privileged-access review is not a control; it is a formality.
3. What does the last audit say? A finding that reappears in two consecutive reviews is evidence the interval is wrong, and it is the single easiest thing for a supervisor to spot.

Then write the number down, in the policy, with the sentence that explains it. A documented “quarterly, because privileged accounts turn over with every project rotation” survives challenge. An undocumented “annually” does not, because there is nothing to challenge — and nothing to show under Article 32(2)(e), which lets authorities request the documented cybersecurity policies themselves[5]. Our guide to continuous versus periodic monitoring works through where the extra cost of a shorter interval actually earns its keep.

The PDCA Loop Is Already Written Into the Annex

Plan-Do-Check-Act is the standard answer to “how do we improve after go-live”, and it is usually asserted rather than mapped. It does not need to be asserted here. The Annex is already built as a loop; the four phases correspond to specific points.

Phase	Annex anchor	The concrete output
Plan	2.1 risk assessment; 1.1 policy; 7.2(a)–(f)	Refreshed risk assessment and treatment plan, an approved policy, and a measurement programme that names what is measured, how, when, and by whom.
Do	Annex sections 3–13; 1.1.1(e)	Controls running, with the staff, budget, processes and tooling the policy committed to.
Check	2.2 compliance monitoring; 2.3 independent review; point 7 effectiveness measurement; 3.6 post-incident review	Compliance status, audit findings, KPI results, and root causes from real incidents.
Act	2.3.3; 3.6.2; 1.1.1(d)	Corrective actions taken or residual risk formally accepted against your risk acceptance criteria — and lessons fed back into risk treatment and response procedures.

Point 1.1.1(d) is the sentence that makes the loop mandatory rather than advisable: the security policy itself must “include a commitment to continual improvement of the security of network and information systems”[2]. The improvement obligation is written into the document your management body signs.

The Act phase is where most programmes quietly break. Annex point 2.3.3 gives exactly two permitted endings for a finding: corrective action, or residual risk accepted according to your own risk acceptance criteria. There is no third option, and “noted, deferred, still open at the next review” is not one of them.

Checking Effectiveness Means Three Different Questions

Article 21(2)(f) requires “policies and procedures to assess the effectiveness of cybersecurity risk-management measures”[3]. Germany’s BSI splits that single word into three tests that fail independently, which is the most useful framing published by any national authority[7]:

• Konzeptionelle Eignung — conceptual suitability. Is this measure capable of reducing the risk it was chosen for? A quarterly awareness email cannot reduce a credential-theft risk no matter how faithfully it is sent.
• Umsetzungstreue — implementation fidelity. Is it applied in daily operations as designed? A rollout that reaches, say, 94% of accounts is a fidelity failure rather than a design failure — and the remaining 6% is usually where the privileged accounts sit.
• Ergebniswirksamkeit — results effectiveness. Does it produce a measurable outcome? Patch quotas, response times, and phishing simulation click rates are the BSI’s own examples.

Most programmes only test the second one, because implementation fidelity is the easiest to evidence and the least useful to know. A control can be perfectly implemented and conceptually wrong.

CIR point 7.2 then turns the test into six decisions you must record: what is monitored, by what method, when the monitoring happens, who performs it, when results are analysed, and who analyses them[1][2]. The regulation separates (d), who measures, from (f), who analyses and evaluates. It does not require different people, but the split is a good reason not to let whoever runs a measurement be the only one judging it. Point 7.3 requires the measurement policy itself to be reviewed at planned intervals, which is the loop checking its own instruments. Our breakdown of the KPIs auditors expect covers what to put in the “what” column, and the post-go-live indicator set covers where each number comes from.

The Second Clock: Reviews That Fire on Events, Not Dates

Almost every review obligation in the Annex carries a second trigger alongside the interval, and it is the one that catches organisations out. The recurring phrasing is “at planned intervals and when significant incidents or significant changes to operations or risks occur”[2].

Four events restart the clock regardless of where you are in the year:

• A significant incident. Post-incident review under 3.6.1 must identify root cause where possible and produce documented lessons learned; 3.6.2 requires those lessons to change risk treatment and response procedures, not just sit in a report.
• A significant change to operations. A new plant, an acquisition, a cloud migration, an outsourcing deal.
• A significant change to risks. A newly exploited vulnerability class in a technology you depend on.
• A supplier change. Point 5.1.6 obliges you to act on changes in the cybersecurity practices of suppliers and service providers, on their timetable rather than yours.

Point 3.6.3 adds the meta-check that catches sloppy programmes: it requires you to review, at planned intervals, whether incidents actually led to post-incident reviews. An organisation with twelve significant incidents and three post-incident reviews has a documented gap that requires no auditor skill to find.

A 12-Month Calendar You Can Defend

The order matters more than the months. Each activity should produce the input the next one needs, so the year ends with a management body approving a policy that reflects evidence gathered during the year, rather than re-approving last year’s document. The provenance column is what makes this defensible: it tells you, and your auditor, which dates you are permitted to move.

Month	Activity	Annex point	Provenance
Jan / Apr / Jul / Oct	Recurring-incident assessment	3.4.2(b)	Binding — quarterly
February	Access rights and privileged-access review	11.2.3, 11.3.3	You set it (ENISA suggests annual)
March	Supplier and service-provider review; SLA reports	5.1.6, 5.1.7	You set it
May	Incident-response and continuity testing	3.5.5, 4.1.4	You set it
June	Independent review / internal audit fieldwork	2.3.1–2.3.4	You set it
July	KPI analysis and effectiveness evaluation	7.2(e), 7.3	You set it
September	Risk assessment and treatment plan refresh	2.1.4	Binding — at least annually
October	Role assignment and resourcing review	10.1.3	Binding — at least annually
November	Compliance monitoring report to the management body	2.2.1, 2.2.3, 2.3.3	You set it
December	Management body reviews and approves the security policy	1.1.2	Binding — at least annually

If your entity sits outside the Implementing Regulation’s Article 1 scope, read “binding” in that last column as “the benchmark your auditor has”, and the rest of the table as a defensible default.

The sequencing logic is the point. Audit findings (June) and KPI evidence (July) reach the risk assessment while it is still open (September). The refreshed risk picture then drives the resourcing decision (October), because 10.1.3 asks about the human resources committed to roles and that answer changes when risk changes. Only then does the policy go to the board (December), which is the one review where 1.1.2 requires the result to be documented. Run those four in the reverse order and the board approves a policy built on evidence a year old. If you are still closing initial gaps, our five-level maturity self-assessment is the better starting point, and the 90-day audit preparation plan covers the evidence pack itself.

What Each Role Owns

Role	Owns	The one thing to change this quarter
CISO / IT security manager	The measurement programme under 7.2 and the technical review intervals	Write the justification sentence for every interval you currently run. The ones you cannot justify are the ones to change.
Compliance officer	The calendar, the evidence trail, and the two-outcome rule in 2.3.3	Close every finding as either corrective action or documented risk acceptance. Nothing stays open across two reviews.
SME owner / non-technical lead	Impartiality where you have no audit function	Point 2.3.2 lets you use alternative measures to guarantee impartiality when your size prevents separating the reviewer from the reviewed — but you must document what those measures are.
Board / management body	Approval and oversight under Article 20(1), with personal liability attached	Ask for the count: how many findings from the last review are still open, and under whose accepted residual risk.

Article 20(1) is not a reporting formality. Management bodies “approve the cybersecurity risk-management measures”, “oversee its implementation” and “can be held liable for infringements”[4] — and the CIR points the annual policy review at the management bodies specifically, not at the security team[2].

Mistakes That Turn an Improvement Loop Into an Audit Finding

• Reviewing without documenting. Point 1.1.2 requires the result of the review to be documented. A review with no record did not happen.
• “Reviewed, no changes” with nothing behind it. Record what was considered — incidents, audit results, threat changes — so that “no change” reads as a decision rather than an omission.
• An internal reviewer inside the line of authority. Point 2.3.2 prohibits it, and it is trivially visible from an org chart.
• Intervals set once and never revisited. Point 7.3 requires the review policy itself to be reviewed. An interval that has never changed despite two years of incident data is evidence of a loop that is not running.
• Findings that neither close nor get accepted. The only two endings 2.3.3 permits are corrective action and documented residual-risk acceptance.
• Post-incident reviews that happen sometimes. Point 3.6.3 requires you to check whether incidents actually led to reviews. Track the ratio yourself before somebody else does.
• Treating ENISA’s “at least annually” as law. It is guidance under a binding “planned intervals”. Cite it as guidance, and cite your own risk analysis as the reason.

Frequently Asked Questions

How often does NIS2 require a compliance review?
For entities bound by CIR 2024/2690, three things are fixed at least annually — the security policy (1.1.2), the risk assessment and treatment plan (2.1.4), and the assignment of personnel to security roles (10.1.3) — plus a quarterly recurring-incident check (3.4.2(b)). Everything else says “at planned intervals”, meaning you set the frequency from your risk analysis and document why[1][2].

Is an annual internal audit mandatory under NIS2?
The Directive does not name a frequency. The CIR requires independent reviews at planned intervals (2.3.4) carried out by people with audit competence who sit outside the line of authority of the area reviewed (2.3.2). ENISA’s guidance recommends at least annually, but that recommendation is indicative, not binding[2].

Does the CIR apply to my organisation if we are not a cloud or DNS provider?
No. Article 1 limits it to eleven digital categories[1]. Article 21(2)(f) still applies to every essential and important entity through your national transposing law, and the CIR remains the most detailed published interpretation of what “assess the effectiveness” means in practice.

What evidence should a continuous improvement programme produce?
Documented review results, KPI data with the analysis behind it, independent review reports presented to the management body, records of corrective actions and formal residual-risk acceptances, and post-incident review records. Article 32(2)(g) lets authorities request evidence of implementation, including audit results and “the respective underlying evidence”[5].

Can we run reviews less often than annually?
Not for the four fixed points. For the thirty-eight open-interval points, a longer interval is defensible if your risk analysis supports it and you have recorded the reasoning — that is precisely what “at planned intervals” leaves open. What is not defensible is a longer interval chosen for convenience and never written down.

Key Takeaways

• The CIR Annex fixes only four review cadences: three annual (1.1.2, 2.1.4, 10.1.3) and one quarterly (3.4.2(b))[1][2].
• Thirty-eight further points say “at planned intervals” — those intervals are your risk decision, and they are auditable as one[2][6].
• PDCA maps directly onto the Annex: Plan (2.1, 1.1, 7.2), Do (sections 3–13), Check (2.2, 2.3, 7, 3.6), Act (2.3.3, 3.6.2).
• Effectiveness has three failure modes, not one: conceptual suitability, implementation fidelity, results effectiveness[7].
• Every finding ends in corrective action or documented residual-risk acceptance. There is no third option (2.3.3).
• Sequence the year so audit and KPI evidence reaches the risk refresh before the board approves the policy.

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 — Article 1 (scope) and Annex, EUR-Lex
2. ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0, June 2025 — verbatim Annex reproduction with indicative guidance, enisa.europa.eu (PDF)
3. Directive (EU) 2022/2555, Article 21 — cybersecurity risk-management measures, nis-2-directive.com
4. Directive (EU) 2022/2555, Article 20 — governance, nis-2-directive.com
5. Directive (EU) 2022/2555, Article 32 — supervisory and enforcement measures for essential entities, nis-2-directive.com
6. National Cyber Security Centre (Ireland), NIS2 Draft Risk Management Measures Guidance, 24 June 2025 — RMM005 continuous improvement, ncsc.gov.ie (PDF)
7. BSI, #nis2know: Bewertung der Wirksamkeit von Maßnahmen, bsi.bund.de