Vulnerability Management: A Step-by-Step Process Guide

TL;DR

Vulnerability management is a continuous four-phase lifecycle: discover, prioritize, remediate, and verify. Organizations with a structured program reduce their mean time to remediate critical vulnerabilities from 60 days to under 15. This guide walks security teams through building a repeatable process using CVSS scoring, scanning tools like Nessus and OpenVAS, risk-based prioritization, severity SLAs, and leadership reporting frameworks.

In September 2024, a regional healthcare network with 14 clinics and over 200,000 patient records suffered a ransomware attack that encrypted their electronic health record system for eleven days. The entry point was a critical remote code execution vulnerability in their VPN appliance. The CVE had been published seven months earlier. The vendor had released a patch five months earlier. The IT team had flagged it in a scan report three months earlier. The remediation was "scheduled for next quarter."

That gap between knowing about a vulnerability and actually fixing it is where breaches happen. Not in the unknown. Not in the exotic zero-day. In the backlog. In the spreadsheet. In the next-quarter column.

Vulnerability management is the discipline that closes that gap. It is not a tool you install or a scan you run on Fridays. It is a program, a continuous cycle of finding weaknesses, deciding which ones matter most, eliminating them, and proving they are gone. This guide breaks that cycle into concrete steps that security teams of any size can implement immediately.

The Vulnerability Management Lifecycle

Every mature vulnerability management program follows four phases that repeat continuously. Skipping any phase creates a gap that attackers will eventually find.

Phase 1: Discover

Discovery has two components. First, you need a complete, accurate inventory of every asset in your environment: servers, workstations, network devices, cloud instances, containers, IoT devices, and applications. You cannot protect what you do not know exists. Shadow IT, forgotten test servers, and unmanaged cloud accounts are where unpatched vulnerabilities hide.

Second, you scan those assets for known vulnerabilities. A vulnerability scanner probes each system, checks software versions against vulnerability databases, tests for misconfigurations, and produces a list of findings. Each finding maps to a CVE identifier in the NIST National Vulnerability Database, which serves as the authoritative source for vulnerability information worldwide.

Authenticated scans, where the scanner logs into each system with credentials, discover significantly more vulnerabilities than unauthenticated scans. An external scan sees what an attacker sees from the network. An authenticated scan sees what the system administrator sees: missing patches, weak configurations, outdated libraries, and local privilege escalation paths.

Phase 2: Prioritize

A typical enterprise scan returns thousands of findings. Treating every vulnerability as equally urgent leads to alert fatigue and wasted effort. Risk-based prioritization separates what matters now from what can wait.

The Common Vulnerability Scoring System (CVSS) provides a standardized severity score from 0.0 to 10.0. Published by FIRST.org, CVSS evaluates each vulnerability across three metric groups: base (inherent characteristics), temporal (factors that change over time like exploit availability), and environmental (relevance to your specific infrastructure).

CVSS severity levels break down as follows:

However, CVSS alone is insufficient. A Critical vulnerability on a development laptop behind a VPN presents less real risk than a High vulnerability on a public-facing web server processing payment card data. Effective prioritization layers three additional factors on top of CVSS scores.

Asset criticality. Not all systems carry equal value. A database server holding protected health information matters more than a conference room display screen. Classify assets into tiers (mission critical, business important, standard, non-essential) and weight vulnerability severity by the tier of the affected asset.

Exploit availability. A vulnerability with a public exploit kit on GitHub poses immediate danger. A theoretical vulnerability with no known exploit can wait. The CISA Known Exploited Vulnerabilities (KEV) catalog lists over 1,100 CVEs confirmed to be actively exploited in the wild. Any vulnerability on this list moves to the front of the remediation queue regardless of CVSS score.

Business context. A vulnerability in a system undergoing decommissioning next week does not need the same response as the same vulnerability in a system launching to production tomorrow. Remediation decisions must account for system lifecycle, upcoming changes, and operational constraints.

Phase 3: Remediate

