You ran a vulnerability scan. It found 12,000 vulnerabilities. Now what? If your answer is “prioritize by CVSS score and work from the top,” you’re going to spend months patching things nobody is exploiting while ignoring the medium-severity vulnerability that an attacker used to breach your competitor last week. CVSS tells you how bad a vulnerability could be in theory. It doesn’t tell you whether anyone is actually exploiting it in the wild, whether it’s reachable in your environment, or whether your compensating controls already mitigate it.
A vulnerability management program that works doesn’t just scan and generate reports. It scans, prioritizes by actual risk, assigns ownership, tracks remediation against SLAs, and feeds lessons back into the process. Here’s how to build one that reduces risk instead of producing PDFs that nobody reads.
DO / DON’T
DO:
- Scan continuously, not quarterly — Quarterly scans are compliance artifacts. Continuous scanning catches new vulnerabilities as they appear.
- Prioritize by exploitability — A vulnerability with a known exploit in the wild is more urgent than a theoretical vulnerability with a higher CVSS score.
- Set patch SLAs by risk tier — Critical/exploited: 48 hours. High: 14 days. Medium: 30 days. Low: 90 days. Adjust for your risk appetite.
- Track remediation to closure — A vulnerability that’s been “in progress” for six months isn’t being managed. It’s being ignored.
- Establish a vulnerability disclosure program — Give security researchers a way to report vulnerabilities to you. A VDP is cheaper than a breach.
- Correlate scan results with threat intelligence — CVSS is context-free. Threat intel adds the context that determines actual risk.
DON’T:
- Don’t rely on CVSS scores alone — CVSS measures theoretical severity. A CVSS 10 on an air-gapped system behind three firewalls is less urgent than a CVSS 7 on your internet-facing web server.
- Don’t scan without a plan to fix — Scanning without remediation is just documenting your failures with precision.
- Don’t treat vulnerability management as an IT-only problem — Business owners decide acceptable risk. IT implements the fixes. Both need to be in the loop.
- Don’t ignore the scan tool’s false positives — Tune your scanner. Untuned scan results erode trust in the program and cause alert fatigue.
- Don’t patch in production without testing — A patch that breaks a production system creates a different kind of incident. Test first.
Building the Program
Step 1: Asset Inventory
You can’t scan what you don’t know about, and you can’t prioritize what you haven’t classified. Before you scan anything, make sure your asset inventory is current.
For each asset, you need:
- Criticality — How important is this system to business operations? A customer-facing payment system is more critical than an internal wiki.
- Exposure — Is it internet-facing, DMZ, internal-only, or air-gapped? Exposure determines reachability.
- Data classification — Does it process or store Restricted, Confidential, or Internal data?
- Owner — Who is responsible for patching and maintaining this system?
Your vulnerability management program inherits the quality of your asset inventory. If the inventory is incomplete, your scan coverage has the same gaps. CIS Control 1 (Enterprise Asset Inventory) exists for this reason.
Step 2: Scanning
Scanner Selection
Choose your scanning approach based on your environment:
- Authenticated scans — The scanner logs into each system with credentials and checks installed packages, configurations, and patch levels from the inside. Far more accurate than unauthenticated scans. More findings, fewer false positives.
- Unauthenticated scans — The scanner probes from the outside, like an attacker would. Good for discovering what’s exposed but misses a lot of internal vulnerabilities.
- Agent-based scanning — A lightweight agent on each endpoint reports its vulnerability state continuously. Best for laptops, remote devices, and cloud workloads that aren’t always reachable by network scanners.
Common tools: Nessus, Qualys, Rapid7 InsightVM, OpenVAS (free/open source), and cloud-native options (AWS Inspector, Azure Defender, GCP Security Command Center).
Scan Frequency
- Internet-facing assets — Continuous or daily. These are reachable by anyone on the internet. New vulnerabilities are weaponized within hours of disclosure.
- Internal servers — Weekly minimum. Daily preferred.
- Workstations and endpoints — Agent-based continuous scanning. Network scans miss devices that aren’t on the network when the scan runs.
- Development and staging — Scan before promotion to production. Catch vulnerabilities before they reach production.
Step 3: Prioritization
This is where most programs fail. Twelve thousand vulnerabilities sorted by CVSS score is not a prioritized remediation plan. It’s a spreadsheet of despair.
Risk-Based Prioritization
Layer these factors on top of CVSS:
- Exploit availability — Is there a public exploit? A Metasploit module? An exploit kit? Check CISA’s Known Exploited Vulnerabilities (KEV) Catalog — if a CVE is on this list, it’s actively being exploited and needs immediate attention.
- Asset criticality — A vulnerability on your payment processing server is higher priority than the same vulnerability on a test server.
- Exposure — An exploitable vulnerability on an internet-facing system is higher priority than the same vulnerability behind three layers of network segmentation.
- Compensating controls — Does a WAF, IPS, or network segmentation already mitigate the attack path? This doesn’t eliminate the vulnerability but may reduce its urgency.
- Threat intelligence — Is the vulnerability being used by threat actors targeting your industry? Sector-specific ISACs and CISA Alerts provide this context.
Tools like EPSS (Exploit Prediction Scoring System) from FIRST.org estimate the probability of a vulnerability being exploited in the next 30 days. Combine EPSS with asset criticality for a prioritization model that reflects actual risk, not theoretical severity.
Patch SLAs
Define remediation timelines by risk tier and enforce them:
| Tier | Criteria | SLA |
|---|---|---|
| Critical | CISA KEV listed, or active exploitation confirmed, or internet-facing with public exploit | 48 hours |
| High | CVSS 7.0+ with exploit available, or CVSS 9.0+ without exploit, or on critical assets | 14 days |
| Medium | CVSS 4.0-6.9, or CVSS 7.0+ on non-critical internal assets | 30 days |
| Low | CVSS below 4.0, no known exploit, internal only | 90 days |
These are starting points. Adjust for your risk appetite, change management constraints, and operational requirements. The point is having documented, measurable timelines — not aspirational targets that nobody tracks.
Step 4: Remediation Tracking
Every vulnerability needs an owner, a timeline, and a status. Track remediation in a system that provides visibility — a ticketing system, a vulnerability management platform’s built-in tracking, or at minimum a structured spreadsheet.
For each vulnerability:
- CVE ID and description
- Affected asset(s)
- Risk tier and SLA
- Assigned owner
- Remediation action — Patch, configuration change, compensating control, or risk acceptance
- Status — Open, in progress, remediated, verified, or accepted
- Verification — Rescan after remediation to confirm the fix. A ticket closed without verification is a hope, not a fix.
Report metrics to leadership monthly:
- Mean time to remediate (MTTR) by risk tier
- SLA compliance rate — Percentage of vulnerabilities remediated within their SLA
- Vulnerability aging — Count of vulnerabilities past their SLA
- Scan coverage — Percentage of assets scanned within the last cycle
- Trend lines — Are you getting better or worse over time?
Step 5: Vulnerability Disclosure Program
If you build software, run services, or operate internet-facing infrastructure, you need a way for security researchers to report vulnerabilities to you.
A vulnerability disclosure program (VDP) is not a bug bounty. A bug bounty pays researchers for findings. A VDP simply provides a channel and a commitment to respond. CISA BOD 20-01 requires federal agencies to maintain a VDP, but every organization benefits from one.
At minimum:
- Publish a
security.txtfile at/.well-known/security.txtper RFC 9116 - Include a contact email, encryption key (PGP), and your disclosure policy
- Commit to acknowledging reports within a reasonable timeframe (48 hours)
- Define safe harbor — researchers acting in good faith won’t be threatened with legal action
If It Already Happened
If a vulnerability in your environment was exploited before you patched it:
- Contain the breach — Isolate the compromised system. Don’t patch the vulnerability on a compromised system and call it fixed — the attacker is already inside.
- Investigate scope — Determine what the attacker accessed, what data was affected, and whether they established persistence.
- Patch the vulnerability — After containment and forensic evidence preservation, patch the vulnerability on all affected systems.
- Review your prioritization — If this vulnerability was deprioritized, figure out why. Was the prioritization model missing exploit intelligence? Was the asset criticality wrong? Fix the model, not just the vulnerability.
- Report through CISA and applicable regulatory channels. If personal data was compromised, check breach notification obligations under GDPR, HIPAA, state laws, and other applicable regulations.
Vulnerability management is a program, not a scan. Scan continuously, prioritize by exploitability and asset criticality (not just CVSS), set SLAs, track remediation, and report metrics. Start by scanning your internet-facing assets this week. Cross-reference the results against CISA’s KEV catalog. Patch whatever matches. That’s your first cycle. Then build the rest of the program around it.