Vulnerability Management Lifecycle Explained (2026 Guide)

## What Is the Vulnerability Management Lifecycle? The vulnerability management lifecycle is the repeating process an organisation uses to find weaknesses in its systems, decide which ones matter, fix them, prove they are fixed, and report on the result. It is a **continuous loop**, not a project with an end date — new assets appear, new CVEs are published daily, and yesterday's clean scan says nothing about today's exposure. If you are new to the discipline, start with our primer on [what vulnerability management is](/blog/what-is-vulnerability-management), then come back here for the operating model. ## The Five Stages ### 1. Discover — Know What You Own You cannot protect an asset you do not know exists. Discovery builds and maintains an inventory of every internet-facing host, internal server, endpoint, container image, cloud resource, SaaS integration, and code dependency. Practical inputs: - External attack surface discovery (DNS, certificate transparency, cloud IP ranges) - Authenticated and unauthenticated scanning of internal networks - Cloud provider asset APIs (AWS Config, Azure Resource Graph, GCP Asset Inventory) - SCA and SBOM output for third-party libraries - Container registry and image scanning The most common root cause we find in assessments is not an unpatched CVE — it is a forgotten host nobody knew was still exposed. ### 2. Prioritise — Decide What Actually Matters A mid-size environment can generate tens of thousands of findings. Treating them equally guarantees the important ones get buried. Prioritisation blends four signals: | Signal | Question it answers | |---|---| | CVSS severity | How bad is the flaw in the abstract? | | Exploit availability (KEV, EPSS) | Is it being exploited in the wild right now? | | Asset criticality | Does this system hold customer or payment data? | | Exposure | Is it internet-facing, or three network hops deep? | A medium-severity flaw on an internet-facing payments API outranks a critical on an isolated internal test box every time. That is the essence of risk-based vulnerability management. ### 3. Remediate — Fix, Mitigate, or Accept Every prioritised finding takes one of three paths: patch or fix the code, apply a compensating control (WAF rule, network segmentation, feature flag), or formally accept the risk with a named owner and a review date. "Ignored" is not one of the three. Suggested remediation SLAs — set yours in policy and measure against them: | Risk rating | Internet-facing | Internal | |---|---|---| | Critical | 24–72 hours | 7 days | | High | 7 days | 30 days | | Medium | 30 days | 90 days | | Low | 90 days or next release | Best effort | ### 4. Verify — Prove It Is Actually Fixed Closing a ticket is not evidence. Verification means rescanning, retesting the specific attack path, and confirming the fix did not simply move the vulnerability elsewhere. A meaningful share of "remediated" findings we retest are still exploitable — usually because the fix landed in one environment, one endpoint, or one branch, but not all of them. ### 5. Report — Make the Programme Visible Reporting closes the loop for two audiences: engineering (what to fix next) and leadership or auditors (is risk trending down?). Track mean time to remediate by severity, open findings by age and asset criticality, SLA compliance rate, recurrence rate, and coverage — the percentage of your inventory actually being scanned. Then the loop restarts. Discovery runs continuously, not annually. ## Where Programmes Break - **No asset owner.** Findings with no named owner never get fixed. - **Scanner output treated as the programme.** A tool produces data; a programme produces decisions. - **No exception process.** Without a formal accept-and-review path, teams silently ignore findings instead. - **Scanning without testing.** Scanners cannot reason about broken access control or business logic. [Penetration testing](/penetration-testing) covers what scanning structurally cannot. - **No coverage metric.** Perfect remediation across 60% of your estate is a 40% blind spot. ## How It Maps to Compliance - **SOC 2** — CC7.1 expects detection and monitoring of vulnerabilities plus evidence of timely remediation. - **ISO 27001** — Annex A 8.8 requires management of technical vulnerabilities with defined timelines. - **PCI DSS** — Requirement 11 mandates quarterly internal and external scanning plus rescans until clean. - **NDPA 2023 (Nigeria)** — requires appropriate technical measures to protect personal data, and a documented vulnerability programme is the clearest way to demonstrate them. For US SaaS teams preparing for audit, the lifecycle above is the artefact your auditor is looking for. For Nigerian fintechs and integrators, the same loop supports CBN expectations and [NRS integration security assessments](/nrs-integration-security-assessment). ## Frequently Asked Questions **What are the stages of the vulnerability management lifecycle?** Discover, prioritise, remediate, verify, and report — running continuously rather than as a one-off project. **How often should we run vulnerability scans?** Continuously or weekly for internet-facing assets, at least monthly internally, and after every significant change. Quarterly is a compliance floor, not a security target. **Is vulnerability management the same as penetration testing?** No. Vulnerability management is a continuous process of finding and fixing known issues at scale. A [penetration test](/blog/what-is-penetration-testing) is a point-in-time, manual, exploit-driven assessment that finds what scanners cannot. **What is a good mean time to remediate?** Aim for under 72 hours for critical internet-facing findings and under 30 days for high-severity issues. The trend matters more than any single number. **Who should own the programme?** A named security owner sets policy and SLAs; asset and application owners in engineering do the fixing. Shared ownership without named individuals is why programmes stall. ## Build a Lifecycle That Actually Closes Most teams have scanners. Far fewer have a loop that ends in verified fixes and audit-ready evidence. **Want a programme that runs itself?** [See our vulnerability management service](/vulnerability-management), [check your security maturity in 5 minutes](/security-scorecard), or read the [penetration testing cost guide](/blog/how-much-does-a-penetration-test-cost) to plan budget.