Tenable NIS2 Compliance: What CIR Annex 6.5/6.6 and Lumin Risk Scores Actually Map To

Tenable’s own NIS2 marketing is careful to say its tools help you ‘align with’ the directive — it never says a scan report makes you compliant. That distinction matters more than the vendor copy lets on, because the two things a Tenable deployment actually produces — a prioritized vulnerability list and a Cyber Exposure Score — map to specific, narrow points inside NIS2’s technical rulebook, not to the whole compliance obligation. This guide traces exactly where that mapping holds, where it’s your own interpretation rather than settled law, and what a scanner can never hand you: the documented policy an auditor actually wants to see.

Does CIR 2024/2690 Even Apply to Your Organisation?

Most vendor content about NIS2 and ‘technical measures’ quietly assumes Commission Implementing Regulation (EU) 2024/2690 — the technical annex with the specific vulnerability-scanning and patch-management language — applies to every NIS2 entity. It doesn’t. The CIR’s Annex is legally binding only on a defined set of digital infrastructure and digital-service-provider categories.

Your organisation	Is the CIR Annex legally binding?	Governing legal basis
DNS provider, TLD registry	Yes	CIR Annex Section 6.5, 6.6, 6.10
Cloud, data centre, or CDN provider	Yes	CIR Annex Section 6.5, 6.6, 6.10
MSP or MSSP	Yes	CIR Annex Section 6.5, 6.6, 6.10
Online marketplace, search engine, social platform	Yes	CIR Annex Section 6.5, 6.6, 6.10
Trust service provider	Yes	CIR Annex Section 6.5, 6.6, 6.10
Everyone else — manufacturing, energy, health, finance, transport, public administration	No	Article 21(2)(a) and 21(2)(e) directly

The ten bound categories — DNS providers and TLD registries, cloud/data-centre/CDN providers, MSPs and MSSPs, online marketplaces, search engines, social networks, and trust service providers — are confirmed against the CIR’s own scope article via OpenKRITIS’s structured mapping. If you’re not on that list, the CIR Annex isn’t a checklist you’re required to pass — it’s a benchmark auditors and competent authorities increasingly point to when judging whether your Article 21(1) measures reflect the ‘state of the art.’ For most Tenable customers reading this article, that’s the honest framing: everything below is either a direct legal requirement (if you’re CIR-bound) or a defensible best-practice reference (if you’re not).

The general legal basis, for everyone, sits in Article 21. Article 21(2)(a) requires ‘policies on risk analysis and information system security.’ Article 21(2)(e) requires ‘security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.’ Those two clauses — not the CIR Annex — are what your vulnerability-scanning program is actually answering to if you’re outside the ten bound categories.

Tenable Vulnerability Management, Tenable One, and Tenable Security Center: Mapping Scans to CIR 6.5 and 6.6

Tenable’s core product line splits three ways. Tenable Vulnerability Management (the product formerly branded Tenable.io) is the cloud-native scanner — fast to deploy, no on-prem infrastructure. Tenable Security Center Plus (formerly Tenable.sc) is the on-premises equivalent for organisations with data-residency or air-gapped requirements. Tenable One sits above both as the unified exposure-management layer, pulling IT, cloud, identity, and OT findings into a single risk view across 300+ integrated data sources. All three share Tenable’s core scanning technology; the difference is deployment model and how far the resulting data gets unified with non-IT asset classes.

Where this connects to CIR text is specific, not general. Section 6.5 (Security Testing) doesn’t just ask for scanning — it names methods explicitly: relevant entities must ‘regularly carry out security tests based on a dedicated policy and procedures,’ and the Annex lists ‘penetration testing, vulnerability scanning, application security tests, configuration tests, or security audits’ as accepted approaches. A continuously scheduled Tenable scan genuinely is one of the named 6.5 methods. Section 6.6 (Security Patch Management) requires patch procedures ‘aligned with… change management, vulnerability management, risk management’ — and Tenable’s Vulnerability Priority Rating (VPR) is exactly the kind of prioritization signal that clause expects a patch process to consume. Section 6.10 (Vulnerability Handling and Disclosure) requires entities to ‘obtain information about technical vulnerabilities’ and address critical ones without undue delay — Tenable Research’s vulnerability intelligence feed is a legitimate channel for that duty.

