Blog
The only CTEM metrics leadership will read
Most exposure reporting is a count. Findings discovered, findings fixed, criticals open, a trend line that goes up when the scanner gets better and down when someone changes the severity threshold. Leadership has learned that these numbers do not mean anything, and they are right.
CTEM gives you the chance to report something different, because two of its five stages produce evidence that vulnerability management never did: validation tells you what is really exploitable, and mobilisation tells you whether it got fixed. The five metrics below are built on those two stages. They fit on one page.
Why vulnerability counts fail
A count of open vulnerabilities rises with discovery coverage. Add a cloud posture feed and the count doubles. The organisation is no safer or less safe than the day before, but the chart says things got worse. The reverse also happens: retire a scanner integration and the count drops.
A count does not distinguish reachable from unreachable. A CVSS 9.8 on a host with no route from any attacker position weighs the same as one on the VPN concentrator. Whatever the total is, the leadership team cannot tell what it implies.
Counts also hide the failure that matters. Verizon’s 2025 Data Breach Investigations Report found that exploitation of vulnerabilities was involved in about one in five breaches, and that of the edge-device vulnerabilities in the CISA KEV catalogue it tracked, only 54 percent were fully remediated, with a median of 32 days to do so (Verizon, 2025 DBIR). A count of “criticals closed this month” would have looked healthy in those organisations. A metric on time to close the ones that were actually exploitable would not.
The five metrics
| Metric | Definition | Direction you want |
|---|---|---|
| Validated exposures open | Exposures proven exploitable in your environment and not yet verified closed | Down, and small |
| Median time to close, by class | Days from validation to verified closure, split by exposure class | Down, per class |
| Critical processes with no validated attack path | Of the business processes ranked critical in scope, how many have no proven path to them | Up, towards all of them |
| Coverage of scope | Share of in-scope assets seen by at least two discovery sources and assessed this cycle | Up, towards 100 percent |
| Validation rate | Share of prioritised exposures that were tested rather than assumed | Up |
Validated exposures open
This is the headline number. It counts only exposures that passed validation: someone or something exploited them, safely, in your environment. It excludes the scanner’s opinion.
It is small by construction, usually tens rather than thousands, which is what makes it readable. When it goes up, either validation coverage widened or something new arrived. Say which.
The trap is letting it drift back into a count. If the validation stage weakens, unvalidated findings creep in and the number stops meaning anything. Report validation rate next to it so the reader can tell.
Median time to close, by class
Time from validation to verified closure, where verified means re-tested, not “ticket marked done”. Split by class because the classes have different owners and different fixes: an exposed service on the perimeter, an over-privileged identity, a missing patch on a server, a cloud misconfiguration.
Use the median. Averages get dragged by the one item stuck in a change freeze for a year. Show the slowest class separately and name why it is slow. Often the reason is that the owning team was never told they were the owner.
Critical processes with no validated attack path
This is the metric that makes the business owner look up. Scoping produced a ranked list of critical processes. Attack path analysis and validation produced evidence about which of them an attacker could reach. The metric is the count of processes for which no validated path currently exists, out of the total.
“Three of seven” is a sentence a board member understands, and “three of seven, up from one of seven last quarter” is a sentence that justifies budget. It also keeps the program honest about scope: a process that has not been assessed does not count as protected.
Coverage of scope
The percentage of in-scope assets that were seen by at least two discovery sources and assessed in the current cycle. It is the metric that stops the other four from being flattered by ignorance.
Report it alongside the reconciliation gap: assets seen by one source but not another. A program that shows 98 percent coverage with an unexplained gap of four hundred hosts is reporting on the estate it can see, not the estate it has.
Validation rate
Of the exposures prioritised this cycle, what share were validated by test rather than accepted on severity. Gartner’s March 2025 market guide on adversarial exposure validation estimates that 40 percent of organisations will have formal validation initiatives by 2027, which is a polite way of saying most do not yet. Your validation rate is how you show which side of that line you are on.
Early programs validate the top ten and nothing else, so the rate is low. That is fine. The trend matters, and the number lets you explain why the headline metric is small.
How to present them
One page. Five numbers, each with this quarter, last quarter, and one sentence on what moved and why. No dashboard screenshots, no severity pie chart, no list of CVEs.
Lead with critical processes with no validated attack path, because it is expressed in the business’s own terms. Follow with validated exposures open and median time to close, because they show the program doing work. Close with coverage and validation rate, because they show the first three are trustworthy.
State the scope at the top of the page. “These numbers cover the external attack surface and the payments platform” is what makes “three of seven” meaningful and stops the reader assuming it covers everything.
Bring one story. The exposure that validation showed was not exploitable and was downgraded, saving a weekend of patching. The one that was worse than the scanner said. The class that got faster because a team finally had an owner named. One story, a paragraph long, next to the number it explains.
What not to add
Resist the request for a single risk score. A number from 0 to 1000 that goes up and down is a count with extra steps, and nobody can say what a fall of forty points bought. If a platform produces one, it can live on the operational dashboard.
Resist mean time to detect and respond. They are incident metrics, and they belong to a different report. The exception is the detection result from validation: the share of validated exposures where nothing fired. That belongs here, as a footnote to validation rate, because it is the strongest argument you will have for detection engineering budget.
Resist adding a sixth metric each quarter. The page is one page because leadership will read one page.
Next
If your program cannot yet produce these numbers, the 90-day plan ends with a first version of exactly this report. The maturity model shows which level each metric becomes available at, and the assessment will tell you where you are now.