NIS2 Network Security Audit Checklist: 29 Controls Your Auditor Tests — Plus the 6 Most Teams Fail

Ask most IT teams what a NIS2 network security audit checks and you get an answer built from ISO 27001 muscle memory: firewalls, segmentation, maybe MFA. That answer isn’t wrong, but it’s incomplete in a specific, costly way — auditors don’t score “do you have a firewall.” They score whether you can produce dated, verifiable evidence that a named control is configured, reviewed, and owned. A network diagram that exists is not the same thing as a network diagram an auditor accepts.

This checklist breaks the network security domain of a NIS2 internal audit into 29 individually testable controls, each mapped to the specific NIS2 Article 21(2) provision or CIR 2024/2690 Annex point that governs it, with the exact evidence type an auditor will ask to see. Six of the 29 fail more often than the rest combined — not because they’re technically harder, but because they sit at the boundary between IT and documentation, and documentation is where compliance programmes quietly rot.

Who This Checklist Applies To

Article 21(2)(e) of Directive (EU) 2022/2555 requires “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” from every essential and important entity, in every sector, regardless of size band [1]. Unlike Commission Implementing Regulation (EU) 2024/2690, which legally binds only ten digital-infrastructure and ICT categories (DNS providers, cloud, MSPs, and similar) [2], the network security duty under Article 21(2)(e) has no sector carve-out.

Entity type	Bound directly by Art. 21(2)(e)?	Bound by CIR 2024/2690 Annex §6?
Essential entities (all sectors, Annex I)	Yes	Only the 10 digital-infrastructure categories
Important entities (all sectors, Annex II)	Yes	Only the 10 digital-infrastructure categories
Cloud, MSP, MSSP, DNS, CDN, data centre, trust service, marketplace, search engine, social platform providers	Yes	Yes — Annex §6 is directly binding

What NIS2 Actually Requires for Network Security

Article 21(2)(e)’s text is narrower than most compliance guides imply — it covers acquisition, development, maintenance, and vulnerability handling/disclosure, not a generic “network security” mandate [1]. In practice, though, this is the provision auditors use to test firewalls, segmentation, and system hardening, because CIR 2024/2690’s Annex Section 6 (“Security in network and information systems acquisition, development and maintenance”) fills in the operational detail — specifically point 6.7 (network security) and point 6.8 (segmentation) [2].

Section 6.7 requires entities to “document the architecture of the network in a comprehensible and up to date manner,” apply controls that “protect the relevant entities’ internal network domains from unauthorised access,” control remote access “including access by service providers,” and “allow connections of service providers only after an authorisation request and for a set time period” [2]. Section 6.8 requires entities to “segment systems into networks or zones in accordance with the results of the risk assessment” [2]. Where a control below draws on other Article 21(2) measures — access control (i), cryptography (h), MFA (j), risk analysis (a) — that’s noted individually; not every network-adjacent control lives under (e) alone.

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.

The 29-Control Checklist

Each control lists the governing provision and the evidence type an auditor accepts — not “a policy exists,” but the specific artefact: a dated export, a signed log, a named owner.

Architecture & Segmentation (7)

#	Control	NIS2 / CIR basis	Evidence type
1	Network architecture diagram, current version	CIR §6.7 [2]	Dated diagram + revision log
2	Zoning/segmentation concept tied to risk assessment	CIR §6.8 [2]	Zoning rationale document referencing the risk register
3	OT/IT boundary architecture documented	CIR §6.8; Art. 21(2)(e) [1][2]	Boundary diagram (DMZ/airlock) + boundary firewall ruleset
4	Firewall rule set reviewed on a defined cadence	Art. 21(2)(e); CIR §6.7 [1][2]	Rule export + dated review sign-off
5	DMZ configuration for externally facing systems	CIR §6.7 [2]	DMZ architecture doc + hardening checklist
6	Trusted-channel separation between distinct systems	CIR §6.7 [2]	Config showing logical/cryptographic separation
7	Service-provider connections authorised and time-limited	CIR §6.7 [2]	Authorisation log with expiry dates

Access & Remote Connectivity (6)