CIR requirement	What the text actually requires	What Tenable scanning gives you	What’s still missing
6.5 — Security testing	Dedicated policy + procedures; documented methodology; criticality-weighted results feeding effectiveness assessments	Continuous automated scanning; prioritized findings via VPR	The written testing policy, defined scope/cadence, and the link from findings to your effectiveness-assessment record
6.6 — Patch management	Procedures aligned to change/vulnerability/risk management; proportionate; no new instability; customer notice for outages	A prioritized patch queue (VPR × asset criticality)	The documented patch SLA, change-management sign-off, and advance-notice process
6.10 — Vulnerability handling & disclosure	Monitor vulnerability channels; address critical findings without undue delay	Tenable Research threat intelligence feed	The disclosure/coordinated-vulnerability-disclosure policy and named escalation owner

None of this is a criticism of the product — it’s an accurate description of where a scanner’s output ends and a compliance document begins. For the full CVSS/EPSS-based SLA framework and the OT-specific compensating-control patterns (virtual patching, segmentation, allowlisting) that a 6.6 patch procedure needs, see our dedicated NIS2 patch management and vulnerability handling guide — this article focuses on where a specific vendor’s tooling fits into that framework, not on rebuilding the framework itself.

Tenable Lumin’s Cyber Exposure Score as an Article 21(2)(a) Risk Register Input

Tenable Lumin layers a single number — the Cyber Exposure Score (CES) — on top of raw scan data. CES runs 0 to 1000, built from the Asset Exposure Score of every licensed asset scanned in the last 90 days; each asset’s score combines its Vulnerability Priority Rating (exploit likelihood) with its Asset Criticality Rating, a 1-10 business-importance value recalculated daily and adjustable by your team. In Tenable’s own marketing, the score exists for one purpose: helping CISOs communicate risk to the board and benchmark against industry peers. Tenable’s own material stops there — it does not claim CES as a compliance-reporting metric, and that omission is worth taking seriously rather than papering over.

Here’s the original synthesis, offered as a practical framing rather than a sourced fact: Article 21(2)(a) requires a policy on risk analysis, and a defensible risk analysis is one that’s documented, criticality-weighted, and periodically reviewed. A CES trend line — tracked by asset class over successive 90-day windows — can function as one *input* into that risk register, provided three conditions hold. First, someone accountable has reviewed and, where necessary, overridden the default Asset Criticality Ratings; an unreviewed default is not your organisation’s judgment of what matters, it’s Tenable’s generic default. Second, what goes into the register is the trend and the remediation decisions it drove, not a single point-in-time score with no narrative. Third, the register still needs your own stated risk appetite and treatment decisions attached — a number, however well-calculated, is not itself a policy. Treat this as a reasonable practitioner approach, not as a Tenable-endorsed compliance method or as settled regulatory guidance.

Tenable OT Security (Formerly Indegy): CIR 6.5 by Analogy for Industrial Environments

Tenable acquired the industrial-security firm Indegy in December 2019 for $78 million. Indegy’s platform, built specifically for ICS/SCADA environments, detected unauthorised changes to controller firmware, logic, and configuration — the kind of tampering an IT-focused scanner would never see. That technology became Tenable OT Security, and the acquisition itself explains why it works differently from Tenable’s IT products: active network scanning that’s routine on an IT endpoint can crash a twenty-year-old programmable logic controller, so Tenable OT Security leans on passive network monitoring and controlled Active Query checks instead of blanket active scans.

For manufacturing, energy, and utility operators, this matters because most OT/ICS entities sit outside the CIR’s ten bound categories — the same scope caveat from the first section applies here too. CIR Section 6.5’s testing requirement is not a direct legal obligation for a typical factory floor. What Tenable OT Security genuinely offers instead is a tool-level implementation of the exact compensating-control pattern our own patch-management guide describes for legacy ICS that can’t be actively scanned: continuous passive visibility, configuration-change tracking as a proxy for ‘testing’ when live scanning is too risky, and asset inventory depth that most IT-only vulnerability scanners never reach on the OT side. Positioned this way — by analogy to 6.5, alongside an IT vulnerability management deployment rather than replacing it — it’s a legitimate way to demonstrate the same ‘state of the art, proportionate’ standard Article 21(1) asks of every entity, OT-heavy or not.

What Tenable Doesn’t Give You

