How to Build a NIS2 Internal Audit Program When the Rules Only Say “Planned Intervals”: Scope, Cadence, Evidence

Neither NIS2 nor its implementing regulation tells you how often to audit. The Directive’s obligation on you, in Article 21(2)(f), is to have “policies and procedures to assess the effectiveness of cybersecurity risk-management measures”. For the providers it covers, Commission Implementing Regulation (EU) 2024/2690 goes further and requires independent reviews, but only “at planned intervals and when significant incidents or significant changes to operations or risks occur”. The interval is yours to set.

That is the design problem in one sentence. Whatever cadence you write into your audit program becomes the yardstick you are measured against, and a review you planned but never ran is a gap against your own document. This guide covers how to scope the program, how to set a cadence you can defend, and what the program has to produce for an auditor or a supervisor.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type, and NIS2 implementation differs by Member State and sector. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Who this applies to, and which text binds you

In plain terms: every essential and important entity needs some way to test whether its security measures work. How detailed that has to be depends on whether the implementing regulation covers you directly.

Regulation 2024/2690 is binding in every Member State without transposition, but its Article 1 limits it to eleven categories of provider: DNS service providers, TLD name registries, cloud computing, data centre, content delivery network, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers. For those entities, Annex points 2.2, 2.3 and 7 spell out the assurance work in detail. Everyone else answers to the national law that transposes Article 21(2)(f), which can be looser.

Your situation	What sets the program’s content	How a supervisor can test it
One of the 11 provider categories in Article 1 of Regulation 2024/2690	Annex points 2.2 (compliance monitoring), 2.3 (independent review) and 7 (effectiveness), applied directly	Article 32 if essential, Article 33 if important
Other essential entity (for example energy, transport, health)	National law transposing Article 21(2)(f); the regulation is a useful reference but not binding on you	Article 32(2): “regular and targeted security audits”, ad hoc audits, random checks
Other important entity	National law transposing Article 21(2)(f)	Article 33: ex post only, triggered by “evidence, indication or information” of non-compliance; “targeted security audits”, with no “regular” audits

National drafting does vary. Ireland’s draft guidance from the National Cyber Security Centre (June 2025) lists “Independent review of network and information security policies where appropriate” as a supporting action, which is softer than the regulation’s “shall”. Check your national competent authority’s guidance before you decide how much of the regulation’s structure to adopt. Even where it isn’t binding, it is the most detailed EU text describing what an assurance function looks like, so it makes a sensible benchmark. For how the essential versus important split plays out on inspection day, see what a first NIS2 audit looks like for each entity type.

One program, three assurance streams

In plain terms: the regulation describes three different kinds of checking. A workable internal audit program schedules all three and sends their results through one reporting line.

Most guidance on this topic quotes point 2.3 and stops. That misses two-thirds of the design. Point 2.3.3 says the results of independent reviews, “including the results from the compliance monitoring pursuant to point 2.2 and the monitoring and measurement pursuant to point 7, shall be reported to the management bodies.” Three streams, one funnel.

Stream	Question it answers	Who may run it	Binding timing (Regulation 2024/2690)	ENISA suggestion (non-binding)
Compliance monitoring (point 2.2)	Are we following our own policies, topic-specific policies, rules and standards?	Not restricted; ENISA lists internal or external	“regularly”; at planned intervals and on significant incidents or changes	At least annually, with reports to management bodies at least annually
Independent review (point 2.3)	Is our whole approach sound, and is it implemented, “including people, processes and technologies”?	Individuals “with appropriate audit competence” outside the line of authority of the area under review	At planned intervals and on significant incidents or changes	At least annually
Effectiveness assessment (point 7)	Do the measures actually produce the result they were chosen for?	Whoever point 7.2(d) names	You determine “when” under point 7.2(c)	By measure type: continuously, “biannually”, annually, and after incidents or significant changes

