How to Build a Vulnerability Management Program

Almost every organization we assess already has vulnerability data. Many have a great deal of it: a scanner running on schedule, a dashboard, a number in the tens of thousands. What they do not have is a process that converts that data into fewer exposed systems, and the gap between those two things is where the discipline actually lives.

This is a description of the process that works, in the order it has to happen.

Stage 1: coverage, before anything else

The most important number in your program is not how many findings you have. It is what fraction of your estate produced them. An organization scanning 60 percent of its assets and triaging brilliantly is in worse shape than one scanning 95 percent and triaging crudely, because the unscanned 40 percent is not low risk, it is unmeasured risk.

So start by reconciling scanner coverage against reality: cloud accounts across every region someone once experimented in, container images, endpoints, network ranges, SaaS, and code dependencies. In most first engagements the coverage gap is the single largest finding, and it is invariably more valuable than any refinement to how the existing findings are ranked.

Stage 2: prioritize on exploitability, not severity alone

CVSS was designed to describe a vulnerability's characteristics, not to order your work queue, and using it that way produces a list where a 9.8 on an isolated test box outranks a 7.5 on the internet-facing system holding customer records. Risk-based vulnerability management means adding the context CVSS deliberately excludes.

Four filters do most of the work. Deduplicate: the same CVE across three hundred hosts is one decision, not three hundred tickets. Establish reachability: internet-facing, or reachable from a realistic foothold. Check exploit availability, because a vulnerability with a weaponized public exploit is a different proposition from a theoretical one. And check whether a compensating control already breaks the path, which is where penetration test results earn their keep.

The illustrative numbers above matter less than the shape. Whatever your starting count, the output has to be a queue a team can clear in a sprint.

Stage 3: put remediation where the work already happens

Findings that live in a security dashboard get fixed at the rate at which engineers visit security dashboards, which is approximately never. Integrate into the tracker they already use, with an owner, a due date derived from severity, and enough context to act without scheduling a meeting.

The credibility point is worth being blunt about. Engineering will work a queue that is short, accurate, and prioritized. Send them ten thousand unvalidated items once and you will not get their attention back for a year. Sending less, more accurately, is how you buy the throughput to eventually send more.

Stage 4: SLAs you can actually meet

Set remediation targets to what your organization can genuinely deliver, then tighten them over time. An SLA missed every month teaches everyone that the SLA is decorative, which is worse than a longer target that holds. Define the emergency path separately, because actively exploited issues on exposed systems need hours or days rather than a place in the normal cycle.

What matters more than the specific numbers is that a missed SLA triggers something: an escalation, a named conversation, a decision to accept the risk formally. If missing it triggers nothing, you do not have an SLA, you have an aspiration in a spreadsheet.

Stage 5: govern the things you will not fix

End-of-life software, an appliance whose vendor has moved on, a system that breaks when touched. These are normal, and pretending they will be patched is how tickets stay open for three years and auditors write findings.

A functioning exception has four parts: a named owner senior enough to accept the risk on the organization's behalf, a documented compensating control, an expiry date, and a review cadence. Auditors do not object to accepted risk. They object to risk nobody decided to accept.

Stage 6: measure the program, not the backlog

Report mean time to remediate by severity against SLA, the age of the oldest open critical and high findings, coverage as a percentage of known assets, recurrence rate, and SLA adherence by owning team. Lead with those.

Do not lead with total open findings. That number moves whenever someone tunes the scanner, it invites a question you cannot answer well, and it gets worse precisely when you improve coverage, which punishes the right behaviour. Recurrence is the most diagnostic metric of the six: the same finding class returning means a process defect in code review or provisioning, and no amount of remediation effort fixes a process defect.

Where programs actually fail

Three failure modes, in order of frequency. Triage without coverage, which optimizes the visible portion of the estate. Prioritization by severity alone, which produces a queue nobody trusts and which quietly deprioritizes the exposed medium-severity issue that a real attacker would use first. And no exception process, so unfixable things stay permanently open, the backlog loses meaning, and everyone learns to ignore the aging report.

A fourth, less common but more expensive: a program that measures itself on findings closed and never validates whether the closures reduced real exposure. That is what penetration testing feedback prevents, and it is covered in continuous vs annual penetration testing.

Where BD Emerson fits

We design and operate these programs through our vulnerability management practice, and we take no license margin on tooling, so our view on whether your current scanner is adequate is not a sales motion. Because we also run continuous penetration testing and red teaming, your prioritization gets validated against what is genuinely exploitable rather than against a generic score. The evidence the program produces also serves SOC 2 and ISO 27001 requirements without a separate exercise.