Expected loss is probability times impact. It is a useful way to rank vulnerabilities because it forces you to state both parts. It breaks down when probabilities are guesses, when impacts are heavy tailed, or when you add numbers that mean different things. Use it with ranges, not single points.
A worked example
Illustrative. Two issues compete for a fix this week.
- Issue A: 30 percent chance of being exploited this year, and a loss of 10,000 if it happens. Expected loss 3,000.
- Issue B: 1 percent chance, and a loss of 1,000,000. Expected loss 10,000.
By the formula B outranks A, despite being far less likely. If you fix A first because it is more probable, you leave the larger expected loss open.
Where it helps
- It surfaces the rare but severe items that a likelihood only ranking would bury.
- It exposes disagreement. If two people rank differently, they usually disagree about one of the two inputs, and you can discuss that input directly.
- It lets you compare fixing something against accepting it, in the same units.
Where it breaks
- The probability is a guess. Exploit likelihood data helps, but your exposure matters too. A flaw in code that is never called has a very low probability whatever the public score says.
- Impact is heavy tailed. The average loss tells you little when most outcomes are small and a few are enormous. Look at the worst plausible case as well as the average.
- Spurious precision. Writing 0.0137 times 842,000 looks rigorous and hides that both numbers are rough. Use bands such as low, medium, high with stated ranges.
- Adding scores that are not in the same units. A sum of "risk points" across many issues can mean nothing unless each point maps to a stated amount.
- Correlation. Ten issues in one library are not ten independent bets. One upgrade removes them all, and one attacker can use them together.
Better practice
- Use ranges. "Probability 1 to 5 percent, loss 200,000 to 2,000,000" gives an expected loss range, and the ranking is usually stable even when the numbers are not.
- Add a cost to fix. Rank by expected loss removed per hour of work. A cheap fix with a modest loss can beat a costly one with a larger loss.
- Modify the probability with evidence about reachability and exposure. See reachability and noise for how that changes the list.
- Apply hard rules above the math. Known exploited issues on internet facing systems should go first regardless of the formula.
Calibrate your guesses
People are usually overconfident. Our exercise on calibrating risk estimates gives a practical way to check your ranges against outcomes over time.
Quick check
Is probability times impact the same as a severity score?
No. A severity score describes how bad a flaw is in general. Expected loss is specific to your system, combining how likely it is to be used against you and what it would cost.
What if I cannot estimate probability at all?
Use broad bands and state them. A rough, honest range is more useful than a refusal to estimate, as long as you revisit it with new evidence.
Last reviewed: 19 October 2026.
