What are common mistakes with security ROI?

Why security ROI is easy to overstate

Security ROI is usually misread when teams turn uncertainty into a single number. The better question is not whether security creates a precise financial return, but whether a control meaningfully changes the loss profile, compliance exposure, or operating burden enough to justify the spend. That is a risk and decision exercise, not a spreadsheet trick.

One common mistake is treating avoided loss as if it were already saved cash. Another is ignoring the recurring cost of running the control, including tuning, exceptions, investigations, renewals, and the people needed to keep it effective over time.

For investment framing, the relevant comparison is usually between the current exposure and the post-control exposure, plus the implementation and maintenance cost. That is why the most useful outputs are often ranges, scenarios, or prioritised risk reductions rather than a single “return” figure that looks exact but rests on weak assumptions. For programs that need to justify security spend in the context of identity, IAM, PAM or agent access, the business-case structure in Identity and NHI Security Business Case Guide is a practical reference point.

Where ROI calculations go wrong in practice

ROI breaks down when teams compare unlike things. A control that reduces breach likelihood, one that lowers regulatory exposure, and one that reduces operational toil do not all produce the same kind of value, so forcing them into one uniform formula often hides the real trade-off.

Another mistake is using inconsistent assumptions across options. If one control is evaluated with optimistic likelihood estimates, zero maintenance cost, and full loss avoidance, while another is judged on conservative assumptions, the comparison is not decision-grade.

Teams also undercount the cost side. Controls that appear “cheap” at purchase can become expensive once you include false positives, admin time, integration work, user friction, audit evidence, and lifecycle maintenance. That issue shows up in many control areas, including authentication hardening, where recurring operational burden is often larger than the initial rollout. Common missteps are documented in Top 10 MFA Mistakes, especially where rollout errors and fallback paths create hidden cost and weak protection.

Security ROI also suffers when assumptions are not reusable. If the model cannot be defended later, it is better to present a low, medium, and high case than to claim precision that cannot be audited. That is especially important when the control decision affects access, secrets, or account governance, because the operating cost and risk reduction can change materially with scale.

What a better security value comparison looks like

A better approach is to compare controls on the basis of measurable effect, not rhetorical value. Ask what loss scenario changes, what exposure is reduced, what burden is created, and how stable the assumptions are if the environment changes.

For example, some controls reduce the chance of a high-impact event, while others mostly improve visibility or governance. Those can both be worthwhile, but they should not be scored as if they produce the same kind of return. In cloud and identity-heavy environments, overprivilege, leaked secrets, and misconfiguration often create value cases that are stronger than headline breach reduction alone, because they also reduce investigation load and downstream operational noise. Related failure patterns are grouped well in Top 10 Cloud Security Risks and Top 10 Secrets Management Mistakes.

It also helps to separate avoided loss from avoided uncertainty. A good control may not prove it will prevent a breach, but it can still be justified if it narrows the blast radius, improves detection, or makes compliance failures less likely. That is a stronger and more defensible value statement than promising savings that can never be observed directly.

Risk and Threat Considerations

Security ROI errors become dangerous when they hide real exposure. Overstating return can lead to underinvestment in controls that reduce credible attack paths, regulatory penalties, or operational disruption, while understating cost can lead to controls that look good on paper but fail under sustained use.

Failure mechanism: The model assumes losses are certain, independent, or fully preventable, and it ignores that control effectiveness decays when exceptions, alert fatigue, maintenance debt, or incomplete coverage accumulate.

Impact: Leaders can approve the wrong control, overcommit budget to low-value activity, or leave major exposure unaddressed because the numbers made the investment look safer than it was.

Practitioner Guidance

What to verify: Validate that every ROI claim states the loss scenario, the likelihood change, the impact change, and the ongoing operating cost in the same units. If any of those are missing, the result is not decision-grade.

Decision rule: If the control mostly reduces tail risk or compliance exposure, present it as risk reduction with cost context rather than as a traditional profit-style ROI. If the benefit is mostly operational, measure time saved, error reduction, or investigation load instead of forcing a breach-avoidance narrative.

What practitioners underestimate: Maintenance effort is often the hidden driver of bad ROI math. A control that needs continual tuning, cleanup, or exception handling can still be worth it, but only if that burden is explicit from the start.

Practitioner takeaway: The safest ROI discussion is usually not “What is the exact return?”, but “What measurable risk does this remove, what does it cost to sustain, and how confident are we in the assumptions?”

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?