The vulnerability management lifecycle: how to prove every stage happened

The NIS2 compliance review is next quarter. The auditor's questionnaire has a section on vulnerability management. It does not ask whether you run scans. It asks whether you run a programme.

There is a difference. You know you run scans. Whether what you have constitutes a programme, whether there is an evidence trail that satisfies an auditor who reads the questionnaire carefully, is the question this article answers.

By the end, you will have a complete picture of each stage in the vulnerability management lifecycle, the specific evidence that stage must produce, and what an auditor is looking for when they ask for proof.

What is the vulnerability management lifecycle?

The vulnerability management lifecycle is a continuous, repeating process that organisations use to identify security weaknesses, assess and prioritise them, fix them, confirm those fixes, and generate a documented record of the whole sequence. It is not a one-off scan, not a quarterly report, and not a set of ad-hoc remediation tickets. It is a permanent operating model.

The word "lifecycle" is precise. Vulnerabilities are not a fixed list you work through once. New CVEs (Common Vulnerabilities and Exposures, the public identifiers assigned to disclosed software flaws) are published every day, and the volume is climbing: FIRST forecasts roughly 59,000 published CVEs in 2026, the first year projected to exceed 50,000. Your environment changes continuously: new servers, updated dependencies, changed firewall rules, new subdomains. The lifecycle re-runs on a schedule and on every material change, because the attack surface is never static.

Roughly 59,000 CVEs are forecast for 2026. The first year ever projected to exceed 50,000.

How is vulnerability lifecycle management different from running a one-off scan?

Vulnerability lifecycle management is the ongoing process of discovering, assessing, remediating, and proving remediation across your full environment. A one-off scan is a single stage of that process, producing a point-in-time findings list. One without the other is not a programme. The scan tells you what exists. The lifecycle tells you what happened to each finding.

An auditor asking for evidence of a vulnerability management programme is not asking for a scan report. They are asking for a trail: the scan ran on a specific date, each finding was assessed with a documented priority rationale, each was assigned to a named owner with a deadline, each was remediated and rescanned, and the rescan confirmed the fix. That complete trail is what the lifecycle produces. A findings list is the beginning of it.

What is the correct order of the vulnerability management lifecycle?

The correct sequence is Discover, Assess, Prioritise, Remediate, Verify, and Report. Each stage feeds the next, and skipping or reordering any of them creates gaps that surface at audit time rather than at runtime.

The 4-step, 5-step, and 6-step models across NIST, ISO 27001, and vendor documentation all describe the same underlying process at different levels of granularity. The table below maps the major variants:

This article follows the 6-stage model. Report is kept as a distinct stage because producing auditor-verifiable evidence is operationally separate from confirming a fix. Programmes that collapse the two are where most compliance gaps appear: the fix is confirmed, the evidence of the fix is never packaged in a form an auditor can verify.

What are the six key phases of a vulnerability management lifecycle?

The six phases of the vulnerability management lifecycle are Discover, Assess, Prioritise, Remediate, Verify, and Report. Each phase has two layers: the operational action (what most guides describe) and the evidence artefact that action must produce (what almost no guide describes). The evidence layer is what turns a scanning habit into a documented programme.

What follows is each stage: the action in brief, and the specific artefact it must generate.

Stage 1: Discover

Discovery maps every asset in scope: servers, subdomains, IP ranges, APIs, code repositories, and cloud resources. The output is a current, accurate inventory of what is under management. Assets that are not in scope are, by definition, outside the programme, and findings on them will not appear in your audit trail.

Continuous asset discovery matters here because scope drift is constant. A new subdomain appears when a developer spins up a preview environment. A new port opens when a service is reconfigured. A baseline captured once and never updated is stale within weeks. A continuous attack surface monitor maintains the inventory passively, flagging new assets as they appear without requiring a manual trigger.

What evidence does Discover produce?

The Discover stage must produce a dated asset inventory: each target's first-seen date, its current scope status, and a log of scope changes with a reason and date for each. This is the reference against which all later scan coverage is assessed. Without a recorded baseline, an auditor cannot determine whether a scan covered the full environment or only part of it. The baseline is not a one-time document. It is a living record, and the change log is part of the evidence.

