How to Run a NIS2 Internal Audit: Article 21 Evidence Requests, Control Testing, and CAP Reporting

Why Article 21(2)(f) Is the Legal Foundation for Internal Audit

Most organisations treat NIS2 internal audit as an ISO 27001-style continuous improvement exercise. That framing is useful but legally imprecise. Article 21(2)(f) explicitly requires “policies and procedures to assess the effectiveness of cybersecurity risk-management measures” — a direct obligation to verify that controls work, not just that they exist.

The distinction matters for audit scope. A policy document for incident handling satisfies the “policy” requirement of Article 21(2)(b). Whether that policy is tested, followed, and effective is what Article 21(2)(f) requires you to assess. Internal audit is the mechanism for producing that assessment.

The legal architecture is circular by design. Article 21 requires organisations to implement 10 categories of cybersecurity measures. Article 21(2)(f) requires organisations to assess whether those measures are effective. Article 20 requires the management body to receive and approve the results of that assessment. Articles 32 and 33 then give supervisory authorities the power to demand evidence of all three steps. ENISA’s Technical Implementation Guidance confirms that the guidance covers “examples of evidence” for each of the 13 thematic areas of the Implementing Regulation — the same categories internal audit should be producing.

If your organisation already has an internal audit function, extending scope to NIS2 adds approximately 15–20 auditor-days annually for a mid-sized entity. Without an existing function, establishing one from scratch is a high-effort initiative requiring dedicated resource or an outsourced co-sourcing arrangement. See our full breakdown of the underlying obligations in the NIS2 requirements guide.

The Four-Stage Annual Audit Cycle

A single annual review is insufficient for NIS2. Distributing audit activity across the year ensures continuous control monitoring, reduces the risk of a supervisory visit finding unresolved gaps, and generates the rolling evidence that Article 20 management reviews require.

The following four-stage cycle maps each audit type to the Article 21 measures most relevant to it. Each stage feeds the next — Stage 1 findings involving the incident response plan are retested in Stage 3; supplier gaps identified in Stage 2 appear in the BCP exercise risk assumptions in Stage 4. The four outputs collectively form the evidence package for the annual Art. 20 management review.

Stage	Audit type	Key articles	Suggested timing	Output
1	Article 21 controls compliance audit	Art. 21(2)(a)–(j)	Q1	Audit report + CAP
2	Supplier security audit	Art. 21(2)(d)	Q2	Supplier findings + CAP
3	Incident response plan test	Art. 21(2)(b), (c)	Q3	Exercise report + lessons learned
4	BCP exercise	Art. 21(2)(c)	Q4	BCP test log + RTO/RPO actuals

Stage 1 — Auditing All 10 Article 21 Controls

Stage 1 covers every Article 21(2) sub-measure, (a) through (j). The objective is to establish whether each control exists, whether it is evidenced, and whether it has been tested and remains effective. The table below maps each sub-measure to the evidence to request, the primary fieldwork technique, and the minimum acceptable evidence standard.

This is the evidence a supervisory authority would examine under Articles 32 and 33 — which is exactly why internal audit should examine it first. Before completing this stage, read our NIS2 audit preparation guide to ensure your evidence repository is organised for retrieval.

