What should boards ask instead of how many CVEs are open?

Why boards should stop asking for a CVE count

A raw vulnerability count says little about whether an organisation can actually be reached, moved through, or harmed. A board-level question should focus on exposed attack paths, the systems they can reach, and the likely business impact if those paths are used. That shifts reporting from backlog volume to decision-grade risk. For threat context, the exploitability and reachability of a weakness matter far more than the number attached to it, which is why a live NIST National Vulnerability Database record is only one input to governance, not the governance answer itself.

That approach also forces teams to separate theoretical weakness from operational exposure. A critical CVE on an isolated asset is not the same board problem as a moderate issue on a path that reaches finance, identity, production cloud, or an AI gateway. If the organisation cannot show whether an attack path is reachable today, the board is managing uncertainty rather than risk.

What boards should ask about attack paths and business loss

The better board question is not “how many vulnerabilities are open?” but “which paths reach our most critical services, and which of those paths are live right now?” That question surfaces the junctions that matter: internet-facing entry points, misconfigurations, overprivileged access, stale credentials, weak segmentation, and cross-system dependencies. It also creates room to discuss whether a path depends on human accounts, service accounts, or AI-connected systems, because the route into the business often matters more than the headline weakness.

Boards should also ask what loss each path could create in business terms. That means linking a technical path to outage duration, regulatory exposure, fraud risk, customer harm, or loss of decision integrity. Where a vulnerability or exposed credential enables lateral movement or privilege escalation, the board should hear the likely blast radius, not a score alone. The strongest questions are scenario-based: if this path is used, what fails first, what data or service is exposed, and how quickly would we notice?

Scenario framing also helps prioritise remediation when multiple weaknesses compete for attention. A lower-severity issue can outrank a higher-severity one if it sits on a path to a crown-jewel system or can be combined with authentication, configuration, or token abuse. The board does not need every technical detail, but it does need to know which combinations of control failure create the highest-consequence routes.

How to translate vulnerability data into board decisions

Useful board reporting should compress technical detail into a few decision points: reachability, exploitability, material business impact, and time to reduce exposure. The board can then ask whether the organisation is shortening the window during which the path is usable, not just trimming a queue of open findings. That makes reporting useful for funding, risk acceptance, and escalation.

When the issue involves exposure through software supply chain or identity material, governance should ask who owns the remediation path and what compensating controls exist until it is closed. For vulnerability intelligence and exploit tracking, the CVE Program remains the canonical identifier source, but the board question should still be whether the weakness is reachable in the current environment. When the path is already exploitable, the management response should be driven by business-criticality and exposure window, not by report volume.

Boards that want an operationally useful view should ask for trend lines on reachable critical paths, not just remediation counts. That shows whether the attack surface to crown-jewel services is shrinking, whether compensating controls are working, and whether any path has become newly reachable after a cloud, identity, or application change. It is a more stable measure of risk reduction than monthly CVE closure totals.

Risk and Threat Considerations

Open CVE counts can hide the real danger: an attacker usually needs a reachable path, not the largest list. When organisations track volume instead of exposure, they can miss the few weaknesses that materially change breach likelihood, especially where identity, configuration, or AI integrations expand the route into critical systems.

Failure mechanism: A weakness becomes board-relevant when it is reachable today, can be chained into privilege gain or lateral movement, and touches a system whose compromise changes the business outcome.

Impact: The organisation may fund the wrong fixes, underestimate blast radius, and leave a small number of high-value attack paths open long enough for exploitation to become a material incident.

Practitioner Guidance

What to prioritise: Ask for a short list of the top reachable paths to crown-jewel systems, each tied to business impact and time-to-exposure reduction. If a report cannot name the path, the control gap, and the loss scenario together, it is not yet board-grade.

What to verify: Require evidence that the path is currently reachable in the live environment, not only present in a scanner or backlog. Reachability, privilege level, and compensating controls should be validated before the board accepts a risk treatment decision.

Practitioner takeaway: The board’s job is to decide which attack paths are acceptable, not to count technical findings, so reporting should be organised around exposure, exploitability, and business consequence.

Related resources from NHI Mgmt Group

• What should boards ask instead of provisioning speed and certification counts?
• How should boards measure identity risk instead of identity activity?
• What should AI review boards ask before approving identity AI?
• What breaks when API authorization is spread across many services instead of one edge layer?