Stage 2: Assess

Assessment runs the vulnerability scan against every in-scope asset. This is where the technical detection happens: probing ports, testing web applications, analysing code, checking DNS configuration, validating SSL certificates. Each finding is matched against the National Vulnerability Database, assigned a CVE where one exists, and enriched with a CVSS (Common Vulnerability Scoring System) severity score and an EPSS (Exploit Prediction Scoring System) probability score that estimates the likelihood of active exploitation within 30 days.

This stage has its own dedicated guide. For the full account of how vulnerability scanning works, which attack surfaces it covers, and what authenticated versus unauthenticated scans test differently, the detail is in how vulnerability scanning works. This article picks up from where that one ends.

What evidence does Assess produce?

The Assess stage must produce a scan record distinct from the findings report. The scan record shows:

• The target.
• The scan type.
• The scanner engine versions used.
• The scheduled or manual trigger.
• The start and end timestamps.

The findings report shows what was found. The scan record proves the scan ran, when it ran, and what it covered. For audit purposes, you need both. A findings list without a scan record does not prove coverage; it only proves what was found within whatever coverage happened.

Stage 3: Prioritise

Prioritisation determines which findings get fixed first. You cannot fix everything, and the data behind the backlog is no longer neutral on this point. NIST reports that CVE submissions rose 263% between 2020 and 2025, and in response the National Vulnerability Database moved to a prioritised enrichment model: it now triages which CVEs it enriches first rather than processing every one. When the database that feeds your scanner has to prioritise, an unranked remediation queue is not defensible. The standard inputs are the CVSS score, the EPSS probability, the KEV flag from the CISA Known Exploited Vulnerabilities catalog, and business context: is this asset customer-facing, is it in scope for a compliance framework, is it accessible from outside the network?

CVE submissions rose 263% in five years. The National Vulnerability Database now triages which CVEs it enriches first, rather than processing every one. When the database feeding your scanner has to prioritise, an unranked queue is not defensible.

The CVSS score is the severity of the vulnerability in isolation. The EPSS score is the probability that the vulnerability is actively being exploited in the wild within 30 days. The KEV flag confirms active, real-world exploitation has already been documented. A finding with CVSS 7.5 and EPSS 0.2% is generally less operationally urgent than a finding with CVSS 5.8 and EPSS 72%. Risk-adjusted prioritisation using all three signals produces a defensible, auditable ordering.

What almost no programme records is the reasoning behind the order. The scores are captured. The decision is not. An auditor reviewing a remediation queue where a Critical-CVSS finding was not addressed first will ask why. If the answer is documented, that a lower-CVSS finding was elevated because it had a 68% EPSS score and sat on an internet-facing asset, that is a defensible answer. If the only record is the queue order itself, with no rationale, it is not.

What evidence does Prioritise produce?

The Prioritise stage must produce a priority decision record for each finding above the programme's remediation threshold. This does not require a separate document. A finding card in a vulnerability management platform should carry the CVSS score, the EPSS score, the KEV flag where applicable, the assigned risk-adjusted priority level, and a note for any manual override. The note is the evidence. Without it, the decision is invisible to anyone reviewing the programme later.

Stage 4: Remediate

Remediation assigns each finding to the person or team responsible for the fix, sets a deadline based on severity, and tracks progress until the finding is confirmed closed. SLA (Service Level Agreement) thresholds define the deadline by severity level: how long a finding at each severity is allowed to stay open before it counts as overdue. The escalation path defines what happens when that deadline is missed.

Most programmes have SLAs on paper. Fewer have escalation paths that fire. A Critical finding assigned to a developer with a 7-day SLA is only a meaningful control if something happens on day 8 when it is still open. If nothing happens, the SLA is documentation rather than a control. The escalation is what makes the SLA a real commitment.

