Vulnerability management process flowchart (scan to verified closure)

What the vulnerability management process flowchart (scan to verified closure) process is

Vulnerability management is the recurring operational cycle that finds known weaknesses across an estate, decides which of them matter, gets them fixed and proves it. The trigger is a schedule rather than an event: a scan window opens against the asset inventory, and everything downstream depends on that inventory being right. The chart below follows one cycle end to end. The scan scope and credential coverage are agreed before anything is scanned, the authenticated scan runs, vendor advisories arrive alongside the scanner's own output, findings are deduplicated and confirmed, a rating combines severity with exploitability and what the asset actually holds, a deadline and a named owner are attached, a change carries the fix, a rescan either closes the finding or reopens it, and the register and the metrics are what management reviews before the next window opens.

This is the programme, not the fix. What one system owner does inside a single ticket — validating the finding against their own build, choosing between a patch, an upgrade, a configuration change and a decommission, testing it and deploying it — is the vulnerability remediation process, and it hangs off the single 'Apply the patch, config or compensating control' step drawn here. The vendor patch itself, with its applicability assessment, non-production testing, ring deployment and rollback, is patch management, a separate cycle that this one consumes rather than contains. And the full security exception workflow — business justification, compensating controls, an approval level that follows the risk rating, a register entry and a renewal review — sits behind the 'Exception approved with an expiry date?' decision rather than inside it. Keeping those boundaries visible is what stops one chart trying to be three. Treat what follows as a starting point to be adapted under your own security policy, your regulatory obligations and the judgement of a competent security practitioner.

Four decisions carry the process. 'Every in-scope asset scannable?' comes first because coverage failures are invisible: an asset no scan template reaches produces no findings, and a clean dashboard and an unscanned estate look identical from the report. 'Known exploited or critical severity?' is the prioritisation split, and it sits in the analyst's lane because the exploit evidence is theirs, while the emergency track it opens sits with Security management, who hold the authority to interrupt other work. 'Remediable within the SLA?' is deliberately in the System owner / IT operations lane rather than the analyst's — the person who has to make the change is the person who knows whether the window exists — and its negative branch leads to an exception decision owned by Security management, because accepting risk is a management act rather than an engineering one. 'Rescan shows the finding closed?' hands the process back to the analyst, so that closure rests on evidence rather than on someone marking a ticket done.

What this flowchart covers

In this template

• Five swimlanes (Vulnerability analyst, System owner / IT operations, Change manager, Security management and Vendor) across six phases: scope and discovery, scan and intake, triage, prioritise and assign, remediate and verify, and report and review
• A coverage gate before any scanning: "Every in-scope asset scannable?" sends missing credentials and undeployed agents back to be fixed, because an asset the scanner cannot authenticate against reports almost nothing and still counts as scanned
• Two intake routes into one queue: the scanner's own output, and a vendor advisory arriving on the "Publish the advisory and the fixed release" step, so something announced between scan windows does not sit unowned until the next cycle
• A triage pair most charts collapse into one box: "Finding confirmed on the asset?" routes unconfirmed results to "Suppress as a false positive with evidence", a closed terminal that still demands a reason, an expiry and an approver
• Rating and deadline as separate acts: "Score by CVSS, exploitability and asset value" produces the rating, "Known exploited or critical severity?" splits emergency work from the routine band, and only then is a fix owner named and accountable
• Closure on evidence, with two loops and an escape: "Rescan shows the finding closed?" reopens anything still present, "Remediable within the SLA?" routes to "Exception approved with an expiry date?", and overdue findings escalate before metrics are published

When to use this template

• You are writing or rewriting a vulnerability management standard and need one picture of who scans, who rates, who fixes and who accepts the residual risk
• Findings are ageing past their deadlines and nobody can say whether they stall at triage, at assignment, at the change window or at the rescan
• You are selecting or replacing a scanner and want the process agreed before scan policies, credential stores, asset groups and SLA bands are configured
• Security and IT operations disagree about what counts as remediated, so the rescan, the exception route and the escalation path need to be explicit and owned
• An auditor or a customer security questionnaire has asked for a documented description of how vulnerabilities are identified, rated, remediated and verified

How it works

1. Rename the lanes to your roles

   Replace Vulnerability analyst, System owner / IT operations, Change manager, Security management and Vendor with the roles you actually have. In a small team the analyst and the system owner are often the same person, so merge those lanes rather than drawing a handoff that only exists on paper. Keep Security management separate even then, because the exception and escalation branches need an authority who is not also the fixer.

2. Write your scan scope and coverage rule

   State which assets are in scope, how they get there from the inventory or CMDB, which are scanned with credentials or an agent and which are not, and how often each group is scanned. Note the exclusions and who may grant one. Coverage is the number that makes every other number in the programme mean something, so put it on the chart rather than leaving it in a tool setting nobody reads.

3. Define how a finding is rated

   Say which severity scale you use and where the score comes from, then say what you add to it. A severity score describes technical impact; exploitation evidence and asset context describe how much you should care this week. Write down the combination you actually use, name its inputs, and record who may override a rating and on what evidence that override rests.