Germany’s Federal Office for Information Security (BSI) offers a useful way to see why all three are needed. The BSI’s effectiveness guidance separates conceptual suitability (could the measure reduce the risk in theory?), implementation fidelity (is it applied as planned, day to day?) and results effectiveness (does it produce measurable results?). Our reading, not the BSI’s mapping: compliance monitoring mostly tests fidelity, the independent review is the only stream that questions suitability, and point 7 is where results get measured. A program that runs only one stream can pass a control that is faithfully applied and still useless.

Point 2.3.3 also closes every finding the same way: “Corrective actions shall be taken or residual risk accepted according to the relevant entities’ risk acceptance criteria.” There is no third option. A finding that sits open with neither decision recorded is the gap, and it lands with the management body that Article 20(1) makes responsible for overseeing implementation. For the mechanics of closing findings, see how corrective action works under NIS2.

Scope: build the audit universe from 13 chapters, not 10 points

In plain terms: list everything the program has to cover before you decide how often to cover it.

The common shortcut is to audit against the ten lettered points of Article 21(2). The regulation’s Annex has thirteen chapters, and the mapping isn’t one-to-one. Point (a) splits into chapter 1 (the network and information system security policy) and chapter 2 (risk management). Point (i) spreads across human resources security, access control, asset management and environmental and physical security, chapters 10 to 13. An audit universe built from the ten points tends to collapse those into one line and under-test them.

Use the thirteen chapters as the rows of your audit universe, then add two items the chapter list hides:

• The assurance program itself. Chapter 7 is the effectiveness policy, and it can be audited like any other. ENISA suggests reviewing that policy and its procedures at least every two years.
• The people and process side of each chapter. Point 2.3.1 asks for a review of the approach “and its implementation including people, processes and technologies”. A review that only inspects technical configurations covers one of the three.

Point 7.2 tells you what feeds the ranking: the policy and procedures “shall take into account results of the risk assessment pursuant to point 2.1 and past significant incidents”. In practice that gives each row of the universe two inputs, its inherent risk rating and its incident history, and those two inputs set the tier in the next section.

Cadence: fixed clocks, one floor, and a risk-tiered rotation

In plain terms: a few reviews have a legal minimum. The audits themselves don’t, so you set them by risk and write the reasoning down.

Across the whole of Regulation 2024/2690, “at least annually” appears three times, and none of them is the independent review. The fixed clocks a program must respect are these:

Clock	Source	Status
Network and information system security policy reviewed by management bodies at least annually	Annex point 1.1.2	Binding (Article 1 entities)
Risk assessment results and risk treatment plan reviewed at planned intervals and at least annually	Annex point 2.1.4	Binding (Article 1 entities)
Assignment of personnel to security roles reviewed at planned intervals and at least annually	Annex point 10.1.3	Binding (Article 1 entities)
Recurring incidents assessed “on a quarterly basis”	Annex point 3.4.2(b)	Binding (Article 1 entities)
Compliance monitoring and independent reviews at least annually	ENISA guidance on points 2.2.3 and 2.3.4	Recommended, not binding
Effectiveness policy and procedures reviewed at least every two years	ENISA guidance on point 7.3	Recommended, not binding

The cleanest way to meet ENISA’s annual floor without auditing everything in depth every year is to split the work into two layers. Every year, run one program-level independent review of the overall approach under point 2.3.1, and fold the three binding annual reviews into the same cycle. Underneath it, rotate deep-dive audits of individual chapters by risk tier. Point 6.5.2(a) shows the regulation already thinks this way about testing, because entities set “the need, scope, frequency and type of security tests” based on the point 2.1 risk assessment.

Here is an illustrative three-year rotation for a mid-sized cloud or managed service provider. It is a recommended internal practice, not a legal requirement, and your tiers must come from your own risk assessment.

