BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity | Serving organizations across Canada, the US, and beyond | Last updated August 21, 2026

Quick answer: No organization remediates every vulnerability in its environment. The goal of vulnerability management is not to close every finding; it is to close the findings that matter before an attacker exploits them. Risk-based prioritization uses four factors to rank vulnerabilities by actual business risk: the severity of the vulnerability itself (CVSS base score), the criticality of the affected asset (how important is this system to the business), the real-world exploitability in your environment (is this vulnerability actually reachable and actively being exploited in the wild), and the remediation effort required to close it. The combination produces a prioritized remediation queue where the highest risk reduction per unit of effort comes first.

Key Takeaways

• Raw CVSS scores are a starting point for prioritization, not the end. They reflect the severity of the vulnerability in isolation, not the risk it creates in your specific environment. Applying asset criticality, network reachability, and active exploitation context to the base score produces a priority ranking that reflects what matters to your business rather than what matters to a generic environment.
• The CISA Known Exploited Vulnerabilities (KEV) catalog identifies vulnerabilities that have been confirmed as actively exploited in real-world attacks. Any vulnerability in the KEV catalog that is present in your environment should be treated as the highest remediation priority regardless of its CVSS score, because active exploitation in the wild eliminates the theoretical uncertainty about whether the vulnerability is actually dangerous.
• Asset criticality is the multiplier that makes prioritization meaningful. A critical vulnerability on a system with no sensitive data and no network path to anything important is a lower priority than a medium vulnerability on a system holding customer financial records with direct connectivity to your payment processing infrastructure.
• Remediation effort is a legitimate prioritization input. Two vulnerabilities with equivalent risk scores may have very different remediation costs: one requires a configuration change taking two hours, the other requires a major infrastructure upgrade taking three months. Sequencing the quick win ahead of the longer project, while managing the longer project in parallel, produces faster risk reduction than a strict risk-ranking that would delay the quick win until the project is completed.
• Accepted vulnerabilities, findings that the organization has assessed and decided not to remediate within the standard timeline, must be formally documented with rationale, compensating controls, approver, and re-evaluation date. Informal non-remediation with no documentation is an unmanaged risk that creates audit and governance problems; formal risk acceptance with documentation is a managed decision that auditors can evaluate.

The Four Dimensions of Risk-Based Prioritization

Vulnerability severity: CVSS base score

The CVSS base score provides the starting point for every vulnerability’s priority. It reflects the inherent characteristics of the vulnerability: how it is accessed (network, adjacent, local, or physical), how complex the attack is, what privileges are required, whether user interaction is needed, and the impact on confidentiality, integrity, and availability. Critical scores (9.0 to 10.0) represent vulnerabilities that are remotely exploitable with no authentication required and that can result in full system compromise or significant data exposure. High scores (7.0 to 8.9) represent serious vulnerabilities with significant impact. Medium scores (4.0 to 6.9) represent vulnerabilities that require some conditions or that have limited impact. Low scores (0.1 to 3.9) represent vulnerabilities with minimal exploitability or impact.

The CVSS base score is technology-neutral: it describes the vulnerability itself, not any particular deployment of the affected software. This is the source of its value as a standardized comparison tool and the source of its limitation as a standalone prioritization criterion. The same CVSS score appears on the vulnerability whether the affected software is running on your most critical production system or on a decommissioned test instance with no network connectivity. The score alone cannot tell you which one matters.

Asset criticality

Asset criticality is the organization’s own assessment of how important each system is to business operations and what data it holds. A system holding customer financial records and processing transactions has higher criticality than a system serving as an internal document management tool. A system running mission-critical applications that the business cannot operate without has higher criticality than a developer sandbox. Asset criticality is documented in the asset inventory, which is a core component of any mature IT and security program and is expected under ISO 27001, SOC 2, and PCI DSS.

Applying asset criticality to vulnerability prioritization multiplies the effective priority of vulnerabilities on critical systems and reduces the effective priority of the same vulnerabilities on low-criticality systems. A medium-severity vulnerability on a payment processing server may rank above a high-severity vulnerability on an internal wiki server when asset criticality is factored in. This reordering reflects the actual risk to the business rather than the intrinsic severity of the vulnerability, and it is what makes the remediation queue efficient.

Network reachability and compensating controls

