A patch program that reports “96 percent patched” every month can still be sitting on the exact vulnerability that gets the company breached. The problem is not the number itself, it is what the number hides. A single aggregate percentage treats a forgotten internet-facing jump box the same as a rarely used internal print server, and it treats a critical remote code execution flaw the same as a low-severity information disclosure. If you own patch reporting, whether you write it or defend it in a steering committee, the metrics below are built to survive that scrutiny.
Why “percent patched” hides the systems that actually matter
Percent patched is a ratio: patched systems divided by total systems in scope. Ratios compress information, and compression always throws something away. Consider a fleet of 4,000 endpoints at 96 percent patched. That sounds close to done, but it leaves 160 systems open. If those 160 include three internet-facing VPN concentrators with a known exploited vulnerability, the ratio is telling you the program is healthy while the actual risk exposure is severe.
The deeper issue is denominator selection. Most patch dashboards pool workstations, servers, network appliances and cloud instances into one count, then divide by the whole fleet. Workstations patch fast because reboot windows are frequent and low-risk; servers patch slowly because maintenance windows are scarce and change control is heavier. Blending the two produces a number that mostly reflects workstation volume, not the exposure that determines whether an attacker gets in.
A second failure mode is treating “patched” as binary when severity is continuous. A system missing one low-severity patch and a system missing a critical, internet-reachable one both count as “not patched” in the denominator, and both count the same in the percentage. For a CISO reporting up, or an engineer defending a backlog, the fix is to stop reporting a single ratio and start reporting a small set of metrics that each answer a different risk question.
Metrics worth reporting: coverage, age of oldest open patch, SLA attainment, recurrence
Four metrics, tracked together, give a much harder picture to game than one blended percentage.
- Coverage: the percentage of assets in inventory that were scanned or agent-checked in the last patch cycle, broken out by asset tier. This is not “percent patched,” it is “percent visible.” A program cannot manage what it cannot see, and coverage gaps are usually where the real exposure lives. If coverage on server-tier assets sits below 95 percent while workstation coverage is at 99 percent, that gap is the story, not the aggregate.
- Age of the oldest open critical patch: not an average, a maximum. Averages hide a single ancient vulnerability inside a sea of freshly discovered ones. Report the age in days of the single oldest unremediated critical or high finding on each exposure tier. A board member does not need to understand CVSS to understand a finding that has been open for over 200 days on an internet-facing host.
- SLA attainment: the percentage of vulnerabilities closed within your policy window, measured per severity and per exposure tier, not blended. If your policy is 15 days for internet-facing critical findings and 45 days for internal critical findings, report attainment against each window separately. A program hitting 90 percent on internal SLAs but 40 percent on internet-facing SLAs has an entirely different risk profile than the reverse, and a single blended attainment number erases that difference.
- Recurrence rate: the percentage of findings that were marked remediated and then reappeared on a later scan of the same asset with the same CVE or plugin ID. Recurrence is the strongest signal of whether the program’s “done” actually means done. A recurrence rate above roughly 5 percent usually points to golden image drift, incomplete patch deployment across a device group, or a configuration management tool re-pushing an old package version.
None of these four requires new tooling if your vulnerability data already carries first-seen date, last-seen date, asset tags and remediation timestamps. What it requires is querying by cohort instead of by the whole fleet.
Segmenting by exposure: internet-facing versus internal assets
Exposure segmentation is one of the most effective changes most patch programs can make to their reporting, and it costs nothing beyond tagging assets correctly. Split every metric above into at least two tiers: internet-facing (anything reachable from outside the corporate network, including cloud instances with public IPs and anything behind a reverse proxy that terminates external traffic) and internal-only.
The reason this matters is that exploitability, not just severity, drives real-world risk. A critical vulnerability on an isolated internal lab machine with no path to production is a lower priority than a medium-severity vulnerability on a host that sits directly on the internet and appears in CISA’s Known Exploited Vulnerabilities catalog. Network reachability data, when available, refines this further by confirming which internal assets are actually reachable from a compromised entry point rather than assuming flat network access.
Set different SLA windows per tier and report attainment against each window. A reasonable starting point many programs use: internet-facing critical and any finding on the KEV catalog gets a 72-hour to 7-day window, internet-facing high gets 15 days, internal critical gets 30 days, internal high gets 45 to 60 days. The exact numbers should match your risk appetite and any regulatory obligation (PCI DSS requires patching critical vulnerabilities within 30 days on in-scope systems, for example), but the principle holds regardless of the numbers you pick: internet-facing assets earn a materially tighter clock than internal ones, and your reporting should show both clocks side by side, not one blended figure.
Leading versus lagging indicators for a patch program
Percent patched and SLA attainment are lagging indicators: they tell you how the program performed over a period that has already closed. They are necessary for compliance evidence, but they cannot tell you whether next quarter will be better or worse. Leading indicators fill that gap.
Three leading indicators worth tracking alongside the lagging set:
- Backlog trend: the net change in open critical and high findings week over week. If new critical findings are arriving faster than they are being closed, SLA attainment will degrade in the following reporting period even if it looks fine today. Plot the trend line, not just the current backlog size.
- Time from patch availability to deployment window scheduled: how many days pass between a vendor releasing a patch and that patch being scheduled into a maintenance window, independent of whether the window has happened yet. A growing gap here predicts a growing SLA problem before it shows up in attainment numbers.
- Scan and agent freshness: the percentage of in-scope assets with a scan or agent check-in inside the last 7 days. This is a leading indicator for coverage. If freshness drops, your next coverage and SLA numbers will look artificially good simply because stale assets stop generating new findings, not because they got safer.
A program that only reports lagging indicators is always explaining the past. Pairing each lagging metric with its leading counterpart lets a security engineer flag a problem to leadership before it shows up as a missed SLA, which is a materially different conversation to have.
Building a one-page executive slide from the same data
Executives do not need twelve charts. One slide, built from the same underlying data as the technical dashboard, does the job if it is structured correctly. A layout that works well in practice:
| Row | Content | Why it belongs |
|---|---|---|
| 1 | Open critical findings on internet-facing assets, aged in buckets (0-15, 16-30, 31-60, 61+ days), shown as a trend over the last 6 reporting periods | Shows direction, not a snapshot; the 61+ bucket is the number that should worry a board |
| 2 | SLA attainment by tier, current period versus prior period | Compliance evidence and trend in one row |
| 3 | Recurrence rate, current period versus prior period | Answers “is remediation actually sticking” |
| 4 | Coverage percentage by asset tier | Answers “how much of the fleet is this data even describing” |
The discipline that makes this slide credible is refusing to let it diverge from the data the engineering team works from day to day. If the executive slide is built from a separate, manually curated spreadsheet, the two will drift apart within a quarter, and the first time someone notices the discrepancy, every number in the deck loses credibility. Feeding the same query results into both the technical dashboard and the one-page summary through a shared reporting layer, rather than a hand-built export, is what keeps the two aligned as the underlying data changes daily.
Avoiding metric gaming, such as counting reboot-pending devices as done
Every metric in this article can be gamed, usually not out of bad faith but because the tooling’s definition of “remediated” is looser than the definition a CISO actually needs. The most common gaps:
- Reboot-pending counted as patched: a patch management tool frequently marks a system as “installed” the moment the package is applied, even though a required reboot has not happened and the vulnerable binary is still loaded in memory. If your remediated count includes reboot-pending devices, add a check for pending-reboot state before crediting the fix, or hold the SLA clock open until the next successful reboot is confirmed.
- Remediation action logged, not verified: a ticket marked “resolved” in the ITSM tool is not the same as the vulnerability being gone. The only reliable confirmation is a fresh scan or authenticated check that no longer detects the finding on that asset. Platforms that automate this phase, such as SITEY, re-test the specific finding after a patch or configuration change is applied rather than trusting the closed ticket or the patch tool’s exit code, which is the difference between a metric that reflects intent and one that reflects outcome.
- SLA clock stopped early: some programs stop the SLA timer the moment a change ticket is submitted, not when the fix is confirmed. This flatters attainment numbers while leaving the actual exposure window open for however long change approval and deployment take. Stop the clock at verified closure, full stop.
- Scan scope quietly shrinking: an asset that stops reporting, whether from a decommissioned agent, a firewall rule change, or a credential expiring on an authenticated scan, drops out of the denominator entirely. A shrinking denominator can make percent-based metrics improve even as real coverage gets worse. Track the raw count of in-scope assets alongside every percentage, not just the percentage itself.
The common thread is that gaming a metric usually means declaring victory at the point of action rather than the point of verified effect. Structuring remediation workflows around patch management that tracks deployment status separately from confirmed closure, and routing every fix through retest and closure before it counts against a metric, closes most of these gaps without adding manual review overhead. When the underlying vulnerability records already carry exposure tags, SLA timestamps and verification status, mapping the same data into audit-ready output for a framework like PCI DSS or ISO 27001 through compliance mapping becomes a query against existing fields rather than a separate reporting project run once a quarter.
None of these metrics require exotic tooling. They require agreeing, in writing, on what “remediated” means before the first report goes out, and then holding every dashboard, ticket and executive slide to that same definition.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.