What do teams get wrong about calculating security ROI from incident loss data?

A common mistake is treating security like a normal profit investment and focusing on productivity or purchase price alone. Another mistake is ignoring historical incident frequency, direct loss, and indirect breach costs when estimating value. Good ROSI analysis uses realistic loss assumptions and the expected effect of controls, otherwise the result is too vague to support a decision.

Why incident loss data is the right input, but the wrong place to stop

Security ROI becomes unreliable when teams treat incident loss as a single number instead of a distribution of outcomes. The useful question is not whether a control “pays for itself” in the abstract, but whether it reduces expected loss from the incidents that are most likely and most expensive in that environment.

That means the calculation has to distinguish direct loss, such as response cost and recovery effort, from indirect loss, such as downtime, customer churn, legal exposure, and business interruption. If you ignore those categories, you can make a control look unimportant even when it materially changes the loss curve.

For incident-driven analysis, the better framing is expected loss avoided, not gross savings. That requires a realistic baseline for how often incidents happen, how severe they are when they do happen, and how much a proposed control actually changes either frequency or impact. Without that structure, ROI becomes a story rather than a decision tool.

Use incident loss data to estimate both frequency and severity, not just average breach cost.
Separate one-time recovery cost from recurring operational drag after the incident.
Model the control’s effect on likelihood, blast radius, and time to recovery.

Where teams misread the numbers

One common error is assuming historical incidents are a clean predictor of future loss. In practice, incident data is usually sparse, uneven, and shaped by detection quality, reporting thresholds, and changing attack patterns, so a simple average can understate tail risk.

Another mistake is double counting or omitting costs. For example, response labour, legal review, and system restoration may be counted, while revenue interruption, contract penalties, and customer remediation are missed. The result is an ROI model that looks precise but is missing the business consequences that usually drive the decision.

Teams also over-credit controls for losses they would not have prevented. If a measure only shortens recovery time, it should not be modelled as eliminating the entire incident cost. Good analysis isolates the portion of loss the control can plausibly reduce, which is where the value estimate comes from.

For NHI-heavy environments, the loss side is often underestimated because compromise can persist after notification if secrets remain valid or privilege remains excessive. NHIMG research notes that 91.6% of secrets remain valid five days after the targeted organisation is notified, which is a strong reminder that delayed remediation can keep loss accumulating after the first detection event.

Risk and Threat Considerations

Incident loss data can make weak assumptions look defensible if teams average away rare but severe events. That creates a false sense of precision, especially where credential theft, privilege abuse, or lingering access turns a contained incident into a broader compromise.

Failure mechanism: The model understates expected loss because it assumes historical incident costs are complete, independent, and representative, while the real environment may have unmeasured indirect costs, delayed containment, or repeated exploitation of the same weakness.

Impact: Teams underinvest in controls that would materially reduce breach duration, recurrence, or blast radius, and they may approve measures that look efficient on paper but do not change the actual loss profile.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Incident loss models depend on limiting excessive access that can amplify breach impact.
	13 — Data Protection	Loss calculations should include the impact of exposed or exfiltrated data on breach cost.
Recommendation — Apply CIS Control 6 to reduce the access paths that turn incidents into larger losses. Apply CIS Control 13 to protect sensitive data whose exposure would materially raise incident cost.
NIST CSF 2.0	ID.RA — Risk Assessment	ROI from incident loss data requires realistic loss estimates, frequency, and impact analysis.
	RS.MI — Incident Mitigation	The value claim depends on whether a control reduces response time and containment cost.
Recommendation — Use ID.RA to model expected loss and the control effect before funding a security investment. Use RS.MI to quantify how a control shortens containment and lowers incident loss.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Valid secrets and delayed rotation can extend incident duration and inflate realised loss.
	NHI-03 — Least Privilege and Access Minimization	Excessive privilege increases blast radius, which directly changes expected incident loss.
Recommendation — Rotate and revoke secrets promptly to reduce the loss window after compromise. Minimise privilege so an incident cannot spread into higher-cost compromise.

Practitioner Guidance

What to prioritise: Anchor the ROI discussion on the loss dimensions that would change a funding decision, usually downtime, recovery labour, regulatory exposure, and customer impact, rather than on purchase price alone. If the control only changes one of those dimensions, model only that effect.

What to verify: Test whether the incident dataset includes repeat events, near misses, and post-notification remediation delays, because those are often what change the expected value. If the data set only contains headline breach summaries, treat it as directionally useful but too thin for a final investment case.

Practitioner takeaway: The point of ROI analysis is to estimate avoided loss with enough realism to support a decision, not to produce a neat percentage that ignores how incidents actually unfold.