NIS2 Vulnerability Management Policy Template: The 5 Fields Your Patch Documentation Must Include

Article 21(2)(e) of the NIS2 Directive requires ‘security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure’ from every essential and important entity. Search for a ‘NIS2 vulnerability management policy template’ and you will find dozens of documents that restate the CVSS scoring system, add a generic ‘patch promptly’ clause, and call it compliant.

None of the templates we reviewed while researching this article separate the five fields an auditor actually checks for in the written policy itself, as distinct from the underlying scanning and patching activity. This article is the document-assembly layer: which fields your policy must contain, in what order, with a worked field-by-field walkthrough you can adapt. For the full mechanics of CVSS scoring, scan cadence, and OT compensating controls, see our companion deep-dive on vulnerability management under CIR Annex 6; for the coordinated vulnerability disclosure policy specifically, see how to write a NIS2 vulnerability disclosure policy.

Why ‘We Patch Regularly’ Doesn’t Survive an Audit

In plain language: having a patching habit is not the same as having a documented policy. An auditor cannot verify a habit — they verify a dated, approved document that defines scope, timelines, and evidence. If your organisation patches diligently but has no written policy stating how, competent authorities treat that as a governance gap, not a technical one.

Article 21(2)(e) of Directive (EU) 2022/2555 applies to every essential and important entity in scope of NIS2, as part of the all-hazards, proportionate measures required under Article 21(1)-(2) [1]. Commission Implementing Regulation (EU) 2024/2690 (CIR) expands this into detailed technical requirements for the specific digital-infrastructure and ICT-service entities it binds directly — DNS providers, cloud, data centres, CDN, MSP/MSSP, marketplaces, search engines, social platforms, and trust service providers — under Annex Section 6 [3]. Every other essential or important entity is bound by Article 21(2)(e) directly; CIR Annex Section 6 is nonetheless the closest thing to an official EU reference structure and is widely adopted as best practice even where it isn’t formally mandatory.

For a compliance officer, this policy is the audit-trail artefact — the document you hand over when a competent authority asks ‘how do you handle vulnerabilities?’ For an IT security manager, it’s the operational contract that tells the team exactly which timelines and escalation paths apply. Both readings have to be satisfied by the same document, which is why the five fields below are structured the way they are.

The 5 Fields Every Vulnerability Management Policy Must Contain

Every compliant policy document needs these five fields, populated with your organisation’s actual numbers and named contacts — not left as placeholder text.

Field	What it defines	Where it usually goes missing
1. Scan frequency & sources	How often systems are scanned, and which intelligence feeds are monitored	Internal systems left unscanned; only internet-facing assets covered
2. Severity-to-SLA matrix	Remediation timeframe per CVSS band, with an escalation trigger	No documented timeframes at all — ‘as soon as possible’ isn’t auditable
3. Documented exception process	How and when a patch is deferred, and what compensates for it	Exceptions happen informally via email, never logged
4. OT / legacy compensating controls	What replaces patching when a system genuinely cannot be patched	Field omitted entirely — treated as a technical afterthought, not a policy field
5. CVD reporting channel	How external researchers and the public report vulnerabilities to you	No published contact; disclosure handled ad hoc by whoever picks up the email

Field 1 — Vulnerability Sources and Scan Frequency

State, in the policy itself, which sources feed your vulnerability register: automated scanning (internal and external-facing systems on different cadences), vendor security advisories, threat intelligence feeds such as CISA’s Known Exploited Vulnerabilities catalogue, and — where you develop software — dependency/SBOM scanning of open-source components. BSI’s own NIS2 guidance frames this as ‘regular scanning of systems for known security gaps and criticality assessment,’ paired with a documented reporting process so findings reach the right team without delay [4].

Write the cadence as a number your organisation will actually meet, not an aspirational one: internet-facing and critical systems typically need weekly or continuous coverage, internal systems monthly at minimum. A field that just says ‘regularly’ fails the same audit test as ‘we patch regularly’ at the policy level.

Field 2 — The Severity-to-SLA Matrix (and Why the Regulation Won’t Give You One)

