How do you prove ROI on things that didn't happen? Cybersecurity's hardest sales problem is that its value lives in absences—breaches prevented, downtime avoided, fines escaped. You resolve it by quantifying expected loss: model the probable cost of an incident, multiply by its likelihood, and show how the control shrinks that number.
That reframing—from "this breach was prevented" to "expected annual loss fell from X to Y"—is what turns a security pitch into a business case a CFO will approve. Here is the method, step by step.
Why cybersecurity ROI is hard to prove
Cybersecurity ROI is hard to prove because its central value is counterfactual: you are asking a CFO to fund the prevention of events that, if your product works, will never occur. You cannot point to a specific breach you stopped, and you cannot promise a breach will never happen. That is fundamentally different from a productivity tool that demonstrably saves measurable hours.
This is why so many security pitches default to fear, uncertainty, and doubt—and why so many fail at finance. A CFO cannot approve budget against an emotion or a worst-case headline. The breach-cost statistic that terrifies a CISO is, to finance, an unanchored number with no probability attached. The task of quantifying cybersecurity ROI is to convert that fear into a disciplined, probabilistic financial model the CFO can audit.
The resolution is to stop claiming certainty about individual events and start modeling risk the way finance already thinks about it: as expected loss across a portfolio of possibilities.
How to quantify cybersecurity ROI: the expected-loss model
To quantify cybersecurity ROI, model the security control's effect on expected loss and compare it to the control's cost. Expected loss is the foundation, and it is calculated in a way a CFO recognizes from every other risk decision the company makes.
The model runs in five steps:
- Estimate impact. What does a relevant incident cost an organization of this buyer's size and sector? Anchor it to a primary benchmark such as the IBM Cost of a Data Breach Report, adjusted to the buyer's profile—not a vendor's scariest number.
- Estimate likelihood. What is the annual probability of that incident, drawn from the buyer's incident history or industry rates?
- Compute expected annual loss under the status quo: impact × likelihood.
- Model the control's effect. Quantify how it reduces probability, reduces impact, or shortens detection-and-response time—then recompute expected loss with the control in place.
- Take the difference. Expected loss avoided is the core value driver, to which you add operational savings, compliance savings, and insurance benefits.
The defensibility of the whole model depends on transparent assumptions. The single benchmarks security teams should be using are collected in the cybersecurity business case statistics for 2026.
ROSI vs. ROI: the right formula for security investments
The right formula for a security investment is Return on Security Investment (ROSI), the avoided-loss variant of ROI. Standard ROI divides realized gains by cost; ROSI divides avoided expected loss net of cost by cost—because security returns are probabilistic, not realized revenue.
The ROSI formula is: (expected loss avoided by the control − cost of the control) ÷ cost of the control. If a control reduces expected annual loss by $600,000 and costs $200,000 fully loaded, ROSI is ($600,000 − $200,000) ÷ $200,000 = 200%. The reason ROSI is the correct frame is that it makes the probabilistic nature of the return explicit, which is exactly what a CFO needs to see to trust it. A return presented as certain reads as a vendor exaggeration; a return presented as risk-adjusted reads as analysis.
ROSI also forces honesty about residual risk: the control reduces expected loss but never to zero, and a credible model says so.
What CFOs actually want in a cybersecurity business case
CFOs want a cybersecurity business case translated entirely into financial language, with every number traceable to a source. Technical metrics—threats blocked, alerts triaged, detection coverage—matter to the CISO but do not move finance. The CFO is evaluating a capital allocation decision and wants the metrics that govern one.
Specifically, a CFO is looking for five things: expected loss avoided (the risk-reduction value driver), payback period (when the investment returns its cost), multi-year net ROI, the quantified cost of inaction (the status quo is the real competitor), and side effects on cyber-insurance premiums and compliance or audit cost. Each of these must carry a visible, editable assumption—finance rejects models whose inputs it cannot inspect.
ValueNova is an AI-powered value engineering platform that helps B2B sales teams build repeatable, CFO-ready business cases. For security deals, that means producing exactly this set of finance-grade outputs, with the underlying risk assumptions kept transparent rather than buried. For the tooling category that supports this motion, see business case software for cybersecurity sales teams.
Common mistakes when presenting cybersecurity ROI to finance
The most common mistake when presenting cybersecurity ROI to finance is leading with a breach-cost headline and no probability—a number designed to frighten rather than to model. Finance reads an unanchored "breaches cost millions" claim as marketing and discounts everything that follows it. Always pair impact with likelihood.
The second mistake is hiding or inflating assumptions to make the return look larger. A CFO has reviewed inflated vendor projections for years; an opaque 800% ROSI triggers skepticism, not a signature. A transparent, sensitivity-tested 150% return is far more persuasive than an unverifiable 800% one. Show the conservative case alongside the base case—acknowledging uncertainty increases credibility rather than weakening the pitch.
The third mistake is ignoring residual risk and insurance. Cyber insurance reduces but does not eliminate expected loss, and many controls lower premiums—both belong in an honest model. Omitting them makes the case look either naïve or overstated, and either reading costs the deal. Models built ad hoc in spreadsheets are especially prone to these errors; see why spreadsheet business cases collapse for the failure modes to avoid.