What Is Vulnerability Management? The Process, Stage by Stage
- Vulnerability management is a continuous cycle of five stages: inventory, assess, prioritise, remediate, verify.
- It is not the same as vulnerability assessment - an assessment is a point-in-time snapshot, one stage of the cycle.
- The two stages that break are inventory (you cannot protect assets you do not know about) and verification (nobody checks the fix worked).
- Scanning is one input, not the programme. A scan reports possibilities; a programme is what you do with them.
Vulnerability management is the continuous process of identifying, assessing, prioritising, remediating and verifying weaknesses across your systems. It runs in a loop rather than as a project, and it is not a synonym for scanning - scanning is one input to one stage of it.
The distinction from a vulnerability assessment matters and gets muddled constantly. An assessment is a point-in-time snapshot: what was wrong on Tuesday. Management is the ongoing programme that snapshot feeds.
The five stages
- Inventory. Establishing what you actually have: applications, services, dependencies, endpoints, cloud resources, and who owns each. Continuous, because the estate changes constantly.
- Assess. Examining those assets for weaknesses. Scanning contributes here, and so does penetration testing, code review, and dependency analysis. Different methods find different things.
- Prioritise. Deciding order. Severity, exploitation likelihood, reachability in your specific deployment, and business impact all feed this, and it is the stage most often reduced to sorting by a single score.
- Remediate. Fixing, mitigating, or formally accepting. Accepting is a legitimate outcome as long as it is a decision with an owner and a date, rather than a queue item that aged out.
- Verify. Confirming the fix actually closed the hole. Then back to stage one.
Where programmes actually break
Two stages, consistently, and neither is the assessment.
Inventory. You cannot protect what you do not know exists. The recurring pattern in real incidents is not an unpatched known asset - it is a forgotten one. A staging environment that was never decommissioned, an internal admin tool exposed to the internet, an API version kept alive for one legacy client. None of it appears in a scan of the assets you remembered to scan.
Verification. The fix ships, the ticket closes, and nobody re-runs the specific attack. Sometimes the patch was incomplete. Sometimes it was correct and a later change reintroduced the flaw. Without verification, closed means "someone said so".
The stage everyone invests in is assessment, because it is the one you can buy. The two that decide whether the programme works are the unglamorous ones at either end of it.
Assessment methods are not interchangeable
A frequent source of false confidence is treating one assessment method as covering the ground of another.
| Method | Finds | Misses |
|---|---|---|
| Dependency scanning | Known-vulnerable libraries | Anything in your own code |
| Configuration scanning | Misconfigurations and exposure | Application logic |
| Static code analysis | Dangerous patterns in source | Flaws that exist only at runtime |
| Penetration testing | Exploitable chains, logic abuse | Whatever was left out of scope |
The gap that catches people is the last row of the third method. A broken authorisation check is not a dangerous pattern in the source - the code is written correctly, and the flaw is a decision nobody made. It exists only in the running system, which is why dynamic testing is not optional if you want that class covered.
How each compliance framework treats this cycle is mapped on compliance frameworks and testing.
A note on what this article is not
Worth being direct, because plenty of pages on this topic are a product pitch in a cardigan: Intrudify is not a vulnerability management platform. We do not do asset inventory, we do not aggregate your scanner output, and we are not a network or infrastructure product. We test web applications and APIs, deeply, and we report what we proved.
Vulnerability management is the programme around that. We think the concepts are worth explaining properly whether or not you ever buy anything from us.
Frequently asked questions
What is vulnerability management?
The continuous process of identifying, assessing, prioritising, remediating and verifying weaknesses across your systems. It runs as a loop rather than a project, and scanning is one input to one stage of it rather than the whole thing.
What are the stages of the vulnerability management process?
Five: inventory of what you have, assessment for weaknesses, prioritisation of what to fix first, remediation, and verification that the fix worked. Then the cycle restarts, because both the estate and the threat landscape keep changing.
What is the difference between vulnerability management and vulnerability assessment?
An assessment is a point-in-time snapshot of what was wrong when it ran. Management is the ongoing programme that consumes those snapshots, decides priority, drives fixes, and verifies them. An assessment is one stage of the cycle.
Is scanning enough for vulnerability management?
No, for two reasons. Scanning only examines assets you knew to include, and forgotten assets are a recurring cause of real incidents. And scanners report possibilities rather than confirmed exploitability, so a whole class of flaw - broken authorisation, where the code is written correctly - is invisible to them.