Qualys VMDR for NIS2 Compliance: Mapping TruRisk Scoring to CIR Annex 6.5 and 6.6

Qualys VMDR will tell your security team exactly which CVE to patch first. It will not tell your compliance officer which line of Commission Implementing Regulation (EU) 2024/2690 that patch decision satisfies. That gap — between what a vulnerability management platform scores and what an auditor asks to see — is where most NIS2 vulnerability management projects lose time. This guide maps Qualys VMDR’s actual scoring mechanics to the CIR Annex’s actual text, and draws a hard line between what the regulation requires and what is simply good practice built on top of it.

Two things up front, because both get blurred constantly in vendor content on this topic. First, CIR 2024/2690’s Annex is legally binding only for a defined list of digital infrastructure providers — most organisations running Qualys are not in that list, and for them the Annex is a benchmark, not a statute. Second, the CIR’s actual patch management text says patches must be applied "within a reasonable time" — it does not specify day counts by severity tier. Any article, including this one, that presents specific remediation windows as if they were quoted from the regulation is misrepresenting it.

What Article 21(2)(e) and CIR Annex Section 6 Actually Require

In plain terms: the NIS2 Directive obliges every essential and important entity to run a documented, risk-based process for testing and patching its systems. The CIR Annex spells out, in much greater technical detail, what that process needs to include — but only for a narrow set of digital infrastructure and ICT service providers.

The NIS2 Directive’s own text is short. Article 21(2)(e) requires "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure," and Article 21(1) requires that whatever measures an entity takes reflect the state of the art, the cost of implementation, and the entity’s own risk exposure and size [1]. That is the binding obligation for every essential and important entity, regardless of sector.

The CIR Annex’s Section 6 ("Security in network and information systems acquisition, development and maintenance") operationalises that obligation into named technical points. Three of them matter directly for a vulnerability management platform:

CIR Annex point	What it requires	Where Qualys fits
6.5 — Security testing	Documented test methodology; scope/frequency/type set by risk assessment; recorded results with criticality; mitigate critical findings; review the policy at planned intervals	VMDR’s continuous scanning schedule + criticality-tagged results
6.6 — Security patch management	Patches applied within a "reasonable time"; tested before production; sourced from trusted, integrity-verified channels; documented justification if a patch is declined	Qualys Patch Management module + TruRisk-driven prioritisation
6.10 — Vulnerability handling and disclosure	Monitor vulnerability announcements; scan at planned intervals with documented results; address critical vulnerabilities without undue delay; align with change/risk/incident management	VMDR detection feed + TruRisk severity classification

[2] This is the table an auditor is actually working from — not a generic "patch your systems" instruction, but three named, testable obligations with their own documentation requirements.

Does CIR 2024/2690 Actually Apply to You?

The short answer for most Qualys customers: not directly, but the underlying obligation still applies. The CIR Annex’s technical requirements are legally binding only on nine defined categories — DNS service providers, TLD name registries, cloud computing providers, ICT/managed service providers, managed security service providers, and providers of online marketplaces, online search engines, social networking platforms, and trust services [3]. Germany’s BSI, the national competent authority, confirms this split directly: it points digital infrastructure and ICT providers to the CIR for sector-specific technical detail, while every other entity works from the Directive’s own state-of-the-art standard [5].

If your organisation sits outside those nine categories — a manufacturer, a hospital, an energy utility — the CIR Annex is not your law. It is, however, the single most detailed public description of what "state of the art" vulnerability management looks like under Article 21(2)(e), and using it as a design benchmark is defensible practice even where it isn’t a legal requirement. Our full NIS2 scope test covers entity classification in more detail, and the CIR 2024/2690 overview walks through all 13 Annex sections.

How Qualys VMDR Maps to Section 6.5 Security Testing

Section 6.5 doesn’t ask for a one-off penetration test. It asks for a documented, repeatable testing process whose scope and frequency trace back to a risk assessment, with results recorded well enough that a reviewer can reconstruct what was tested, when, and how critical the findings were [2]. That is a description of continuous vulnerability scanning with an audit trail, not a point-in-time exercise.

