NIS2 Vulnerability Management Under CIR Annex 6: Patch SLAs by CVSS Score, OT Compensating Controls, and CVD Requirements

Most NIS2 vulnerability programmes fail audits not because organisations cannot patch, but because they cannot prove what they patched, when they patched it, and — critically — why they chose not to patch something. Commission Implementing Regulation (EU) 2024/2690 (CIR), applicable from 2 January 2025 for entities within its scope, translates the high-level obligation of Article 21(2)(e) into two legally distinct controls: security patch management (Annex §6.6) and vulnerability handling and disclosure (Annex §6.10). Treating them as interchangeable is the most common gap in pre-audit assessments — and one of the first things a competent authority will identify during supervisory review.

This guide maps both controls to their exact CIR Annex requirements, provides a CVSS-based patch SLA framework aligned with ENISA’s Technical Implementation Guidance, addresses the specific challenges of operational technology (OT) environments, and explains what §6.10.2(e) requires from your coordinated vulnerability disclosure procedure under Article 12 of the NIS2 Directive.

Scope: Which Entities Must Apply CIR Annex 6

CIR 2024/2690 applies directly to a defined subset of NIS2-regulated entities: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers (MSPs), managed security service providers (MSSPs), online marketplace operators, online search engines, social networking service platforms, and trust service providers.

Entities outside this list remain subject to Article 21(2)(e) through their member state’s national NIS2 transposition, but the CIR Annex is not directly binding on them. In practice, competent authorities across the EU are treating CIR Annex 6 as the reference standard for what “appropriate and proportionate” vulnerability management looks like — making it the de facto benchmark for all supervisory assessments, not just those within its direct scope.

Before mapping your controls to CIR Annex 6, confirm your entity’s designation as essential or important under your member state’s transposition. Our NIS2 requirements guide covers the applicability decision framework for all ten Article 21 measures.

Two Separate Controls: §6.6 vs §6.10 — Why the Distinction Matters

CIR Annex Section 6 governs “security in network and information systems acquisition, development and maintenance” — the regulatory implementation of Article 21(2)(e). Within that section, two sub-sections address vulnerability-related obligations with different scopes and different compliance triggers:

Control Area	CIR Annex Section	Primary Obligation
Vulnerability Handling and Disclosure	§6.10	Obtain, assess, and manage technical vulnerability information; scan; disclose per national CVD policy
Security Patch Management	§6.6	Apply patches within reasonable time; test before production; use trusted sources; document exceptions
Security Testing	§6.5	Define scope, frequency and type of tests based on risk; document findings; apply mitigating actions

Vulnerability handling (§6.10) is the upstream intelligence and assessment process: monitoring vulnerability feeds, scanning your estate, evaluating your exposure, and deciding what requires remediation. Patch management (§6.6) is the downstream execution process: applying fixes within defined timeframes using tested, trusted sources. A programme that scans thoroughly but lacks documented patch test records fails §6.6. A programme that patches promptly but cannot show its intelligence sources or scan logs fails §6.10. Each must be evidenced independently.

Both controls integrate directly with your risk assessment process — the risk treatment plan drives remediation priority under §6.10, and risk acceptance documentation covers non-remediation decisions under §6.6.2.

Vulnerability Scanning Under CIR Annex §6.10: Channels, Cadence, and Evidence

CIR §6.10.1 establishes the core obligation: entities shall obtain information about technical vulnerabilities in their network and information systems, evaluate their exposure, and take appropriate measures to manage them. The requirement to “evaluate exposure” goes beyond subscribing to a vulnerability feed. You must assess whether your specific systems — with their configurations, network positions, and access controls — are actually exploitable through the identified vulnerability.

CIR §6.10.2 specifies five implementation requirements that must all be satisfied:

Monitoring channels (§6.10.2(a)): Vulnerability intelligence must flow from “appropriate channels” — specifically CSIRTs, competent authorities, and suppliers. In practice this means active subscriptions to at least one national CSIRT advisory service (CERT-EU, BSI, NCSC, ANSSI, or equivalent), NVD/CVE database alert feeds, and supplier security advisories for all critical ICT components in scope. Channel subscriptions and review procedures must be documented and reviewed at planned intervals under §6.10.4.

Scanning cadence (§6.10.2(b)): Vulnerability scans must be performed “where appropriate, at planned intervals, recording evidence.” ENISA’s Technical Implementation Guidance frames vulnerability management as a near-real-time or continuous discipline for internet-exposed systems, and a periodic (at minimum quarterly) process for internal systems. The specific interval is risk-justified, not fixed — but the evidence of every scan run must be retained: scope, date, tool used, findings, and follow-up actions. Scan reports without documented follow-up actions are an incomplete evidence set.

