Security teams should start with expected loss, not with tool cost. Estimate annual loss expectation from incident frequency and single loss expectation, then model how much loss the control prevents and compare that reduction with the annual investment. This gives the board a risk based financial view, even when exact losses are imperfect. The goal is to justify the amount of security needed, not to chase a generic ROI figure.
Why expected loss beats tool cost as the starting point
When the business impact is hard to quantify, the useful move is to anchor the conversation in expected loss. That means estimating how often the event could occur, what a single event is likely to cost, and how much the control reduces that loss. The board usually understands avoided loss, budget trade-offs, and exposure reduction better than a generic ROI percentage.
This framing also prevents a common mistake: treating security spend as if it must prove a clean profit return. Many controls are loss-reduction measures, not revenue generators, so the calculation should show whether the control materially lowers expected harm relative to its annual cost. If the loss estimate is uncertain, express it as a range and compare scenarios rather than pretending precision.
In practice, this approach works best when the team can separate direct costs, such as response and recovery, from indirect costs, such as outage time, customer churn, regulatory scrutiny, and engineering disruption. The more clearly those cost buckets are defined, the easier it is to explain why a control is justified even when the exact business impact is not fully knowable.
How to build a defensible model when the numbers are imperfect
Start with a simple expected annual loss model: incident frequency multiplied by single loss expectation. Then estimate the control effect as a percentage reduction in either frequency, severity, or both. A patching control may reduce frequency; monitoring may reduce dwell time and therefore severity; a compensating control may reduce blast radius. Do not force every control into the same shape.
If the business impact is highly uncertain, use bands rather than point estimates. For example, you can model best case, likely case, and adverse case, then show the expected loss avoided under each. That gives decision makers a transparent view of the assumptions that matter most. It is better to be approximately right about the range than exactly wrong about a single number.
For the model to be credible, the assumptions must be explicit. Security teams should document the event class, the time horizon, the baseline exposure, the control mechanism, and the reason the control is expected to change the outcome. NIST Cybersecurity Framework 2.0 is useful here because it supports risk-based governance, prioritisation, and communication across the functions the business already recognises.
Risk and Threat Considerations
Any return-on-security model is vulnerable to bad inputs, especially when teams use coarse estimates or optimistic assumptions. The biggest risk is underestimating frequency or overclaiming control effectiveness, which can make a weak control look financially justified and push spend away from higher-value risk reduction.
Failure mechanism: The model breaks when incident history is too thin, scenarios are too generic, or the assumed reduction does not match how the control actually works in the environment. If the organisation cannot evidence the frequency assumption or the loss components, the calculation becomes a presentation exercise instead of a decision tool.
Impact: Boards may approve controls that do not materially reduce expected loss, while better controls remain unfunded. Over time, this creates a false sense of precision, weak prioritisation, and a security portfolio optimised for easy-to-defend spend rather than real risk reduction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Aligns security spend to expected-loss and risk-based prioritization. |
| GV.OV-01 — Organizational Context and Risk Appetite | Board-level security economics must reflect business context and tolerance for loss. | |
| ID.RA-03 — Risk Assessment | The model depends on estimating likelihood, impact, and control effectiveness. | |
| Recommendation — Frame investments against expected loss reduction and document the assumptions behind each control choice. Map each security proposal to business context, loss tolerance, and decision-making thresholds. Estimate event likelihood and impact ranges before comparing controls on loss reduction. | ||
| CIS Controls v8 | CIS-17 — Incident Response Management | Incident response cost reduction is a material part of expected-loss modelling. |
| Recommendation — Quantify how controls reduce response time, recovery effort, and downstream incident cost. | ||
| NIST SP 800-63 | IAL/AAL/FAL — Digital Identity Assurance Levels | Identity assurance choices affect fraud and account-recovery loss assumptions. |
| Recommendation — Use assurance strength to estimate how authentication changes breach likelihood and loss. | ||
Practitioner Guidance
What to prioritise: Separate the modelling problem into three decisions, how likely the event is, how costly the event is, and how much the control changes that outcome. That sequence matters because cost estimates without a frequency view can make rare events look oversized, while frequency without loss can make nuisance issues look more important than they are.
What to verify: Test whether the control changes frequency, detection time, recovery time, or blast radius, then reflect only those effects in the model. If a control does not change a measurable loss driver, it may still be valuable for governance or resilience, but it should not be sold as a major financial reducer without evidence.
Practitioner takeaway: The best security investment model is one that shows how much expected loss is avoided, under stated assumptions, and keeps the discussion focused on risk reduction rather than forcing an artificial ROI number.
Related resources from NHI Mgmt Group
- How should security teams use business impact analysis to improve cyber resilience?
- How should security teams prioritise vulnerabilities when business impact matters more than severity scores?
- What do security teams get wrong about SOAR return on investment?
- What do security teams get wrong about return on security investment?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