#	Control	NIS2 / CIR basis	Evidence type
8	Remote access enforces MFA/2FA	Art. 21(2)(j) [1]	VPN/ZTNA config export showing MFA enforcement
9	Privileged account list reviewed on a defined cadence	Art. 21(2)(i) [1]	Privileged account list + dated review sign-off
10	Access control policy, least privilege	Art. 21(2)(i) [1]	Policy doc + sample provisioning/deprovisioning log
11	Endpoint posture verified before remote connection	CIR §6.7 [2]	ZTNA/NAC posture-check configuration
12	Third-party remote access register	CIR §6.7 [2]	Register listing scope and expiry per vendor
13	Internal network access control (802.1X/NAC)	CIR §6.7 [2]	NAC policy + enforcement log

Wireless Security (3)

#	Control	NIS2 / CIR basis	Evidence type
14	Wireless authentication method documented (WPA3-Enterprise/802.1X vs. shared key)	Art. 21(2)(h); CIR §6.7 [1][2]	Wireless controller config export
15	Guest network isolated from corporate VLANs	CIR §6.8 [2]	VLAN configuration export
16	IoT/OT devices restricted to a segregated SSID	CIR §6.8 [2]	Wireless policy + SSID/VLAN mapping

Logging & Monitoring (5)

#	Control	NIS2 / CIR basis	Evidence type
17	Log retention period defined and matched to actual storage	Art. 21(2)(f); CIR §3.2.5 [1][2]	Retention policy + storage config showing actual retention
18	Authentication events logged (origin, user, outcome)	CIR §3.2 [2]	Sample log export from SIEM/log platform
19	Firewall/IDS/IPS events logged	CIR §3.2 [2]	Sample export of blocked-event logs
20	Anomaly detection against a documented baseline	CIR §3.2.4 [2]	Baseline documentation + alert rule set
21	Log integrity protected against tampering	CIR §3.2.5 [2]	Tamper-protection/WORM config or hash-verification process

Vulnerability & Patch Management (4)

#	Control	NIS2 / CIR basis	Evidence type
22	Vulnerability scanning on a defined cadence	Art. 21(2)(e) [1]	Scan schedule + latest scan report
23	Patch management SLA by severity	Art. 21(2)(e) [1]	Patch policy + closure records
24	Vulnerability disclosure process with a named contact point	Art. 21(2)(e) [1]	Published/documented disclosure policy
25	Penetration testing performed and remediated	Art. 21(2)(f) [1]	Latest pentest report + remediation tracker

Governance & Documentation (4)

#	Control	NIS2 / CIR basis	Evidence type
26	Network security policy, board-approved current version	Art. 21(2)(a) [1]	Policy doc with approval date/signature page
27	Asset inventory cross-referenced to network zones	Art. 21(2)(i) [1]	Asset register cross-referenced against the network diagram
28	Change log for network/firewall configuration changes	Art. 21(2)(e) [1]	Change ticket trail
29	Effectiveness review of network controls	Art. 21(2)(f) [1]	Internal audit or KPI report on network control performance

The 6 Controls That Fail Most Audits

These six recur across audit-preparation guidance and technical implementation notes more than any other network controls [2][3][4]. None of them require new technology — each is a documentation or ownership gap on a control the organisation likely already has, in some form, on the network.

1. Architecture diagram not current. CIR §6.7 requires the network architecture documented “in a comprehensible and up to date manner” [2] — not once, on an ongoing basis. Diagrams get drawn during initial compliance projects and then quietly diverge from reality as firewalls, VLANs, and cloud connections change. An auditor who spots one undocumented segment during a walkthrough will reasonably question the rest. Fix: assign a named owner and a fixed review trigger — every network change, not an annual calendar date.

2. OT/IT boundary undocumented. Where IT and operational technology share a site, the boundary between them is exactly the CIR §6.8 segmentation obligation applied to the highest-risk pair of zones on the network [2] — yet it’s frequently the one boundary drawn informally, because the OT side was historically outside IT’s ownership. An auditor will ask specifically for the boundary firewall ruleset and the justification for each rule, not just the general segmentation diagram.

3. Firewall rules never reviewed. Rule sets accumulate over years of ad hoc changes — a temporary rule for a vendor project that outlived the project, a “any-any” entry added to unblock testing and never removed. Without a defined review cadence and a dated sign-off, the rule export alone doesn’t satisfy Art. 21(2)(e)’s maintenance obligation [1]; it shows what’s configured, not that anyone verified it’s still justified. Fix: a quarterly review with a named reviewer and a documented decision — keep, tighten, or remove — per rule.

4. Remote access lacks 2FA everywhere it should. MFA on the corporate VPN is common; MFA on every remote path — vendor support access, legacy site-to-site tunnels, break-glass admin accounts — is less common, and auditors test the exceptions, not the default path [1]. A single unenforced remote-access route undermines the control regardless of how well the primary VPN is configured.

