27 NIS2 Vulnerability Audit Controls: The 5 Most Teams Get Wrong

The first wave of national NIS2 audits is underway in 2026. In our review of the sourced audit-evidence guidance below, vulnerability management stands out as one of the harder areas to pass on paper alone — not because the underlying controls are exotic, but because most organisations can describe them and few can prove them. A scanning policy on paper and a scanning policy an auditor can verify against a coverage report, a ticket export, and a signed exception log are two different things.

Under Directive (EU) 2022/2555 [1], a competent authority doesn’t grade your intentions. It pulls artefacts. This checklist breaks the vulnerability management audit into 27 individual controls across five areas — scanning, patching, security testing, coordinated vulnerability disclosure, and OT compensating controls — each paired with the specific evidence an auditor expects to see. It also flags the five controls that fail audits most often, and why.

What a Vulnerability Management Audit Actually Checks

In plain terms: a NIS2 vulnerability management audit checks whether you can prove — not just claim — that you scan for security weaknesses on a schedule, patch them within a defined SLA, test your defences periodically, accept vulnerability reports from outside researchers, and have a documented plan for the systems you can’t patch. Auditors don’t read a policy PDF and move on; they pull records behind it.

That evidence-first posture is written into the Directive itself. Article 32 gives competent authorities the power to run “regular and targeted security audits carried out by an independent body or a competent authority,” plus ad hoc audits “where justified on the ground of a significant incident,” and to issue “requests for evidence of implementation of cybersecurity policies, such as the results of security audits” [2]. Every control below needs a named artefact sitting behind it before anyone asks for one.

The legal anchor for vulnerability management specifically is narrow: Article 21(2)(e) requires “security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure” [3] — one clause, with no scan frequency or patch SLA written into the Directive text. The granular detail auditors actually test against — scanning cadence, patch timelines, test methodology — comes from Commission Implementing Regulation (CIR) 2024/2690, Annex I, sections 6.5, 6.6, and 6.10 [4]. That CIR formally binds only digital-infrastructure entity types (DNS providers, cloud services, data centres, and similar), but Germany’s BSI applies its scanning-and-patching structure as the working technical benchmark for Article 21(2)(e) across sectors [5] — worth knowing if an auditor cites CIR wording against a manufacturing or healthcare entity: treat it as an interpretive benchmark, not a binding requirement, outside that entity list. For the full set of Article 21 obligations beyond vulnerability handling, see our Article 21 risk-management measures guide. If you’re not yet sure NIS2 applies to your organisation at all, run the two-minute scope test first.

Most public NIS2 checklists stop at listing the requirement, such as have a patch management process or conduct vulnerability scans. That is the easy 80 percent. The harder, auditable 20 percent is the evidence layer underneath each requirement: which artefact proves it, who owns producing that artefact, and how stale it is allowed to get before it stops counting as proof. The list below treats every control as a pair, requirement plus evidence, because that pairing is what actually gets checked in the room.

The 27 Controls Auditors Check

Grouped into the five areas an audit actually walks through. Each row pairs a control with the specific artefact an auditor expects — not the policy statement, the evidence.

Vulnerability Scanning (6 controls)

Control	Evidence Auditors Expect
Documented scanning policy (tool, scope, frequency)	Signed policy naming the scan tool, asset scope, and cadence
Asset inventory mapped to scan scope	Asset register cross-referenced against the scan target list
Scan coverage percentage tracked over time	Dashboard or report showing % of inventory scanned per cycle, trended
Authenticated (credentialed) scanning for internal systems	Scan configuration showing credentialed vs. unauthenticated scan type
CVSS-based severity scoring on findings	Scan report with a CVSS score attached to each finding
Findings triaged and assigned within a defined SLA	Ticketing export showing assignment timestamps against the SLA

Patch Management (6 controls)

Control	Evidence Auditors Expect
Documented patch management policy	Policy covering testing, source verification, and deferral criteria
Patch SLA banded by severity	SLA table plus ticket closure times matching each band
Patches tested before production deployment	Change record showing a test step ahead of the production push
Patch source integrity verification	Checksum or signature verification log
Documented justification for every deferred patch	Signed risk-acceptance form per deferred patch
Patch compliance rate reported to management	Recurring compliance report with a management sign-off

