Threat and vulnerability management is the continuous process of identifying, classifying, prioritising, and remediating security weaknesses across your environment before attackers exploit them. It combines vulnerability scanning and patching with threat intelligence so your security team spends time on exposures that are actually being weaponised in the wild, not just those with the highest theoretical scores. By the end of this guide, you will know how to build a program that covers asset inventory, scanning cadence, risk-based prioritisation, remediation SLAs, and the metrics that tell you whether any of it is working.
Threat Management vs Vulnerability Management: Two Disciplines, One Program
Security teams often conflate these terms, and conflating them costs you remediation cycles. Vulnerability management is asset-focused: you enumerate what you own, scan it for known weaknesses, score those weaknesses, and track fixes. Threat management is adversary-focused: you gather intelligence on who is attacking organisations like yours, what techniques they use, and which vulnerabilities they are actively chaining into real exploits.
Run them separately and you get a long patching queue with no sense of urgency, or a threat feed with no anchor to your actual attack surface. Run them together and every remediation decision is grounded in two facts at once: does this weakness exist in my environment, and is someone out there actively trying to use it? That combination is what separates a vulnerability management program that moves risk from one that just moves tickets.
As of 2026, the threat intelligence side of this equation has matured considerably. Commercial and open-source feeds now publish exploit availability and active exploitation status within hours of a CVE being weaponised. The CISA Known Exploited Vulnerabilities catalogue, which you can access at https://www.cisa.gov/known-exploited-vulnerabilities-catalog, is a government-maintained list of vulnerabilities confirmed to be exploited in the wild. Any CVE on that list belongs in your emergency remediation queue regardless of its CVSS score.
Asset Inventory: The Foundation Every Vulnerability Management Program Gets Wrong
You cannot protect what you have not counted. Asset inventory is the unglamorous prerequisite that determines the accuracy of everything downstream, from scan coverage to remediation metrics. A gap in your inventory is a blind spot in your program.
Effective asset inventory means capturing more than IP addresses. You need operating system version, installed software, owner or responsible team, network zone, data classification of workloads running on the asset, and whether the asset is internet-facing. That last attribute matters enormously for prioritisation: an internet-facing web server with a critical vulnerability is a different risk category than an air-gapped internal workstation with the same CVE.
I have seen organisations run vulnerability scans against a CMDB that was eighteen months out of date. The scan results looked clean because the scanner never saw half the infrastructure. Shadow IT, acquired company assets, and cloud workloads spun up outside the change management process are the three most common sources of inventory gaps. Integrating your scanner with cloud APIs, using passive network discovery alongside active scanning, and requiring asset registration as part of your provisioning workflow all help, but none of them fully substitute for periodic manual audits of high-value network segments.
A practical starting point: classify assets into tiers by criticality and exposure. Tier 1 covers internet-facing and business-critical systems. Tier 2 covers internal systems with sensitive data or privileged access. Tier 3 covers everything else. Your scanning cadence and remediation SLAs will differ by tier, so the tier assignment is a decision with real downstream consequences.
Scanning Cadence: How Often You Need to Run Vulnerability Scans
Scanning cadence is a function of asset criticality, the rate at which your environment changes, and the speed at which new exploits emerge for your technology stack. There is no universal answer, but the following cadences reflect what most mature programs converge on.
Tier 1 assets (internet-facing and business-critical) warrant continuous or near-continuous scanning. For many organisations this means authenticated scans weekly and unauthenticated scans from an external vantage point daily, supplemented by scan triggers whenever a new CVE is published for technologies you run. Tier 2 assets should be scanned at least monthly. Tier 3 assets quarterly, with a full authenticated scan annually at minimum.
Authenticated scanning is not optional for accuracy. Unauthenticated scans miss a significant share of vulnerabilities because they cannot inspect installed software versions, patch levels, or configuration states that require local access to evaluate. The overhead of managing scan credentials is real, but the alternative is a materially incomplete picture of your exposure. Use a privileged scan account with read-only access, rotate credentials quarterly, and store them in your PAM solution.
Scan data ages quickly. A scan result from six weeks ago tells you almost nothing about your current exposure if your deployment pipeline is active. Treat scan data as perishable and build your reporting around the most recent scan per asset, not an aggregated view that obscures how stale individual results are.
Risk-Based Vulnerability Prioritisation: Moving Beyond CVSS Scores Alone
The Common Vulnerability Scoring System (CVSS) gives every published vulnerability a score from 0 to 10. Scores of 9.0 to 10.0 are Critical, 7.0 to 8.9 are High, 4.0 to 6.9 are Medium, and 0.1 to 3.9 are Low. The full scoring methodology is documented by FIRST at https://www.first.org/cvss/. CVSS is useful as a baseline severity signal, but using it as your sole prioritisation criterion is a known failure mode.
The problem is that CVSS measures theoretical severity, not actual exploitation likelihood. A CVSS 9.8 vulnerability on an isolated internal server that requires local access to trigger may be genuinely lower priority than a CVSS 6.5 vulnerability that has a public exploit and is being actively scanned for on the internet. CVSS does not know about your network topology, your compensating controls, or whether exploit code is circulating on criminal forums right now.
Two supplementary signals correct for this. First, the Exploit Prediction Scoring System (EPSS) is a machine-learning model that estimates the probability a given CVE will be exploited in the next 30 days, expressed as a percentage. A CVE with EPSS of 0.94 (94% probability of exploitation) deserves more attention than a CVSS 9.8 with EPSS of 0.002. Second, the CISA KEV catalogue tells you when exploitation has already been confirmed. A CVE on KEV is not a prediction; it is a documented fact.
A mature prioritisation framework layers these signals. Start with CVSS to filter out genuinely low-severity noise. Then promote any CVE that appears in the CISA KEV catalogue to your highest remediation tier regardless of CVSS. Then use EPSS to further rank the remaining queue, combining it with your asset criticality tiers to get a risk score that reflects both exploitability and impact to your specific environment. This approach is what the industry increasingly calls risk-based vulnerability management, and it consistently reduces remediation volume without increasing risk exposure.
The National Vulnerability Database (NVD) at https://nvd.nist.gov is the authoritative source for CVSS scores and CVE enrichment data. Your scanner vendor feed will pull from NVD, but checking NVD directly is useful when you need to verify a score or access supplementary analysis that the scanner UI does not surface.
Remediation SLAs by Severity Tier
Service level agreements for remediation give your program teeth. Without defined SLAs, every vulnerability is equally urgent, which means none of them are. With SLAs, your security team and the engineering teams responsible for patching have a shared contract about what fixed on time actually means.
SLA timelines should reflect both severity and asset tier. The table below shows a representative framework. Adapt the timelines to your organisation’s risk appetite, but be sceptical of any program where Critical SLAs exceed 30 days for internet-facing assets.
| Severity | CVSS Range | Tier 1 (Internet-facing / Critical) | Tier 2 (Internal / Sensitive) | Tier 3 (Standard) |
|---|---|---|---|---|
| Critical | 9.0 – 10.0 | 15 days (KEV: 72 hours) | 30 days | 45 days |
| High | 7.0 – 8.9 | 30 days | 45 days | 90 days |
| Medium | 4.0 – 6.9 | 60 days | 90 days | 180 days |
| Low | 0.1 – 3.9 | 180 days | 180 days | Best effort |
The 72-hour emergency SLA for KEV findings on Tier 1 assets reflects the reality that if a vulnerability is actively exploited in the wild and your internet-facing infrastructure carries it, you are in active breach condition. That timeline is not a patch-and-test cycle; it is an isolation-or-compensating-control cycle while the patch is prepared.
Exceptions handling is as important as the SLA itself. Define a formal exception process: who can approve an extension, what compensating controls are required to qualify for one, and what the maximum extension period is. Without this, SLAs become aspirational rather than binding, and your metrics will systematically look better than your actual exposure.
Integrating Threat Intelligence into Your Vulnerability Program
Threat intelligence is only useful if it changes a decision. The way to ensure it does is to build explicit integration points between your threat intel feeds and your vulnerability prioritisation workflow, rather than treating threat intel as a separate report that gets read and filed.
The most direct integration is CVE-level enrichment. When your scanner identifies a vulnerability, automatically check whether it appears in the CISA KEV catalogue, whether a public exploit exists in sources like Exploit-DB or Metasploit modules, and what the current EPSS score is. Most enterprise vulnerability management platforms support this enrichment natively or via API integration. If yours does not, a lightweight script pulling from the NVD API and CISA KEV JSON feed can approximate it.
The second integration point is threat actor profiling. If your threat intelligence team or commercial feed identifies that threat actors targeting your sector are actively exploiting a specific CVE or class of vulnerabilities, that context should immediately elevate the priority of matching findings in your environment. This requires your threat intel team and your vulnerability management team to share a common vocabulary and, ideally, a shared ticketing workflow.
A citable observation from operational experience: organisations that treat threat intel and vulnerability data as separate workstreams consistently see longer mean time to remediation on the vulnerabilities that end up causing incidents. The breaches that follow a predictable pattern, confirmed exploit availability followed by mass scanning followed by targeted intrusion, are the ones that well-integrated programs catch early. The handoff between knowing a CVE is being actively exploited and confirming your environment carries it should take hours, not the weeks it takes when the two teams operate in separate silos.
Understanding the Full Vulnerability Management Lifecycle
A point-in-time view of vulnerabilities is not a program; it is a snapshot. The vulnerability management lifecycle is the repeating cycle that keeps your exposure under control as your environment changes and new CVEs are published. That cycle runs from asset discovery through scanning, analysis, prioritisation, remediation, and verification, with every stage feeding data back into the next iteration.
Verification deserves specific attention because many programs skip it. After a patch is deployed, you need a rescan of the affected asset to confirm the vulnerability is actually gone. Patches fail to apply. Configuration drift reintroduces vulnerabilities. Compensating controls that were supposed to mitigate a finding get removed during unrelated maintenance. Without verification scanning, your closure metrics are based on tickets closed, not on vulnerabilities actually remediated.
Build your lifecycle documentation around the data flows, not the tools. Tools change; the underlying questions do not. What assets exist, what is their current state, which weaknesses are present, which are highest priority given active threat context, who owns the fix, has the fix been verified? Answering those questions reliably and repeatedly is what a mature program looks like.
Metrics That Tell You Whether Your Program Is Working
The metrics that matter in vulnerability management are the ones that reflect actual risk reduction, not process activity. Vulnerability count and scan coverage are easy to report; they tell you how busy your program is. Mean time to remediate and SLA adherence tell you whether your program is effective.
Mean Time to Remediate (MTTR) measures the average time from vulnerability detection to verified closure, segmented by severity. Track MTTR separately for Critical, High, and Medium findings. A program that remediates Critical findings in 12 days on average but takes 180 days for High findings is leaving significant exposure unaddressed, because High-severity vulnerabilities with good EPSS scores and active exploits are often more dangerous in practice than the most theoretical Criticals.
Coverage is the second core metric: what percentage of your known assets received an authenticated scan within the required cadence for their tier? A coverage rate below 95% for Tier 1 assets means you have blind spots in your highest-risk segment. Track this weekly.
SLA adherence by severity tier shows whether your organisational remediation capacity matches your program’s requirements. If Critical SLA adherence sits at 60%, you have either an under-resourced patching function, unrealistic SLAs, or both. That gap is a business risk that needs to be communicated to leadership in those terms, not buried in a vulnerability dashboard that only security teams read.
Reopen rate measures how often a closed vulnerability reappears in subsequent scans. A high reopen rate signals either that patches are not being applied correctly, that verification scanning is not catching failures, or that configuration management is not maintaining the fixed state. Each of those is a different root cause with a different fix.
As of 2026, leading programs are also tracking vulnerability density per asset tier, which normalises finding counts against the size of your inventory and lets you compare exposure levels across business units or cloud accounts over time. This metric becomes especially useful when you are making investment decisions about where additional scanning, patching resources, or architectural hardening will produce the most risk reduction per pound spent.
Building a Threat and Vulnerability Management Program That Scales
Most programs fail to scale not because the technology is inadequate but because the program was designed around the security team’s capacity rather than the organisation’s asset growth rate. A vulnerability management program that works for 500 assets will not work for 5,000 without deliberate design changes.
The architectural decisions that matter at scale are automation depth, integration with development pipelines, and ownership distribution. On automation: your triage workflow should automatically apply the KEV check, EPSS enrichment, and asset tier lookup to every new finding and pre-assign a priority level before any human reviews it. Human attention should go to exception handling and the findings that automated triage cannot confidently categorise, not to processing every scan result manually.
On development pipeline integration: vulnerabilities introduced in application code, container images, and infrastructure-as-code should be caught before they reach production, not after. This means integrating software composition analysis and container image scanning into your CI/CD pipeline and treating those findings through the same prioritisation and SLA framework as your infrastructure scan results. The organisations that do this well see a significant reduction in the volume of application-layer findings reaching production environments, which is where they are hardest and most disruptive to fix.
On ownership distribution: security teams cannot own remediation. They can own discovery, prioritisation, and tracking, but the actual patching of infrastructure and applications sits with the teams who operate those systems. This means your program needs clear escalation paths, a ticketing integration that routes findings to the right engineering team automatically, and a reporting cadence that gives engineering managers visibility into their own SLA performance. When engineering teams see their own data, remediation speeds up.
A well-designed threat and vulnerability management program is not a security project. It is an operational capability that runs continuously, integrates with how your organisation builds and operates technology, and produces measurable reductions in exposure over time. The organisations that build it that way treat vulnerability management not as an annual audit exercise but as a core part of how they manage operational risk.
Frequently Asked Questions
What is threat and vulnerability management?
Threat and vulnerability management is the continuous practice of discovering security weaknesses across your assets, scoring them by exploitability and business impact, and remediating them within defined timeframes. It integrates threat intelligence so that findings confirmed as actively exploited in the wild receive immediate escalation rather than joining a standard patching queue.
What is the difference between vulnerability management and threat management?
Vulnerability management focuses on your own assets: finding weaknesses, scoring them, and tracking fixes. Threat management focuses on adversaries: gathering intelligence on who is attacking your sector, what techniques they use, and which vulnerabilities they are weaponising. A mature program runs both disciplines together so that remediation decisions reflect real-world attack activity, not theoretical severity scores alone.
How do you prioritise vulnerabilities?
Effective prioritisation layers three signals: CVSS score as a baseline severity indicator, EPSS to estimate exploitation probability in the next 30 days, and the CISA Known Exploited Vulnerabilities catalogue for confirmed exploitation. Asset criticality and internet exposure then apply context. This combination produces a risk-ranked queue that reflects both exploitability and impact to your specific environment.
What metrics matter in vulnerability management?
Mean Time to Remediate (MTTR) segmented by severity, SLA adherence by tier, scan coverage percentage for each asset tier, and vulnerability reopen rate are the four metrics that reflect actual program effectiveness. Process metrics like ticket count or scan frequency measure activity, not risk reduction, and should be secondary to outcome-based reporting for leadership.