Art. 21(2)	Evidence to request	Fieldwork technique	Minimum acceptable
(a) Risk analysis	Risk register (dated), risk methodology document, management approval minutes	Document review; interview risk owner on update triggers and last review date	Register updated within 12 months; board-approved methodology on file
(b) Incident handling	IR plan, tabletop exercise log, post-incident review records, CSIRT/authority notification evidence	Walkthrough of detection-to-notification workflow; review log timestamps; sample 2–3 real incidents end-to-end	Plan tested in last 12 months; notification log shows ≤24h/72h compliance for any reportable incidents
(c) Business continuity	BIA document, BCP per critical service, backup restore test log, DR failover test record	Config review of backup solution; review restore test log timestamps and RTO/RPO actuals vs. targets	Backup restored to target RTO/RPO within last 6 months; DR test documented with pass/fail outcome
(d) Supply chain	Supplier register with risk classification, sample contracts (security clauses, audit rights), Tier 1 supplier assessment reports	Document review; walkthrough of supplier onboarding process; contract clause sampling for 3–5 Tier 1 suppliers	All Tier 1 suppliers assessed within 18 months; contracts include incident notification SLA and audit rights
(e) Secure development	SSDLC policy, vulnerability scan reports (≤30 days old), patch closure records with timestamps, CVE tracking log	Log sampling: select 5 critical/high CVEs from last quarter; verify closure within SLA (critical ≤72h, high ≤7 days)	All critical CVEs closed within 72 hours; scan coverage ≥95% of in-scope assets
(f) Effectiveness assessment	Previous audit reports, security KPI dashboards, penetration test report (≤12 months), remediation evidence with retest results	Review pentest report currency; verify remediation tracking covers all critical/high findings; check KPIs are reported to management body	Pentest completed in last 12 months; all critical findings remediated with retest confirmation
(g) Cyber hygiene & training	Training completion records (timestamps + scores), phishing simulation results (click rate + report rate trend over last 4 runs), management body training log	Sample 10% of staff training records; review phishing simulation trend; verify management body training completion	100% completion for mandatory training; management body training within last 12 months
(h) Cryptography	Cryptographic policy, endpoint full-disk encryption coverage report, TLS scan results for external-facing services	Config review: pull endpoint management console FDE status report; run TLS scan against 5 external services	FDE on all managed endpoints; no deprecated protocols (TLS 1.0/1.1, SSLv3) on external services
(i) Access control	JML process documentation, quarterly access review records with sign-off evidence, PAM session logs, asset inventory	Walkthrough of JML workflow; sample 5 leavers from last 3 months and verify account disable within SLA; access review sign-off audit trail	Zero leavers with active accounts beyond SLA; access reviews completed on schedule with documented sign-off
(j) MFA	MFA deployment scope document, conditional access policy, authentication log sample, exceptions register with expiry dates	Config review: pull MFA coverage report from identity provider; review exceptions register; log sample for privileged account logins	MFA on all remote access, VPN, and privileged accounts; no unexpired exceptions for high-risk accounts

Fieldwork Toolkit for Stage 1

Walkthroughs: Trace a process end-to-end with the control owner. For incident handling, follow one real incident from initial alert through to CSIRT notification. For access control, follow one leaver from departure notice to account closure. Walkthroughs surface gaps that documentation reviews miss — a policy may describe a 24-hour disable SLA that the ticketing system consistently closes at 72 hours.

Configuration reviews: Export settings directly from the system of record — endpoint management console, identity provider, vulnerability scanner. A policy document claiming full-disk encryption is deployed is not evidence; a console export showing 847 of 850 managed devices encrypted is. The gap between the two is a finding.

Log sampling: Pull 10–20 log entries for the control under review and verify they match the expected outcome. For access control, 5 leaver records checked against Active Directory account disable timestamps is more defensible than a policy attestation. For patch management, select 5 critical CVEs from the last quarter and trace each through the remediation log to a verified close date.

Interview guides: Ask control owners: “What would trigger you to update this document?” (risk register, IR plan, BCP). The answer tests whether the review cycle is embedded in practice or only runs when someone asks. Record answers in interview notes — they are evidence that the control is actively managed, not just documented.

Stage 2 — Supplier Security Audit

Article 21(2)(d) requires security measures covering “relationships between each entity and its direct suppliers.” Under the NIS2 Implementing Regulation 2024/2690 the right to audit a supplier must be established contractually before you can exercise it — a point confirmed in OrbiqHQ’s vendor assurance analysis of Article 21(2)(d). Stage 2 fieldwork therefore begins by checking whether those contractual foundations exist — their absence is itself a finding.

Pre-audit: risk classification

Pull the supplier register and apply a three-tier classification before requesting evidence:

• Tier 1 (Critical): Suppliers with access to your network, critical data, or essential service delivery — full security assessment required annually
• Tier 2 (Important): Suppliers providing significant but non-critical services — questionnaire-based assessment at least every 18 months
• Tier 3 (Standard): Commodity suppliers — contract clause verification only, no periodic assessment required

Evidence to request from Tier 1 suppliers:

• Completed security questionnaire aligned to NIS2 or ISO 27001 control domains
• Penetration test report for services delivered to your organisation, issued within 18 months, with critical findings evidenced as remediated
• Incident notification commitment: written SLA to notify within a defined timeframe (72 hours mirrors your own NIS2 obligation)
• Evidence of employee cybersecurity awareness training and a designated security contact
• Software Bill of Materials (SBOM) for critical software components where applicable