Critical vulnerability response (§6.10.2(c)): Critical vulnerabilities must be “addressed without undue delay.” This phrase creates the legal obligation; the CVSS-based SLA framework below gives it operational definition.

Process integration (§6.10.2(d)): Your vulnerability programme must integrate with change management, patch management, risk management, and incident management. A vulnerability finding that does not generate a change ticket, a risk register entry, or a patch task is a documented compliance gap. Evidence of integration — typically a link from scan findings to change management records — is one of the primary tests in a supervisory audit.

Non-remediation documentation (§6.10.3): When a vulnerability’s impact justifies it, you must create and implement a mitigation plan. When you choose not to remediate, you must document and substantiate that decision with a risk acceptance record. There is no permissible “we are aware but have not assessed” category under CIR §6.10.

CVSS-Based Patch Prioritisation: The SLA Framework

CIR §6.10.2(c) requires addressing critical vulnerabilities “without undue delay.” ENISA’s Technical Implementation Guidance recommends implementing a formal vulnerability response SLA matrix tied to risk severity, using CVSS v3.1 or v4.0 as the primary scoring mechanism, supplemented with environmental metrics and EPSS (Exploit Prediction Scoring System) to reflect your actual exposure profile.

The following SLA table represents current consensus across ENISA guidance and enforcement-phase supervisory expectations in transposing member states. Define these timeframes in your documented Vulnerability and Patch Management Procedure:

Severity	CVSS Base Score	Patch SLA	Escalation Requirement
Critical	9.0 – 10.0	24 – 48 hours	Immediate CISO notification; out-of-cycle emergency change required
High	7.0 – 8.9	7 days	CISO notification within 24 hours; expedited change review
Medium	4.0 – 6.9	30 days	Include in next scheduled maintenance window
Low	0.1 – 3.9	90 days	Next scheduled patch cycle; documented risk acceptance if deferred further

Three implementation points that most guides omit:

Adjust for environmental context. A CVSS 9.8 vulnerability in an air-gapped system with no network exposure presents fundamentally different risk than the same score on an internet-facing authentication endpoint. CIR §6.10 requires evaluating your specific exposure, not the vulnerability’s theoretical severity in isolation. Apply the CVSS environmental score to reflect your configuration and access controls. Where the full environmental score is not calculable, document your reasoning for the SLA tier applied — that documentation is what protects the decision in a supervisory review.

Supplement CVSS with EPSS for High and Critical triage. ENISA explicitly endorses EPSS alongside CVSS. A CVSS 7.5 vulnerability with a widely circulated public exploit demands faster response than a CVSS 9.1 with no proof-of-concept in the wild. Build EPSS checks into your triage workflow: a high EPSS score on a High-severity CVE should trigger Critical-tier response timelines.

Every SLA breach requires documented justification. When the 48-hour Critical window is missed — because the patch failed testing, because the vendor delayed confirmation, because the change window was unavailable — that exception must be logged in your risk register with a specific justification, a compensating control record, and a revised remediation date. Helpdesk ticket notes do not satisfy §6.10.3.

CIR Annex §6.6: Patch Management Obligations — Including the Documented Exception Rule

Section 6.6 governs the application of patches once a remediation decision has been made. CIR §6.6.1 imposes four specific requirements on the patching process itself:

1. Timely application: Patches must be applied “within reasonable time after availability” — the SLA table above gives this regulatory language its operational meaning.
2. Pre-production testing: Every patch must be tested before production deployment. For Critical patches with a 24–48 hour SLA, this requires a fast-track test environment capable of validating within hours — not a waiver of the testing requirement.
3. Trusted sources and integrity verification: Patches must originate from trusted sources and be verified for integrity before deployment. Vendor-signed packages delivered via official update channels satisfy this; binaries sourced from third-party repositories do not.
4. Additional measures when patches are unavailable: When a vendor patch does not yet exist for a confirmed vulnerability, compensating controls must be implemented immediately. This applies to zero-day vulnerabilities and end-of-support systems, distinct from the OT exception below.

The §6.6.2 documented exception rule is the provision most organisations fail to apply correctly. CIR §6.6.2 permits an entity to choose not to apply a patch when “the disadvantages outweigh the benefits” — but requires that the decision be “duly documented and substantiated.” A §6.6.2 exception record must include: the specific CVE and available patch; a structured analysis of why the patch’s risks to production stability, certification, or vendor support outweigh its security benefit; the compensating controls implemented in its absence; and a scheduled review date. Without this documentation, a decision not to patch is a compliance failure, not a risk-based decision.

