A vulnerability management program is the continuous cycle of discovering, prioritizing by risk, remediating, and verifying fixes to security weaknesses across your IT environment. It is not a scan report. Your first move: confirm asset inventory is current, then ingest the CISA Known Exploited Vulnerabilities catalog to flag any CVE already under active attack.
- Run an authenticated scan against one high-value maintenance group this week.
- Cross-reference results against KEV before anything else.
- Anything that matches goes to the front of the remediation queue.
Key Takeaways
A vulnerability management program succeeds when KEV-driven prioritization, authenticated scanning, and closed-loop verification run on a fixed cadence with named owners at every stage.
| Point | Details |
|---|---|
| Start with KEV | Confirm asset inventory, then ingest the CISA KEV catalog to flag confirmed-exploited CVEs first. |
| Scan authenticated, not just external | Authenticated scans catch missing patches and misconfigurations that unauthenticated scans miss. |
| Layer KEV, EPSS, CVSS, and exposure | KEV drives emergency response; EPSS and CVSS refine everything else by probability and severity. |
| Close the loop with rescans | Never close a remediation ticket without a scan confirming the finding is actually gone. |
| Consider a managed partner for regulated environments | Marfi runs discovery, triage, remediation, and monitoring under one accountable team with 24/7 SOC coverage. |
Table of Contents
- What Does a Vulnerability Management Program Actually Cover?
- Why Does Risk-Based Prioritization Matter So Much?
- How Does the Vulnerability Management Process Actually Run?
- How Do You Combine KEV, EPSS, CVSS, and Exposure Into One Priority Score?
- Which Tools Actually Deserve Automation?
- How Should Patch Management Actually Run Day to Day?
- What Metrics Actually Prove the Program Is Working?
- What Does a 90-Day Rollout Actually Look Like?
- Where Does a Managed Partner Fit Into This Program?
- What Do Practitioners Get Wrong Most Often?
- How Marfi Runs Vulnerability Management for Regulated Teams
- Sources
What Does a Vulnerability Management Program Actually Cover?
Scope confusion kills most programs before they start. The program covers internet-facing systems, internal servers, endpoints, cloud workloads, and software dependencies tracked through software composition analysis (SCA). It runs on defined roles: asset owners who approve changes, security operations that triages findings, engineering teams that patch, change management that schedules the work, and an executive sponsor who breaks ties.
A vulnerability assessment is a snapshot. A vulnerability management program is the ongoing machine that assessments feed into. Patch management is one remediation lever inside that machine, not the whole program.
Why Does Risk-Based Prioritization Matter So Much?
Historical data suggests fewer than 4% of known vulnerabilities have ever been observed under active exploitation. That statistic alone should reshape how your team spends its remediation hours.
Statistic callout: The CISA KEV catalog passed 1,200 entries as of April 2026, growing by roughly 10 to 15 additions a month. Every one of those entries represents a vulnerability with confirmed real-world exploitation, not theoretical risk.
Attackers move faster than most patch cycles. The organizations that close the gap treat assessment speed and remediation speed as a competitive advantage, not a compliance checkbox. Regulators increasingly agree: frameworks tied to SOC 2, HIPAA, and CMMC now expect documented, timely remediation as evidence of operational maturity, not just a policy on paper.
How Does the Vulnerability Management Process Actually Run?
Every mature program cycles through four stages, each with a named owner and a set cadence.
- Discovery. Run authenticated scans, not just unauthenticated ones. Authenticated scans log into the host and see configuration issues and missing patches that external scans miss entirely. CIS Control 7 recommends automated internal scans at least quarterly; most regulated organizations scan internally monthly and externally more often than that, given how fast internet-facing exposure changes. Reconcile every scan result against your CMDB so nothing scans as a ghost asset nobody owns.
- Prioritization. Match findings against KEV first. Layer in EPSS for near-term exploitation probability and CVSS for baseline severity. Check exposure: is it internet-facing, and does it touch sensitive data?
- Remediation. Patch where you can. Where you can't, apply a configuration change or a compensating control, and route the work through change management so testing happens before deployment, not after.
- Verification. Rescan after remediation. Close the ticket only when the scan confirms the finding is gone, not when engineering says "should be fixed."
Pro Tip: Never close a remediation ticket on an engineer's word alone. Require a rescan result attached to the ticket. Programs that skip this step quietly accumulate "fixed" vulnerabilities that were never actually fixed.
How Do You Combine KEV, EPSS, CVSS, and Exposure Into One Priority Score?
Triage without a formula turns into whoever complains loudest gets patched first. Build a fixed order instead.
- KEV match = automatic top tier. If CISA's directive guidance shows confirmed exploitation, it jumps the queue regardless of CVSS score.
- Internet-facing KEV findings move fastest. These carry the shortest SLA in the program.
- EPSS scores the rest. For everything not on KEV, EPSS gives you a near-term probability estimate of exploitation, which is more useful for triage than CVSS alone.
- CVSS sets the floor. It tells you theoretical severity, useful once KEV and EPSS have done the sorting.
- Exposure and business criticality shift the tier up or down. A high-CVSS finding on an isolated test server can wait; a moderate finding on a customer database cannot.
A workable tier structure: Tier 1 (KEV or internet-facing critical) gets remediated within days. Tier 2 (high EPSS, internally exposed) gets weeks. Everything else fits into the normal monthly patch cycle that CIS Control 7 calls for.
Which Tools Actually Deserve Automation?
Not every step needs a tool thrown at it, but a few consistently pay for themselves.
- Network and host scanners for authenticated discovery across servers, endpoints, and cloud workloads.
- SCA tools to catch vulnerable open-source dependencies before they ship.
- Patch managers to push fixes to defined maintenance groups on schedule.
- ITSM connectors that auto-create tickets from scan results and route them by SLA tier.
Automate KEV ingestion first. Pulling the KEV feed directly into your scanner or ticketing pipeline turns a static list into automatic escalation the moment a match appears. Keep one authoritative asset source, scan authenticated wherever credentials allow, and test patches in a staging environment before mass deployment.
How Should Patch Management Actually Run Day to Day?
NIST's patch management guidance frames patching as preventive maintenance, the same category as an HVAC service contract, not a firefight. That framing matters because it changes how business owners plan around it.
Assign every asset to a maintenance group with a shared patch window and testing plan. Servers running the same application stack belong together; isolated legacy systems get their own group with tighter oversight.
For emergency patching, skip the normal window when a KEV match hits a critical asset, but still test in a lower environment first if the timeline allows even an hour. For assets that genuinely cannot be patched, whether legacy hardware or vendor-locked systems, document a compensating control such as network segmentation or enhanced monitoring, and log an exception with a review date. An unpatchable system with no compensating control and no owner is the single most common finding in a failed audit.
What Metrics Actually Prove the Program Is Working?
Pick metrics that map to a decision, not just an activity count.
| Metric | Audience | What it tells you |
|---|---|---|
| % KEV remediated within SLA | Executives | Whether the highest-risk findings get closed fast enough |
| Mean time to remediate (MTTR) by tier | Engineering managers | Where the remediation pipeline is bottlenecked |
| % assets scanned | Security operations | Whether the inventory and scan coverage are actually complete |
| Patch success rate | IT operations | Whether deployed patches are landing without rollback |
Report MTTR and patch success rate to engineering weekly. Reserve KEV-SLA compliance and overall risk trend for the executive audience monthly. Run a formal remediation review every month, matching the cadence CIS Control 7 recommends, and adjust SLAs when a tier consistently misses its target.
What Does a 90-Day Rollout Actually Look Like?
Standing up a program from nothing, or fixing a broken one, fits into three sprints.
- Days 0 to 14: Build or validate the asset inventory, assign an owner to every critical asset, run baseline authenticated scans, and ingest the KEV catalog into your triage process.
- Days 15 to 45: Define remediation SLAs by tier, write remediation playbooks for the most common finding types, and connect scan output to your ticketing system for at least one high-priority maintenance group.
- Days 46 to 90: Expand automation to remaining asset groups, start tracking MTTR by tier, and run the first formal governance review with the executive sponsor to reset SLAs based on real data.
Programs that skip the governance review at day 90 tend to drift back into ad hoc patching within two quarters, because nobody revisits whether the original SLAs still fit reality.
Where Does a Managed Partner Fit Into This Program?
Running this cycle in house demands dedicated headcount most regulated companies don't have spare. Marfi operates a 24/7 security operations center and holds SOC 2 Type II certification, giving clients continuous monitoring and remediation orchestration without building that function from scratch.
Marfi's team handles asset inventory validation, authenticated scanning, KEV-driven triage, and remediation coordination across managed cybersecurity services, while aligning the program to frameworks like NIST and CMMC for organizations that need audit-ready evidence. Companies with limited internal security staff, active regulatory obligations, or growth plans that outpace their current IT team are the clearest candidates for a managed approach over building everything internally.
What Do Practitioners Get Wrong Most Often?
Noisy, unauthenticated scans that flood tickets with false positives kill team morale fast. Missing asset owners is worse: a finding with nobody accountable never gets fixed, no matter how good the scanner is.
The fastest quick win is a KEV-only sprint against your riskiest maintenance group, paired with a one-page executive summary. Speed and testing rigor will always trade off against each other; accept a documented compensating control when patching truly can't happen in time, but never accept silence instead of a decision.
— Danny
How Marfi Runs Vulnerability Management for Regulated Teams
Marfi is the alternative to stitching together five different vendors for scanning, patching, and compliance reporting. One accountable team runs discovery, prioritization, remediation orchestration, and continuous monitoring under a single service agreement, so nothing falls through the cracks between tools that don't talk to each other.
That matters most for companies juggling SOC 2, HIPAA, or CMMC obligations with a lean internal team. Marfi's managed cybersecurity services cover the full lifecycle this article walks through, backed by a 24/7 SOC and SOC 2 Type II certification, while CMMC and NIST SP 800-171 readiness work maps remediation evidence directly to audit requirements. If your team is spread thin or your compliance deadline is closer than your remediation backlog can handle, request an assessment through Marfi's managed IT services page and get a clear picture of where your program stands.
Sources
- CIS Critical Security Control 7: Continuous Vulnerability Management
- Known Exploited Vulnerabilities catalog — CISA
- Creating a Patch and Vulnerability Management Program (NIST SP 800-40r4)