Vulnerability and Exposure Management for Boards

Most organisations know about far more vulnerabilities than they can ever fix, and attackers only need the few that are exploitable and exposed. This briefing is for directors, chief executives, audit and risk committee members and CISOs who approve the budget and risk appetite for vulnerability and exposure management. It explains why software flaws are now a leading way into organisations, why a falling count of open findings can hide rising risk, how to test management's answers and what a credible first 90 days looks like. It stays at board level. The operating detail is in the Vulnerability Management Guide and the Exposure Management and CTEM Guide.

The risk in one paragraph

Every piece of software the organisation runs, buys or exposes to the internet will have flaws, and new ones are published every day. Scanners find thousands of them, most of which will never be used by an attacker. A small fraction are actively exploited, sit on systems reachable from the internet, or give access to credentials and sensitive data, and those are the ones that turn into breaches. Exposure management widens the view beyond software flaws to misconfigurations, unmanaged assets, exposed credentials and over-privileged identities, because attackers chain these together. The board's risk is not that vulnerabilities exist; it is that the organisation cannot tell which of them matter, does not know all the assets it owns, takes too long to fix the dangerous ones, or quietly accepts unsupported technology without anyone senior owning that decision. The board influences the outcome through three choices: the risk appetite expressed as remediation deadlines, the funding for replacing unsupported technology, and who has the authority to accept a risk instead of fixing it.

Why this is a board-level issue now

Exploitation now leads the breach statistics. Verizon's 2026 Data Breach Investigations Report states that 31% of breaches in its data set started with exploitation of software vulnerabilities, ahead of stolen passwords as the top way in. The report covers incidents from November 2024 to October 2025.
Governments publish what is being exploited. CISA's Known Exploited Vulnerabilities (KEV) catalogue lists flaws with reliable evidence of exploitation in the wild and a clear fix. Binding Operational Directive 22-01 requires US federal civilian agencies to remediate KEV entries by set deadlines, and CISA strongly encourages every other organisation to make immediate KEV remediation part of its plan. A board can ask a simple question: how many KEV entries are open on our estate today? See the CISA KEV Catalogue Guide.
Regulators and certifications set clocks. The UK Cyber Essentials scheme requires fixes for critical or high-risk vulnerabilities (vendor rated, CVSS v3 base score of 7 or above, or no severity given) within 14 days of release, and removal of unsupported software. Frameworks such as NIST CSF 2.0 (ID.RA-01, PR.PS-02) and ISO/IEC 27001:2022 Annex A 8.8 expect a managed process with evidence.
The UK NCSC places the decision not to patch with senior leaders. Its vulnerability management guidance says a decision not to update is a senior-level risk decision, taken within the wider risk management policy, and that time, budget and risks belong on the risk register. That is a direct statement of board accountability.
Patching no longer equals safety. Attackers increasingly steal credentials, keys and sessions through a flaw, and that access survives the patch. In the ToolShell SharePoint exploitation, stolen machine keys let attackers stay in after patching, and in CitrixBleed stolen session tokens bypassed MFA. Remediation has to include identity clean-up.

Vulnerability management and exposure management compared

Aspect	Traditional vulnerability management	Exposure management	What the board should expect
Scope	Known software flaws (CVEs) on scanned hosts	Flaws plus misconfigurations, unmanaged assets, exposed secrets, identity and cloud permission paths	A scope statement naming what is and is not covered
Prioritisation	Severity score (CVSS) alone	Exploitation evidence (KEV, EPSS), reachability, asset value and attack paths	A written prioritisation rule, not "fix all criticals"
Validation	Rarely; assumes the scanner is right	Tests whether the exposure can actually be exploited (penetration tests, attack path analysis, breach and attack simulation)	Evidence that top risks were confirmed and fixes verified
Ownership	Security team raises tickets	Asset and service owners accountable for fixes, security sets standards	Named owners with deadlines in their objectives
Measure of success	Number of open findings	Time to close exploitable exposure on critical services	Trend of risk-weighted metrics, not raw counts

The continuous threat exposure management (CTEM) model commonly describes five stages: scoping, discovery, prioritisation, validation and mobilisation. The value for the board is the last stage: getting the right owners to fix the right things quickly. See the Risk-Based Vulnerability Management Guide and the Attack Surface Management Guide.

How prioritisation should work

Severity scores describe how bad a flaw could be in theory, not how likely it is to be used. Three public signals change that picture and should feature in management's rules:

Signal	Published by	What it tells you	Typical use
KEV catalogue	CISA	Exploitation in the wild has been reliably observed and a fix exists	Fix immediately, with the shortest deadline in policy
EPSS	FIRST EPSS Special Interest Group	Probability (0 to 1) that a CVE will be exploited in the next 30 days, updated daily	Rank the large middle band of findings that are not yet in KEV
SSVC	CISA and Carnegie Mellon SEI	A decision tree using exploitation status, technical impact, automatability, mission prevalence and public well-being impact	Outcomes Track, Track*, Attend and Act map to remediation urgency
CVSS	FIRST	Technical severity of the flaw	Baseline input and certification thresholds, never the only rule
Internal context	The organisation	Internet exposure, business criticality, data held, credentials present	Raises or lowers urgency for the specific asset

See the EPSS Guide and the Vulnerability Prioritisation Guide.

Expressing risk appetite as deadlines

The clearest way for a board to state its appetite for vulnerability risk is a small set of remediation tiers that management then reports against. The table below is NHI Mgmt Group's illustrative starting point to be calibrated to the organisation's sector, regulation and capacity, not a standard.

Tier	Example trigger	Illustrative deadline	Who may accept a delay
Emergency	In KEV or SSVC "Act", and internet-facing or holding privileged credentials	Mitigate within days, ideally 72 hours	Executive risk owner only, short expiry
High	Critical or high severity (CVSS v3 7 or above) or high EPSS, on important systems	14 days, in line with Cyber Essentials	Service owner with CISO agreement
Standard	Other findings on supported systems	Next scheduled maintenance cycle	Service owner
Unsupported	Technology no longer receiving fixes	Funded replacement date	Board-visible exception

Five questions for the board to ask

How much of our estate do we actually see? Ask for the percentage of known assets (servers, endpoints, cloud accounts, internet-facing services, SaaS) covered by scanning or equivalent assessment, reconciled with an external attack surface scan. Unscanned assets are invisible risk.
How many actively exploited vulnerabilities are open today, and for how long? A credible answer gives the number of open KEV entries, the oldest one and its owner, separately for internet-facing systems.
What is our remediation deadline for each risk tier, and are we meeting it? Expect deadlines in days per tier, with the share of fixes made on time over the last quarter. See the Remediation SLAs and Vulnerability Exceptions Guide.
Who can accept a risk instead of fixing it, and how many exceptions are past their expiry? Exceptions should be time-limited, owned by a named executive and have compensating controls. Permanent exceptions are unfunded decisions.
When we patch an exploited flaw, how do we know the attacker did not get in first? Look for a compromise check after emergency patches, and rotation of credentials, keys, certificates and tokens held by the affected system.

Red flags in management answers

"We fix all criticals within 30 days": a severity-only rule spends effort on flaws nobody exploits while exploited medium-rated flaws wait.
"Our open vulnerability count is down 40%": raw counts fall when scan scope shrinks or low-risk items are closed. Ask what happened to exploitable exposure on critical services.
"The supplier handles patching": for SaaS this may be true; for appliances, managed services and outsourced IT the contract must state the deadlines and the evidence.
"That system is end of life but isolated": ask for the evidence of isolation, the exception owner and the funded replacement date.
"We have not been asked to test our fixes": unverified remediation is common; rescans and validation should close a finding, not a ticket status.

What good looks like

A complete inventory: assets, software and internet-facing services are known and owned (NIST CSF 2.0 ID.AM-01 and ID.AM-02; SP 800-53 CM-8).
Risk-based deadlines: exploited and internet-facing flaws fixed in days, the rest on a predictable cycle, with policy approved by the risk committee.
Owners who fix: service owners carry remediation targets; security sets standards, measures and escalates.
Patching as routine maintenance: NIST SP 800-40 Rev. 4 frames patching as preventive maintenance and a normal cost of running technology, which means planned maintenance windows and automated updates by default.
Lifecycle discipline: unsupported technology is replaced on a funded plan (SP 800-53 SA-22, CSF PR.PS-02) and any exception is visible to the board.
Identity in the loop: remediation of an exploited system includes rotating the service accounts, API keys and certificates it held. See the Exploited Vulnerability Breaches Lessons Guide.

Where to invest first

Priority	Investment	Why first	Typical owner
1	External attack surface discovery and asset inventory	You cannot fix what you cannot see; internet-facing assets are where exploitation lands	CISO with IT operations
2	Exploitation-led prioritisation (KEV, EPSS, asset context)	Cuts the fix list to what matters and frees engineering time	Vulnerability management lead
3	Automated patching for endpoints, servers and browsers	Removes the bulk of routine work so people focus on hard cases	IT operations
4	Replacement budget for unsupported technology	Unsupported systems stay vulnerable to every future flaw	CIO and CFO
5	Validation and post-patch compromise checks	Confirms fixes work and that attackers were not already in	Security operations and testing

