Compliance
How to build a vulnerability management program, step by step
The parts of a working vulnerability management program: scope, policy, scanning, prioritization, remediation, verification, exceptions and the metrics to report.
By Brandon Sooknanan, Founder, Varaxon Technologies · · 5 min read
A vulnerability management program is the ongoing process an organization uses to find, rank, fix and verify security weaknesses in its systems. Buying a scanner is the easy part. The program is everything around it: what gets scanned, how often, who fixes what and by when, what happens when a fix is not possible, and how anyone can tell the whole thing is working.
The steps below apply whether you run security for one company or deliver it as a service to many clients. Most security frameworks expect the same building blocks, so a program built this way also gives you the evidence auditors ask for.
1. Define scope and build the asset inventory
You cannot protect what you do not know about. Start with a list of what the program covers: servers, workstations, network devices, cloud workloads, web applications and internet-facing addresses. For each group, note the owner, how critical it is to the business and whether it can be reached from the internet.
The inventory does not need to be perfect on day one. Your first scans will find systems nobody listed, and adding them is part of the process. What matters is that the scope is written down, so a missing system is a visible gap rather than a silent one.
2. Write the policy
A short policy turns good intentions into rules. It should answer five questions:
- What is scanned, and how often? For example monthly authenticated internal scans and weekly external scans. See how often to run vulnerability scans.
- How are findings ranked? Name the signals you use, such as CISA KEV, EPSS, CVSS and asset criticality.
- How fast must each priority be fixed? A table of deadlines per priority. Our remediation SLA guide has a starting matrix.
- Who can accept a risk, and for how long? Acceptances should need a named approver and expire.
- What is reported, to whom, and how often? For example a monthly summary to management and a quarterly review with each client.
3. Scan consistently
Pick scanners that fit the assets: a network scanner such as Tenable Nessus or Greenbone OpenVAS for servers and devices, endpoint agents for laptops that are rarely on the office network, and a web application scanner for sites and APIs. Our comparison of vulnerability scanning tools covers the main options.
Consistency matters more than the brand. Use authenticated scans wherever you can, because they see missing patches and insecure settings that an unauthenticated scan cannot. Keep scan policies and credentials stable between cycles so results are comparable. Our guide to internal vs external vulnerability scans explains why you need both views.
4. Prioritize by risk
A typical scan returns far more High and Critical findings than anyone can fix in a month. Rank them so the first work is the work that matters most:
- CVEs on the CISA KEV catalog, which are known to be exploited, especially on internet-facing systems.
- Findings with a high EPSS probability of exploitation.
- The remaining findings by CVSS severity, raised for critical or exposed assets and lowered where a control already blocks the attack.
This is the core idea of risk-based vulnerability management.
5. Remediate, then verify
Turn findings into actions with an owner and a date, then put those actions into the system your team already works from, usually the ticketing or PSA tool. Group related findings so one patch cycle closes many rows. When the work is done, a rescan with the same settings confirms it. A ticket marked closed is a claim; a clean rescan is evidence. The vulnerability remediation guide covers the process in detail.
6. Handle exceptions in the open
Some findings cannot be fixed on time: legacy systems, vendor-controlled appliances, applications that break on the new version. Record each as a risk acceptance with the reason, any compensating control, the approver and an expiry date. Review them at every reporting cycle so an exception does not quietly become permanent.
7. Measure and report
Report on outcomes. A few numbers, tracked over time, tell you whether the program works:
| Metric | What it tells you |
|---|---|
| Mean time to remediate, by priority | How quickly the team closes what it finds |
| Findings past their deadline | Where the policy is being missed, and by whom |
| Known exploited CVEs open | Exposure to attacks that are happening now |
| Fixed, new and still open since the last scan | Progress between cycles |
| Open risk acceptances, and how many have expired | Whether exceptions are under control |
| Scan coverage against the inventory | Whether you are seeing everything in scope |
For clients and management, keep the report short and plain. Our guides on explaining findings to non-technical clients and the vulnerability assessment report template help with the format.
What the frameworks expect
- CIS Controls v8, Control 7 (Continuous Vulnerability Management): a documented process, regular automated scanning and risk-based remediation.
- ISO/IEC 27001:2022, Annex A control 8.8 (Management of technical vulnerabilities): obtain information about vulnerabilities, evaluate exposure and take appropriate measures.
- NIST Cybersecurity Framework 2.0: vulnerabilities in assets are identified, validated and recorded as part of risk assessment (ID.RA).
- PCI DSS v4: quarterly internal and external scans, rescans until high-risk findings are resolved, and critical patches within one month. See our PCI vulnerability scanning guide.
None of these sets a single right answer for tools or deadlines. They all expect a written process, evidence that you follow it, and decisions based on risk.
Keeping the program running
The hardest part of a program is the monthly grind of turning a raw scan export into a ranked list, chasing fixes and proving progress. We built Varaxon Scan Hub to take on that part. It reads exports from Nessus, Greenbone/OpenVAS, Qualys, Rapid7 and other scanners, ranks findings with CISA KEV, EPSS and CVSS, writes evidence-led reports, and compares each scan with the last to show what was fixed, what is new and what is still open. Every new account gets a 14-day free trial, no card needed: see how it works.
Common questions
What are the main stages of vulnerability management?
Asset discovery, scanning, prioritization, remediation, verification and reporting. The cycle repeats on a fixed schedule, with exceptions handled through documented risk acceptance.
Is vulnerability scanning the same as vulnerability management?
No. Scanning finds weaknesses. Vulnerability management is the whole process around the scan: ranking findings, assigning and tracking fixes, verifying them and reporting on progress.
How long does it take to set up a vulnerability management program?
A basic program, with a scope, a written policy, a first round of authenticated scans and a remediation plan, can be running within a few weeks. It then matures with each cycle as the inventory and processes improve.
Who should own the vulnerability management program?
One named person should own the process and the reporting, usually in security or IT. Fixes are owned by whoever controls each system, which is why the policy should name owners per asset group.
Turn your next scan export into a client-ready report.
Run a free pre-flight check