How to Prioritize Vulnerabilities Using Exploitability, Exposure, and Asset Criticality

Most vulnerability programs agree that CVSS alone isn't enough. Fewer have replaced it with something that works on a Tuesday morning when the queue has 40,000 open findings.

The model below is intentionally simple. It uses three inputs, produces a small number of priority tiers, and can be explained to an engineer in a couple of minutes. Simple models get used. Elaborate ones get debated.

The three inputs

Exploitability

How likely is it that someone will actually use this vulnerability?

Useful signals, roughly in order of strength:

1. Listed in CISA KEV or confirmed exploited by a trusted vendor or threat intelligence source
2. Public, working exploit code available
3. High EPSS probability
4. None of the above

Collapse these into three levels: exploited, likely, and unknown. Don't treat "unknown" as "safe." It just means you lack evidence.

Exposure

Can an attacker reach the vulnerable component?

• External: reachable from the internet, directly or through a load balancer
• Internal: reachable from the corporate network or user endpoints
• Restricted: isolated, segmented, or only reachable by a small set of systems

Exposure data usually comes from cloud inventory, attack-surface scans, and firewall rules. It will be imperfect. Default unknown assets to "internal," not "restricted."

Asset criticality

What would a compromise cost?

• High: identity systems, production data stores, payment paths, CI/CD with deploy credentials, security tooling
• Medium: production services without sensitive data, important internal tools
• Low: development, test, and sandbox systems

Get this list from service owners, not from security alone. They know which systems keep the business running.

Combining them

Map the inputs into tiers. One workable version:

• P1 — fix in days: exploited and external, or exploited and high criticality
• P2 — fix in a couple of weeks: exploited and internal; likely and external; likely and high criticality
• P3 — fix within normal cycles: likely and internal; unknown and external with high or critical severity
• P4 — scheduled maintenance: everything else

The exact timelines depend on your organization. What matters is that P1 stays small. If it regularly contains hundreds of items, the criteria are too loose or the environment has a deeper problem worth escalating.

Where CVSS fits

Severity still matters. Use it as a tiebreaker within a tier and as a filter for items that have no other signal. A critical-severity, externally exposed vulnerability with no exploitation data yet deserves attention, which is why it appears in P3 above.

Adjustments

Two modifiers are worth adding once the basics work.

Reachability. For application dependencies, evidence that the vulnerable code isn't reachable can lower priority by one tier. Require a documented reason.

Compensating controls. A specific, verified control, such as a WAF rule blocking the exploit path or a disabled feature, can lower priority by one tier for a defined period. Give it an expiry date and an owner.

Avoid stacking adjustments until a P1 becomes a P4. If something was exploited and exposed, a control buys time; it doesn't remove the need to patch.

Operationalizing it

A model on a slide doesn't change anything. To make it real:

• Compute tiers automatically. Pull the inputs from their sources on a schedule and assign tiers in code.
• Show the reasoning. Each finding should display why it landed in its tier.
• Tie SLAs to tiers. Track time to remediate per tier, per team.
• Review exceptions. Any manual tier change gets a reason and a reviewer.
• Revisit monthly. Check whether P1 volume is reasonable and whether anything that was exploited slipped through lower tiers.

Keeping data honest

The model is only as good as its inputs. Expect the first version to reveal gaps: assets with no owner, services with no exposure data, systems nobody can rate. Treat those gaps as findings in their own right. Fixing asset data often does more for risk reduction than any single patch.

Why this works

Three inputs, four tiers, documented rules. It isn't sophisticated, and that is its strength. Teams can predict how a finding will be prioritized, challenge it with evidence, and spend their limited time on the vulnerabilities most likely to hurt.