A vulnerability that is present in the environment but not reachable from any realistic attack path presents lower risk than the same vulnerability on a directly exposed system. Network reachability analysis asks: can an attacker who starts from the most accessible network position, typically the internet or a compromised user workstation, actually reach the affected system and exploit this vulnerability? The answer depends on the network architecture, the segmentation controls in place, the authentication requirements for accessing the affected service, and the presence of any intervening security controls that would prevent or detect exploitation before it succeeds.

Compensating controls are additional measures that reduce the exploitability of a vulnerability without remediating it. A vulnerability in a web service that is protected by a well-configured web application firewall with specific rules blocking the known exploitation technique has lower effective risk than the same vulnerability with no WAF protection. A vulnerability in a system accessible only from a highly restricted administrative network with MFA-required access and full session logging is materially less exploitable than the same vulnerability on a system accessible from any corporate network. Compensating controls should be documented in the vulnerability register with their effectiveness assessment, and they should affect the priority score of the associated findings.

Active exploitation context

Active exploitation context is the intelligence that tells you whether attackers are currently exploiting a specific vulnerability in real-world attacks. The CISA Known Exploited Vulnerabilities catalog is the authoritative source: it lists vulnerabilities that have been confirmed as actively exploited, updated continuously as new exploitation evidence emerges. The catalog was created specifically to help organizations prioritize remediation of vulnerabilities that are not just theoretically dangerous but demonstrably being used in active attacks. Any vulnerability in the KEV catalog that is present in your environment should be treated with the highest urgency regardless of its CVSS score.

Beyond the KEV catalog, the Exploit Prediction Scoring System (EPSS) provides daily-updated probability scores for each published CVE, estimating the likelihood of exploitation in the next 30 days based on threat intelligence data. EPSS scores allow organizations to distinguish between vulnerabilities that have public exploit code available and are being actively targeted and those that have similar CVSS scores but low real-world exploitation probability. Threat intelligence feeds from commercial providers add sector-specific context: vulnerabilities being targeted by threat actors active in the organization’s industry deserve elevated priority even if they are not yet in the KEV catalog.

Building the Remediation Queue

With the four prioritization dimensions applied, the remediation queue is built by combining the scores into a composite priority ranking. The simplest approach is a weighted formula: the CVSS score multiplied by the asset criticality tier, adjusted for reachability (full weight if reachable, reduced if behind compensating controls), and given a mandatory escalation to the top of the queue if the vulnerability is in the KEV catalog or has a high EPSS score. More sophisticated risk quantification frameworks use mathematical models that produce monetary risk estimates for each finding, enabling prioritization based on expected financial impact.

The remediation queue is not a fixed list. It changes as new vulnerabilities are discovered, as asset criticality ratings change, as new exploitation intelligence emerges, and as remediations are completed. Treating the remediation queue as a living document, updated at each scan cycle and whenever significant new information arrives, is what makes the prioritization sustainable over time rather than a one-time exercise that becomes stale within weeks of its production. This is the same discipline that separates a real program from a raw scanner dump, the subject of why your vulnerability scanner produces noise rather than risk intelligence.

Armour Cybersecurity applies this multi-dimensional prioritization framework to every vulnerability assessment engagement, producing a remediation roadmap that reflects the organization’s specific asset criticality profile, network architecture, and compliance context. It builds on the validation and scoping foundation described in what a vulnerability assessment actually tells you.

Frequently Asked Questions

What is the CISA KEV catalog and how should we use it?

The CISA Known Exploited Vulnerabilities catalog is a curated list maintained by the US Cybersecurity and Infrastructure Security Agency of vulnerabilities that have been confirmed as actively exploited in real-world cyberattacks. CISA adds a vulnerability only when it has a CVE ID, reliable evidence of exploitation in the wild, and clear remediation guidance, and updates the catalog continuously. It is freely available at cisa.gov and is the authoritative public source for active-exploitation status. For US federal civilian agencies, remediation of KEV entries is mandatory under CISA’s binding operational directives; that mandate was originally BOD 22-01 (2021) and, as of June 10, 2026, is governed by its successor BOD 26-04, which prioritizes remediation using a risk-scored model rather than a single flat deadline. For private sector organizations, the directives do not apply, but the KEV catalog is a valuable prioritization input: any KEV vulnerability present in the environment has moved from theoretical risk to confirmed active threat and should be escalated to the top of the remediation queue regardless of other priority factors.