4. Set the SLA bands and start the clock

   Put your own remediation deadlines on the chart and delete the placeholders. Agree each band with the owners who have to meet it, and be explicit about when the clock starts, because detection date, ticket date and vendor publication date produce very different ageing reports from the same estate. State what the emergency track means in practice and who may open it.

5. Agree the exception and escalation route

   Decide who may approve an exception, what evidence goes with it, the longest life it may have and what compensating control must be running while it does. Then agree the escalation for anything overdue without an exception: who is told, at what age, and what happens if nothing changes after that. Both routes need a named individual rather than a shared mailbox.

6. Decide what proves a finding is closed

   Closure should rest on a rescan of the affected asset, not on a ticket being marked done. Write down which scan proves it, how soon it runs after a fix, and what happens when the rescan still reports the finding. Record whether a compensating control closes a finding or only reduces it, because those two conventions produce very different registers and very different metrics.

7. Walk it against a real finding

   Take two findings from the last cycle, one that closed on time and one that went overdue or ended as an exception, and trace both through the chart. Any step people describe that is not drawn, and any drawn step that is quietly skipped in practice, is the finding worth acting on before you publish the process to anyone else.

Frequently asked questions

What are the steps in a vulnerability management process?

A scan cycle opens against the asset inventory, and the scope and credential coverage are set before anything runs; assets the scanner cannot reach are fixed and rechecked. The scheduled authenticated scan runs, and vendor advisories arriving between scans join the same queue. Findings are deduplicated and enriched with exploit data, then confirmed against the asset, with anything unconfirmed suppressed as a false positive together with its evidence. Confirmed findings are scored on severity, exploitability and asset value, routed to an emergency track or a standard deadline band, and assigned to a named fix owner. The owner either remediates within the deadline, through a change window where one is needed, or requests an exception with an expiry date. A rescan confirms closure or reopens the work. Finally the register is updated, overdue findings are escalated, coverage, ageing and closure metrics are published, and management reviews the trend before the next cycle.

What is the difference between vulnerability management and patch management?

Vulnerability management is the cycle that discovers weaknesses across an estate, rates them and drives them to a verified close, whatever the treatment turns out to be. Patch management is one of those treatments: the operational cycle that takes a vendor release, assesses whether it applies, tests it, schedules it and deploys it. NIST's guidance on enterprise patch management planning (SP 800-40 Revision 4) makes the same point from the other direction, framing patching as preventive maintenance and as one of several ways to respond to the risk a software vulnerability creates. The practical consequence is that a vulnerability programme measured only in patches installed will under-report itself, because configuration changes, upgrades, decommissioning and compensating controls all close findings too, and some findings have no patch to install at all.

Is a CVSS score enough to prioritise remediation?

CVSS, maintained by FIRST, scores technical severity from 0.0 to 10.0, and its qualitative bands in version 3.1 are Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0. Version 4.0, published in 2023, keeps a base score and adds explicit Threat and Environmental metric groups. What CVSS deliberately does not tell you is how likely exploitation is or how much a given asset matters to you. Teams usually add two other signals: an exploit-probability score such as EPSS, also from FIRST, which estimates the probability that a vulnerability will be exploited in the wild in the next thirty days and is recalculated daily, and evidence of actual exploitation such as CISA's Known Exploited Vulnerabilities catalog. Asset context is the third input and it is yours alone. That is why this chart scores and then routes on 'Known exploited or critical severity?' rather than sorting a list by score.

How often should vulnerability scans run, and who owns the process?

Frameworks differ, so take the frequency from whichever applies to you rather than from a general rule. ISO/IEC 27001:2022 Annex A control 8.8, management of technical vulnerabilities, requires that information about technical vulnerabilities in systems in use is obtained, that exposure is evaluated and that appropriate measures are taken, but it sets no interval and leaves the cadence to your risk assessment. PCI DSS version 4 is more prescriptive for cardholder data environments: internal vulnerability scans at least once every three months and after any significant change, performed as authenticated scans, with external scans by an Approved Scanning Vendor. Many organisations scan far more often than the minimum because the cost of another scan is low. On ownership, the usual split is the one drawn here: security owns detection, rating and reporting; the system owner owns the fix; management owns exceptions and escalations. A programme where security also owns remediation tends to stall, because the analyst has neither the change rights nor the operational risk.

What records should a vulnerability management process produce?

Enough to reconstruct any single finding a year later without opening the scanner. In practice that means a register entry per finding carrying the affected asset, the detection date, the rating and what fed it, the assigned owner, the deadline, the treatment chosen and the closure evidence. Alongside it sit the scan configuration and coverage evidence, so a reviewer can tell what was in scope and what was authenticated; the suppression list, with a reason and a review date for every false positive; the exception register, with justification, compensating control, approver and expiry; and the rescan output that closed each finding. Reporting is the last record: coverage, ageing against the deadline bands and closure rate over time, together with what management decided when the trend moved. A reviewer will usually test the register against the scanner rather than the other way round, so unexplained findings that exist in the tool and not in the register are the common finding.