VMDR’s asset-based continuous scanning schedule and per-asset criticality tagging map onto that requirement mechanically: each scan cycle is a documented test event, each detection carries a timestamp and a severity classification, and the scan schedule itself can be tied to an asset’s risk tier. What VMDR does not do on its own is write the testing policy — the documented rationale for why a given asset class is scanned weekly versus quarterly, and who signed off on that cadence. That policy document, and the periodic review Section 6.5 requires of it, is a governance artefact that sits alongside the tool, not inside it. Our NIS2 penetration testing and security testing guide covers where a manual pentest still fits alongside continuous scanning under this same Annex point.

TruRisk, QDS, CVSS, and EPSS — What They Actually Measure

Three scoring systems get used almost interchangeably in vendor material, and they measure genuinely different things. Getting this distinction right matters for Section 6.5’s "criticality assessment" requirement, because the score you cite as your criticality basis needs to mean what you say it means.

If Tenable is the other platform on your shortlist, our companion piece on how Tenable’s Lumin risk scores map to the same CIR 6.5/6.6 points walks through the equivalent mapping using Tenable’s own scoring methodology.

CVSS (Common Vulnerability Scoring System), maintained by FIRST.org, "provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity" on a 0–10 scale [7]. It measures how bad a vulnerability could theoretically be — not how likely anyone is to actually exploit it.

EPSS (Exploit Prediction Scoring System), also maintained by FIRST.org, is "a data-driven machine-learning model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days," published as a daily 0–1 probability score plus a percentile rank [6]. It measures likelihood, not severity.

QDS (Qualys Detection Score), the mechanism behind TruRisk, fuses both of those inputs — plus CISA’s Known Exploited Vulnerabilities list, exploit code maturity, active malware activity, and any compensating controls already applied to the asset — into a single 1–100 score [8]:

QDS band	Score range	Qualys guidance
Critical	90–100	Prioritise remediation
High	70–89	Prioritise remediation
Medium	40–69	Standard remediation cycle
Low	1–39	Track, batch into routine patching

Qualys recommends treating a QDS of 70 or above as the remediation-priority threshold [8]. According to Qualys’s own published methodology, this fused approach rates fewer than 1% of vulnerabilities as Critical and fewer than 7% as High — a substantially smaller working list than CVSS alone typically produces, which the company reports ranks roughly half of all vulnerabilities as High or Critical on severity alone [9]. That gap is the entire practical argument for using a fused score as your Section 6.5 criticality basis rather than raw CVSS: fewer findings competing for the same remediation window, with the prioritisation logic documented rather than left to an analyst’s judgment call.

A Practitioner SLA Framework for CIR 6.6’s "Reasonable Time"

This is the section where accuracy matters most, because it is the section every other vendor-adjacent article on this topic gets wrong. CIR Section 6.6 does not define "reasonable time" with a number. It requires only that patches be applied within a reasonable time after release, tested before production, sourced from verified channels, and — if a patch is skipped — that the decision be documented and justified [2]. There is no CIR-mandated 15-day or 72-hour clock. Any table that presents one as a legal requirement is inventing it.

What follows instead is a practitioner framework: one reasonable way to operationalise "reasonable time" using QDS as the criticality input, offered as a general guideline rather than a quoted regulatory threshold.

QDS band	A practitioner-reasonable window	CIR 6.6 hook
Critical (90–100)	Days, not weeks	"Reasonable time" read against an actively exploited or near-certain-exploitation vulnerability; overlaps Section 6.10’s "without undue delay" language for critical findings
High (70–89)	Within the next one to two patch cycles	Standard reasonable-time interpretation for high-confidence, high-impact findings
Medium (40–69)	Next scheduled maintenance window	Reasonable time can extend to routine cadence where risk doesn’t justify emergency action
Low (1–39)	Batched into routine patch cycles	Candidate for the "documented decision to decline" clause if the patch introduces more operational risk than it removes

The point of building the framework this way is that every row is defensible on the same logic CIR 6.6 already demands: a documented rationale tied to risk. A QDS-based justification — "this vulnerability scored Critical because of confirmed active exploitation, not just a high CVSS base score" — is a stronger audit answer than a bare CVSS number, because it shows the entity actually weighed exploitation likelihood, not just theoretical severity.

