A single vulnerability does not appear and disappear in one step. It is discovered, checked against what you already know, scored, handed to an owner, fixed, re-tested, and finally closed. Each of those moments is a distinct stage with its own purpose, its own inputs, and its own exit condition. When teams talk about the vulnerability lifecycle stages, they are describing this ordered path that every finding travels from the moment it is observed to the moment it leaves your active workload.
This explainer walks through each stage in plain terms. It defines what the stage is, what changes during it, and how you know a finding is ready to move on. The goal here is the definition itself, not the deep mechanics of any single step. Where a stage has its own engineering detail, such as how a triage queue is worked or how a status state machine enforces transitions, this guide points you to a more focused read. If you want the full end-to-end view of how these stages connect into a running program, the vulnerability management lifecycle pillar covers the whole picture.
What “Vulnerability Lifecycle” Means
The vulnerability lifecycle is the full sequence of states a single finding passes through, from first observation to final resolution. A finding is one vulnerability on one asset. That scoping matters, because the lifecycle is tracked per finding, not per scan and not per CVE. The same weakness on two servers is two findings, and each one runs its own lifecycle.
In a vulnerability management platform, the finding record owns this entire life. It carries creation, deduplication, triage, assignment, the status workflow, SLA tracking, re-testing, evidence, external ticketing, and reporting export. Thinking in stages is simply a way to break that single record’s journey into readable phases. The standards community describes the same idea at the program level. NIST SP 800-40 Rev. 4 frames remediation as an ongoing cycle of identifying, prioritizing, and resolving flaws rather than a one-time event, and the SANS vulnerability management maturity model treats discovery, assessment, and remediation as repeating functions rather than a checklist you finish once.
The stages below are the practical breakdown of that cycle as it applies to a single finding.
Stage 1: Discovery and Intake
Discovery is where a vulnerability first enters the system as a finding. There are two common origins. The first is a scanner. Tools such as Nessus, Qualys, Rapid7, DAST engines, and SAST engines export results that are ingested as findings. The second is a human. A pentester or analyst can author a finding directly when they observe something a scanner would not catch.
The important definitional point is that both paths produce the same kind of record. A scanner-imported finding and an analyst-written finding share one model. The scanner-sourced one simply carries extra provenance fields such as its scanner source and a scanner reference, while the manual one is created by hand. Intake is the moment that record is created with a title, a description, an affected asset, and an initial severity.
At this stage the finding is raw. It has not yet been compared against everything else you already know about. That comparison is the next stage, and it is what keeps your workload honest.
Stage 2: Deduplication and Normalization
Scanners are noisy by design. Run two tools across the same network and they will report the same weakness twice in different language. Run the same tool next week and it reports the issue again. Without a dedup step, every one of those reports becomes a separate item to triage, and your counts inflate fast.
Deduplication is the stage that collapses repeat reports of the same vulnerability on the same asset into a single finding. The platform decides whether an incoming finding is genuinely new or a restatement of one it already has. On create, a new finding that carries the same fingerprint as an existing open finding in the same company is rejected as a duplicate, unless the caller explicitly forces it through. A fingerprint here is a stable identifier for a vulnerability instance, so two reports that resolve to the same fingerprint are treated as the same finding rather than two.
Normalization sits alongside deduplication. Different scanners name and structure the same issue differently, so their output is mapped into one shared shape before it can be compared and merged. This stage is defined here at the conceptual level. The full mechanics of how a correlation and deduplication engine decides between creating, updating, and reopening a finding are a topic in their own right and worth a dedicated read. For now, the takeaway is simple. After this stage, you hold one record per real issue rather than one record per scanner report.
Stage 3: Triage and Severity Assignment
Triage is where a finding is reviewed and given the priority it deserves. This is the stage that separates a flood of raw results into an ordered work queue. The analyst confirms the issue is real, judges its actual impact in your environment, and sets or adjusts its severity.
Severity governance is a defining trait of this stage. A finding tracks two values. The original severity preserves whatever the scanner reported, and the effective severity is the value the team actually works to. The two are kept separate on purpose, because a scanner’s rating is an input, not a verdict. An issue rated high by a tool may be lower in practice once compensating controls are considered, or higher once exposure is understood. Keeping the original value means you never lose the scanner’s opinion even after a human or a rule changes the working severity.
Triage is also where enrichment pays off. A finding can be linked to a vulnerability template that backfills identifiers such as CWE and MITRE technique references, which gives the analyst more context for the priority call. The detailed how-to of working a triage queue, including the filters, bulk actions, and decision criteria analysts use day to day, is covered in the vulnerability triage workflow guide. This stage, in definition, is the moment a finding stops being raw input and becomes a prioritized item of work.
Stage 4: Assignment and Ownership
A prioritized finding with no owner goes nowhere. Assignment is the stage that gives a finding a responsible party so remediation can actually begin. In practice this means routing the finding to the person or team who owns the affected asset or the relevant fix.
Modern platforms allow more than one owner. A finding can carry multiple assignees, and those assignees can be individual users or whole teams, not just a single name. The same flexibility applies to attribution on the discovery side, where a finding records who found it through a found-by relationship that also supports both users and teams. This matters because real remediation often crosses boundaries. A platform owner, an application team, and a third party may all touch one fix.
Assignment is also the point where the status workflow starts to move on its own. When a finding that is still in the open state is assigned, its status flips to assigned automatically. That small automation is the bridge between triage and active work, and it leads directly into the next stage.
Stage 5: Remediation in Progress
Remediation in progress is the working stage, where the owner actually fixes the underlying weakness. From a lifecycle perspective, this is usually the longest stage, and it is the one that SLAs are written to govern. A finding here typically sits in one of three states. It is open if nobody has picked it up, assigned once it has an owner, and in progress once work has actively begun.
The fix itself happens outside the tool. Someone patches a system, updates a dependency, changes a configuration, or rewrites vulnerable code. The lifecycle’s job during this stage is to track that the work is moving and to hold the finding accountable to its deadline. A finding does not jump straight from in progress to closed, though. Before it can be considered resolved, the claimed fix has to be proven, and that proof is the next stage.
How Status Moves Through a State Machine
Status does not change freely. The lifecycle is enforced by a state machine that only allows specific transitions, so a finding can never skip from a working state to a closed one without passing through verification. The defined states are open, assigned, in progress, retest, reopened, not accessible, closed, false positive, and accepted risk. The allowed moves between them are fixed.
From open, a finding can move to assigned, in progress, false positive, accepted risk, or not accessible. From assigned, it can move to in progress, false positive, accepted risk, or not accessible. From in progress, it can move to retest, false positive, accepted risk, or not accessible. From retest, it can move to closed, reopened, or not accessible. A reopened finding can go back to in progress or to retest. A not accessible finding can return to open, or move to false positive, accepted risk, or closed. Any move outside this map is rejected as an invalid transition.
The platform exposes the allowed next statuses for a finding’s current state, which lets the interface offer only the legal choices rather than a free-form dropdown. This is why the lifecycle stays consistent across thousands of findings. The rules live in the model, not in each person’s habits. The granular workflow that analysts follow inside these states is detailed in the triage workflow guide.
Stage 6: Verification and Re-Test
Verification is the stage that proves a fix actually worked. A claim that something is patched is not the same as confirmation that the vulnerability is gone. Re-test is how that confirmation is captured, and the lifecycle treats it as a required step rather than an optional courtesy.
There are two flavors of re-test. An analyst-driven re-test is a manual cycle where a tester re-checks the issue and produces a re-test record of the result. A vendor-driven re-test is evidence captured from the tooling itself, such as a code snippet, a taint flow, or a dependency graph for static and composition findings, or an asynchronous re-check against a running target for dynamic findings. Either way, the finding enters the retest state while this happens, which is exactly why the state machine routes in progress findings to retest before they can close.
Verification has a built-in fork. If the re-test confirms the fix, the finding is cleared to close. If the re-test shows the issue is still present, the finding is reopened instead. The reopened state is a real lifecycle position, not a deletion and re-entry. The finding keeps its history and goes back to active work, where it can be put back in progress or re-tested again. This loop is what stops a vulnerability from being marked done on someone’s word alone. NIST SP 800-115 makes the same point at the program level, treating retesting as the way you validate that remediation was effective rather than assumed.
Stage 7: Closure and Reporting
Closure is where a finding leaves the active workload. The lifecycle defines several terminal states, meaning states a finding can enter but not transition out of. Closed is the most common, reached only from the retest state after verification succeeds. That ordering is deliberate. A finding cannot be closed without first being re-tested, which keeps closure honest.
Closed is not the only ending. A finding can also terminate as false positive when triage or re-test shows it was never a real exposure, or as accepted risk when the organization makes a documented decision to live with the issue. Both are terminal, the same as closed, and both represent a legitimate, audited resolution rather than an unresolved gap. There is also a not accessible state for findings that cannot currently be reached or verified, which is not terminal and can return to open or move on to one of the terminal outcomes.
Reporting is the natural companion to closure. Once findings reach terminal states, they feed the metrics, exports, and audit evidence that show a program is working. The audit-logged history of every status change is what lets a manager or an auditor reconstruct exactly how a finding moved from open to closed and who acted at each step. This is the point where the lifecycle of one finding becomes a data point in the health of the whole program.
Where SLAs Fit Across the Stages
An SLA is the committed timeframe to remediate a finding, and it threads through the active stages rather than sitting in just one. The deadline is set from severity. Higher severity earns a shorter window, and the resolved deadline can be overridden per project or per company so different parts of an organization can hold different standards.
The SLA clock starts once a finding is real and active, runs through assignment and remediation in progress, and stops when the finding reaches a terminal state. It is not a rigid countdown either. The lifecycle supports pausing and resuming the clock, which matters when work is legitimately blocked through no fault of the owner. When the deadline passes while a finding is still open, that is an SLA breach, and the platform tracks escalation and its history so a breach is visible rather than silent.
One nuance worth flagging is what happens when severity changes during triage or re-test. Because the deadline is derived from severity, changing the severity has to recalculate the deadline so the promise stays consistent with the new priority. The full recalculation logic is its own topic. For this guide, the point is that SLAs are not a separate stage. They are a constraint layered across discovery through closure, giving every other stage a clock to answer to.
A Quick Reference Table of Lifecycle Stages
| Stage | Purpose | Typical status |
|---|---|---|
| Discovery and intake | Capture the vulnerability as a finding | open |
| Deduplication and normalization | Collapse repeat reports into one finding | open |
| Triage and severity assignment | Confirm and prioritize the finding | open |
| Assignment and ownership | Route the finding to a responsible owner | assigned |
| Remediation in progress | Fix the underlying weakness | in_progress |
| Verification and re-test | Prove the fix worked | retest, reopened |
| Closure and reporting | Resolve and record the finding | closed, false_positive, accepted_risk |
This table is a summary, not the rulebook. The real ordering is enforced by the state machine described above, where not accessible and reopened handle the cases that a clean linear path does not. Use the table to picture the flow, and use the state machine when you need to know exactly which move is legal next.
Why Knowing the Stages Helps
Naming the stages is not academic. It changes how a team works. When everyone agrees that a finding is in triage rather than remediation, they stop arguing about whether it is anyone’s job yet. When closure is defined as something that can only follow verification, nobody quietly marks an issue done without proof. When SLAs are understood as a clock across stages rather than a single deadline at the end, the urgency lands on the right people at the right moment.
The stages also make a program measurable. Each stage has a clear entry and exit, so you can ask useful questions. How long do findings sit before triage? How many reopen after a failed re-test? How many breach their SLA before they are assigned? Those questions only have answers because the lifecycle is broken into defined, tracked stages. A program that treats vulnerabilities as a flat to-do list cannot answer any of them.
If you want to see how these stages connect into orchestration, analytics, and reporting across a real program, the vulnerability management lifecycle pillar covers the end-to-end view. If you want the operational depth of one stage in particular, the vulnerability triage workflow guide goes deep on how findings are worked once they are in the queue.
Frequently Asked Questions
What are the stages of the vulnerability management lifecycle?
The stages are discovery and intake, deduplication and normalization, triage and severity assignment, assignment and ownership, remediation in progress, verification and re-test, and closure and reporting. Each stage has a defined purpose and a clear exit condition, and a finding moves through them in an order enforced by a status state machine. SLAs run across the active stages rather than forming a stage of their own.
What is the difference between triage and remediation?
Triage is the decision stage. An analyst confirms a finding is real and sets its priority and severity. Remediation is the action stage that follows, where the owner actually fixes the weakness. Triage answers how urgent this is and who should own it. Remediation answers whether the fix is done. A finding is prioritized in triage and then resolved in remediation, and the two are never the same step.
What does re-test mean in vulnerability management?
Re-test means verifying that a claimed fix actually worked before the finding is closed. It can be analyst-driven, where a tester re-checks the issue and records the result, or vendor-driven, where the tooling captures evidence such as a code snippet, a taint flow, or a dynamic re-check. If the re-test passes, the finding can close. If it fails, the finding is reopened and goes back to active work.
When is a vulnerability considered closed?
A vulnerability is considered closed only after verification succeeds. In the state machine, a finding reaches the closed state from the retest state, which means it cannot be closed without first being re-tested. This ordering is deliberate. It prevents a finding from being marked resolved on someone’s word alone and keeps closure backed by proof.
What is a terminal status for a finding?
A terminal status is a state a finding can enter but cannot transition out of. There are three. Closed is reached after a successful re-test. False positive is used when the issue turns out not to be a real exposure. Accepted risk is used when the organization makes a documented decision to live with the issue. All three represent a final, audited resolution rather than an open gap.
Why are duplicate findings removed during the lifecycle?
Scanners overlap and repeat, so the same vulnerability on the same asset can be reported many times. Deduplication collapses those repeats into one finding using a stable fingerprint, so a new report that matches an existing open finding is treated as the same issue rather than a new one. This keeps counts accurate, keeps triage focused on real work, and keeps program metrics meaningful.
Do SLAs apply to every stage of the lifecycle?
SLAs apply across the active stages rather than to a single one. The deadline is derived from severity and can be overridden per project or company. The clock starts once a finding is active, runs through assignment and remediation, can be paused and resumed when work is legitimately blocked, and stops at a terminal state. If the deadline passes while the finding is still open, that is a breach, which triggers tracked escalation.
