A vulnerability management program is the repeatable process you use to find, prioritize, fix and verify security weaknesses across your systems. To build one from scratch, you need eight things: a policy that sets scope and timelines, an accurate asset inventory, regular authenticated scanning, a way to prioritize findings, a remediation workflow with clear owners, an exceptions process, verification that fixes worked, and metrics that show progress. With focused effort, you can have the basics running in about 90 days.
This guide walks through each component and ends with a phased startup plan. It draws on two free, widely used references: the CIS Controls v7.1 and NIST Special Publication 800-40 Revision 3.
What is a vulnerability management program?
Running a scanner isn't a program. A program is a cycle that repeats on a schedule and gets better each time: discover assets, assess them, prioritize what you find, remediate, verify, and report.
CIS Control 3 describes the goal well: "Continuously acquire, assess, and take action on new information in order to identify vulnerabilities, remediate, and minimize the window of opportunity for attackers." The key words are "take action." A scan report that nobody acts on is just a list of problems.
Which frameworks should you base it on?
You don't need to invent your process. Two references cover most of what a small or mid-sized organization needs.
CIS Controls v7.1, released by the Center for Internet Security in April 2019, puts Continuous Vulnerability Management at Control 3. Its seven sub-controls call for:
- Automated scanning of all systems with an up-to-date SCAP-compliant tool, weekly or more often
- Authenticated scanning, using local agents or remote scanners with elevated rights
- Dedicated scanning accounts that aren't used for other administrative work
- Automated operating system patch management
- Automated third-party software patch management
- Comparing back-to-back scans to confirm vulnerabilities were remediated
- A risk-rating process to prioritize remediation
Control 3 depends on Controls 1 and 2, "Inventory and Control of Hardware Assets" and "Inventory and Control of Software Assets." You can't scan or patch what you don't know exists.
Version 7.1 also introduced Implementation Groups, which sort sub-controls by organizational size and resources. Automated operating system and third-party patching (3.4 and 3.5) sit in Implementation Group 1, the basic cyber hygiene tier. Automated scanning starts at Implementation Group 2. If your team is very small, that ordering tells you where to start.
NIST SP 800-40 Rev. 3, the Guide to Enterprise Patch Management Technologies (July 2013), covers the patching side. Its executive summary recommends deploying patch management tools in phases, securing those tools themselves, and balancing security against usability and availability. It also sorts metrics into implementation, effectiveness and efficiency, and impact measures.
What are the core components of a vulnerability management program?
Policy and scope
Start with a short written policy that leadership approves. It should define what's in scope (servers, workstations, network devices, cloud workloads, applications), how often you scan, how quickly each severity level must be fixed, and how exceptions work.
Set remediation timeframes you can actually meet, then tighten them over time. Many organizations give internet-facing systems shorter deadlines than internal ones. An unrealistic policy gets ignored and undermines everything else.
Asset inventory
Your inventory defines the boundaries of the program. Pull data from every source you have: directory services, DHCP logs, endpoint management tools, cloud provider consoles and network discovery scans. Reconcile them, because each one will miss something.
For each asset, record at least an owner, a business criticality rating and whether it's exposed to the internet. Those three fields drive prioritization and ticket routing later. A software inventory (Control 2) lets you match vendor advisories to affected systems before a scan even runs.
Scanning: authenticated where possible
An unauthenticated scan sees roughly what an attacker on the network sees: open ports, service banners and remotely detectable flaws. An authenticated scan logs in and checks installed software versions, missing patches and local configuration. It finds much more and produces fewer false positives.
Follow CIS sub-controls 3.2 and 3.3. Create dedicated scanning accounts, don't use them for anything else, and restrict where they can log in from. Use agents for laptops and other devices that are rarely on the network during scan windows.
On cadence, CIS calls for weekly or more frequent scans. If weekly produces more findings than your team can process at first, start monthly and speed up as remediation catches up. Scanning faster than you can act only grows the backlog.
Prioritization
You'll find far more vulnerabilities than you can fix at once, which is why CIS 3.7 asks for a risk-rating process. Start with the CVSS base score, then adjust for whether exploit code is publicly available, whether the asset is internet-facing and how critical it is to the business.
A simple tiering scheme is enough to begin with:
| Priority | Typical criteria | Handling |
|---|---|---|
| 1 | High or Critical severity, public exploit code, internet-facing or business-critical asset | Emergency path, outside the normal cycle |
| 2 | High or Critical severity on internal systems | Next scheduled maintenance window |
| 3 | Medium severity, or mitigated by other controls | Normal patch cycle |
| 4 | Low severity, limited exposure | Batch with routine updates |
Write your prioritization rules down. Consistent, documented rules are easier to defend to auditors and leadership than case-by-case judgment calls.
Remediation workflow and ticketing
Route findings to the teams that own the systems, using the ticketing system they already work in. Group findings by fix rather than raising one ticket per finding. A single cumulative update might close dozens of findings across a server group, and one well-scoped ticket gets done faster than forty small ones.
Automate routine patching wherever you can (CIS 3.4 and 3.5). NIST SP 800-40 notes the tension between patching quickly and testing properly, so agree on maintenance windows and a lightweight testing step in advance. Define a separate emergency path for urgent vulnerabilities that can't wait for the normal cycle.
Exceptions
Some vulnerabilities can't be fixed on schedule. A vendor may not support a patch on its appliance, or a legacy system may have no fix at all. Handle these through a formal exception process rather than letting them quietly age.
Every exception should record the business reason, any compensating controls (such as network segmentation or restricted access), who approved the risk, and an expiry date. When an exception expires, it comes back for review instead of renewing itself.
Verification
A closed ticket isn't proof of a fix. Rescan to confirm, and compare consecutive scans as CIS 3.6 recommends. Close findings only when the scan shows them resolved.
Watch for vulnerabilities that come back. Recurrence often points to an outdated system image, a configuration management gap or a patch that failed to install silently.
Metrics and reporting
Use NIST's three categories to keep metrics meaningful:
- Implementation: percentage of in-scope assets covered by authenticated scanning, percentage under automated patching
- Effectiveness and efficiency: median time to remediate by severity, percentage fixed within policy timeframes, number of open exceptions
- Impact: incidents traced to known, unpatched vulnerabilities, or unplanned downtime caused by patching
Report trends, not just raw counts. A falling time-to-remediate tells leadership more than a raw count of open findings. Give operations teams detailed dashboards and give executives a short monthly summary.
Roles and responsibilities
Programs stall when nobody owns the next step. Agree on these roles early:
| Role | Responsibility |
|---|---|
| Program owner (usually security) | Runs scanning, sets priorities, tracks metrics |
| Asset or system owners | Accountable for remediation on their systems |
| IT operations | Applies patches and configuration changes |
| Development teams | Fix vulnerabilities in in-house applications |
| Senior management | Approves the policy and signs off on risk acceptance |
A 90-day plan to start your program
Here is a realistic sequence for a small or mid-sized organization starting from nothing.
Days 1–30: Foundation
- Get a sponsor in senior management and agree on scope
- Draft the policy, including remediation timeframes and the exception process
- Build the first asset inventory from every data source you have
- Choose your scanning approach and create dedicated scan accounts
- Run a discovery scan and a pilot authenticated scan on a small group of systems
Days 31–60: Baseline
- Extend authenticated scanning to all in-scope assets and fix credential failures
- Set a scan cadence your team can sustain
- Document prioritization rules and connect findings to your ticketing system
- Automate operating system patching where it isn't already
- Tackle the highest-priority findings on internet-facing and critical systems first
Days 61–90: Operate and measure
- Put the exception process into use with approvals and expiry dates
- Verify fixes with rescans and compare consecutive results
- Extend automated patching to common third-party software
- Produce your first metrics report for leadership
- Review what worked and plan the next quarter, such as agents for laptops, cloud workloads or web applications
At the end of 90 days you won't have a mature program, but you'll have a working cycle that you can measure and improve.
Common mistakes when starting out
A few problems show up again and again in new programs:
- Scanning before the inventory is ready. You end up with findings on systems nobody claims and blind spots nobody notices.
- Relying on unauthenticated scans. They miss many missing patches and inflate false positives, which erodes trust with system owners.
- Dumping raw scan reports on IT teams. A huge PDF export doesn't get fixed. Prioritized, grouped tickets do.
- Exceptions without expiry dates. Temporary risk acceptance turns permanent by default.
- Measuring only the number of open findings. The count rises every time you add assets or scan more thoroughly, which can make real progress look like failure.
Frequently asked questions
How often should you run vulnerability scans?
CIS Controls v7.1 calls for weekly or more frequent automated scanning. That's a good target, but pick a cadence your team can act on and increase it as remediation improves. Also scan after major changes and when a serious new vulnerability affects software you run.
What's the difference between vulnerability management and patch management?
Patch management is one way of fixing vulnerabilities. Vulnerability management is the wider process: finding weaknesses, deciding which matter most, choosing a fix (a patch, a configuration change or a compensating control) and verifying the result.
Do small organizations need a formal program?
Yes, but it can be lightweight. A one-page policy, a spreadsheet inventory, automated patching and a monthly authenticated scan with a follow-up process is already a program. The CIS Implementation Groups give you a reasonable order to add capability as you grow.
Next steps
- Name a program owner and get leadership to approve a short policy.
- Reconcile your asset inventory before you tune a single scan.
- Move to authenticated scanning as early as possible.
- Automate patching for operating systems and common third-party software.
- Measure coverage and time to remediate from the first month, so you can show progress.