How do we handle a large backlog of unaddressed vulnerabilities from previous scan cycles?

A large inherited vulnerability backlog is best addressed through a triage exercise that applies the risk-based prioritization framework to the entire backlog, separating it into three categories. The first is vulnerabilities that require immediate remediation: KEV catalog entries, critical findings on highly critical assets, and any finding where active exploitation in the environment is suspected. These go to the front of the remediation queue regardless of their age. The second is vulnerabilities that require scheduled remediation within defined timeframes, prioritized by the composite risk score. The third is vulnerabilities that are candidates for formal risk acceptance: findings that have been present for an extended period, that have low composite risk scores given the asset criticality and reachability factors, and that the organization can document a reasonable case for accepting until a future remediation cycle. Clearing the backlog through this three-category triage is significantly faster than attempting to process the entire backlog sequentially by age or CVSS score.

What SLAs should we set for vulnerability remediation by severity?

A common industry convention uses a four-tier structure aligned to CVSS severity ranges. Critical vulnerabilities (CVSS 9.0 to 10.0) are remediated within 14 to 30 days. High vulnerabilities (CVSS 7.0 to 8.9) within 30 to 60 days. Medium vulnerabilities (CVSS 4.0 to 6.9) within 90 days. Low vulnerabilities (CVSS 0.1 to 3.9) within 180 days or formally accepted with documentation. These are conventions, not universal rules, and they should be adjusted based on your risk-based prioritization: KEV catalog entries warrant a much shorter maximum regardless of CVSS severity, and findings on critical assets with high reachability should sit at the shorter end of the range for their severity tier. Where a compliance framework such as PCI DSS specifies its own remediation timelines, those framework requirements take precedence over generic industry benchmarks.

How does vulnerability prioritization connect to our risk register?

Vulnerability prioritization and the organizational risk register are connected through the asset inventory and criticality ratings that both reference. The risk register documents strategic risks at a business level; the vulnerability register documents specific technical findings at an asset level. The connection between them is that persistent patterns in the vulnerability register should surface as risk register entries. A sustained vulnerability remediation backlog for a specific critical system, a vulnerability class that recurs in every assessment cycle despite remediation efforts, or a technology stack with structural weakness that requires an architectural change should be documented in the security risk register as a managed organizational risk with treatment decisions, compensating controls, and ownership assigned at the appropriate governance level. This connection ensures that leadership visibility into the vulnerability posture is maintained through the risk management function rather than buried in a technical findings dashboard that executives do not routinely review.

What is risk acceptance for a vulnerability and when is it appropriate?

Risk acceptance is the formal decision by an authorized approver to acknowledge a vulnerability and decide not to remediate it within the standard timeline, documented with rationale, compensating controls, and a re-evaluation date. It is appropriate when the remediation cost significantly outweighs the residual risk given the asset criticality and reachability factors, when the remediation requires a change that is not technically feasible within the standard timeframe (for example, replacing end-of-life hardware that is on a phased replacement roadmap), or when a compensating control reduces the exploitability sufficiently that the residual risk is within the organization’s documented risk appetite. Risk acceptance is not appropriate as a default response to findings that are difficult or inconvenient to remediate; it requires genuine risk analysis and documented authorization at the right authority level based on the finding severity and asset criticality. Informal non-remediation without documentation is a governance failure that auditors identify as such.

The Bottom Line

You will never close every vulnerability in your environment, and trying to is how teams burn their capacity without reducing their actual risk. The work that matters is ranking findings by real business risk, which means layering four things onto the raw CVSS score: how critical the affected asset is, whether the vulnerability is actually reachable given your segmentation and compensating controls, whether it is being exploited in the wild right now, and how much effort remediation takes. Escalate anything in the CISA KEV catalog to the top regardless of its score, sequence quick wins ahead of long projects while running both, and formally document the findings you consciously accept so residual risk is a managed decision rather than an invisible gap. Treat the resulting queue as a living document that updates every cycle. Armour Cybersecurity builds exactly this prioritized remediation roadmap on every vulnerability assessment, sequenced by real risk reduction and mapped to your compliance obligations.