See our dedicated vulnerability and patch management guide for CVSS-banded SLA timelines in detail.

Security / Penetration Testing (5 controls)

Control	Evidence Auditors Expect
Documented security testing policy (scope, frequency, type)	Policy referencing a risk-based test-scope decision
Risk-based test scope determination	Risk assessment record linked to the test-scope decision
Independent test execution (internal or third-party)	Signed test report with an independence statement
Findings remediation tracked to closure	Remediation tracker with closure dates
Retesting of critical findings	Retest report confirming the fix held

Coordinated Vulnerability Disclosure (4 controls)

Article 12 designates each Member State’s CSIRT as coordinator for external vulnerability reports, acting as “a trusted intermediary” between the reporter and the affected organisation, and can preserve reporter anonymity on request [6].

Control	Evidence Auditors Expect
Public disclosure channel designated (e.g. security.txt)	Published security.txt or vulnerability-contact page live on the domain
CVD policy with triage/response timelines	Documented CVD policy with named response SLAs
Coordination point for the national CSIRT coordinator known	Internal record naming the CSIRT contact and escalation path
Reporter anonymity option documented	Reporter log showing an anonymity option was offered

For the full policy build, see how to write a coordinated vulnerability disclosure policy.

OT / Legacy Compensating Controls (6 controls)

Control	Evidence Auditors Expect
OT/legacy asset inventory with end-of-life status	Asset register with an EOL or unsupported-status field
Documented compensating control per unpatchable asset	Exception register mapping each asset to its specific control
Network segmentation/isolation evidence	Topology diagrams plus versioned firewall configurations
Monitoring/detection on isolated OT segments	SIEM or IDS alert logs scoped to the OT segment
Signed management/board authorisation per exception	Time-stamped, signed exception approval record
Scheduled exception review cycle	Review log showing the last review date against the required cadence

The 5 Controls That Fail Most Audits

Of the 27, five are the ones we’d flag first based on the audit-evidence patterns in the sources above — not because organisations lack the underlying control, but because nobody kept the specific artefact an auditor pulls.

1. Scan coverage percentage

Most teams can produce a scan report. Few can say what percentage of their actual asset inventory that scan covered — and an auditor’s first follow-up question after seeing a clean scan is usually “coverage of what, exactly?” Without an asset register to scan against, a clean result proves nothing; it may simply have missed half the estate. Track coverage as a trended metric across cycles, not a one-off percentage pulled for the audit.

2. Exception (risk-acceptance) list age

Every vulnerability management programme accumulates exceptions — patches deferred, scans excluded, findings accepted as residual risk. What gets flagged isn’t the existence of exceptions; it’s exceptions with no review date, sitting untouched since the day they were filed. Auditor-evidence guidance for legacy systems recommends scheduled quarterly or annual review, plus a mandatory review after any incident [7]. An exception log where every entry carries a genuinely recent “last reviewed” date is what separates a managed risk from an abandoned one.

3. OT compensating controls documented

NIS2 doesn’t require replacing a 20-year-old PLC overnight. It does require a documented, asset-by-asset link between “this system can’t be patched” and “here is the specific compensating control in place” — network segmentation, hardened jump-host access, or protocol-aware monitoring, each traceable to a named asset [7]. A general statement that “OT is segmented,” without a per-asset mapping, is one of the most common gaps flagged in manufacturing and energy pre-audit reviews. See our manufacturing NIS2 checklist for the sector-specific version of this control.

4. Patch deferral without documented justification

CIR 2024/2690 explicitly allows deferring a patch — but only “where the disadvantages of applying the patches outweigh the cybersecurity benefits,” and only once that reasoning is “duly documented and substantiated” [4]. In practice, most deferred patches carry no such record; the patch was simply never applied, and nobody wrote down why. An undocumented deferral reads to an auditor exactly like an unpatched system nobody noticed.

5. Coordinated vulnerability disclosure channel

Article 12 gives every Member State a CSIRT that can coordinate external vulnerability reports [6], but that mechanism only engages once a researcher has a way to reach your organisation in the first place. BSI’s guidance recommends a published security.txt file (RFC 9116) as the minimum viable channel [5] — a control that costs almost nothing to implement and is nonetheless frequently missing, because it sits outside the scanning-and-patching workflow vulnerability teams already track day to day.