Procurement connects directly here. CIR §6.1.2(b) requires procurement processes to include requirements for security updates throughout the entire lifetime of ICT products and services, and replacement plans before end of support. If your vendor cannot deliver patches, your procurement process failed a CIR requirement. Existing contracts with unsupported products require a §6.6.2 exception record, compensating controls, and a documented replacement roadmap. See our secure development and acquisition guide for embedding these requirements into your procurement lifecycle.

OT/ICS Patching: Compensating Controls When Patches Cannot Be Applied

Operational technology environments present the most significant practical challenge in NIS2 vulnerability compliance. Industrial control systems, SCADA platforms, manufacturing execution systems, and building automation systems routinely run on legacy operating systems — Windows XP, Windows 7, and Windows Server 2008 remain in active production across EU critical infrastructure — where patches either do not exist, void equipment certification, require months-long safety validation, or risk production shutdowns that are economically more damaging than the vulnerability scenario being mitigated.

CIR §6.6.2 is the legal mechanism for managing this reality. Apply a four-step decision sequence to each vulnerability affecting an OT asset:

Step	Decision Point	Action	Documentation Required
1	Is a vendor patch available?	If yes → Step 2. If no → Step 4	Patch availability record with source and date
2	Can the patch be applied without voiding certification or triggering safety validation?	If yes → test and schedule. If no → Step 3	Vendor confirmation or engineering assessment
3	Can patching wait for the next scheduled maintenance window?	If yes → schedule; implement compensating controls until then. If no → Step 4	Maintenance window date; interim compensating control log
4	Patching infeasible or no patch exists	§6.6.2 exception + §6.10.3 mitigation plan + compensating controls	Exception record signed by management body; mitigation plan with review date

Compensating controls accepted under NIS2-aligned OT security practice include:

• Virtual patching: Deploy industrial firewall rules or IPS signatures that block known exploit vectors at the network layer, without modifying the endpoint or affecting certification status. Each rule must be tied to a specific CVE in documentation, with a review date aligned to the remediation roadmap.
• Enhanced network segmentation: Isolate unpatched OT assets into dedicated network zones with strictly enforced, allowlisted ingress/egress rules that block the specific attack vector identified in the CVE. Document the segmentation boundary as a compensating control for that specific vulnerability — general §6.8 network segmentation does not automatically satisfy a §6.6.2 exception unless it materially reduces the CVE’s exploitability.
• Targeted anomaly detection: Deploy OT-aware intrusion detection with alert rules specifically addressing the exploitation patterns of the known unpatched vulnerability. Document alert thresholds, response procedures, and escalation paths — evidence of active monitoring is integral to the compensating control record.
• Physical access controls: For vulnerabilities requiring physical or local network access, documented physical security measures under §13.3 can materially reduce exploitability. Capture this as a CVSS environmental scoring adjustment to demonstrate that the adjusted risk score reflects realistic exposure.
• Accelerated decommission planning: Where compensating controls do not reduce risk to an acceptable level, a documented replacement plan with management body approval satisfies §6.10.3’s mitigation plan requirement and demonstrates a credible risk reduction trajectory to supervisory authorities.

One OT-specific complication: many vulnerabilities in industrial communication protocols — Modbus, DNP3, EtherNet/IP, PROFINET — have no NVD entry and no assigned CVE, because they were documented as protocol design weaknesses rather than software defects. Your vulnerability programme must extend to these protocol-level risks using IEC 62443 assessment methodology, not just NVD/CVE lookups.

Coordinated Vulnerability Disclosure: §6.10.2(e) and Article 12

CIR §6.10.2(e) requires every in-scope entity to “lay down a procedure for disclosing vulnerabilities in accordance with the applicable national coordinated vulnerability disclosure policy.” This is an internal documentation requirement — you need a written CVD procedure, not merely awareness that national frameworks exist.

The national CVD framework derives from Article 12 of the NIS2 Directive — not Article 25 (which covers standardisation). Article 12 requires each member state to designate a CSIRT as the national CVD coordinator, acting as a trusted intermediary between vulnerability reporters and affected entities. When a vulnerability affects systems across multiple member states, the designated CSIRTs coordinate through the CSIRT network. ENISA maintains the European Vulnerability Database for voluntary disclosure of publicly known vulnerabilities.

Your internal CVD procedure under §6.10.2(e) must cover:

• A designated security contact for receiving external vulnerability reports, with a documented first-response SLA (industry standard: acknowledgement within 5 business days)
• An internal triage and assessment workflow integrating incoming reports into your §6.10 vulnerability handling process
• A safe harbour commitment for good-faith security researchers, specifying the scope of authorised testing activity
• A disclosure timeline policy — typically 90 days from acknowledgement to public disclosure, coordinated with patch availability — aligned with ENISA guidance and national CSIRT policy
• An escalation path to the national CSIRT coordinator when a reported vulnerability affects multiple organisations or critical infrastructure