Closing the Vulnerability Handling and Disclosure Gap (Section 6.10)

Section 6.10 sits next to patch management but asks for something patching alone doesn’t cover: an intake process for vulnerability information (monitoring CSIRT and supplier announcements, not just running your own scanner), documented scan intervals, an "without undue delay" response commitment for critical findings, and — distinct from the patch itself — a coordinated vulnerability disclosure procedure aligned with the applicable national CVD policy [2].

VMDR’s detection feed covers the scanning and monitoring half of that. It does not, on its own, constitute a disclosure procedure, and it does not substitute for the explicit link Section 6.10 requires between vulnerability handling and your incident and change management processes. That linkage — who gets notified when a Critical QDS finding appears, and how it feeds into your existing incident workflow — is a documented handoff, not a tool configuration.

Documentation Checklist for Your Next Audit

An auditor working from CIR Section 6.5, 6.6, and 6.10 will typically ask for evidence in four categories:

• Testing policy and records — the documented methodology behind your scan scope/frequency, plus dated results with criticality assigned (Section 6.5)
• Patch evidence — deployment logs showing pre-production testing and source verification, plus any documented exceptions where a patch was deliberately declined (Section 6.6)
• Vulnerability handling records — scan-interval documentation and evidence that critical findings were actioned without undue delay (Section 6.10)
• Disclosure procedure — a written CVD process referencing the applicable national scheme (Section 6.10)

Ownership of that evidence set is rarely one person’s job: IT operations typically owns the scan/patch execution logs, while a compliance or GRC function owns the documented policy and exception-justification paperwork that ties the technical activity back to Article 21(2)(e). Our vulnerability management audit checklist breaks this down into a full control-by-control evidence list, and the vulnerability management policy template covers the five fields a patch policy document needs to survive review. For the wider CVSS-based SLA discussion this article deliberately didn’t re-derive, see our CIR Annex 6 patch management guide.

Frequently Asked Questions

Does using Qualys VMDR make an organisation NIS2 compliant?
No single tool can. VMDR can support the technical scanning, scoring, and patch-tracking activity behind Section 6.5, 6.6, and 6.10, but the documented policy, risk-based rationale, and disclosure procedure those sections also require sit outside the platform.

Is TruRisk the same thing as a CVSS score?
No. CVSS measures theoretical severity on its own 0–10 scale. TruRisk’s QDS folds CVSS in as one input alongside EPSS exploitation-likelihood data, CISA’s known-exploited list, and asset-specific context, producing a fused 1–100 priority score.

Is my organisation legally bound by CIR 2024/2690 if we’re not a digital infrastructure provider?
Generally no — the Annex’s technical requirements bind only the nine defined provider categories. Every other essential or important entity is bound by Article 21(2)(e)’s general obligation and can treat the CIR Annex as a practical benchmark rather than a legal floor.

Key Takeaways

CIR Section 6.5, 6.6, and 6.10 describe three connected obligations — documented testing, reasonable-time patching, and disclosure-aligned vulnerability handling — and a platform like Qualys VMDR can carry real evidentiary weight against all three, provided the scoring methodology behind a criticality claim is understood and documented, not just quoted as a number. The regulation itself stays deliberately non-prescriptive on exact timelines; building your own risk-based SLA framework, and being explicit that it’s your framework rather than a quoted legal threshold, is what turns a vulnerability scanner’s output into audit-ready evidence.

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, Article 21 — nis-2-directive.com
• [2] CIR 2024/2690 Annex, Technical and Methodological Requirements — Advisera
• [3] CIR 2024/2690 — NIS2 Technical Measures — nisd2.eu
• [4] “Directive (EU) 2022/2555 (NIS2)” — EUR-Lex (CELEX 32022L2555)
• [5] “NIS-2 FAQ” — BSI (Bundesamt für Sicherheit in der Informationstechnik)
• [6] EPSS — FIRST.org
• [7] Common Vulnerability Scoring System (CVSS) — FIRST.org
• [8] “TruRisk Score Model” — Qualys official product documentation
• [9] “In-Depth Look into the Data Science Behind Qualys TruRisk” — Qualys blog