Building a vulnerability management program from scratch: five parts in 90 days

A vulnerability management program built from scratch has five parts stood up over 90 days: an asset inventory with a named owner per internet-facing host, authenticated scan coverage at 90 percent or better, a signed one-page triage rule built on KEV, EPSS and CVSS, a monthly queue sized to last quarter's real closures, and a rescan rule that decides when a ticket closes.

Why the build order matters more than the scanner

The CVE program published 48,185 vulnerabilities in 2025, a 20.6 percent jump over 2024 and roughly 131 new entries every day. Against that flood, Cyentia and FIRST's exploitation study keeps landing on the same figure: somewhere between 5 and 6 percent of all CVEs are ever exploited in the wild. A vulnerability management program is the machinery that separates those two numbers for your own estate.

The common failure is sequencing. A team buys a scanner, points it at every subnet it knows about, and wakes up with a backlog nobody owns. The scanner becomes the program, and the program inherits every blind spot the scanner has.

Take one host as the running example: a VPN concentrator a contractor racked in 2019. It has no endpoint agent, no ticket, no listed owner, and it answers on port 443 to the whole internet. Each of the five parts below has to account for that box, and the order they are built in decides whether it is found in week one or after an incident.

Parts one and two: an inventory the scanner has to agree with

Start with what you own, and only then with what a scanner can reach. Those are two different lists, and the gap between them is where the 2019 concentrator lives. The 2025 Verizon breach report put exploitation at 20 percent of initial access, ahead of phishing, and 22 percent of those exploits landed on edge devices such as firewalls and VPN gateways. Edge devices are exactly the assets that fall out of spreadsheets.

Three feeds you already run will build the inventory: DHCP leases plus the cloud provider's instance list for what is alive, the identity directory for who is responsible, and the firewall's external rule set for what is reachable from outside. Merge them into a table with four columns: asset, owner, internet-facing, business tier. The feeds will contradict each other, and reconciling each contradiction is the actual work. The exit condition for part one is a named owner on every internet-facing row.

Part two gives the scanner credentials or an agent on every host in that table. Unauthenticated scans read a version banner and guess, and backported fixes break the guess in both directions: a distribution that ships an old banner with new fixes gets flagged for problems it closed a year ago, while a host with a lying banner gets waved through. Measure coverage as one ratio, hosts scanned with credentials over hosts in the inventory. Below 90 percent overall, and 100 percent on the internet-facing tier, the backlog describes the scanner's reach rather than your exposure. Publish that ratio next to the backlog count every week, because the ratio is what tells a reader whether the count is worth anything.

Part three: a triage rule that fits on one signed page

The first full authenticated scan will return somewhere between ten and a hundred findings per host. Nobody patches that list. It exists to feed a written rule with three filters, applied in order, each one discarding most of what remains.

The first filter is CISA's Known Exploited Vulnerabilities catalog. In August 2026 it held 1,665 entries across 276 vendors, and CISA only adds an entry when there is reliable evidence of active exploitation, an assigned CVE, and clear remediation guidance. That makes each entry a fact about attacker behaviour rather than a forecast. Any KEV finding on an internet-facing asset goes to the top with a 21-day due date, the clock BOD 22–01 set for federal agencies.

The second filter is EPSS, FIRST's daily probability that a CVE will be exploited in the next 30 days. A score above 0.1 on an internet-facing or tier-one asset earns a 30-day due date. Because scores move every day, the rule reads the score on the day the queue is built and does not chase it afterwards.

The third filter is CVSS, and it ranks only what the first two left behind: critical and high on tier-one assets get 90 days, everything else joins the normal patch cycle. Write the thresholds down and have the CIO sign the page. The signature settles the recurring argument with auditors, since a 9.8 with no exploit and no exposure is a property of the CVE, and the rule spells out why it sits behind a 7.2 that CISA has already seen used. For the 2019 concentrator, the rule is what turns an anonymous edge box into a dated ticket the moment its firmware shows up in KEV.

Part four: a monthly queue sized to last quarter's closures

Capacity belongs to the teams that deploy patches, and the honest way to measure it is to count what they finished rather than what they promised. Pull the last 90 days of tickets, count the patches that were deployed and rescanned clean, and divide by three. If the answer is 40 fix actions, the monthly queue holds 40, filled from the top of the triage output, with the remainder visible in the backlog under a date.

The alternative has been measured. Flashpoint's read of the 2025 DBIR found the median time to fully remediate a KEV entry had risen to 43 days, and only 26 percent were fully fixed within the year. Queues sized to scanner output stop being read.

Each queue entry is a fix action, one patch or one configuration change, assigned to the asset owner from part one, with the CVEs it closes attached and the rescan date written in on the day it is created. Ship the queue on the same day every month. The only thing that breaks the cycle is a new KEV entry that matches one of your assets, which goes in immediately.

Part five: nothing closes without a rescan

NIST SP 800–40r4 defines enterprise patch management with five verbs: identify, prioritize, acquire, install, verify. A deployment record proves the fourth verb. Only a rescan proves the fifth. Hosts that installed a kernel update and never rebooted still report vulnerable, and they still are. Failed installs on Windows update rings look identical to successes in the deployment console.

That gap is where programs publish numbers they cannot defend. A compliance dashboard reading 97 percent is quoting the deployment tool; the scanner reading the same hosts will say less, and the lower figure is the one both the auditor and the attacker use. So the closing rule is mechanical: a ticket closes when the part-two scanner rescans the host and the finding is gone. Screenshots close nothing. Schedule the rescan within 48 hours of every deployment window and track two ratios from it: fix actions that verified clean on the first pass, and fix actions that needed a reboot or a second attempt. The first is your real remediation rate. The second is the reboot debt to negotiate with the server team next quarter.

After 90 days the program owns five artifacts, none of them a tool: an inventory with an owner on every internet-facing host, a coverage ratio at 90 percent or better, a signed triage page, a queue with a measured capacity, and a rescan rule that decides when a ticket closes. The 2019 concentrator now has an owner, a credentialed scan, a KEV-driven due date, a slot in the queue, and a rescan that proves the fix landed. Report one number to leadership each month: known exploited vulnerabilities on internet-facing assets, open past their due date. Start by building the inventory this week and let the target for that number be zero.

This article expands on our video "How do I build a vulnerability management program from scratch?" — watch it here.

Source: NIST SP 800–40r4 Guide to Enterprise Patch Management Planning.