The gap here is industry-wide, not a small-team problem. The 2026 Verizon Data Breach Investigations Report found that vulnerability exploitation has become the leading initial access vector for breaches, yet organisations fully remediated only 26% of the known-exploited vulnerabilities in CISA's KEV catalog during 2025, taking a median of 43 days to close the ones they did fix. Scanning is not the bottleneck. Remediation to closure is.

Only 26% of CISA KEV vulnerabilities were fully remediated in 2025. Median time to close: 43 days. Vulnerability exploitation is now the leading initial access vector for breaches.

What evidence does Remediate produce?

The Remediate stage must produce an assignment record and an SLA trail. The assignment record shows who received the finding, when, and at what priority level. The SLA trail shows the deadline, the escalation events that fired with their timestamps and recipients, and the date the finding was marked resolved by the assignee. If the deadline was extended, the extension must be logged with a reason. If the finding was escalated, the escalation record shows who was notified, when, and whether they acknowledged it. This trail demonstrates the fix was managed to completion, not just completed.

Stage 5: Verify

Verification rescans the affected asset after remediation is marked complete. If the finding no longer appears in the rescan, the platform closes it automatically with a confirmed-resolved status and a timestamp tied to the rescan job. If the finding still appears, it is reopened, the SLA resets, and the assignee is notified.

Most programmes treat the assignee's "done" status as sufficient proof. It is not. A developer can mark a finding resolved without the fix being deployed, without the fix being effective, or without the fix reaching the affected asset. The only proof that holds at audit is a rescan result showing the finding absent, with the rescan date, scope, and job ID attached to the original finding record.

How do you verify and prove a vulnerability was remediated?

To prove a vulnerability was remediated, the affected asset must be rescanned after the fix is marked complete. The rescan must cover the same attack surface as the original detection scan. If the finding does not appear in the rescan, the platform auto-closes it with a confirmed-resolved status and a tamper-evident timestamp. That timestamp, linked to the rescan job ID and the original finding record, is the evidence. A "clean report" from a rescan that covered different scope, or that could not reach the target, proves nothing.

Stage 6: Report and prove

The Report stage produces the documentation that shows the programme ran. Most programmes stop here at a dashboard, a PDF export, or a summary for the board. That output is useful but insufficient for a formal compliance review. An auditor examining a NIS2 or ISO 27001 audit does not read a dashboard. They request evidence for a specific finding or control and they want something they can verify independently, not a report that your platform produced and you could have edited.

The evidence chain is the layer that almost no guide reaches. It is not a report. It is a per-finding, tamper-evident record of every state change that finding passed through, from detection to confirmed resolution, with a cryptographic verification chain that proves the record was not altered after the fact. The chain uses SHA-256 hashing over each recorded event, advisory-locked at write time to prevent concurrent modification, with microsecond-truncated timestamps that make retroactive editing detectable.

What is an auditor pack for vulnerability management?

An auditor pack is a structured export of the evidence for a specific vulnerability finding or for the programme as a whole. A per-finding pack contains:

• Scan record: the original scan that detected the finding.
• Finding card: CVSS and EPSS scores plus the priority rationale.
• Assignment and SLA trail: the owner, the deadline, and any escalations.
• Rescan record: the confirmed-resolved timestamp.
• Compliance mapping: which ISO 27001, NIS2, DORA, or other controls the finding was relevant to.

Its manifest also carries a chain verification result an auditor can use to confirm the event log matches the hash chain and was not modified after the fact.

A tenant-wide auditor PDF covers the same evidence across all findings in a defined date range, formatted for an auditor who needs programme-level coverage rather than individual finding detail. Manual attestation, for controls that require human sign-off rather than automated evidence, adds per-control attestation records with attached file evidence, a sign-off history, and reminder scheduling for recurring controls.

A full evidence architecture contains the complete per-finding trail, from scan record through to rescan-confirmed resolution, packaged so an auditor can verify it independently (learn more at vornin.com/features). Vornin produces the evidence at each stage automatically, without requiring anyone to assemble it after the fact.

Why most models show six stages (and where the seventh hides)