Smaller organisations get most of the value from items 1, 3 and 4: an accurate inventory, automatic updates and removing unsupported software. Larger organisations with many teams and cloud estates need items 2 and 5 to keep thousands of findings manageable. See the Patch Management Guide.

Metrics to track

Metric	What it shows	Good direction
Assessment coverage of known assets (%)	How much of the estate is visible	Above 95%, rising
Open KEV entries, internet-facing and internal	Exposure to flaws attackers are using	Near zero on internet-facing systems
Median time to remediate by tier	Speed against risk appetite	Within policy deadline for each tier
Remediation on time (%)	Whether owners meet deadlines	Above 90% for the top tier
Active exceptions and overdue exceptions	Risk accepted instead of fixed	Few, all within expiry
Unsupported assets in production	Permanent exposure	Falling to a funded zero

Report these per business service, not just in total, so the board can see where risk concentrates. See the Vulnerability Metrics Report Template.

A 90-day plan

Days 1 to 30, see the estate: reconcile the asset inventory with an external attack surface scan; list every internet-facing service, its owner and its support status; report open KEV entries on those services.
Days 1 to 30, close the obvious: remediate or mitigate open KEV entries on internet-facing systems; where no patch exists, apply the supplier's mitigation and record it.
Days 31 to 60, set the rules: approve a remediation policy with risk-based deadlines, an exception process with named approvers and expiry dates, and the requirement to rotate credentials after an exploited flaw. See the Vulnerability Management Policy Template.
Days 31 to 60, assign owners: put remediation targets into the objectives of service owners, not only the security team.
Days 61 to 90, measure and fund: publish the first board metrics pack; present a costed replacement plan for unsupported technology; agree a validation programme for the most critical services.
Day 90, review: the risk committee reviews progress against the metrics, approves or rejects open exceptions and sets the next quarter's targets.

Common failure patterns

Counting instead of prioritising: monthly reports of total findings that never show whether exploited flaws on critical services are closed.
Scope blind spots: cloud accounts, SaaS, acquired companies and edge appliances outside the scanning programme. See the Vulnerability Management for Network Devices Guide.
Patch and forget: closing the flaw but leaving stolen credentials valid, as in the Ivanti Connect Secure exploitation where VPN credentials and service accounts were taken.
Exceptions that never expire: risk accepted once by a manager and never revisited.
Security owns the fix: security teams raising tickets that no service owner is measured on.

Framework mapping

Framework	Reference	Board relevance
NIST CSF 2.0	ID.AM-01, ID.AM-02, ID.RA-01, ID.RA-08, PR.PS-02	Inventory, vulnerability identification, disclosure handling, software lifecycle
NIST SP 800-53 Rev. 5	RA-5, SI-2, CM-8, SA-22, RA-7	Scanning, flaw remediation, inventory, unsupported components, risk response
CIS Controls v8.1	Control 7 Continuous Vulnerability Management	Process, remediation and automated patching safeguards
ISO/IEC 27001:2022	Annex A 8.8 Management of technical vulnerabilities	Certifiable requirement with audit evidence
MITRE ATT&CK	T1190 Exploit Public-Facing Application, T1133 External Remote Services, T1078 Valid Accounts	The entry routes vulnerability management is meant to close

Practitioner checklist

Reconcile the asset inventory with external attack surface discovery every month.
Ingest the KEV catalogue and EPSS scores into prioritisation, with internet exposure and asset criticality.
Publish remediation deadlines per tier and measure on-time remediation per owner.
Run a time-limited, executive-owned exception process with compensating controls.
Verify fixes by rescanning or testing before closing findings.
After any exploited flaw, run a compromise check and rotate credentials, keys, certificates and tokens on the affected system. See the Service Account Security Guide.
Hold a funded replacement plan for unsupported technology.
Report risk-weighted metrics per business service to the risk committee each quarter.

Standards and references

How NHI Mgmt Group can help

We provide independent board briefings and risk assessments on the identities that exploited systems hold and expose: service accounts, API keys, certificates and machine credentials that must be rotated when a flaw is exploited. Our NHI Foundation Level Training Course helps security and engineering teams govern these non-human identities. Contact us to arrange a briefing.

Vulnerability and Exposure Management Executive Briefing: Board Questions, Metrics and a 90-Day Plan