How We Rank Risks: Dollars at Stake, Not CVSS

Why CVSS is the wrong top-of-queue ranking signal

Here's the conversation every security leader has had with a CEO at least once.

CEO: "What's the most important thing we're working on right now?"

CISO: "The Log4j CVE — it's critical severity."

CEO: "OK, but what does it threaten?"

CISO: "…"

The pause is the problem. CVSS — the Common Vulnerability Scoring System — answers the question how severe is this vulnerability if exploited in isolation. It does not answer what business value is this risk threatening. Those are different questions, and for top-of-queue decisions, only the second one is useful.

This is the gap our prioritization engine closes. Your top risk isn't the one with the highest CVSS. It's the one burning the most business value per hour that it remains unresolved.

The formula

$priority\_score = technical\_score × asset\_multiplier × revenue\_multiplier × breach\_multiplier$

Four inputs. Each answers a question that matters:

1. Technical score — how severe is the risk if realized? Standard 4×4 impact × likelihood (0-25), the number every risk register already has.

2. Asset multiplier — what does this risk touch? Weighted by the criticality tier of linked assets: Critical = 2.0x, High = 1.7x, Medium = 1.4x, Low = 1.1x, None = 1.0x. A risk touching a critical revenue-generating asset is more urgent than an identical-severity risk touching a dev sandbox.

3. Revenue multiplier — what's the dollar impact per hour of exposure? Log-scaled with diminishing returns, capped at 2.0x. $1K/hr ≈ +7%, $10K/hr ≈ +23%, $100K/hr ≈ +46%, $1M/hr ≈ +69%. We cap it so revenue can't dominate technical severity — a risk with no technical substance shouldn't rank high just because it touches a revenue-heavy process.

4. Breach multiplier — is the clock already ticking? 1.0 baseline + 0.15 per breached mitigation task + 0.3 if any task hit the executive-escalation level. Capped at 2.0x. SLA failure on a risk lifts it in the queue because unresolved urgency compounds.

The product of all four gives a score that ranges from 0 (no risk) to roughly 100 for the worst-case: a critical-severity risk touching critical assets that threaten millions in revenue and has tasks breached past executive escalation.

The same inputs, a different answer

Take two risks, real shapes you'd see on any risk register:

Risk A — Classic CVSS winner

• Severity: Critical CVE in a web framework. technical_score = 20
• Linked assets: none specified
• Linked business processes: none
• Mitigation tasks: on track, no breaches

Under CVSS, this is your #1 — score 10.0, category "Critical."

Priority score: 20 × 1.0 × 1.0 × 1.0 = 20.0

Risk B — What actually matters

• Severity: High CVE on an API server. technical_score = 15
• Linked asset: Stripe payment gateway, criticality = critical (asset_mult = 2.0)
• Linked business process: Stripe payments flow, revenue_impact_per_hour = $12,000 (revenue_mult = 1.23)
• Mitigation tasks: one breached, escalated to risk owner at day 3

Under CVSS, this is #2 — score 7.5, category "High."

Priority score: 15 × 2.0 × 1.23 × 1.15 = 42.4

Same risk register. Same two risks. CVSS says A first. The dollar-stake formula says B first — and when the CEO asks why, the answer is right there: the second risk threatens $12,000/hour of Stripe payments processing, it's touching the payment gateway itself, and remediation is already slipping.

That's the conversation every security leader wants to have with their CEO. The formula is just the piece that lets them.

Why not just sort by CVSS and call it a day?

Three failure modes we see repeatedly in real programs:

1. The loudest-alert-wins trap. Scanners are noisy. CVSS ranks by how-bad-could-it-get in a worst-case isolation of the vulnerability — no context about whether the bug is reachable in your environment, whether the asset it lives on matters, or whether exploitation would cause any business harm. Teams chase whatever just crossed the "Critical" threshold in the scanner and never get to the risks with real business exposure.

2. The CISO-to-CEO translation gap. CVSS scores are technical scores. "CVSS 9.8" doesn't mean anything to a CEO or a board. "This risk threatens our payments flow, which is $12,000/hour of revenue" does. A ranking engine that produces an answer in the CEO's language closes the translation gap at the source, not as a quarterly board-deck translation exercise.

3. Business impact lives in spreadsheets, not risk registers. Most programs have RTO/RPO numbers for business processes somewhere — usually a BCP spreadsheet owned by someone other than the security team. Those numbers never get joined to the risk register, so the business-impact context is invisible at decision time. The dollar-stake formula makes the join mandatory: a risk either links to a business process (and carries that weight in its ranking) or it doesn't (and sits lower in the queue).

Why the multipliers work the way they do

Design choices worth calling out:

Log-scaled revenue. We don't want a $1M/hr process to make a risk rank 1000x higher than a $1K/hr process. Diminishing returns (ln(1 + x/1000)/10) means revenue impact shifts ranking meaningfully but can't dominate. Capped at 2.0x regardless of input.

Asset multiplier is bounded, not unbounded. 2.0x maximum even for a critical asset. We want the formula to surface both "critical asset, moderate severity" and "high severity, moderate asset" as top-tier — not pick one shape and ignore the other.

Breach pressure is surgical. We don't want every overdue task in the register pushing risks up uniformly. The multiplier grows per breached task but caps quickly, and executive-escalation specifically triggers the max. This reflects the real-world signal: a single task breached-and-escalated-to-CEO means the risk has political urgency beyond its technical severity.

The ranking is deterministic and auditable. Every multiplier is a pure function of the inputs. Sort order doesn't change based on weather, AI suggestions, or any other black box. When the CEO asks "why is this risk #1?", the engine can enumerate exactly: technical score N, asset tier X, $Y/hr revenue, Z SLA breaches. That defensibility is load-bearing for audit conversations.

What you need to link for the formula to work

The formula is only as useful as the context you feed it. Three dependencies:

1. Assets linked to risks. In Radius360 this is the risk_assets many-to-many table; in any GRC tool, the equivalent is a CMDB with an owner and criticality tier, joined to the risk register.

2. Business processes linked to risks. Similar join. The business process carries revenue_impact_per_hour (from the Business Impact Assessment the BCP team already has).

3. Mitigation tasks with SLAs. The breach multiplier relies on tasks having due dates and a breach mechanism. A risk register with SLA-less tasks gets a flat breach_mult = 1.0 — still works, just without the urgency boost.

Most programs already have two of these three somewhere. The work is wiring them to the risk register so the ranking engine can see them at query time. Once wired, the shift from CVSS to dollar-stake ranking is a single query.

Closing

Two things change when you run this formula:

1. The risk at the top of your queue changes. Not always, but often enough that the new ranking produces visibly different prioritization than CVSS-sorted lists. Specifically: risks that touch critical business assets move up; risks on irrelevant systems move down.

2. The conversation with leadership changes. You stop saying "this CVE is critical" and start saying "this risk threatens $X/hour of revenue." That's the language that earns budget and closes the translation gap that most security programs leave open.

Radius360 runs this engine live on every risk. See the prioritization view in your trial account, or if you want to understand the rest of the execution layer first, read the Security Posture as a Service breakdown.

---

Technical note: the exact weights above are our current defaults. The engine is tenant-configurable — industries with unusual risk profiles can tune the multipliers. Defaults were calibrated against ~200 real risk registers across vCISO client books.