Who Owns What: A Role Snapshot

NIS2 vulnerability management audits touch more than the security team. A quick map of who owns which artefact — and what an auditor is likely to ask each role directly:

Role	Owns	Typical Auditor Question
CISO / IT Security Lead	Scan cadence, patch SLA enforcement, test scoping	“Show me last quarter’s scan coverage trend.”
Compliance Officer	Evidence trail, exception register, audit liaison	“Where’s the review date on this exception?”
OT / Plant Engineering Lead	Legacy asset inventory, compensating controls, segmentation	“Which control offsets the fact this PLC can’t be patched?”
Management Body / Board	Sign-off on risk acceptances, remediation budget	“Who approved deferring this patch, and when?”

Building Your Audit Evidence Trail in 4 Steps

1. Inventory and baseline (High effort). Build or refresh the asset register, including OT and end-of-life status, then run a full-scope scan to establish your actual coverage percentage — not the percentage you assumed.

2. Define SLAs and evidence templates (Medium effort). Set patch SLA bands by CVSS severity, build a standard exception/risk-acceptance form, and document the criteria that determine test scope and frequency.

3. Close the CVD gap (Low effort). Publish a security.txt file, write a short coordinated vulnerability disclosure policy with named response timelines, and record your national CSIRT coordinator’s contact details internally.

4. Schedule the review cadence (Low effort). Put quarterly exception reviews, an annual penetration test, and board sign-off on deferred patches on a recurring calendar — and log every review, even when nothing changes.

Frequently Asked Questions

How often does NIS2 require vulnerability scanning?

The Directive itself sets no fixed number. CIR 2024/2690 requires scan frequency to be risk-based rather than fixed [4], and as a general guideline, practitioners commonly run automated scans weekly to monthly depending on asset criticality — treat any specific cadence as a documented risk decision, not a hard legal minimum.

Does NIS2 require penetration testing?

The words “penetration testing” don’t appear in the Directive text. Article 21(2)(e) and (f), read together with CIR 2024/2690’s security-testing provisions, are widely interpreted by national authorities as requiring periodic, risk-scoped testing of control effectiveness [4][5] — in practice, treat it as expected evidence even though it isn’t named explicitly.

What counts as a compensating control for OT systems that can’t be patched?

Network segmentation or air-gapping, hardened access via jump hosts with MFA and session logging, and protocol-aware monitoring for ICS/SCADA traffic are the compensating controls most consistently accepted — provided each is documented against a specific asset, not described as a blanket policy [7].

Who actually conducts a NIS2 vulnerability management audit?

Your national competent authority, under Article 32 — through on-site inspections, off-site supervision, regular or ad hoc security audits, and direct requests for evidence [2]. Where an independent body carries out a targeted audit, the cost is borne by the audited entity.

What happens if a vulnerability management gap is found during an audit?

Article 32 gives competent authorities a graduated toolkit rather than an immediate fine: binding instructions, orders to bring measures into compliance within a set deadline, and compliance-audit requirements sit alongside administrative fines. In practice, a documented remediation plan with owners and dates, produced quickly after a finding, is treated very differently from silence — auditors are checking for a functioning management system, not a perfect one.

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] European Parliament and Council. Directive (EU) 2022/2555 (NIS2) — EUR-Lex.

[2] NIS2 Directive. Article 32 — Supervisory Measures and Powers — nis-2-directive.com.

[3] NIS2 Directive. Article 21 — Cybersecurity Risk-Management Measures — nis-2-directive.com.

[4] Advisera. CIR 2024/2690 Annex I — Technical and Methodological Requirements.

[5] Bundesamt für Sicherheit in der Informationstechnik (BSI). NIS-2: Sicherheitsmaßnahmen und Schwachstellenmanagement.

[6] NIS2 Directive. Article 12 — Coordinated Vulnerability Disclosure — nis-2-directive.com.

[7] ISMS.online. NIS 2 Legacy Systems: Audit-Proof Compensating Controls When You Can’t Patch.