How should security teams calculate return on security investment for controls that mainly reduce risk instead of generating revenue?

Why Risk Reduction Needs a Different Financial Model Than Revenue ROI

Controls that mainly reduce risk do not create a revenue stream, so classic ROI language can mislead decision-makers. The useful comparison is avoided loss versus control cost, which lets security teams compare very different controls on a common financial basis. That shift matters because the buyer is not asking whether the control earns money, but whether it reduces expected loss enough to justify the spend.

This approach is strongest when the control changes the likelihood, impact, or both of a known loss scenario. If a control only creates compliance comfort or operational convenience, the financial case is weaker and should be treated separately from loss avoidance.

How to Estimate the Benefit of a Risk-Reducing Control

Start with the annualized loss expectancy for the scenario you are trying to reduce. Then estimate the mitigation ratio, meaning how much of that loss the control is likely to prevent, detect earlier, or contain. Subtract the annual control cost, and you have a practical measure of net avoided loss that supports budget comparison.

That estimate should be scenario-based rather than abstract. A control that reduces phishing-driven account takeover, for example, should be measured against the loss pattern it interrupts, not against a generic enterprise-wide security score.

Because the method is based on assumptions, the goal is consistency, not false precision. Use the same assumptions across candidate controls so the relative ranking is defensible even if the absolute numbers are approximate.

What Makes the Calculation Useful in Budget Decisions

Quantitative risk analysis is useful because it turns security from a purely qualitative debate into a repeatable decision model. It helps teams compare a preventive control, a detective control, and a compensating control without pretending they have identical financial effects.

The key practitioner signal is whether the control changes expected loss enough to matter at the portfolio level. A small reduction in one high-frequency loss event can outperform a very expensive control that only marginally lowers a rare event, even when the latter feels more “serious.”

That is why the calculation should be used for prioritisation, not as a promise of exact payback. It supports better ordering of investments and creates a defensible narrative for finance leaders who need to understand why a security spend is justified.

Risk and Threat Considerations

The main financial risk is overstating benefit by assuming a control removes more loss than it really does. If the mitigation ratio is guessed too optimistically, teams can approve controls that look economical on paper but fail to reduce meaningful exposure in practice.

Failure mechanism: The estimate breaks when the loss scenario is poorly defined, the control effect is double-counted, or the annual loss expectancy is borrowed from a different environment with different frequency or impact.

Impact: The organisation may underinvest in controls that actually reduce exposure, or overinvest in controls that feel reassuring but do little to reduce expected loss.

Practitioner Guidance

What to prioritise: Anchor the model to one material loss scenario at a time, then compare controls using the same loss assumptions. That keeps the discussion tied to measurable exposure rather than to vague security sentiment.

What to verify: Check that frequency, impact, and mitigation estimates are sourced from the same operating context, not from unrelated benchmarks. If the numbers cannot be defended consistently, treat the result as directional and avoid over-precision.

Practitioner takeaway: The best security finance case is usually not “this control has ROI,” but “this control removes more expected loss than it costs, under explicit assumptions we can explain and repeat.”

Related resources from NHI Mgmt Group

• How should security teams use policy and governance changes to reduce cybersecurity risk instead of relying only on technical controls?
• How should teams reduce the risk from overprivileged NHIs?
• How should security teams reduce risk from fragmented IAM controls?
• How should security teams reduce risk in software delivery pipelines with NHI controls?