Audit red flags: No contractual audit rights, no designated security contact, no incident notification commitment, and penetration test reports older than 24 months should each be recorded as findings in the CAP register. Large ICT providers frequently resist amended contract terms — document the negotiation outcome and assess residual risk where contractual protections cannot be obtained.

Stages 3 and 4 — Incident Response Test and BCP Exercise

Stage 3: Incident Response Plan Test

Article 21(2)(b) requires incident handling capability. An IR plan that has never been tested is not a control — it is a document. The test generates the evidence that the control works, and the lessons-learned output feeds directly into Stage 1’s CAP register for any gaps that surface.

A tabletop exercise should test three specific NIS2 obligations:

• Detection and escalation: How long until the scenario is escalated internally? Compare against your defined alerting SLAs.
• Notification timelines: Does the team correctly identify the 24-hour early warning trigger and the 72-hour incident notification trigger to the national CSIRT? Who makes that call and through what channel?
• Containment and communication: Are out-of-band communication channels available if primary systems are compromised? Are roles clear when the IT Security Manager is unavailable?

Evidence to produce from Stage 3: a scenario document (the tabletop script), a participant list with roles, a timing log recording key decision points and elapsed time, and a post-exercise report with specific improvement actions, owners, and deadlines. An improvement action without an owner and deadline is not a finding close-out — it is a note.

Stage 4: BCP Exercise

Article 21(2)(c) covers “business continuity, such as backup management and disaster recovery.” The BCP exercise tests whether critical services can be restored within the Recovery Time Objective (RTO) and whether data can be restored to the Recovery Point Objective (RPO) documented in the Business Impact Analysis.

What to test and verify during Stage 4:

• Backup restoration: Restore a sample dataset from the most recent backup and record the actual elapsed time vs. target RTO. Verify restored data integrity via checksums or record counts.
• 3-2-1 verification: Confirm three copies exist across two media types, with one off-site or immutable copy.
• Failover test: Where a DR environment exists, test failover and measure time to service availability vs. declared RTO.

Evidence to produce: a backup restoration log (timestamp, data set, actual RTO, pass/fail vs. target), an integrity verification record, a 3-2-1 compliance check output, and a lessons-learned document for any RTO/RPO breach.

The NIS2 Corrective Action Plan Format

Every material finding from Stages 1–4 should enter a centralised CAP register. The format below satisfies three purposes: internal tracking, management body reporting under Art. 20, and documentation for a supervisory authority request under Art. 32. Using a consistent format across all four audit stages means the management review package can be assembled without reformatting.

Field	Content	Example
Finding ref	Sequential ID	2026-IA-014
Stage	Audit stage that generated the finding	Stage 1 — Art. 21(2)(i)
Article breached	Specific Art. 21(2) sub-measure	Art. 21(2)(i) — access control
Finding description	Factual observation, no opinion	3 of 5 sampled leavers retained active AD accounts 10–14 days after departure; SLA is 24 hours
Risk rating	Critical / High / Medium / Low (see framework below)	High
Root cause	Why the control failed	JML process relies on manual HR email to IT; no automated account disable workflow
Recommended action	Specific remediation step	Integrate HRIS departure event with automated account disable via identity platform Lifecycle Workflows
Owner	Named role (not individual)	IT Security Manager
Target date	Specific date	2026-08-31
Verification method	How closure will be confirmed	Re-run leaver sample test on 5 accounts; confirm zero active accounts beyond SLA
Status	Open / In Progress / Closed	In Progress

NIS2-Specific Severity Framework

The NIS2 Directive does not prescribe internal finding categories — this framework is a practitioner interpretation designed to prioritise remediation by supervisory risk:

• Critical: A control required by Article 21 is entirely absent — no policy, no implementation, no evidence. This would be flagged immediately in an Article 32 supervisory inspection. Remediate within 30 days.
• High: The control exists but cannot be evidenced, or evidence shows the control failed (leavers with active accounts beyond SLA, critical CVEs unpatched beyond 72 hours). Remediate within 60 days.
• Medium: The control exists and is evidenced, but review cycles are overdue or documentation is incomplete. Remediate within 90 days.
• Low: Minor documentation gap with no operational impact on control effectiveness. Remediate within 180 days.

From Audit Report to the Article 20 Management Review