5. Wireless authentication method undocumented or mismatched to risk. Enterprise-grade 802.1X/WPA3 on the corporate SSID, a shared pre-shared key on a guest or IoT network with no documented justification for the gap — auditors expect the authentication method for each SSID to be explicitly stated and reasoned, not assumed from the network name [1][2].

6. Log retention set by default, not verified. Neither the NIS2 Directive nor CIR 2024/2690 mandates a specific retention duration — CIR §3.2.5 requires logs “maintained and backed up for defined periods,” without naming the period [2]. That makes the gap self-inflicted: a SIEM shipped with a 30- or 90-day default retention that was never reset to match the organisation’s own documented policy. As a general guideline, a 12-month baseline (roughly six months hot storage, six archived) is a commonly cited defensible floor in practitioner guidance, with some member states referencing longer periods for essential entities — but the number matters less than whether the documented policy and the actual system configuration agree. See our full breakdown of CIR 2024/2690 logging requirements for the retention-tier detail.

What an Auditor Will Actually Ask

Documentation review establishes the baseline; the interview is where gaps between paper and practice surface. Auditors commonly walk network and IT staff through questions like these [3][4]:

Architecture & segmentation

• “Walk me through this diagram — when was it last updated, and what changed since then?”
• “Show me the firewall rule that connects the OT segment to the corporate network. Who approved it, and when was it last reviewed?”
• “If a new vendor needed network access tomorrow, what’s the process to grant and later revoke it?”

Access & remote connectivity

• “Pull up the list of accounts with remote access. Which ones are exempt from MFA, and why?”
• “When was the last time someone reviewed who still has VPN access after leaving the company?”

Logging & monitoring

• “Show me an authentication log entry from six months ago. Can you retrieve it right now?”
• “What would trigger an alert if someone tried to log into a firewall admin console at 3 a.m.?”

Vulnerability management

• “What’s your patch SLA for a critical vulnerability on an internet-facing system, and can you show me a case where it was met — or missed?”

Closing the Gap: A Simple Framework

For each of the 29 controls, a compliance officer or CISO can score current state against the required state and estimate effort to close the gap — the same framework worth running before any formal NIS2 audit engagement:

Current state	Required state	Typical effort
Control exists, undocumented	Control exists, documented with dated evidence	Low — usually a documentation exercise
Control exists, documented once, never reviewed	Control has a defined review cadence and named owner	Low — process fix, not technical
Control partially implemented (e.g. MFA on primary path only)	Control covers all paths, including exceptions	Medium — technical rollout plus exception tracking
Control absent	Control designed, implemented, and evidenced	High — project-level effort

For a CISO, this framework doubles as a technical remediation roadmap. For a compliance officer or board member without the technical depth to read a firewall rule export, the same table answers the only question that matters going into an audit: how many of the 29 controls sit in the “high effort” row, and how much runway exists before the next inspection.

Frequently Asked Questions

Does passing this checklist mean my organisation will pass a NIS2 audit?
No — this checklist covers the network security domain only, one slice of the ten measures in Article 21(2) [1]. It can serve as evidence of appropriate measures for network security specifically; it doesn’t substitute for a full assessment across risk management, incident handling, supply chain, and the other measure areas.

Do all 29 controls apply if CIR 2024/2690 doesn’t legally bind my sector?
The Article 21(2)(e) obligation applies regardless of sector [1]. CIR §6.7–6.8’s specific wording is legally binding only for the ten digital-infrastructure categories [2], but national competent authorities — including Germany’s BSI — generally treat it as the Commission’s clearest statement of what “appropriate” network security measures look like for everyone else.

How often should this checklist be run internally?
Quarterly for the six high-failure controls, since most involve review cadences rather than one-time fixes; annually, at minimum, for the full 29-control set as part of the internal audit cycle Article 21(2)(f) requires.

Sources

1. Directive (EU) 2022/2555 (NIS2), Article 21(2) — nis-2-directive.com
2. Commission Implementing Regulation (EU) 2024/2690, Annex, Section 6 (points 6.7–6.8) and Section 3.2 — EUR-Lex
3. BSI (Bundesamt für Sicherheit in der Informationstechnik) — NIS-2-Checkliste, German national competent authority guidance
4. ENISA — NIS2 Technical Implementation Guidance