Three roles read this differently. A CISO or security manager gets real technical value from Tenable’s output — it’s the evidence base for prioritization decisions — but that evidence base is not itself a policy document. A compliance officer preparing for an Article 32 or 33 supervisory review needs something a scan export was never built to produce: a dated, versioned, sign-off-tracked document that names the specific CIR section or Article 21(2) point it satisfies. An auditor reviewing your file wants to see who approved the testing policy and when it was last reviewed — not a CSV of CVE IDs. An SME owner with no compliance headcount faces the sharpest version of this gap: paying a consultant to draft that policy layer from scratch typically costs more than a single Tenable Vulnerability Management licence.

None of this is a flaw in the product — vulnerability scanners were never designed to be policy-authoring tools, and no vendor markets them that way. It’s simply the boundary of what scanning output can prove, and it’s the boundary every organisation using Tenable, or any comparable scanner, for NIS2 purposes needs to close with its own documented governance layer.

Choosing Between Tenable.io, Tenable.sc, Tenable One, and Tenable OT Security

The right starting product depends on your entity profile, not on which one has the most features. A cloud-native SME with a small, mostly-SaaS estate is generally better served by Tenable Vulnerability Management — fastest to deploy, no infrastructure to maintain, and proportionate to a smaller Article 21(1) risk profile. An organisation with data-residency constraints, air-gapped segments, or an existing on-prem security operations investment fits Tenable Security Center Plus more naturally. An enterprise juggling IT, cloud, identity, and OT surfaces that needs one number for board-level risk reporting is the actual use case Tenable One and Lumin’s CES were built for — smaller entities rarely need that unification layer and would be paying for consolidation they don’t have the asset sprawl to justify. Manufacturing, energy, and utility operators with legacy PLC/SCADA assets should treat Tenable OT Security as an addition layered on top of an IT vulnerability management deployment, never a replacement for it — NIS2’s all-hazards standard under Article 21(1) doesn’t recognise an IT/OT split, even though your tooling architecture has to.

Frequently Asked Questions

Does using Tenable make my organisation NIS2 compliant?
No. Tenable’s own products are marketed as supporting alignment with the directive, not as a compliance framework. Article 21(2) lists ten separate measure categories — governance, incident handling, business continuity, supply chain, training, cryptography, HR security, access control, and asset management, alongside vulnerability handling — and a vulnerability scanner addresses only one of them.

If I’m not a DNS provider, cloud provider, or MSSP, does CIR 2024/2690 apply to me at all?
Not as a binding legal obligation. The CIR Annex legally binds only the ten digital-infrastructure and digital-service categories listed above. Everyone else answers to Article 21(2)(a) and 21(2)(e) directly, with the CIR Annex available as an optional best-practice reference.

Does the Cyber Exposure Score satisfy the Article 21(2)(a) risk analysis requirement by itself?
No. Treat it as one input into a broader, documented risk register that also records your organisation’s reviewed criticality judgments, risk appetite, and treatment decisions — a single quantified score is not, on its own, a policy.

Is Tenable OT Security a legal requirement for manufacturing or energy entities?
No, unless your specific facility also falls under a separate national critical-infrastructure designation. For most OT operators, the CIR Annex applies only by analogy as a benchmark, not as a binding requirement — the binding obligation remains Article 21(1)’s proportionate, all-hazards standard.

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.

Comparing platforms? Our companion piece on how Qualys VMDR and TruRisk/QDS scoring map to the same CIR 6.5 and 6.6 points works through the equivalent mapping using Qualys’s own scoring methodology.

Sources

• Commission Implementing Regulation (EU) 2024/2690, Annex — EUR-Lex
• CIR 2024-2690 Annex 1: Technical and methodological requirements — Advisera
• Implementing Acts / IT-NIS2 Mapping — OpenKRITIS
• NIS2 Directive Article 21 — nis-2-directive.com
• Solution Overview: Vulnerability Management Solutions for NIS2 Directive Alignment — Tenable
• Solution Overview: NIS2 Compliance with Tenable OT Security for Operational Environments — Tenable
• Tenable One Exposure Management Platform — Tenable
• Tenable Acquires OT Security Firm Indegy for $78 Million — SecurityWeek
• Tenable Lumin: Translating Vulnerability Management Into the Language of Business — Tenable
• Lumin Metrics — docs.tenable.com