This is the field every template gets partly wrong, in one of two directions: some copy a generic table and present it as if the regulation mandates those exact hours; others leave the timeframes blank. Neither is correct.

Neither Article 21(2)(e) of the Directive nor CIR 2024/2690’s Annex Section 6 specifies a numeric patch deadline. The Directive requires vulnerability handling generally [1]; the CIR Annex requires timely, risk-based remediation without prescribing hours or days [3][5]. The specific numbers are a documentation choice your organisation makes and then must follow consistently — which is precisely why an auditor checks whether you have a matrix at all, and whether your remediation records match it, rather than checking the numbers against a regulatory table that doesn’t exist.

A commonly used starting framework looks like this:

CVSS Band	Score Range	Typical SLA
Critical	9.0 – 10.0	24 hours
High	7.0 – 8.9	72 hours
Medium	4.0 – 6.9	30 days
Low	0.1 – 3.9	90 days

Treat this as one defensible starting point, not the only one. Published frameworks vary meaningfully at the top end — some set Critical at 24-48 hours, others allow 7-14 days when the asset isn’t internet-facing or actively exploited — because CVSS score alone doesn’t capture exposure. A Critical-rated vulnerability on an isolated development server is a lower real-world priority than a High-rated one on an internet-facing system with a known exploit in the wild. Whichever bands you choose, the policy field must state the numbers explicitly and name who escalates when a deadline is at risk.

Field 3 — The Documented Exception Process

Every framework accepts that some patches will not be applied on schedule — vendor delay, system incompatibility, or business-critical uptime constraints. What none of them accept is an undocumented gap. The policy field needs a structured exception record, not a footnote, covering: the specific CVE and affected asset, the reason the patch is deferred, the compensating control implemented in its place, who approved the deferral, and a mandatory review date.

An exception log with no review date is functionally the same as no exception process — it becomes a permanent gap that nobody revisits. Build the review date requirement into the field definition itself, not just the underlying register.

Field 4 — OT and Legacy-System Compensating Controls

For manufacturing, energy, healthcare, and any entity running operational technology, this field is not optional detail — leaving it out is the single most common gap we see in generic templates, because most were written for pure-IT environments. Where a patch cannot be applied to a PLC, SCADA system, or medical device without a maintenance window or vendor re-validation, the policy must name the acceptable substitutes:

• Network segmentation isolating the unpatched asset in its own zone
• Virtual patching via firewall or IPS rules blocking the specific exploit vector
• Enhanced monitoring tuned to the vulnerability’s known exploitation pattern
• Physical access controls where exploitation requires local or physical proximity
• A documented, management-approved timeline for eventual patching or replacement

State explicitly in the policy that compensating controls are temporary bridges, tracked with the same review-date discipline as Field 3 — not a permanent alternative to patching.

Field 5 — The Coordinated Vulnerability Disclosure (CVD) Channel

Article 12 of the NIS2 Directive requires each Member State to designate a CSIRT as coordinator for vulnerability disclosure, acting as trusted intermediary between external reporters and affected entities, and to permit anonymous reporting [2]. Your policy’s CVD field needs, at minimum: a published security contact (a security.txt file is the simplest way to do this), a stated first-response timeframe, and a safe-harbour commitment defining authorised testing scope for good-faith researchers.

Germany’s BSI adds a mechanism worth naming even outside Germany: the Common Security Advisory Framework (CSAF, technical guideline TR-03191) for standardised, machine-readable advisory exchange, plus BSI’s own portal for voluntary — including anonymous — vulnerability reporting [4]. If your organisation supplies software, contractually requiring suppliers to publish CSAF-formatted advisories closes a gap most CVD policies never address: how you receive vulnerability information about your own dependencies, not just how the public reports issues in your product. We cover the full CVD policy build — bug bounty scoping, disclosure timelines, CSIRT coordination — separately; this field only needs to reference that document and confirm it exists.

The Documentation Gaps That Actually Fail Audits

Across the templates and live policies we’ve reviewed, the same four gaps recur, in roughly this order of frequency:

Gap	Why it fails review	Fix
No exception review dates	Deferred patches become permanent with no re-evaluation trigger	Make the review date a mandatory field, not optional
SLA matrix with no escalation owner	Deadlines exist on paper but nobody is accountable when one is missed	Name a role (not a person) responsible for each severity band
OT/legacy field entirely absent	Policy reads as IT-only even where OT assets are in scope	Add the compensating-controls field even if currently unused
CVD channel undocumented internally	A public security contact exists, but no internal record of who triages it	Cross-reference the CVD policy and name the triage owner inside this document

Who Owns Each Field: Role-Responsibility Table

Field	Responsible	Accountable	Reviews / Approves
Scan frequency & sources	IT Security Lead	NIS2 Officer	Top management (annual)
Severity-to-SLA matrix	IT Security Lead	NIS2 Officer	Top management (annual)
Exception process	System Administrators	IT Security Lead	NIS2 Officer (per exception)
OT compensating controls	OT/Engineering Lead	IT Security Lead	Top management (per control)
CVD channel	Security Contact / IT Security Lead	NIS2 Officer	Top management (annual)

For a small entity without a formal board, ‘top management’ means whoever holds genuine management authority — owner, managing director, or leadership team. What an auditor checks isn’t the title on the approval line; it’s that the approval and its date exist as a record independent of the policy text itself.

Audit Evidence: What to Keep on File Alongside the Policy

The policy document alone doesn’t satisfy an auditor — it establishes what should happen. What proves it actually happened is a separate evidence trail, and this is where a documented-but-unfollowed policy gets caught. For each of the five fields, keep:

Field	Evidence to retain
Scan frequency & sources	Scan reports/timestamps per cycle; vendor advisory subscription confirmations
Severity-to-SLA matrix	Remediation timestamps (scan → patch verification) per vulnerability, showing SLA was met or an exception was logged
Exception process	The exception register itself, with approver signatures and review-date history
OT compensating controls	Firewall/IPS rule change records, segmentation diagrams, monitoring alert configuration tied to the specific vulnerability
CVD channel	Security contact publication proof (e.g. security.txt file), a log of reports received and response times

Two figures worth tracking as ongoing metrics, independent of the policy text: scan coverage (scanned assets versus your full asset register) and the count of open exceptions past their review date. Auditors read a rising exception backlog as evidence the SLA matrix isn’t being enforced — which undermines Field 2 even if the field itself is well written.

Frequently Asked Questions

Does CIR 2024/2690 legally require my organisation to use these exact five fields?
Only if your entity falls under the specific digital-infrastructure/ICT categories the CIR binds directly [3]. Every other essential or important entity is bound by Article 21(2)(e)’s general vulnerability-handling requirement [1], but the five-field structure is the practical way auditors and consultants operationalise that requirement regardless of whether the CIR formally applies to you.

Can I use a single SLA matrix across every business unit?
You can as a starting point, but CVSS score alone doesn’t reflect real exposure — asset criticality and network exposure vary by business unit. Many organisations keep one baseline matrix and allow documented tightening (never loosening) for higher-risk units.

How is this different from a vulnerability disclosure policy?
This policy governs how you find and fix vulnerabilities in your own systems. A vulnerability disclosure policy governs how external researchers report vulnerabilities to you under Article 12. Field 5 above is the bridge between the two — your policy should reference the CVD policy rather than duplicate it.

Does this policy need to map to ISO 27001?
If your organisation also holds or is pursuing ISO 27001:2022, control A.8.8 (management of technical vulnerabilities) covers substantially the same ground, which makes cross-referencing straightforward — see our NIS2 vs ISO 27001 comparison for the full control mapping.

Sources

• [1] NIS 2 Directive, Article 21: Cybersecurity risk-management measures — nis-2-directive.com
• [2] NIS 2 Directive, Article 12: Coordinated vulnerability disclosure — nis-2-directive.com
• [3] Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex
• [4] BSI — Sicherheitsmaßnahmen und Schwachstellenmanagement (Germany, national competent authority)
• [5] CIR 2024/2690 — NIS2 Technical Measures — nisd2.eu

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.