Remediation is where most programs stall. Discovery and prioritization produce reports. Remediation produces security. Three remediation strategies apply depending on the vulnerability and the operational context.

Patching is the primary fix for most vulnerabilities. The vendor releases a software update that eliminates the flaw. Patching sounds simple, but enterprise patch management involves testing patches against application compatibility, scheduling maintenance windows, coordinating with system owners, deploying across distributed environments, and handling systems that fail to update. Automation tools like WSUS, SCCM, Ansible, or cloud-native patch management services reduce the manual burden but still require oversight.

Configuration changes address vulnerabilities caused by insecure defaults or misconfigurations rather than code flaws. Disabling unnecessary services, restricting network access through a firewall, enforcing encryption, or updating access control lists can eliminate vulnerabilities without any vendor patch.

Compensating controls apply when patching is not immediately possible. Legacy systems running unsupported software, operational technology with strict uptime requirements, or applications awaiting vendor patches may need temporary mitigations. Network segmentation, enhanced monitoring through a SIEM, application firewalls, and additional access restrictions reduce the risk until a permanent fix is available. Compensating controls are not permanent solutions. They are bridges, and every compensating control should have a documented expiration date and a path to full remediation.

Phase 4: Verify

Verification closes the loop. After remediation, rescan the affected assets to confirm that the vulnerability is actually resolved. Patches sometimes fail to install correctly. Configuration changes sometimes revert. New updates sometimes reintroduce old vulnerabilities.

Verification scanning should be targeted and timely. Waiting for the next scheduled monthly scan means living with uncertainty for weeks. Scan the specific assets that received remediation within 48 hours of the change. Confirm the finding is gone. Update the tracking record. Move on.

This phase also catches regression. A server patched on Tuesday may have its configuration overwritten by an automated deployment on Thursday. Continuous verification ensures that fixed vulnerabilities stay fixed.

Choosing Vulnerability Scanning Tools

The scanner you choose shapes every downstream activity in your program. Three tools dominate the market for different reasons.

Nessus by Tenable is the most widely deployed commercial scanner. It offers over 200,000 plugins for vulnerability detection, compliance auditing, and configuration assessment. Nessus excels at credentialed scanning in mixed environments and provides detailed remediation guidance with each finding. The professional version supports unlimited IP scanning and prioritized output.

OpenVAS (Open Vulnerability Assessment Scanner) is the leading open source alternative. Maintained by Greenbone Networks, OpenVAS provides a comprehensive vulnerability test feed updated daily. It lacks some of the polish and integration capabilities of commercial tools, but it delivers solid scanning capability at zero licensing cost. For smaller teams and budget-conscious organizations, OpenVAS provides a legitimate foundation for a vulnerability management program.

Qualys takes a cloud-native approach with agents deployed on endpoints and scanning orchestrated from a SaaS platform. Qualys scales to hundreds of thousands of assets and integrates vulnerability data with asset inventory, patch management, and compliance tracking in a unified platform. Its cloud architecture eliminates the need to manage scanner infrastructure.

Each tool has strengths. Many mature programs run multiple scanners because each engine catches things the others miss. At minimum, your scanning capability needs to support authenticated scanning, schedule automated recurring scans, integrate with your ticketing system for remediation tracking, and produce reports that both technical teams and leadership can understand.

Building a Patching Strategy That Actually Works

Patching is where strategy meets operations. A patching strategy that looks good on paper but crashes production systems will get abandoned. One that avoids all risk by moving slowly will leave critical vulnerabilities exposed for months. The goal is a process that is fast enough to contain risk and careful enough to avoid self-inflicted outages.

Test before deploying. Maintain a staging environment that mirrors production. Apply patches there first. Run automated tests. Verify that critical applications still function. This adds hours to the timeline, not days, and prevents the catastrophic failure that makes teams fear patching.

Automate routine patches. Operating system security updates, browser patches, and standard library updates follow predictable patterns. Automate their deployment to non-critical systems first, then promote to critical systems after a validation period. Reserve manual oversight for patches that touch core business applications or infrastructure components.

