A critical vulnerability on an Alpine-based reverse proxy sitting behind three layers of network controls isn't actually critical.
A medium-severity finding on the database holding 90% of your customer data might be.
CVSS scores don't know the difference. Your security team needs to.
The Baseline Is Just the Start
Vulnerability prioritization is a hot topic for security teams and vendors. Everyone wants a magic number that tells you what to fix first. The problem is that magic number doesn't exist--at least not without context.
The way we approach it: focus on criticals and highs, generally ignore lows, and treat mediums as a "maybe" that gets reviewed after the urgent stuff is handled. That's a reasonable baseline, but it's just the starting point.
Some things flagged as critical don't matter much in practice. Some highs can be demoted when compensating controls reduce the real risk. And some mediums deserve more attention because of what they protect.
What Actually Drives Risk
When you look at prioritization honestly, it comes down to business impact. The technical severity score is one input, but it's not the whole picture.
Real risk to the business: What happens if this gets exploited? Not in theory. In your specific environment, with your specific data, serving your specific customers.
Commercial and legal exposure: What does a breach mean for contracts? For liability? For regulatory compliance? A vulnerability affecting systems that process healthcare data carries different weight than one on an internal dev server.
Data classification: Is this customer data? Internal data? Partner data? Public data? The sensitivity of what's at risk changes how fast you need to move.
Attack path: How hard is it to get here? A vulnerability on an internet-facing system is different from one buried behind VPNs, firewalls, and authentication layers.
Known exploitability: Is this on the CISA KEV list? Is it being actively exploited in the wild? EPSS scores help predict exploitability. These signals matter more than theoretical CVSS calculations.
Customer and revenue impact: Does this infrastructure serve 90% of your customer base or 1%? What revenue flows through these systems?
You pull all that together and make smart decisions. No algorithm does it for you.
The Stakeholder Experiment
We've experimented with stakeholder-specific vulnerability scoring--the concept is appealing. Different people in an organization weight risk differently. The CFO cares about financial exposure. The CTO cares about operational stability. The CISO cares about compliance and reputation.
We ran vulnerabilities through AI personas representing different stakeholders, then pressure-tested the outputs with actual people. "Our AI bot of you thought this. Do you agree?"
It was a fun thought experiment. Interesting results. But it didn't fundamentally change day-to-day operations. When you have tight alignment with your team on risk tolerance and technical context, you don't need elaborate personas. You need clear communication and shared understanding.
Compensating Controls Matter
One of the most common prioritization adjustments: demoting findings where compensating controls reduce real risk.
That critical vulnerability on a system with no network exposure, running behind a WAF, on a hardened container with no persistent storage? It might still need patching eventually, but it's not the fire you put out first.
The reverse is also true. A vulnerability flagged as medium, on a system with direct internet exposure and access to crown jewel data, deserves escalation.
CSPM tools are getting better at incorporating some of this context. Risk scores that adapt based on internet exposure, sensitive data discovery, and access permissions. But they can't know your business. They don't know which customers matter most, which contracts have the strictest SLAs, which systems represent the core of your revenue.
That context lives in your organization. Someone needs to bridge the gap between technical findings and business reality.
Accepted Risk Is Still Risk
Sometimes the answer is that you're not going to fix this.
Maybe the system is scheduled for decommissioning. Maybe the remediation requires changes that break other things. Maybe the risk is real but acceptable given current priorities.
That's fine, as long as you track it. Accepted risks go in the risk register. They get reviewed periodically. They don't disappear just because you decided not to act on them immediately.
The worst situation is unacknowledged risk. Vulnerabilities ignored without explicit decision-making, sitting in the backlog until someone asks about them at the worst possible moment.
Making Prioritization Work
The triage process we use:
- Collect criticals and highs
- Sort by actual business context (not just CVSS)
- Assign the team to fix the real priorities
- Review mediums periodically (some become highs, some become non-issues)
- Track anything you're not fixing as accepted risk
The goal isn't zero vulnerabilities. It's focusing limited resources on what matters most, based on real understanding of your environment.
The Takeaway
Vulnerability severity scores are tools, not answers. They give you a starting point for investigation, not a decision.
Real prioritization requires knowing your business. What data is sensitive. What systems are critical. What contracts require specific protections. What customers you can't afford to disappoint.
Technical scores will never capture all of that. But combined with business context, they become genuinely useful.
If your team is spending time debating which "critical" vulnerabilities are actually critical, or worse, treating everything the same because there's no time to think it through, you're not getting the value you should from your tools. Sometimes it helps to have someone come in who's done this prioritization work across many environments, establish a framework, and get the team aligned on what actually matters.
Jon Rose runs IOmergent, advising engineering-led companies on security strategy and managed cloud security operations.