A vulnerability management program is not a project you finish and move on from. It is a loop that keeps running: scanners return new findings the week after a remediation sprint closes, fresh CVEs get published against software you already run, and a host that passed last month’s scan drifts out of compliance the moment someone rebuilds it from an older base image. The model in this article breaks that loop into six stages: discovery and collection, validation, prioritization, assignment, remediation, and verification. Each stage has one owner, one output, and one specific way it tends to fail. If you are new to running a program, or you inherited one with a backlog nobody can explain, mapping your actual workflow onto these six stages is the fastest way to find out exactly where work is getting stuck.
Why the Lifecycle Is a Loop, Not a Project With an End Date
Treating vulnerability management as a project (scan once, fix everything, declare victory) fails for a structural reason: the input never stops arriving. New CVEs are disclosed against your stack on an ongoing basis, your asset inventory changes every time infrastructure is provisioned or decommissioned, and configuration drift reintroduces flaws that were already remediated once. A six-stage lifecycle treats each scan cycle as one pass through the loop, with findings from this pass feeding the same validation, prioritization, and assignment machinery as findings from the last one. The moment a team starts treating remediation as “done” without closing the loop back to verification, the backlog stops reflecting reality: tickets say resolved, but the next authenticated scan finds the same CVE on the same host.
This is also why lifecycle maturity is measured in cycle time and reopen rate, not a single point-in-time count of open findings. A program with 4,000 open findings and a 12-day average time from discovery to verified closure is healthier than one with 800 open findings and no working retest step, because the second number cannot be trusted.
The Six Stages, Walked Through
1. Discovery and Collection
Discovery starts with an asset inventory, not a scan. A scanner can only report on what it can see and authenticate to, so an incomplete CMDB produces a false sense of coverage regardless of scan quality. Most programs run authenticated checks (installed package versions, registry keys) alongside unauthenticated checks against exposed services, on a cadence tied to exposure: daily or near-daily delta scans for internet-facing assets, weekly full scans internally, and a full re-baseline monthly.
Collection is the unglamorous half of this stage: normalizing output from whichever scanner engines are in use (Nessus, Qualys, Rapid7 InsightVM, open-source engines like OpenVAS or Nuclei) into one schema, then deduplicating. The same flaw is often reported twice, once by an authenticated check and once by a network-based check, or once this week and once last week under a new scan ID. Deduplication typically keys on a composite of CVE identifier (or plugin ID where no CVE exists), host, and port, so the finding is a single row that accumulates scan history rather than spawning a new ticket every cycle. Platforms that automate this step, such as SITEY, hash on CVE ID plus host plus port plus scanner plugin ID before a finding ever reaches an analyst, specifically so the same flaw does not generate a duplicate entry on every scan window.
2. Validation
Not every scanner finding is real. Version-based detection (a plugin sees an outdated banner string and reports the CVE associated with that version) produces false positives when a vendor backports a fix without bumping the version number, or when a WAF or proxy rewrites the banner. Validation is the stage where a finding is confirmed as exploitable in this environment before it consumes anyone’s remediation time.
Concretely, validation means checking exploit preconditions against the actual target: does the CVE require anonymous access, and is that access actually enabled here; does it require a specific configuration flag, and is that flag set; is the port even reachable from the position the scanner claims. Authenticated scanning reduces the false-positive rate considerably because it reads the installed package version directly instead of inferring it from a network response, but it does not eliminate manual triage entirely. Some platforms run findings through an automated validation and triage pass that checks a CVE’s documented preconditions against the scanned service configuration before marking it confirmed, SITEY among them, so a human only sees findings that already cleared a precondition check rather than every raw scanner hit.
3. Prioritization
CVSS base score alone is a weak prioritization signal because it describes theoretical severity, not the probability of exploitation against your specific asset. A more reliable ranking combines four inputs: CVSS base score, EPSS (Exploit Prediction Scoring System) probability, whether the CVE appears on CISA’s Known Exploited Vulnerabilities catalog, and asset criticality (a finding on a public-facing payment gateway is not the same risk as the identical finding on an isolated dev sandbox with no data).
A workable rule set looks like this: any KEV-listed CVE is automatically P1 regardless of CVSS score, since KEV listing means active exploitation has already been observed in the wild. Everything else is scored as CVSS base multiplied by an exposure factor (2x for internet-facing, 1x for internal-only) and an asset criticality weight (3x for assets tagged crown-jewel, 1x for standard, 0.5x for non-production). SLA clocks then follow standard tiers: 15 days for Critical, 30 for High, 90 for Medium, and a documented risk-acceptance path for Low findings that would otherwise sit indefinitely. These are the same SLA windows referenced in CISA Binding Operational Directive 22-01 for KEV remediation in federal environments, and they translate reasonably well to a private-sector SLA policy.
4. Assignment
Assignment is where lifecycles most often break down silently, because it depends on data most organizations do not maintain well: an accurate mapping from asset to owning team. Routing a finding to a generic “IT” queue with no named owner and no SLA clock is functionally the same as not assigning it at all. A working assignment stage pulls owner information from the CMDB or asset tags (a tag of app:billing-db routes to the database team, with the SLA tier set by the asset’s criticality) and opens a ticket in whatever system that team already works from, Jira or ServiceNow being the two most common, rather than a separate vulnerability-only portal nobody checks. The handoff should carry the validated finding, the prioritization rationale, and the SLA due date into the ticket, not just a bare CVE identifier; an assignee who gets a CVE ID and a hostname with no context has to redo the validation and prioritization work themselves.
5. Remediation
Remediation is broader than “apply the vendor patch.” In order of preference: apply the patch or upgrade; apply a configuration change that closes the specific attack path without a full upgrade (disabling a vulnerable feature, tightening a permission); apply a compensating control (a WAF rule, a firewall restriction, network segmentation) when the real fix needs a maintenance window that has not arrived yet; or formally accept the risk with a named approver, a written justification, and an expiration date that forces re-review, typically no more than 90 days out.
The common failure here is trusting a patch job’s exit code as proof of remediation. A configuration management run can report success while the service was never restarted, the wrong package version got pinned by a dependency constraint, or the patch landed on one node in a cluster but not the others behind the load balancer. That gap is exactly what the next stage exists to close, which is why patch management output should be read as a claim to check, not a fact to record.
6. Verification and Closure
A finding should not move to closed status because a ticket field changed to “Resolved.” It should close because a retest, using the same detection logic that originally found it (same plugin ID, same port, same check), no longer reports it. This is the step that catches the failure modes described above: partial patch rollout, a restart that did not happen, or a configuration change applied to staging instead of production.
Verification also needs a regression window: if the same CVE reappears on the same host within roughly 30 days of being marked closed, it should be flagged as a regression rather than filed as a fresh finding, because a regression usually points to a root cause upstream of the individual ticket, such as a golden image or container base layer that was never updated. Platforms built around closed-loop retesting, such as SITEY, re-run the original scan signature against the same asset and port during the retest and closure phase specifically so closure depends on scanner evidence rather than on the assignee’s own status update.
Inputs, Outputs, and Handoff Owners for Each Stage
| Stage | Primary input | Primary output | Typical owner |
|---|---|---|---|
| Discovery and collection | Asset inventory, scan schedule | Deduplicated raw findings | Vulnerability management team |
| Validation | Raw findings, service configuration | Confirmed true positives | Security analyst or automated triage |
| Prioritization | Confirmed findings, EPSS/KEV data, asset criticality | Ranked findings with SLA tier | Security analyst |
| Assignment | Ranked findings, CMDB owner mapping | Tickets with named owner and due date | Vulnerability management team |
| Remediation | Assigned ticket | Patch, config change, control, or accepted risk | Asset owner / operations team |
| Verification and closure | Remediated ticket | Retest evidence, closed or reopened finding | Vulnerability management team |
The Three Stages Where Most Programs Silently Stall
In practice, three of the six stages account for most of the aging backlog: validation, assignment, and verification.
- Validation stalls when the volume of raw findings outpaces manual triage capacity, so analysts either wave findings through unvalidated (inflating the backlog with false positives that never get fixed because nobody can fix a non-issue) or let the validation queue itself back up for weeks.
- Assignment stalls when asset ownership data is stale or missing. A finding sits “unassigned” or gets routed to a team that no longer owns that asset, and the SLA clock either never starts or starts against the wrong owner, who reasonably ignores it.
- Verification stalls when there is no automated retest step at all, and closure depends entirely on the assignee marking their own ticket done. This is the stage where a program can look healthy on paper (low open count, tickets closing on schedule) while the underlying exposure never actually shrank.
How Lifecycle Gaps Show Up as Rising Open-Finding Counts
Each stall pattern above leaves a distinct signature in your metrics, which makes them diagnosable without guessing:
- A growing gap between “findings discovered” and “findings validated” per week points to a validation bottleneck, not a remediation one; adding remediation staff will not help.
- A large bucket of tickets in “assigned” status with no activity for 30+ days, concentrated on a handful of asset groups, points to an assignment mapping problem, usually a stale CMDB field.
- A rising reopen rate (the same CVE, same host, recurring within a defined window after closure) with a flat or shrinking open count is the clearest sign of a broken verification stage: the numbers look good because retesting isn’t happening, not because the risk went away.
- Mean time to remediate holding steady while mean time to close keeps growing usually means the remediation stage itself is fine but verification is queued behind other work.
Tracking cycle time per stage, not just an aggregate mean time to remediate, is what makes these patterns visible early instead of six months into a compliance audit.
Self-Check: Mapping Your Current Process Onto the Model
For each of the six stages, answer three questions in writing. If you cannot answer one of them for a given stage, that is the stage to fix first.
- Who is the named owner of this stage today, by role, not by team name?
- What system or tool produces this stage’s output, and is that output structured data or a person’s judgment call?
- What starts and stops the clock for this stage, and is that clock enforced anywhere, or just documented in a policy nobody checks?
Programs that can answer all three questions for all six stages tend to have short, predictable cycle times even with large finding volumes. Programs that can only answer them for remediation, which is usually the most visible and most staffed stage, tend to have the exact backlog-that-never-shrinks problem described above, because the bottleneck is upstream or downstream of the part everyone is watching.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.