Vulnerability management teams face an uncomfortable reality: there will almost always be more vulnerabilities than available time to remediate them.
New CVEs are published continuously. Security scanners generate extensive lists of findings. Technology teams must balance patching against operational stability, maintenance windows, testing requirements and limited engineering capacity.
The conventional response has been to prioritise vulnerabilities by their Common Vulnerability Scoring System, or CVSS, rating. Critical vulnerabilities are addressed first, followed by high, medium and low findings.
This is understandable. It is also incomplete.
The 2026 Verizon Data Breach Investigations Report found that 31% of breaches now begin with the exploitation of software vulnerabilities, making vulnerability exploitation a leading initial access route.
However, the answer is not simply to patch every vulnerability marked “critical”. The objective should be to identify which vulnerabilities are most likely to create material loss for the organisation—and address those first.
To do that, organisations need to combine technical severity with threat intelligence, asset context, control effectiveness and business impact.
What CVSS actually tells us
CVSS provides a standardised way to describe the characteristics and technical severity of a vulnerability.
CVSS version 4.0 contains four metric groups:
- Base metrics, describing the intrinsic characteristics of the vulnerability;
- Threat metrics, reflecting factors that may change over time, such as active exploitation;
- Environmental metrics, adapting the assessment to a particular environment;
- Supplemental metrics, providing additional context without changing the final score.
The resulting score ranges from 0 to 10, with higher scores indicating greater technical severity.
This makes CVSS extremely useful. It creates a common language that allows vendors, researchers and security teams to communicate consistently about vulnerabilities.
The problem arises when a CVSS Base score is treated as a complete measure of organisational risk.
A Base score does not, by itself, answer questions such as:
- Is the affected system exposed to the internet?
- Is exploitation occurring in the wild?
- Does the asset support a critical business service?
- Are effective compensating controls already in place?
- What data could an attacker access?
- How quickly could the organisation recover?
- What would the disruption cost?
- Would exploitation create regulatory, contractual or legal consequences?
FIRST’s own CVSS specification states that organisations should use CVSS as an input to their vulnerability-management processes alongside factors that fall outside CVSS, including monetary loss, regulatory requirements, customer impact, reputational harm and threats to life or property.
CVSS is therefore an important component of risk analysis, but it is not risk itself.
Two critical vulnerabilities can represent very different risks
Consider two servers affected by vulnerabilities with identical CVSS Base scores of 9.8.
The first is a development server located on an isolated internal network. It contains test data, has no direct internet exposure and can be temporarily shut down without affecting customers.
The second is an internet-facing identity service used by employees and customers. It supports access to critical applications and processes personal information.
The technical vulnerabilities may have the same severity score. The business scenarios are entirely different.
A successful attack against the development server might require several conditions to align and cause limited operational disruption.
A successful attack against the identity service could lead to account compromise, service interruption, incident-response costs, customer notifications, regulatory scrutiny and reputational harm.
Prioritising both findings solely because they have the same CVSS score ignores the factors that determine the organisation’s actual exposure.
Add evidence of exploitation with CISA KEV
The US Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities Catalog, commonly known as CISA KEV.
A vulnerability is not included merely because exploitation is theoretically possible. The catalogue focuses attention on vulnerabilities for which there is evidence of exploitation in the wild.
CISA recommends that organisations use KEV as an input to their vulnerability-management prioritisation frameworks.
KEV answers an important question:
Are attackers known to be exploiting this vulnerability?
A vulnerability appearing in KEV should generally receive immediate attention, particularly when the affected technology is present within the organisation and accessible to a relevant threat actor.
However, KEV should not be used in isolation.
A KEV vulnerability affecting an obsolete product that the organisation does not use presents no direct exposure. A KEV vulnerability affecting a heavily restricted internal system may present less urgency than the same vulnerability on an internet-facing service.
KEV provides strong threat evidence. Asset and environmental context determine what that evidence means to the organisation.
Add exploitation probability with EPSS
The Exploit Prediction Scoring System, or EPSS, provides another valuable signal.
EPSS produces a daily estimate of the probability that exploitation activity will be observed for a published CVE during the next 30 days.
This helps answer a different question:
How likely is this vulnerability to be targeted in the near future?
Where CVSS describes severity, EPSS estimates exploitation probability.
For example, two vulnerabilities may both have CVSS scores above 9.0, but one may have an EPSS probability below 1% while the other has a probability above 70%.
The first vulnerability could still be serious. The second, however, may require substantially more urgent action because the threat conditions are different.
EPSS scores are refreshed daily because exploitation patterns change. Public exploit code may become available. A vulnerability may be incorporated into offensive security tools. Attackers may shift their attention towards a particular technology.
EPSS should therefore be treated as a dynamic signal rather than a permanent classification.
It is also important to understand what EPSS does not provide. EPSS does not predict whether exploitation against your specific organisation will succeed. It does not know whether you run the affected product, whether the asset is exposed or what the resulting loss would be.
That requires organisational context.
Add asset and business context
Threat intelligence becomes actionable when it is connected to the organisation’s environment.
At a minimum, the prioritisation process should consider five contextual questions.
1. Is the organisation actually exposed?
Confirm that the vulnerable product and version are present.
Scanner findings may contain false positives, duplicate findings or systems that are no longer active. A vulnerability that does not exist within the environment should not consume remediation capacity.
2. Can a relevant threat actor reach the asset?
Internet-facing systems will often present different exposure from isolated internal systems.
However, internal does not automatically mean safe. An internal vulnerability may still be reachable following phishing, credential theft, supplier compromise or lateral movement.
The question is not simply whether the asset is online. It is whether a credible threat actor can establish contact with it.
3. What business service depends on the asset?
Asset criticality should reflect business dependency rather than the purchase price of the server.
A modest virtual machine may support authentication, payment processing, manufacturing, healthcare delivery or another critical process.
The more important the service, the greater the potential impact of its compromise or unavailability.
4. Which controls affect the scenario?
Controls can materially change the likelihood or magnitude of loss.
Relevant controls may include:
- network segmentation;
- multifactor authentication;
- web application firewalls;
- endpoint detection and response;
- application allow-listing;
- least-privilege access;
- secure backups;
- centralised logging;
- tested incident-response procedures.
The existence of a policy is not enough. The assessment should consider whether the control is implemented, operating effectively and supported by current evidence.
5. What happens if exploitation succeeds?
Technical impact must be translated into business consequences.
Potential consequences include:
- loss of system availability;
- theft or alteration of information;
- incident investigation and recovery costs;
- lost productivity;
- revenue interruption;
- customer compensation;
- contractual penalties;
- regulatory action;
- legal expenses;
- reputational damage.
This is the point at which vulnerability management becomes cyber-risk management.
Use FAIR to quantify the risk scenario
Factor Analysis of Information Risk, or FAIR, provides a structured method for analysing cyber and operational risk in financial terms.
Rather than describing a vulnerability as simply “high risk”, FAIR encourages analysts to define a specific loss scenario.
For example:
A financially motivated external attacker exploits a vulnerability in the organisation’s internet-facing identity platform, gains unauthorised access to customer accounts and causes response costs, customer losses and regulatory consequences.
The analysis can then consider two broad elements:
- Loss event frequency: How frequently might the scenario produce a loss?
- Loss magnitude: How large might the resulting loss be?
The vulnerability’s characteristics, KEV status and EPSS probability can help inform the frequency side of the analysis.
Asset importance, data sensitivity, operational dependency, control effectiveness and potential response costs help inform magnitude.
The output is not a guarantee of what will happen. It is a defensible range of probable outcomes that decision-makers can compare against remediation costs and competing priorities.
An illustrative prioritisation example
Assume that two assets have vulnerabilities with the same CVSS Base score.
| Factor | Vulnerability A | Vulnerability B |
|---|---|---|
| CVSS Base score | 9.8 | 9.8 |
| Asset | Isolated development server | Customer identity platform |
| Internet-facing | No | Yes |
| CISA KEV | No | Yes |
| Illustrative EPSS probability | 0.6% | 74% |
| Data | Synthetic test data | Customer personal information |
| Compensating controls | Segmentation and restricted access | Partial controls |
| Business dependency | Low | Critical |
| Likely action | Standard remediation cycle | Emergency remediation |
This example does not suggest that Vulnerability A should be ignored. A CVSS score of 9.8 still indicates potentially severe technical consequences.
It shows why Vulnerability B should probably be addressed first.
The decision is supported not by one score, but by the combined evidence:
- confirmed exploitation;
- high predicted exploitation activity;
- direct external exposure;
- critical business dependency;
- sensitive information;
- incomplete compensating controls;
- potentially significant financial loss.
That is risk-based vulnerability prioritisation.
A practical vulnerability-prioritisation workflow
Organisations can implement this approach through the following workflow.
Step 1: Confirm the finding
Verify the affected product, version, asset and vulnerability.
Remove false positives, duplicates and findings associated with decommissioned assets.
Step 2: Record technical severity
Capture the CVSS version, score and vector rather than storing only the numerical score.
The vector provides important information about how the score was calculated.
Step 3: Enrich the finding with threat intelligence
Determine whether the vulnerability:
- appears in CISA KEV;
- has a current EPSS score;
- has publicly available exploit code;
- is being discussed in credible threat intelligence;
- is associated with active campaigns or relevant threat actors.
Step 4: Connect the vulnerability to the asset
Identify:
- the asset owner;
- the asset’s exposure;
- the business service it supports;
- the information it processes;
- its recovery requirements;
- the organisation’s dependency on it.
Step 5: Assess controls
Determine which preventive, detective and responsive controls apply.
Record whether those controls are fully implemented, partially implemented, ineffective or unsupported by evidence.
Step 6: Define the risk scenario
Describe the threat actor, asset, event and business consequences clearly.
Avoid vague statements such as “the vulnerability may cause a breach”. A good scenario explains who might act, what they might do and how the organisation could experience loss.
Step 7: Select the treatment
The available responses may include:
- urgent patching;
- scheduled patching;
- temporary mitigation;
- network isolation;
- enhanced monitoring;
- service replacement;
- formal risk acceptance;
- a time-limited exception with review conditions.
The selected treatment should reflect the risk reduction achieved, the cost of the action and the organisation’s risk appetite.
Avoid creating another misleading score
It may be tempting to combine CVSS, EPSS, asset criticality and control ratings into a single mathematical score.
For example:
CVSS × EPSS × asset criticality = risk score
This can create the appearance of precision without a defensible model underneath it.
CVSS and EPSS measure different things. Asset criticality ratings may be ordinal rather than numerical. Control assessments may contain significant uncertainty.
Combining them without understanding their meaning can produce a score that is easy to rank but difficult to explain.
A better approach is to use each source for its intended purpose:
- CVSS: How technically severe is the vulnerability?
- CISA KEV: Is there evidence of exploitation?
- EPSS: How likely is exploitation activity in the next 30 days?
- Asset context: What is exposed and how important is it?
- Control assessment: What changes the likelihood or impact?
- FAIR: What financial loss exposure does the scenario create?
The outcome should be a transparent decision supported by evidence—not simply another colour or unexplained number.
Bringing vulnerability and risk management together
Vulnerability information is often managed separately from enterprise risk information.
Security teams work with CVEs, scanner findings and patches. Risk teams work with scenarios, controls, policies and business impact. Executives receive dashboards that attempt to summarise both, but the connection between them is frequently unclear.
PurpleWASP brings these elements into a connected risk workflow.
Technical findings can be enriched with threat intelligence, connected to assets and business services, mapped to relevant controls and evidence, and evaluated through a FAIR-based risk scenario.
This helps organisations move beyond questions such as:
How many critical vulnerabilities do we have?
Towards more useful questions:
Which vulnerabilities create the greatest probable loss exposure?
Which remediation action will reduce the most risk?
Which controls are materially changing our exposure?
Where should limited security resources be used first?
These are the questions that enable security teams to communicate with business leaders in terms of priorities, trade-offs and outcomes.
Final thoughts
CVSS remains an essential vulnerability-management standard. The problem is not CVSS itself. The problem is using a technical severity score as a substitute for organisational risk.
Effective prioritisation requires several layers of evidence:
CVSS provides severity.
CISA KEV provides evidence of exploitation.
EPSS provides an estimate of near-term exploitation probability.
Asset and control context explain organisational exposure.
FAIR translates the scenario into probable financial impact.
When these elements are considered together, vulnerability management becomes more focused, explainable and aligned with the organisation’s objectives.
The goal is not to patch the greatest number of vulnerabilities.
The goal is to reduce the greatest amount of business risk with the resources available.
