The 7 Most Common Mistakes When Setting Up a Vulnerability Management Program

Buying a scanner takes an afternoon. Building a program that actually lowers risk takes months, and the failures are rarely technical. They are small early decisions: scanning before anyone knows what the systems do, ranking findings by a score instead of by exposure, handing a long report to a team who can't act on it. Here are the seven mistakes that come up most, and the fix for each.

1. Scanning without asset context

A scanner reports that 10.4.2.19 is missing three patches. Useful? Only if you know whether that host is an internet-facing payment API or a lab machine somebody powered on in 2019. Without that context every finding looks equally urgent, triage turns into an argument, and the loudest voice wins.

Build the inventory first. For each asset, capture an owner, the environment, whether it is reachable from the internet, and roughly what data it holds. Four columns in a spreadsheet beat nothing. Then reconcile the two lists — any host that shows up in scan results but not in the inventory is a finding in itself, because something exists that nobody is accountable for.

Expect drift, and plan for it. A hostname like build-07 can point to three different machines in a year, and an asset that was internal-only in January can be published through a load balancer in June. Reconcile monthly at minimum, and make the inventory a by-product of how work already happens — a field in the change ticket, a tag in the cloud account — rather than a spreadsheet somebody maintains by hand until the week they stop.

2. Treating the CVSS score as the verdict

Scanner severity is a starting point, not a decision. A 9.8 in an isolated lab that requires local access is not the same Tuesday as a 6.5 on a VPN concentrator with a public exploit and thousands of login attempts a day. Sort strictly by score and you will patch the easy, irrelevant things while an exposed, exploitable service waits its turn.

Keep prioritization simple enough that people actually use it. Two axes work well: intrinsic severity, and exposure plus exploitability. Anything severe and internet-facing goes to the top of the queue. The rest waits for a maintenance window — as long as that window is a real date, not a wish.

If you need a tie-breaker, use evidence that says someone is actually attacking the flaw: a listing in a known-exploited-vulnerability catalog, a public proof of concept, or an exploit-prediction score. A vulnerability with a working exploit in the wild outranks a theoretical one with a higher number, every time.

3. No remediation SLAs, or SLAs nobody enforces

Deadlines are what turn a report into a program. Without them, critical findings sit in a backlog while teams argue about priorities nobody wrote down. Defining SLAs and never measuring against them is the same mistake with extra steps.

Start with defaults and tune later:

• Critical, internet-facing, or known to be exploited: mitigate within 48 hours
• Critical, internal only: 15 days
• High: 30 days
• Medium: 90 days
• Low: next scheduled maintenance, or accept with a documented reason

Mitigate is not the same as patch. A WAF rule, disabling the vulnerable service, or segmenting the host can buy time while the real fix is scheduled, and that counts. Every exception needs a named owner and an expiry date. An exception without an end date is an unfixed vulnerability with paperwork.

Be explicit about when the clock starts. Otherwise a finding sits unnoticed in a queue for two weeks and everyone agrees it was "opened" only yesterday. Write down that the timer begins at validation, and publish a one-page monthly report showing what is past SLA. Visibility alone fixes a surprising amount.

4. Dumping raw scanner output on the people who fix it

Nobody reads a 400-page PDF. If the export contains duplicates, findings for hosts the team doesn't own, and a few false positives, the reasonable response is to ignore all of it — and that is what happens.

Do the translation before assigning. Deduplicate by asset and vulnerability, group by the team that owns the asset, and open one ticket per host or per fix rather than forty. Include the evidence someone needs to verify the issue in five minutes: hostname, port, service version, and the request that demonstrates it. If you cannot reproduce it, say so, and validate before blaming anyone.

A good ticket reads like a bug report, not a scan result. "OpenSSL 1.1.1k on payments-api-02:443 — vulnerable to CVE-XXXX-YYYY, reproduce with this command, assigned to the payments team, due in 15 days" gets fixed. "10.4.2.19: multiple vulnerabilities (see attached CSV)" does not.

5. No owner, no closed loop

Findings that belong to "the security team" belong to nobody. Security can find, prioritize, and track. It usually cannot log into a build server and apply the patch. The asset owner can. If that split is unclear, tickets bounce until they age out.

Write it down in three lines: the vulnerability management function runs the process and reports; asset owners remediate or request an exception; a small group with authority resolves disputes and approves risk acceptance. Then meet weekly for thirty minutes on the top new findings only. A short call about ten items gets acted on. A quarterly meeting about four thousand does not.

6. Confusing scan volume with coverage

Scanning more often feels like progress; scan quality matters more. Unauthenticated scans miss most software-level issues, so a weekly unauthenticated scan can be worth less than a monthly authenticated one. Cloud instances that live for two hours never appear in a nightly scan. Container images get rebuilt from the same base image you patched last month.

Fix coverage before you fix frequency. Authenticate the scans, or you are cataloguing open ports and calling it a vulnerability program. Cover cloud accounts through their APIs rather than through the network. Put the scanner in the build pipeline so images are checked before they ship, not after they run. And keep a standing check for the assets that no scan will ever reach: SaaS tenants, third-party portals, the forgotten on-premise appliance.

The test is simple. Ask how many assets you own, then how many the last scan actually saw. If the gap is large or unknown, adding another scan day changes nothing.

7. Measuring program health by the number of findings

A dashboard that only shows a total count is a demoralizing number that moves in the wrong direction as you improve: better scanning finds more, so the graph goes up and everyone assumes things got worse. Nobody fixes 40,000 findings, so nobody tries.

Track a small set of measures that describe movement, not volume:

• Median and 90th-percentile time to remediate, by severity
• Percentage of critical findings inside SLA, reported weekly
• Count of expired exceptions, which should be near zero
• Share of in-scope assets covered by an authenticated scan
• Repeat findings on the same asset, which point at process, not code

Revenue-facing exposure reduction is the goal. "We closed 3,000 tickets" is a busy quarter, not necessarily a safer one.

A simple 90-day rollout order

Most programs fail by attempting everything at once. Sequence it instead:

1. Weeks 1–2: build the inventory and confirm owners for the top 20% of assets by business importance.
2. Weeks 3–4: get authenticated scanning working on that group, even if the rest stays unauthenticated for now.
3. Weeks 5–6: agree SLAs with the teams who will live under them, and get them signed off by someone senior.
4. Weeks 7–8: automate ticketing and the priority rules, so triage is a policy rather than a daily debate.
5. Weeks 9–12: run the weekly thirty-minute triage call, publish the first SLA report, and start retiring expired exceptions.

What good looks like after six months

You should be able to answer three questions without preparing: what is our most exposed critical finding right now, who owns it, and when it will be fixed. If any of those require a meeting, the program is still a tool.

A vulnerability management program is a set of agreements about ownership, timing, and evidence — the scanner is only the thing that starts the conversation.

None of the seven mistakes above are exotic. They are all versions of the same shortcut: skipping the boring decisions to get to the results. Make those decisions early, write them down, and the scanning will finally start to mean something.

Photo: Ketut Subiyanto / Pexels