Entities that discover vulnerabilities in third-party ICT products they use should ensure supplier contracts include vulnerability disclosure notification obligations consistent with §6.10.2(e), and consider voluntary registration with ENISA’s European Vulnerability Database established under Article 12.

Role and Responsibility Matrix

Function	CISO / Security Manager	IT Operations	Compliance / Legal	Management Body
Define patch SLA policy and CVSS thresholds	Owns	Inputs	Reviews	Approves
Vulnerability scanning (§6.10.2(b))	Oversees	Executes	—	—
Critical CVE triage and SLA escalation	Escalation decision	First response	—	Notified (Critical only)
Pre-production patch testing (§6.6.1)	Approves process	Executes	—	—
§6.6.2 exception documentation	Authors	Inputs technical detail	Reviews	Signs off
OT compensating control design	Approves	Implements	—	Risk acceptance sign-off
CVD procedure management (§6.10.2(e))	Owns	—	Reviews	—
Vulnerability channel review (§6.10.4)	Executes	Inputs	—	Informed

Audit Evidence Checklist

Before a competent authority inspection, confirm you can produce evidence for each of the following:

• Documented vulnerability scanning schedule with evidence of execution — scan logs, scope, dates, tool used (§6.10.2(b))
• Active subscriptions to at least one CSIRT advisory service and supplier security advisories (§6.10.2(a))
• Written patch SLA policy with CVSS score thresholds, escalation procedures, and responsible roles (§6.6 / §6.10.2(c))
• Pre-production test records for all Critical and High patches applied in the last 12 months (§6.6.1)
• Risk register entries for all known unpatched vulnerabilities, with remediation status and compensating controls (§6.10.3)
• §6.6.2 exception records for every patch not applied, signed by the appropriate management body (§6.6.2)
• OT compensating control documentation with specific CVE-to-control mapping and review dates (§6.6.2 / §6.10.3)
• Written CVD procedure with designated contact, response SLAs, and disclosure timeline policy (§6.10.2(e))
• Evidence linking vulnerability findings to change tickets or risk register entries — not scan reports alone (§6.10.2(d))
• Annual review record of vulnerability monitoring channels (§6.10.4)

Frequently Asked Questions

Does CIR Annex 6 specify 48 hours as a maximum patch window for Critical vulnerabilities?

CIR §6.10.2(c) requires critical vulnerabilities to be “addressed without undue delay” — it does not define a fixed number of hours. The 24–48 hour window reflects ENISA guidance and what enforcement-phase supervisory authorities are using as a benchmark. Your written policy should define what “without undue delay” means in your operational context, document the reasoning, and apply it consistently. Deviation from an industry-standard benchmark without documented justification is a finding risk in supervisory review.

Can we defer patching if the patch breaks production systems?

Yes — CIR §6.6.2 explicitly permits this when “the disadvantages outweigh the benefits,” provided the decision is duly documented and substantiated. The documentation must be specific to the patch and system in question, include the specific risks that led to deferral, and identify the compensating controls implemented in the interim. A decision not to patch without this documentation is not a risk-based decision — it is a compliance failure under CIR.

Do we need a public-facing vulnerability disclosure policy?

CIR §6.10.2(e) requires a procedure “in accordance with the applicable national coordinated vulnerability disclosure policy.” The specific public disclosure obligations depend on your member state’s national CVD policy implementing Article 12 of NIS2. Most EU member states with active CVD frameworks (Netherlands, France, Germany, Belgium) expect at minimum a designated security contact point. Publishing a full CVD policy is best practice and reduces reputational risk from uncoordinated vulnerability disclosures. ENISA’s CVD policy guidance provides a template framework.

Does NIS2 vulnerability management apply to OT systems?

The obligations in §6.10 apply to all network and information systems in scope, including OT. The difference is in implementation: OT environments constrain what “appropriate measures” look like, not whether the obligation applies. Compensating controls — virtual patching, enhanced segmentation, anomaly detection — are the primary mechanism for managing vulnerabilities where direct patching is infeasible. OT environments without any documented compensating controls for known vulnerabilities are in compliance breach regardless of operational justification.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex
2. NIS 2 Directive — Article 12: Coordinated Vulnerability Disclosure
3. ENISA Technical Implementation Guidance on Cybersecurity Risk Management Measures (2025)
4. NIS 2 Directive — Article 21: Cybersecurity Risk-Management Measures

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.