Vulnerability management is the ongoing process of finding weaknesses, deciding which ones matter, fixing them, and confirming the fix worked. It is a programme, not an exercise.
The short answer
Vulnerability management is the continuous cycle of discovering assets, identifying weaknesses, prioritising them by real risk, remediating them, and verifying closure. Scanning and assessment are steps inside it. What makes it a management programme is ownership, agreed timeframes for fixing things, and evidence that the loop keeps running.
The difference between a scan and a programme is what happens after the report. Most teams can produce findings. Fewer can show who owned each one, how long it took to close, and the trend over six months. That last part is what an auditor asks for.
On this page
The lifecycle
Five stages, running continuously. Skipping the last one is the most common failure, because unverified fixes quietly reappear in the next scan.
Deciding what to fix first
Severity alone is a poor filter: it describes the vulnerability, not your exposure to it. Four inputs together give a workable order.
| Input | What it tells you |
|---|---|
| CVSS severity | How damaging the weakness is in the abstract. A starting point, not an answer. |
| Known exploited status | Whether the vulnerability is being used in real attacks. CISA’s KEV catalogue tracks this. |
| Exploit likelihood | The probability of exploitation in the near term. EPSS scores provide this. |
| Asset context | Whether the affected system is internet-facing, holds customer data, or sits behind a control that already blocks the path. |
The practical filter
Anything critical on an internet-facing asset that is also in the known exploited catalogue goes to the top, regardless of what else is queued. That single rule removes most prioritisation arguments.
Remediation timeframes
Auditors ask whether timeframes are documented and met. Any defensible set works, provided it is written down and measured.
Metrics that matter
Time to remediate
Average days from detection to verified closure, tracked per severity.
Coverage
The share of known assets actually being scanned. Gaps here invalidate every other number.
Recurrence
Findings that return after being closed, which points at process rather than at engineering.
How Osto supports the programme
Osto runs discovery and assessment continuously across applications, APIs, code dependencies, endpoints and cloud accounts, with findings rated by severity and mapped to affected endpoints. Because the same platform runs the WAF, CSPM and compliance modules, prioritisation can account for controls already limiting a finding, and closure evidence is produced where the work happened rather than assembled afterwards.
Free security assessment
Close the loop, not just the ticket
Continuous discovery, ranked findings and verified closure across your applications, cloud and endpoints, from one platform.
Get a free security assessment Book a platform walkthroughContinuous coverage · Evidence auditors accept · One platform, everything
Frequently asked questions
What is vulnerability management?
Vulnerability management is the continuous process of discovering assets, identifying weaknesses, prioritising them by real risk, remediating them and verifying closure. It differs from scanning or assessment because it includes ownership, agreed remediation timeframes and evidence that the cycle keeps running.
How is it different from a vulnerability assessment?
An assessment is a point-in-time exercise producing a ranked list of findings. Management is the programme around it: the assessment is one stage, followed by prioritisation, remediation, verification and measurement, repeated continuously.
What remediation timeframes should we set?
A common pattern is seven days for critical, thirty for high, ninety for medium, and the next scheduled cycle for low. What matters to an auditor is that the timeframes are documented, applied consistently and measured, rather than the specific numbers chosen.
Do frameworks require vulnerability management?
Yes. ISO 27001:2022 addresses it in Annex A 8.8, PCI DSS requires quarterly scanning and defined remediation under Requirement 11, and SOC 2 auditors look for evidence of identification and remediation under CC7.1. All of them expect a repeatable process rather than a single report.
What is the most common failure in a programme?
Incomplete asset discovery. Findings on systems nobody recorded are never triaged, and coverage gaps make every other metric misleading. The second most common is skipping verification, which allows closed findings to reappear unnoticed.