Vulnerability management is a repeating operational cycle with five connected stages: discover assets and weaknesses, assess and prioritize risk, remediate or mitigate, verify the result, and report, monitor, and improve. Verification and lessons learned start the next cycle; the process does not end when a scanner report is closed.
What are the five stages of vulnerability management?
- Identify or discover: Build an accurate inventory and find vulnerabilities.
- Assess and prioritize: Rank findings by technical risk and business impact.
- Remediate or mitigate: Fix the weakness or reduce its exposure with a compensating control.
- Verify: Rescan or retest to confirm the result.
- Report, monitor, and improve: Track outcomes, residual risk, and program performance, then feed the lessons into the next cycle.
IBM describes the lifecycle as continuously discovering, prioritizing, and addressing weaknesses in IT assets. ServiceNow likewise treats the final monitoring and improvement stage as ongoing rather than a one-time sign-off.
Stage 1: Identify or discover assets and vulnerabilities
You cannot manage what you cannot see. Start with an inventory of hardware, virtual machines, cloud resources, applications, operating systems, network services, software versions, configurations, and internet-facing endpoints. Include newly deployed and temporary assets, not just systems recorded in a configuration database.
Use authenticated and unauthenticated vulnerability scans where appropriate, plus other assessment sources such as configuration reviews, penetration tests, code or dependency analysis, cloud-security findings, and reports from vendors or users. Record enough context to connect each finding to an asset, owner, software version, location, and exposure.
Recommended Free Tools
#1 Best Overall
Outputs of discovery
- A current asset and service inventory.
- Evidence for each finding, including affected component and detection date.
- An initial view of exposure, such as internet accessibility, network reachability, or privilege level.
- Ownership information so the next stage can make a decision rather than create an unassigned ticket.
Stage 2: Assess and prioritize risk
A scanner’s severity field is not a treatment plan. Assess each finding using technical severity and exploitability together with exposure, business criticality, data sensitivity, compensating controls, threat intelligence, and the likely operational or safety impact of failure.
Prioritization should answer three questions: how easily could the weakness be exploited, what could an attacker reach or change, and how important is the affected service to the organization? A high-severity issue on an isolated test system may require a different response from a lower-scored weakness on an exposed identity or payment system.
Useful prioritization inputs
- Exploit availability or credible evidence of active exploitation.
- Internet exposure, lateral-movement potential, and reachable attack paths.
- Asset role, business owner, and criticality of the service.
- Data classification, privilege, and regulatory obligations.
- Existing controls, such as segmentation, application allow-listing, or a web-application firewall.
- Change complexity, outage risk, and the time required to test a fix.
Document the decision, not just the score. The record should state the selected action, accountable owner, target date, and any reason a finding is accepted, deferred, or treated with a compensating control.
Stage 3: Remediate or mitigate
Remediation removes the underlying weakness. Typical actions include applying a vendor patch, upgrading software, changing an insecure configuration, disabling an unnecessary service, removing an affected component, or replacing it with a supported alternative.
Free tools Windows power users keep installed
One-click scans. No signup required.
When a direct fix is unavailable or cannot be deployed safely yet, mitigation reduces the risk. Examples include network isolation, access-control changes, disabling a vulnerable feature, restricting administrative paths, enhanced monitoring, or a compensating security control. A mitigation is not the same as claiming the vulnerability is fixed; record its scope, owner, expiry or review date, and residual risk.
Coordinate the change
Security teams generally identify and explain the risk, while IT operations, application teams, system administrators, and service owners implement and test the change. Use the organization’s change-management process for production systems, with a rollback plan and communication for affected users.
Assign accountable work
- Map each finding to a named asset or service owner.
- Set a due date based on risk and operational constraints.
- Link related findings when one patch or configuration change resolves several issues.
- Record exceptions separately from completed remediation.
Stage 4: Verify the result
Closure requires evidence. Rescan or retest the affected asset after the patch, configuration change, or mitigation is in place. Confirm that the original condition is no longer exploitable, the expected version or setting is present, and the control did not introduce a new security or availability problem.
When verification fails
- Still vulnerable: Reopen the finding, update its evidence, and return it to remediation.
- Partially fixed: Separate remaining affected assets or components and reprioritize them.
- False positive: Preserve the evidence and detection rationale so the rule can be tuned without hiding genuine exposure.
- Mitigation only: Keep the underlying vulnerability open or clearly marked as mitigated, with a review date for the permanent fix.
Verification should cover representative systems when a change is deployed broadly, while retaining a way to identify exceptions and systems that missed the deployment.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Stage 5: Report, monitor, and improve
Record findings, decisions, changes, verification evidence, exceptions, and residual risk in a system that supports reporting. Tailor reports to their audience: asset owners need actionable tickets, security leadership needs risk and trend information, executives need business impact, and compliance stakeholders need evidence of control operation.
Measures that show whether the process works
- Open critical and high-risk findings, segmented by exposure or business service.
- Time from discovery to assignment, remediation, and verified closure.
- Verification pass rate and the number of findings reopened.
- Recurring findings by asset, control, or root cause.
- Age and volume of approved exceptions, including overdue reviews.
- Coverage of inventoried assets and scan or assessment coverage.
Use these measures to improve inventory quality, scanning schedules, patch processes, secure configuration standards, ownership models, and exception governance. ServiceNow characterizes this stage as one that never actually ends; CERT-MU similarly describes vulnerability management as providing a continuous view of weaknesses and associated risk.
How should an organization implement the process?
- Define scope and ownership. List the networks, cloud accounts, applications, endpoints, and services in scope. Assign accountable owners and an escalation path.
- Establish the inventory. Reconcile discovery tools, configuration records, cloud inventories, and ownership data. Mark unknown or unmanaged assets for immediate investigation.
- Choose assessment methods. Set scan types and frequencies appropriate to endpoints, servers, applications, containers, cloud resources, and internet-facing systems. Add non-scanner sources where they reveal different classes of weakness.
- Create a risk model. Combine severity, exploitability, exposure, asset criticality, data sensitivity, existing controls, and operational impact. Define how exceptions and accepted risk are approved.
- Route prioritized work. Integrate findings with ticketing or workflow systems, assign owners, set due dates, and group findings that share one remediation.
- Apply fixes and mitigations. Test patches and configuration changes, schedule production changes, document rollback steps, and record compensating controls when needed.
- Verify independently. Rescan or retest after implementation, preserve evidence, and reopen findings that remain exploitable.
- Review performance and adjust. Examine trends, recurring root causes, missed assets, overdue exceptions, and verification failures. Change the next assessment or remediation cycle accordingly.
How often should the lifecycle run?
There is no single universal cadence. Continuous discovery and monitoring are appropriate for fast-changing or internet-facing environments, while scheduled authenticated scans, application assessments, and configuration reviews can be set according to asset type, change rate, threat, and organizational requirements. Run an out-of-cycle assessment after major architecture changes, emergency disclosures, acquisitions, or credible evidence that a vulnerability is being exploited.
The important property is continuity: new assets and findings enter the process, high-risk work is prioritized, completed changes are verified, and the resulting data changes what happens next.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Best Value
Do not confuse lifecycle stages with maturity stages
“Five stages” does not describe one universal framework. IBM and ServiceNow use a five-part operational lifecycle for handling vulnerabilities. Tripwire uses five maturity stages—Initial, Managed, Defined, Quantitatively Managed, and Optimizing—to describe how consistently and quantitatively a vulnerability-management program operates. Those maturity levels are not the sequence for handling an individual finding.
When documenting a program, name the framework first. Otherwise, a reader may mistake a maturity model for the operational workflow.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