The 6-stage model is the consensus because it maps cleanly to how programmes operate in practice and how compliance frameworks describe technical controls. Discover, Assess, Prioritise, Remediate, Verify, Report. The operational loop is complete.

The seventh stage is Govern: the policy layer that defines who owns the programme, what the SLA thresholds are by severity level, how scope is determined and reviewed, how exceptions are recorded and approved, and how the programme itself is audited periodically. Govern sits outside the operational loop because it defines the parameters the loop runs within, not the loop itself.

Organisations without a dedicated security team typically do not have a separate governance function. The IT Manager writes the policy, runs the programme, and reviews it. That is a workable model provided the policy exists in writing, defines SLA thresholds and scope criteria, and records exceptions when the programme deviates from them. ISO 27001:2022 Annex A A.8.8 requires documented technical vulnerability management procedures. The seventh stage is that documentation, and auditors check for it.

How is a vulnerability management lifecycle different from running a vulnerability scan?

A vulnerability scan is stage 2 of the lifecycle. Running scans regularly is not the same as running a programme. A programme is the full loop: a current asset baseline, scheduled scanning across the full environment, prioritisation with documented rationale, remediation with SLA enforcement and escalation, rescan-based verification with timestamped confirmation, and a tamper-evident evidence trail exportable for audit.

The distinction matters for two reasons. First, compliance frameworks treat them differently. NIS2 Article 21 and ISO 27001:2022 A.8.8 require a vulnerability management process, not a periodic scan. A scan report does not satisfy that requirement on its own. Second, the operational risk profile is different. A programme catches whether fixes landed. A scanning habit catches what is broken but provides no assurance that the fix took hold. Without verification, a finding can be marked resolved in a ticket and remain exploitable in production for months.

The situation that drives most organisations to formalise the lifecycle is precise: they have been running scans and are now told, by a NIS2 supervisor, an ISO auditor, or an enterprise customer's procurement questionnaire, that they need to demonstrate a programme. The scan is already running. The gap is the evidence trail that turns scanning activity into a documented, auditable operating model. The situation most teams arrive in is this: "We need to show we have a vulnerability management programme, not just a scanner."

How the vulnerability management lifecycle maps to NIST SP 800-40

NIST SP 800-40 Rev 4 (August 2022) describes enterprise patch management planning. It defines the work as "the process of identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades throughout an organization." Because patching is the primary remediation action for most vulnerability types, that framing maps directly to the vulnerability management lifecycle with only minor differences in terminology.

NIST SP 800-40 does not include a standalone Report stage because its scope is patch operations, not compliance evidence. The Report and Prove stage maps to the broader NIST SP 800-53 Rev 5 CA-7 (Continuous Monitoring) and RA-5 (Vulnerability Monitoring and Scanning) controls, which require documented evidence of monitoring activities and results.

For NIS2 Directive Article 21, the requirement for "appropriate and proportionate technical measures" to manage cybersecurity risk maps to the full 6-stage lifecycle. Article 21(2)(e) is explicit that those measures cover "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure." Periodic scanning satisfies one stage. Documented, verifiable remediation to closure satisfies Article 21. The evidence chain is what makes the remediation verifiable.

For ISO 27001:2022, the relevant controls are A.8.8 (Management of technical vulnerabilities) and A.5.23 (Information security for use of cloud services). A.8.8 requires timely identification, evaluation, and remediation of technical vulnerabilities. The evidence that satisfies the auditor for A.8.8 is the same trail the lifecycle produces: scan records, prioritisation rationale, SLA-tracked remediation, and rescan-confirmed resolution.

Conclusion

The vulnerability management lifecycle is not the hard part. Any organisation running scans is already doing some version of stages 1 and 2. The hard part is the evidence layer: ensuring that each stage produces an artefact an auditor can verify, that the artefacts are tamper-evident, and that the complete trail is exportable when the questionnaire arrives.

For an IT manager running compliance without a dedicated security team, that evidence layer cannot be assembled manually. The programme has to generate it automatically at every stage, without requiring anyone to remember to document what happened. This is what Vornin is built to do.

Frequently Asked Questions