Emergency patching. When a Critical vulnerability with active exploitation hits your environment, normal change management timelines do not apply. Define an emergency patching process in advance. Who authorizes it? How quickly must it deploy? What is the rollback plan? Having this process documented before the crisis means you spend time fixing the problem, not debating the process.

Track everything. Every patch deployment needs a record: which systems, which patch, when it was applied, who approved it, and the verification result. This tracking feeds compliance reporting, audit evidence, and your own program metrics.

Reporting to Leadership

Vulnerability scan output is meaningless to a CFO. CVSS scores, CVE identifiers, and plugin numbers communicate urgency to security teams but not to business leadership. Effective reporting translates technical findings into business risk language.

Report on four metrics consistently.

Mean time to remediate (MTTR) by severity. Track how long vulnerabilities live in your environment from discovery to verified fix. Trend this monthly. Leadership wants to see the line going down.

Open vulnerability count by severity and age. A visualization showing that you have 47 Critical vulnerabilities older than your SLA target communicates urgency faster than any written paragraph. Break this down by business unit to create accountability.

Coverage percentage. What percentage of your asset inventory is under active scanning? If you are only scanning 60% of your environment, the other 40% is a blind spot. This metric drives investment in expanding scanner coverage.

SLA compliance rate. What percentage of vulnerabilities are remediated within the defined SLA for their severity? This single number tells leadership whether the program is meeting its commitments. A rate below 80% signals a resource or process problem that needs attention.

Present these metrics monthly in a one-page dashboard. Reserve detailed technical data for the appendix. Leadership decisions require trends and risk context, not CVE descriptions.

Defining and Enforcing SLAs

Service level agreements for vulnerability remediation transform prioritization from opinion into policy. Without SLAs, every team interprets "fix it soon" differently. With SLAs, expectations are documented, measurable, and enforceable.

Start with the severity-based timeline table above and adapt it to your organization's risk tolerance and operational capacity. A financial services company handling real-time transactions may demand 24-hour Critical SLAs. A manufacturing company with limited maintenance windows may extend that to 72 hours with compensating controls active during the gap.

Define escalation paths for SLA violations. When a Critical vulnerability passes the 72-hour mark without remediation, who gets notified? When it reaches 7 days, what executive receives an alert? Automated escalation removes the burden of manual follow-up and creates institutional pressure to meet deadlines.

Account for exceptions. Some systems genuinely cannot be patched within standard SLAs due to vendor dependencies, regulatory change freezes, or operational constraints. Create a formal exception process that requires documented justification, compensating controls, and a committed remediation date. Review exceptions monthly. Permanent exceptions do not exist.

Building a Repeatable Process

The difference between organizations that manage vulnerabilities effectively and those that get breached through known CVEs is not tools or talent. It is process. A repeatable, documented process that runs whether the security team is fully staffed or short-handed, whether leadership is paying attention or distracted by other priorities.

Document your vulnerability management program in a formal policy. Include scope (which assets), roles (who scans, who patches, who verifies, who reports), frequency (scan schedules, reporting cadence), tools (approved scanners, ticketing integration), SLAs (by severity), exceptions (process and approval authority), and metrics (what you measure and report).

Review and update this policy annually. The threat landscape changes, your infrastructure evolves, and your program must keep pace. What worked last year may not address the container sprawl, cloud migration, or acquisition integration happening this year.

Integrate vulnerability management with your broader incident response program. When a breach investigation reveals that the entry point was a known, unpatched vulnerability, your incident response process should feed back into the vulnerability management program to prevent recurrence. These programs work best when they inform each other continuously.

The healthcare network from the opening of this article did not lack a vulnerability scanner. They had one. They ran scans. They produced reports. What they lacked was the process to ensure those reports translated into action within a timeframe that mattered. Seven months of knowing is worse than not knowing at all, because it means the system, not the attacker, failed.

Build the process. Run the scans. Prioritize by risk. Patch within SLAs. Verify the fix. Report the results. Repeat. That cycle, executed consistently, eliminates the gap between awareness and action where breaches grow.