Annex chapter	Example tier	Year 1	Year 2	Year 3
2 Risk management, 3 Incident handling, 6 Acquisition, development and maintenance, 11 Access control	Tier 1: high risk or recent significant incident	Deep audit	Deep audit	Deep audit
4 Business continuity and crisis management, 5 Supply chain security, 12 Asset management	Tier 2: moderate risk	Deep audit (4, 5)	Deep audit (12)	Deep audit (4, 5, 12)
1 Security policy, 7 Effectiveness, 8 Cyber hygiene and training, 9 Cryptography, 10 HR security, 13 Physical security	Tier 3: lower risk or stable	Deep audit (7, 9)	Deep audit (1, 8)	Deep audit (7, 10, 13)
All chapters	Program level	Annual independent review of the overall approach, plus compliance monitoring of every chapter at least annually

Two rules keep a rotation defensible. First, a significant incident or significant change pulls the affected chapter forward into the current year, because points 2.2.3 and 2.3.4 make those events triggers in their own right. The regulation doesn’t define a “significant change” for this purpose, so write your own definition into the program. An undefined trigger can’t be shown to have fired or not. Second, re-tier after every annual risk assessment update under point 2.1.4. A chapter that stays in Tier 3 for six years because nobody revisited the ranking is the kind of pattern a reviewer notices.

For the faster layer underneath, ENISA’s guidance on point 7.2 suggests continuously measuring real-time controls such as firewalls and IDS/IPS, measuring threat-landscape measures such as vulnerability management and incident response plans “biannually”, and assessing the overall effectiveness of all measures annually. Our guide to security metrics auditors expect covers which numbers to track between audits.

Independence when you have no internal audit department

In plain terms: the person reviewing an area can’t report to the person running it. Small organisations can meet that with rotation, a cross-department committee, or an outside reviewer.

Point 2.3.2 is precise. Reviews are “carried out by individuals with appropriate audit competence”, and where staff conduct them, they “shall not be in the line of authority of the personnel of the area under review.” If the entity is too small for that separation, it “shall put in place alternative measures to guarantee the impartiality of the reviews.” ENISA’s Technical Implementation Guidance (June 2025) names three alternatives: rotating review personnel, a review committee with members from different departments, and an external third-party review provider. Its guidance on point 7 adds that internal assessors “should not have been involved in developing the code or in installing or operating the system being audited.”

Role	Owns in the program	Must not do
Management body	Approves the program; receives results under point 2.3.3; oversees implementation under Article 20(1)	Leave findings with no recorded decision
CISO or security lead	Compliance monitoring, point 7 measurement, remediation plans	Conduct the independent review of areas in their own line of authority
Compliance or legal	Program document, schedule, evidence register, tracking national requirements	Treat ENISA suggestions as binding text, or the reverse
Independent reviewer (internal audit, rotated staff or external)	Point 2.3 reviews, reports, competence and conflict-of-interest records	Review a system they built, installed or operate

For an SME, the practical answer is usually a mix. Rotated staff from outside IT handle compliance monitoring of policy adherence, and an external reviewer takes the annual program-level review and the Tier 1 deep audits. The weak point we see most often in small-entity programs is a CISO who writes the policies, runs the controls and then signs the review. Point 2.3.2 rules that out, and ISO 27001 applies the same logic to its own internal audits, as our ISO 27001 internal audit checklist explains.

The evidence an auditor will ask the program to produce

In plain terms: a supervisor will ask to see your audit results and the evidence underneath them, so the program has to generate a paper trail as it runs.

Both Article 32(2)(g) for essential entities and Article 33(2)(f) for important entities allow “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.” For important entities that power sits behind the ex post trigger in Article 33(1). Both articles also say targeted security audits “shall be based on risk assessments conducted by the competent authority or the audited entity”, so your own risk ranking may end up shaping the supervisor’s scope, and the audited entity pays for an independent body’s targeted audit unless the authority decides otherwise. Who counts as qualified is covered in our guide to NIS2 third-party audits.

Drawing on ENISA’s examples of evidence for points 2.2, 2.3 and 7, a complete program file holds:

