Every security team runs scans. Almost none of them run a real vulnerability management program. There’s a difference, and it’s the reason breaches keep happening at companies that technically “had a scanner.”
A scanner finds problems. Vulnerability management decides which problems matter, fixes them on a deadline, and proves it happened. This post breaks down the actual process, the prioritization math nobody explains clearly, real SLA numbers, and where this discipline gets confused with three other things it isn’t.
What Vulnerability Management Actually Means
Vulnerability management is the continuous cycle of finding security weaknesses across your systems, deciding which ones pose real risk, fixing them, and confirming the fix worked. It is not a one-time audit. It is not a scan report sitting in someone’s inbox. It’s an operating process with owners, deadlines, and metrics attached to it.
It covers:
- Source code and build pipelines
- Cloud infrastructure and workloads
- On-premise servers and network hardware
- Endpoints and employee devices
- Internet-facing applications and APIs
A vulnerability itself is any flaw — a coding mistake, a misconfiguration, an outdated library, a weak authentication setting — that an attacker could use to get in or do damage. That’s distinct from a threat (the attacker) and a risk (what happens if the threat exploits the vulnerability). Most articles blur these three terms together. Keep them separate, because your prioritization decisions depend on it. wtgtechgeek.blog
Why Most Vulnerability Management Programs Fail
Here’s the uncomfortable stat security teams don’t like repeating: most breaches trace back to vulnerabilities that were already known and already had a patch available. Not zero-days. Not nation-state exploits nobody could have predicted. Known flaws that sat unpatched for weeks or months.
That happens for a few concrete reasons:
- Too many findings, no prioritization logic. A mid-size company can generate 10,000+ open findings from a single scan. Nobody fixes 10,000 things. Without a real scoring method, teams either fix randomly or fix nothing.
- Ownership gaps. Security finds the vulnerability. IT or engineering owns the fix. If there’s no clear handoff and deadline, findings sit in a backlog forever.
- CVSS score worship. Teams treat the CVSS severity score as the only input, ignoring whether the flaw is actually being exploited in the wild or sits on an asset nobody could reach anyway.
- No verification step. A patch gets deployed, the ticket closes, and nobody confirms the vulnerability is actually gone.
The Vulnerability Management Lifecycle
A working vulnerability management program runs on six stages, not the “scan and patch” version most guides give you.
Stage 1: Asset Discovery
You cannot manage vulnerabilities on assets you don’t know exist. This includes shadow IT, forgotten cloud instances, third-party integrations, and unmanaged endpoints. Asset inventory is the foundation every later stage depends on — skip it and your vulnerability management coverage has blind spots by default.
Stage 2: Vulnerability Scanning and Identification
Automated scanners check assets against known vulnerability databases (CVE, NVD) and configuration baselines. This stage produces the raw list — the part everyone thinks vulnerability management is, when it’s really just step two of six.
Stage 3: Risk-Based Prioritization
This is where most programs break down, and it’s covered in detail below.
Stage 4: Remediation or Mitigation
Remediation means actually fixing the flaw — patching, reconfiguring, or removing the vulnerable component. Mitigation means reducing the risk without eliminating the flaw (compensating controls, network segmentation, access restrictions) when a full fix isn’t immediately possible. A mature vulnerability management program tracks both paths separately, because treating mitigation as “done” when the underlying flaw is still there is how audits get failed later.
Stage 5: Verification
Rescan or retest to confirm the vulnerability is actually closed. Closing a ticket is not the same as closing a vulnerability.
Stage 6: Reporting and Metrics
Track mean time to remediate (MTTR), percentage of critical findings closed within SLA, and recurrence rate. If leadership can’t see these numbers, the vulnerability management program has no accountability layer.
The Prioritization Problem: Why CVSS Alone Isn’t Enough
CVSS (Common Vulnerability Scoring System) rates severity from 0.0 to 10.0 based on technical characteristics of the flaw itself. It says nothing about whether anyone is actually exploiting it, or whether the affected asset even matters to your business.
A smarter vulnerability management prioritization model combines four inputs:
| Factor | What It Measures | Why It Matters |
|---|---|---|
| CVSS Base Score | Technical severity of the flaw | Baseline starting point |
| EPSS (Exploit Prediction Scoring System) | Probability the vulnerability will be exploited in the next 30 days | Filters theoretical risk from active risk |
| Asset Criticality | How important the affected system is to the business | A critical flaw on a test server ≠ same flaw on a production database |
| Exploit-in-the-Wild Evidence | Confirmed active exploitation (via threat intel feeds) | Moves a finding to “fix today” regardless of CVSS score |
A finding with a CVSS score of 9.8 on an isolated internal test box may matter less than a CVSS 7.2 finding on a customer-facing payment server with a known exploit circulating. Vulnerability management done right weighs all four factors together, not CVSS in isolation.
Vulnerability Management vs. Related Terms
These four terms get used interchangeably constantly, and it causes real confusion when teams are trying to buy tools or define responsibilities.
| Term | What It Actually Covers |
|---|---|
| Vulnerability Management | The full ongoing cycle: discover, prioritize, fix, verify |
| Vulnerability Assessment | A single point-in-time scan or evaluation — one input into vulnerability management, not the whole process |
| Patch Management | Specifically deploying software updates — one remediation method within vulnerability management, not a replacement for it |
| Attack Surface Management | Continuously mapping and monitoring your external-facing assets, including unknown/shadow ones — feeds vulnerability management with discovery data |
If your team is using “patch management” and “vulnerability management” as synonyms, that’s a sign your program is missing configuration issues, weak authentication controls, and architectural flaws that no patch fixes.
Remediation SLA Benchmarks
Numbers make a vulnerability management program enforceable. Vague urgency doesn’t. Here’s a benchmark table used commonly across mature security programs:
| Severity | Recommended Remediation SLA |
|---|---|
| Critical (CVSS 9.0–10.0, actively exploited) | 24–72 hours |
| High (CVSS 7.0–8.9) | 15 days |
| Medium (CVSS 4.0–6.9) | 30–45 days |
| Low (CVSS below 4.0) | 90 days or next patch cycle |
These aren’t arbitrary. Regulatory frameworks like PCI DSS explicitly require patching critical vulnerabilities within 30 days, and many cyber insurance policies now require documented SLAs as a condition of coverage. A vulnerability management program without written SLAs has nothing to show an auditor or insurer.
A Real Example: When Vulnerability Management Fails
The 2017 Equifax breach is the textbook case, and it’s worth walking through because it shows exactly what happens when the lifecycle above breaks at one link.
Equifax was running Apache Struts, an open-source web framework. A critical vulnerability in Struts was publicly disclosed, and a patch was released. Equifax’s internal scanning process failed to catch that the vulnerable version was still running on a customer complaint portal. The flaw sat unpatched for months. Attackers exploited it, and data on roughly 147 million people was stolen.
The failure wasn’t a lack of a scanner — Equifax had one. The failure was in stages 1 and 5: incomplete asset discovery (they didn’t know the vulnerable instance existed on that system) and no verification step to confirm remediation actually happened elsewhere in the environment. That’s a vulnerability management process failure, not a technology failure.
Compliance Frameworks That Require Vulnerability Management
If your organization handles regulated data, vulnerability management isn’t optional — it’s a documented requirement.
- PCI DSS — requires quarterly vulnerability scans and remediation of critical findings within 30 days
- HIPAA — requires risk analysis and management of vulnerabilities affecting protected health information systems
- SOC 2 — requires evidence of a continuous vulnerability management process as part of the Security trust criteria
- ISO 27001 — requires technical vulnerability management as a specific control (Annex A.8.8)
- NIST 800-40 — provides the federal guideline framework most enterprise vulnerability management programs are modeled on
Auditors don’t just ask if you scan. They ask for remediation timelines, ticket history, and proof of verification — which is exactly why the reporting stage of vulnerability management can’t be skipped.
Building a Vulnerability Management Program for a Small Team
Most guidance online assumes an enterprise security team with a dedicated headcount. Most companies don’t have that. Here’s a realistic starting point for a small or mid-size IT team:
- Start with free/open-source scanning tools — OpenVAS or the free tier of Nessus can cover initial discovery and scanning without budget approval.
- Build an asset inventory spreadsheet before buying any tool — you can’t prioritize what you haven’t listed.
- Set two SLA tiers to start — critical (fix within a week) and everything else (fix within 30–60 days). Refine later.
- Assign one owner — even part-time — responsible for tracking open findings to closure. Ownership is the single biggest predictor of whether a vulnerability management effort survives past month one.
- Review monthly, not quarterly — quarterly reviews let critical findings sit far past acceptable exposure windows.
Frequently Asked Questions
What is the difference between vulnerability management and vulnerability assessment?
A vulnerability assessment is a single scan or evaluation at one point in time. Vulnerability management is the ongoing cycle of discovering, prioritizing, fixing, and verifying vulnerabilities continuously.
How often should vulnerability scans run?
Critical, internet-facing systems should be scanned continuously or weekly; internal systems are typically scanned monthly. PCI DSS requires at minimum quarterly scans for regulated environments.
Is patch management the same as vulnerability management?
No. Patch management is one remediation method used inside a vulnerability management program. Vulnerability management also covers misconfigurations, weak controls, and architectural flaws that patches don’t fix.
What is a good remediation SLA for critical vulnerabilities?
Actively exploited critical vulnerabilities should be remediated within 24–72 hours. Non-exploited critical findings are commonly given a 15-day window under most compliance frameworks.
Does a small business need a formal vulnerability management program?
Yes. Attackers use automated scanners that don’t distinguish company size, and cyber insurance policies increasingly require documented vulnerability management practices regardless of headcount.
What is EPSS and why does it matter for vulnerability management?
EPSS predicts the probability a vulnerability will be exploited in the next 30 days. It matters because it separates theoretical severity (CVSS) from real-world exploitation risk, letting teams prioritize what’s actually dangerous right now.
1 Comment