Article 20 requires management bodies to “approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation” — and holds them personally liable for infringements. That oversight obligation requires a structured reporting chain. The management body cannot approve something it has not seen, and “we sent the audit report by email” is not the same as documented board discussion with recorded decisions.

According to ISMS.online’s analysis of Article 20, best practice requires quarterly reporting to the board on cybersecurity status and risk, with an annual formal review of security policies. The four-stage audit cycle outputs are the core input to both cadences.

What to include in the annual management review package:

1. Article 21 controls scorecard (RAG status)
A one-page table showing Red/Amber/Green status for each of the 10 Article 21(2) sub-measures based on Stage 1 audit findings. Red = Critical or High findings unresolved. Amber = Medium findings in progress. Green = No material findings, evidence current.

2. CAP status summary
Total findings by risk rating; open, in-progress, and closed counts; any overdue items with owner names and revised target dates.

3. Key security metrics (KPIs)
Phishing simulation click rate trend across the last four runs; critical and high patch SLA compliance rate; access review completion rate; mean time to detect (MTTD) and mean time to respond (MTTR) from live incidents during the year.

4. Recommendations requiring board decision
Any finding that requires budget or resourcing beyond the IT Security Manager’s authority should include a specific decision request. The management body’s decision — and the evidence that it was discussed — becomes the Art. 20 documentary record. Board minutes referencing the audit findings and the decisions taken are themselves a key piece of evidence. If a supervisory authority under Art. 32 asks whether the management body was informed and acted, those minutes are the answer.

For organisations building their risk register as the foundation for Stage 1 fieldwork, see our NIS2 risk assessment guide.

Frequently Asked Questions

Does NIS2 explicitly require an internal audit function?
Article 21(2)(f) requires “policies and procedures to assess the effectiveness of cybersecurity risk-management measures.” This creates an obligation to assess effectiveness, but does not mandate a dedicated internal audit department. The assessment function can be performed by a compliance team, an outsourced co-source arrangement, or an existing internal audit function with expanded NIS2 scope. What matters is that the assessment is structured, documented, and feeds into the Art. 20 management review cycle.

How often must the NIS2 audit cycle run?
The Directive does not prescribe an internal audit frequency. However, GloCert International’s analysis of Article 21 controls notes that an annual penetration test of critical systems is implied by Art. 21(2)(f)’s effectiveness assessment requirement, and access reviews under Art. 21(2)(i) must run at least quarterly for critical systems. The four-stage annual cycle in this guide is a practitioner framework designed to meet these implied cadences while distributing audit workload across the calendar year.

What is the minimum audit evidence package for a supervisory inspection?
Based on the evidence categories in ENISA’s Technical Implementation Guidance, the minimum defensible package includes: a risk register, an IR plan with test record, a BCP test log, a supplier register with risk classification, a training completion report with phishing simulation data, and the most recent internal audit report with CAP status. The NIS2 audit preparation guide covers the full pre-inspection evidence checklist.

Can the same person run the audit and be responsible for the controls?
Auditing your own controls is an independence impairment. The internal audit function should not be led by the person responsible for implementing the measures being tested. For small entities where full separation is impractical, document the limitation and consider an outsourced co-sourced review for the highest-risk control areas at minimum.

Conclusion

An internal audit programme is not a NIS2 add-on — it is the mechanism by which Article 21 controls become demonstrable under Articles 32 and 33 supervision. The four-stage annual cycle structures the work; the per-measure evidence tables tell you exactly what to request; the CAP format gives every finding a documented remediation path; and the management review package closes the loop with the Art. 20 oversight obligation.

As national supervisory authorities ramp up inspections across the EU, organisations that can produce a documented internal audit trail will be materially better positioned than those that discover gaps under supervisory pressure. Run the audit before the regulator does.

Legal Disclaimer

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. NIS2 Directive (EU) 2022/2555 — EUR-Lex, European Union
2. NIS2 Article 21 Risk Management Measures Explained: All 10 Controls — GloCert International
3. Boardroom Accountability Under NIS2: Article 20 Redefines Cybersecurity Leadership — ISMS.online
4. Your NIS2 Audit Evidence Guide: Logs, Training Records & KPIs — Kymatio
5. NIS2 Penetration Testing: Audit Requirements (2026) — Sectricity
6. Vendor Assurance Under NIS2: What Article 21(2)(d) Requires — OrbiqHQ
7. NIS2 Technical Implementation Guidance — ENISA