1. A program document that answers point 7.2(a) to (f): what is measured, by what method, when, by whom, when results are analysed, and who evaluates them. It should also set out the scope, methodology, frequency, internal or external reviewers, and report templates that ENISA lists for point 2.3.2.
2. The multi-year plan and the current year’s schedule. ENISA lists “detailed independent review plans” and “plans or schedules for future effectiveness assessments” as evidence.
3. Reviewer competence records and conflict-of-interest declarations.
4. Review reports with an executive summary including scope and key findings, methodology, detailed findings, recommendations and conclusions.
5. Management body minutes showing the reports were received. ENISA suggests at least once a year.
6. A recorded decision per finding: a corrective action with an owner and date, or a documented residual-risk acceptance.
7. Risk register updates that reflect review outcomes, which ENISA asks for under point 2.3.3.
8. A trigger log of significant incidents and changes, showing whether each one pulled a review forward.

ENISA’s own evidence list for point 2.3.4 includes records of significant incidents and any review that followed them. In our experience item 8 is the one most often missing, and it is the cheapest to keep. For running each individual audit (evidence requests, fieldwork, corrective action plans), see how to run a NIS2 internal audit. The hub on NIS2 audit preparation covers the supervisor-facing side.

Frequently asked questions

Is an internal audit program mandatory under NIS2?
The Directive requires “policies and procedures to assess the effectiveness” of your measures under Article 21(2)(f), not an internal audit function as such. For the eleven provider categories covered by Regulation 2024/2690, independent reviews under point 2.3 are mandatory. For other entities it depends on national law, and some national drafts, such as Ireland’s, frame independent review as “where appropriate”.

Is one audit a year enough?
No binding text sets the interval. ENISA suggests compliance monitoring and independent reviews at least annually, which is a sensible floor. One annual audit that covers everything superficially is weaker evidence than an annual program-level review plus risk-tiered deep audits, and significant incidents or changes call for reviews outside the calendar.

Can our ISO 27001 internal audit count?
It can carry much of the load if you extend its audit criteria to the Annex points of Regulation 2024/2690 and route the results to the management body under point 2.3.3. The two programs share structure, including risk-based sampling and auditor independence.

Can the CISO perform the independent review?
Not of areas within the CISO’s own line of authority, which in most organisations means most of the security function. The CISO can own compliance monitoring and point 7 measurement while someone outside that line conducts the point 2.3 review.

Sources

• Article 21, Directive (EU) 2022/2555 (NIS2): cybersecurity risk-management measures, including point (f) on assessing effectiveness.
• Article 20, Directive (EU) 2022/2555: governance and management-body approval and oversight of risk-management measures.
• Articles 32 and 33, Directive (EU) 2022/2555: supervisory measures for essential and important entities, including 32(2)(b), 32(2)(g), 33(1) and 33(2)(f).
• Commission Implementing Regulation (EU) 2024/2690, EUR-Lex: Article 1 scope and Annex points 1.1.2, 2.1.4, 2.2, 2.3, 3.4.2(b), 6.5.2, 7 and 10.1.3, plus the Annex chapter headings.
• ENISA, Technical Implementation Guidance on Regulation 2024/2690, version 1.0, June 2025: guidance and examples of evidence for points 2.2, 2.3 and 7. Non-binding.
• BSI (Federal Office for Information Security, Germany), “NIS-2: Bewertung der Wirksamkeit von Maßnahmen”: the three dimensions of effectiveness.
• National Cyber Security Centre Ireland, NIS2 Risk Management Measures Guidance, draft of 4 June 2025: RMM005 supporting actions SA03 and SA06 to SA08. Draft guidance.

Verification note: quoted provisions were checked against the official text of the Directive articles and the full text of Regulation 2024/2690. Counts of “at least annually” refer to the English text of the regulation. ENISA, BSI and NCSC Ireland material is guidance and is labelled as such where used.