A vulnerability management process is the repeatable cycle that finds security weaknesses and fixes the ones that matter most: prepare, discover, assess, prioritize, remediate, verify, and report. The stage that separates working programs from paper ones is risk-based prioritization backed by enforced ownership and SLAs, because scanning without accountable closure just produces a bigger backlog.
TL;DR:
- Prioritize KEV findings first, then high EPSS issues on reachable, exposed assets; rank other findings by asset criticality and put publicly exposed systems first.
- Patch after testing a vendor fix; otherwise use a compensating control or isolate the asset, and log delays as dated exceptions requiring senior approval.
- Close findings only after a rescan or targeted test confirms the fix; require manual review for critical and high risk issues, and attach evidence.
- Review monthly remediation time by severity, SLA adherence, recurring weaknesses, and open critical or high findings, with accepted risks visible to senior leaders.
Table of Contents
- 1. Prepare: Policy, Scope, and Asset Inventory
- 3. Assess and Prioritize: Which Risk Signals Actually Matter
- 4. Remediate and Mitigate: Choosing the Right Fix
- 5. Verify: Retesting, VEX, and Closure Criteria
- 6. Governance, Metrics, and Reporting Leadership Can Act On
- 7. A Practical Runbook for One Remediation Cycle
- What Most Programs Get Wrong About Remediation
- How We Support Your Vulnerability Management Program
- FAQ
- Sources
1. Prepare: Policy, Scope, and Asset Inventory
Before any scan runs, we need a policy that defaults to updating systems promptly, with any deferral logged as a time-boxed exception in a risk register, a principle the NCSC’s vulnerability management guidance builds its entire framework around. Skipping this step is why so many programs drown in findings nobody owns.
A working preparation phase includes:
- A current asset inventory (CMDB and software bill of materials) with internet-facing systems flagged first.
- A documented tool mix: scanners, ticketing, and CI/CD integrations feeding one pipeline instead of five spreadsheets.
- Named owners, enforceable SLAs, and escalation contacts for every asset class before the first finding arrives.
- A central patch and vulnerability function that routes findings and chases closure, which the NCSC notes materially improves remediation rates when teams are otherwise fragmented.
3. Assess and Prioritize: Which Risk Signals Actually Matter
CVSS alone tells you how severe a flaw could theoretically be, not whether anyone is exploiting it. A workable prioritization model layers several signals:
- CVSS v4 as a baseline severity score, never the final word.
- CISA’s Known Exploited Vulnerabilities (KEV) list, which flags what attackers are using right now.
- EPSS scores to estimate exploitation probability over the next window.
- Reachability and runtime exposure: is the vulnerable function actually callable in your environment.
- Asset criticality: what breaks, and for whom, if this is exploited.
NCSC’s patch wave guidance explicitly recommends prioritizing internet-facing and perimeter systems first and using risk-prioritized approaches like SSVC to decide what gets fixed when capacity is limited. In practice, that produces an ordering: anything on KEV moves first, then high-EPSS findings on reachable, exposed assets, then everything else by asset criticality. Automate the enrichment (EPSS pulls, KEV checks) so triage doesn’t depend on someone remembering to look it up, then tag each finding with the SLA tier it inherits and let the ticketing system enforce escalation when that clock runs out.
4. Remediate and Mitigate: Choosing the Right Fix
Not every finding gets the same treatment. The options, roughly in order of preference, are patching, configuration changes, isolating the affected asset, or replacing an end-of-life system that can no longer be patched at all.
- Patch where a vendor fix exists and testing confirms it doesn’t break production.
- Apply a compensating control (firewall rule, WAF signature, disabled feature) when a patch isn’t ready.
- Isolate or segment the asset if neither option is immediately available.
- Retire or replace end-of-life software that has no supported fix path.
When patching has to wait, the NCSC’s guidance on 10 Steps to Cyber Security calls for a time-boxed exception logged in the risk register with senior sign-off, not an indefinite “we’ll get to it.” Change coordination matters here too: schedule deployment windows, prepare rollback plans, and use hot-patching where the platform supports it to limit operational disruption.
Pro Tip: Automate ticket creation and dependency-update pull requests (Dependabot or Renovate-style) so low-risk fixes reach an engineer’s queue without a human triaging every single one.
5. Verify: Retesting, VEX, and Closure Criteria
A fix that hasn’t been confirmed isn’t a fix, it’s a guess. Closure needs evidence, not a status change in a ticket.
- Re-scan the affected asset and run a targeted test against the specific vulnerability that was reported.
- Run regression tests where the change touched shared code or infrastructure, and have a pentester validate high-severity closures where feasible.
- Document exploitability status using VEX or CSAF (affected, not affected, fixed, or under investigation) and attach it to the relevant SBOM.
- Allow auto-closure only for low-risk, clearly verified findings, with manual gating on anything critical or high.
- Track recurrence: if the same weakness reappears on the same asset class, that’s a root-cause problem, not a one-off.
6. Governance, Metrics, and Reporting Leadership Can Act On
Programs that can’t show their numbers can’t defend their budget or their backlog. The core metrics worth tracking monthly are mean time to remediate by severity, SLA adherence, the trend in open critical and high findings, recurrence rate, and the rate at which issues escape earlier testing into production.
Exceptions to these targets belong in the same risk register the NCSC recommends for deferred patches, visible to whoever signs off on residual risk. The NCSC’s broader vulnerability management collection frames this as a cross-cutting activity that needs senior leadership involved whenever risk is being accepted rather than fixed. A monthly dashboard and a quarterly executive summary keep that visibility consistent instead of reactive.
7. A Practical Runbook for One Remediation Cycle
Strip the process down to a single cycle and it looks like this: ingest, dedupe, enrich, triage, assign, fix, verify, close, report, retrospective.
- Ingest findings from every scanner and feed into one pipeline, deduplicating by asset and CVE.
- Enrich with EPSS, KEV status, and reachability data before anyone looks at severity.
- Triage against the priority order, assign an owner, and attach the SLA tier automatically.
- Remediate, verify with a re-scan or targeted test, close with evidence attached, and report the cycle’s numbers before starting the next one.
Keep four roles mapped to every cycle: the asset owner who implements the fix, a triage lead who enriches and assigns, a change approver for anything touching production, and a verifier who signs off closure. Our guide to vulnerability management solutions walks through tooling choices that support this runbook end to end.
Pro Tip: Keep a standing triage, exception sign-off, and verification template so every cycle produces the same evidence trail, no matter who’s running it that week.
What Most Programs Get Wrong About Remediation
Most vulnerability management programs don’t fail because they lack scanners. They fail because nobody owns the finding once it leaves the scanner’s report. Centralizing findings into one pipeline and assigning a human owner to each one, a pattern the NCSC points to directly, closes more tickets than any additional tool ever will.
A sensible maturity path looks like this: starter programs focus on centralizing findings and assigning owners; intermediate programs add EPSS and KEV enrichment plus SLA automation; advanced programs add reachability analysis, code-to-runtime context, and automated remediation pull requests. Governance voices outside security teams also matter here. Executive advisory perspectives like Dr. Rashaan J. Green’s work on cybersecurity leadership reflect a broader shift toward treating vulnerability data as a board-level risk conversation, not a purely technical one. Teams exploring where automation fits into that maturity curve may also find value in OmniPulse’s perspective on AI-driven change management when evaluating how much of triage and enrichment can reasonably be automated versus kept under human review.
— Shirish
How We Support Your Vulnerability Management Program
We can provide managed services following the described process: centralized scanning, risk-based prioritization, enforced SLAs, and verified closure, scaled to your organization’s needs across locations.
- Our services include handling triage, enrichment, and ticketing to reduce manual effort for your internal team.
- Vulnerability management can be combined with SOC and SIEM services for continuous visibility, along with penetration testing when deeper validation is necessary.
- SLA tiers and reporting cadence are adapted according to industry compliance requirements rather than using a generic template.
If you want a clearer picture of where your current process stands, request a maturity review through our vulnerability management services page, or read more on choosing the right vulnerability management partner before you decide.
FAQ
What are the 5 steps of vulnerability management?
Most frameworks describe the cycle as discover, prioritize, remediate, verify, and report, often with a preparation phase feeding in beforehand. The exact count varies by framework, but the order (find it, decide what matters, fix it, confirm the fix, report on it) stays consistent across most practitioner guides.
What are the four stages of vulnerability management?
A common four-stage version collapses the cycle into identify, assess, remediate, and report, treating prioritization as part of the assessment stage rather than its own step. Definitions vary between frameworks, so the stage count matters less than whether each stage is actually enforced with ownership and SLAs.
What are the top vulnerability management tools?
Tool selection depends heavily on your environment, covering categories like SAST, SCA, DAST, container and infrastructure-as-code scanning, and runtime detection, often combined rather than chosen as one single platform. We cover tool mix and integration patterns in more depth in our vulnerability management solutions guide.
How should teams prioritize vulnerabilities beyond CVSS score?
Teams get better results combining CVSS with CISA’s KEV list, EPSS exploitation probability scores, reachability analysis, and asset criticality, rather than ranking by severity score alone. NCSC’s patch wave guidance specifically recommends prioritizing internet-facing systems and using risk-prioritized approaches like SSVC when deciding what to fix first.
What happens when a vulnerability can’t be patched right away?
When patching has to be deferred, the fix is a documented, time-boxed exception entered into a risk register with senior sign-off, not an open-ended delay, a principle outlined in NCSC’s 10 Steps guidance. The exception should include a compensating control where possible and a firm review date.
Sources
Coverage comes from combining tool types, not picking one. Each catches a different class of weakness, and none of them replaces the others.
- 10 Steps to Cyber Security — Vulnerability management (NCSC)
Our own breakdown of scanning approaches for multi-location organizations covers tool selection in more depth in this vulnerability assessment guide.
