That’s why worldwide spending on information security reached an estimated $180B in 2024, per industry analyst Gartner. 

Still, translating the benefits of cybersecurity into dollars and cents has long been a challenge for security teams. This makes optimizing spending on security initiatives difficult because there’s no standard metric for comparing the impact of one versus another. It’s not because there isn’t quantifiable value. It’s because Return on Investment (ROI), the standard used for quantifying the value of an investment, doesn’t directly account for the benefits of cybersecurity measures.

Why ROI Doesn’t Cut It for Cybersecurity

We dive into more detail in our new paper, When ROI Falls Short, but here’s the net of it: the formula for calculating ROI requires a “revenue” or “net profit” value to get the result. Cybersecurity initiatives typically don’t directly generate revenue or a net profit. 

Instead, these initiatives act as a safeguard, preventing potential losses such as data breaches, business downtime, ransomware attacks, reputational damage, and loss of customer trust. As such, an ROI metric that considers profits gained but not losses avoided fails to adequately capture the true impact. 

Why Return on Mitigation (RoM) Over ROI

Security leaders need a metric that reflects the true value of cybersecurity, and ROI isn’t it. Return on mitigation (RoM) redefines how we calculate ROI for cybersecurity. Instead of focusing on net profit, RoM measures “mitigated losses”—the financial damage avoided through proactive security measures.

If you take a closer look, you’ll notice that the RoM formula is the same as ROI, except instead of "revenue," we use "mitigated loss":

By factoring mitigated losses instead of revenue, security leaders see a much clearer picture of the financial impact of their cybersecurity efforts on the bottom line—putting a dollar amount to the losses they’ve prevented.

You can see more detailed examples of how RoM is calculated in our ebook, using the cost of breach data, offensive security program results, and exploitation likelihood, or test it yourself with our light RoM calculator. 

The Call for RoM Standardization

For security leaders, adopting RoM bridges the gap between the theoretical value of cybersecurity testing and the reality of loss prevention. It empowers them to more accurately justify security budgets, communicate value to stakeholders, demonstrate quantifiable risk reduction, and prioritize their resources more effectively—all through a common financial language.

Now imagine if that common language was also common within an organization and across cybersecurity. The standardization of RoM would provide significant benefits to the entire security community. Establishing a common framework for calculating and communicating the financial impact of cybersecurity investments would enable organizations to make more informed decisions about their security strategies. 

When everyone can calculate loss prevention with the same metric, they can benchmark with peers and across industries and better evaluate vendors and solutions. Meanwhile, it also provides greater support for regulators and cyber insurers, who need clear, methodical financial loss data to design regulatory standards and assess the adequacy of cybersecurity investments. 

Conclusion

If you read my recent blog, you’ll remember my stance heading into this year: the fight against cyber threats will not be easy and we’re in this fight together. The standardization of RoM is just one practical way organizations can come together in cybersecurity; by implementing an effective, common method for measuring the value of cybersecurity investments, we’re one step closer to taking down cyber threats on a universal scale.

Cybersecurity initiatives provide financial value to organizations. Board members and non-security executives know this to be true. 

When security incidents from software defects happen, retrospectives often tell the story of heroic remediation in the form of a few hundred lines of code (or less) but maximum organizational disruption: all-hands-on-deck root cause investigations and executives working 24/7 to control fallout. 

This reality has been the main drive behind the adoption of “Shift-Left” security—a proactive approach that integrates security testing like static application security testing (SAST) and software composition analysis (SCA) early in the development process. 

Common pre-production security controls in a software development lifecycle (SDLC).

Catching and fixing security vulnerabilities before they reach build, test, release, and deployment—before they even exist seems easy to justify, right?

Turns out it’s more complicated than that:

1. Return on Investment (ROI) arguments rely on speculation and fear: cost savings by avoiding unexpected losses.
2. Business priorities typically focus on revenue-generating activities. The prospect of adding any extra step to pre-merge workflows when a company is already behind on deadlines is a tough pill to swallow.
3. It’s hard to prove #1, very easy to prove #2.

Here, security leaders find themselves in an all-too-familiar paradox: if an ounce of prevention is worth a pound of cure, how is it so difficult to prove?

Rethinking return on security investment

Is a “return” on loss prevention the right justification for security investment? How do we quantify how well an organization outsmarts cybercriminals? How many organizations budget for expected data breaches as part of fiscal year planning?

Cybercriminal activity isn’t a predictable variable in business operations, but risk mitigation is. A more accurate framework for investment decision-making is return on mitigation (RoM)—the financial impact of preventing breaches, regulation penalties, and reputational damage.

Using the RoM model, we can estimate business impact for pre-attack mitigation. Imagine your team catches a high-severity SQL injection vulnerability during routine testing. Based on the $5.45M average cost of a data breach, its high severity, and exploitation likelihood (5.5%), the estimated mitigated losses is about $149,875. 

For more, check out HackerOne’s RoM calculator to see how much financial damage your security investments prevent.

The true cost gap

Another important factor in investment justification is the delta between cost of remediation pre-production vs. post-production. 

When a vulnerability is caught in production, fixing the code is a resource-intensive process that requires time and work from both security and engineering teams. How is the vulnerability possible? How and when did it get there? What development team, if any, is working on the application now? If we send the vulnerability report to the developers working on it, will they know how to fix it? Will attempt #1 to fix the vulnerability work? What about #2?

The below image from CISQ provides a good visual of how it plays out in practice: a trial-and-error feedback loop.

Dollar signs indicate where most effort/cost is concentrated.

At HackerOne, we see a median resolution lifecycle of 34 days for vulnerabilities reported to penetration tests. 

Even when a patch involves an update to just a few lines of code, determining what lines of code can be like looking for a needle in a haystack. Fixing vulnerabilities discovered in production is roughly 30 times more expensive than finding and fixing them during development.

Source: NIST: The Economic Impacts of Inadequate Infrastructure for Software Testing

Fixing a vulnerability in coding/unit testing is more cost-effective because the context is immediately known, and the complexities involved in writing the code change have already been solved (e.g., navigating existing technical debt to “get it to work”). When a developer is tasked with a vulnerability report to fix, it creates an unplanned cycle of repeating this work. All of the context and technical debt navigation needs to be re-learned. In other words, code patches—even the ones with just a few changed lines of code—take a lot longer than they look.

How big of a problem is this? Just ask your engineering team. Developers spend 13.5 hours a week dealing with technical debt, which is the biggest obstacle to making changes to existing code bases and has an estimated economic impact of $1.52T in the US alone.

A majority of development teams already have a quality assurance stage built into their workflow: pull request review and approval. For most development teams, proposed changes remain in this stage for 47-50 hours, during which defects are caught and fixed prior to merge. During this stage, developers catch and fix about 3.4-4.7 defects per 1,000 lines of code with the help of peer review and automated tooling.¹ These existing development practices provide an opportunity for a non-invasive security policy that, if thoughtfully executed, avoids duplication of development effort and minimal impact on velocity. Ideally, none.

Revisiting our example of an SQL injection vulnerability caught in production, let’s assume the root cause was an implementation where a JavaScript template string was used instead of a parameterized query which would have escaped values properly. If the developer writing the code was informed with the right guidance in a pull request review, it would have taken them 30 minutes to address. Caught in post-production testing, perhaps months later, expect it will take 15 hours of triage, troubleshooting, translating application security terminology to software engineering terminology, etc.

Determining cost impact can be more directly measured based on known operational expenses and varies between organizations. For this example, let’s say the cost is $100 per hour.

Post-production remediation: $1,500

Pre-production remediation: $50

Total operational cost savings: $1,450

This brings overall financial impact to $151,325 when added to return on mitigation ($149,875). Or, 3,027 times cheaper. “An ounce of protection is worth a pound of cure” may be an understatement.

Conclusion

Whether caught pre-production or post-production, catching and fixing vulnerabilities before cybercriminals can exploit them prevents enormous losses. Forecasting business value is best achieved by using a return on mitigation (RoM) framework. The additive business value in pre-production code security comes from significantly lower remediation costs.

There’s no one-size-fits-all methodology for metric-based objectives to determine a “shift-left” security program’s success, but a good place to start is the volume of true positive reports received over the 12 months with a reasonable “prevention” rate prediction (i.e., expecting 40% fewer new true positive reports matching target CWE categories).

How HackerOne is reinventing security for developers

While there’s a clear investment justification for security in development, efforts to “shift-left” often backfire, creating frustration for developers, an unhealthy relationship between engineering and security, and overly strict friction inhibitors on velocity. HackerOne has been on a mission to understand why “shift-left” security isn’t working and to build a methodology-based solution that gets it right.

HackerOne PullRequest is a true, developer-first approach to code security. We combine AI with expert human manual code review. The output – remediation guidance embedded directly in the developers’ existing workflow – empowers them to write secure code and proactively address security risks in the tools they already use. With a developer satisfaction rate of over 96%, HackerOne PullRequest is trusted by development teams because it’s actionable, fast, and self-learned.

¹ Source: HackerOne PullRequest Benchmarks sample of 3,000 organizations and 115,000 repositories spanning Small, Mid-Sized, and Large development team size cohorts.

There’s no debate that catching and fixing security flaws in development saves time, money, and stress.

Over the past 8 months, Luke (hakluke) Stephens and I have spoken with 10 security executives, surveyed over 550 security professionals, and incorporated insights from HackerOne’s CISO Advisory Board. A key challenge emerged repeatedly in our conversations: security leaders need a better way to measure and justify their investments—one that accounts for the financial impact of mitigated risks.

In this blog, we are excited to announce our white paper on Return on Mitigation (RoM), a framework we designed to quantify the financial impact of security programs in a way that speaks to business leaders.

Why traditional ROI falls short in cybersecurity

Organizations that apply traditional ROI models to cybersecurity often focus on cost-cutting measures like reducing headcount or operational expenses. However, this approach fails to account for security’s primary function: risk reduction and breach prevention.

As one CISO put it in our research:

"Security is often viewed as a cost center, not a revenue driver. ROI doesn’t work because you can’t always show direct returns—it’s about preventing damage, not generating income.”

By nature, security efforts protect revenue, brand reputation, and operational continuity by preventing financial losses rather than generating direct profit. Yet, these benefits are often difficult to quantify, making them harder to justify through traditional financial models.

Introducing the Return on Mitigation (RoM) framework

RoM offers a new way to approach cybersecurity justification by reframing security investments to avoid future losses—much like an insurance policy.

Instead of measuring revenue gained, RoM calculates mitigated losses. Instead of asking, "What revenue did this investment generate?" RoM asks, "What losses did we prevent by investing in cybersecurity measures?"

It does this by factoring in:

• The cost of a breach, using benchmarks like IBM’s Cost of a Data Breach Report
• The likelihood of exploitation, based on real-world vulnerability data we modeled on Verizon's Data Breach Investigations Report
• The cost of mitigation, including program investments and remediation efforts

By replacing traditional ROI’s “net profit” with “avoided losses,” RoM can concretely quantify cybersecurity’s financial impact.

The RoM Calculator: A practical tool for security leaders

One of the biggest takeaways from our research was that security leaders need more than theory—they need tools and models to run these calculations in real-world scenarios.

The first-of-its-kind RoM calculator we developed in this study integrates security program results, the likelihood of exploitation through the concept of Exploitation Likelihood Score (ELS), and industry benchmarks to calculate total mitigation savings. It provides organizations with defensible metrics for demonstrating the value of their security programs.

I had the opportunity to run countless real-world calculations on HackerOne customers to measure the financial impact of their security programs in the last 2 months. The results each time confirm that:

With RoM, it is now possible to demonstrate how every dollar spent on proactive security directly protects the bottom line.

A security leader at a global financial infrastructure provider describes it best:

“RoM allows me to justify a $300,000 investment against a potential $5 million critical breach. With this metric, I can show how mitigating vulnerabilities through continuous security testing prevents costly breaches and justifies spending.”

While the advanced RoM calculator is available to customers, we have also developed a light version that allows anyone to explore the concept and run their calculations using high and critical severity findings. 

HackerOne customers can run RoM calculations in real time

The RoM framework is now available to HackerOne customers, who can use the RoM calculator to measure their security investments in real financial terms.

With the HackerOne AI Copilot, Hai, customers can automate RoM calculations on every vulnerability submitted to the HackerOne platform. This means customers can instantly assess the potential financial impact of each vulnerability and prioritize mitigation efforts based on real risk data. By incorporating things like program history, industry benchmarks, and other key factors—such as assigned CVSS, CVE, or EPSS figures—we can bring in various dimensions to our analysis and make these assumptions as realistic, defensible, and actionable as possible, all within the HackerOne platform. 

And that’s just the beginning!

The future of RoM and how you can contribute

RoM provides security teams with a clear, quantifiable way to demonstrate their impact, making it easier to secure buy-in, budgets, and long-term investment in proactive security measures. However, for RoM to become a widely adopted industry standard, we need ongoing input from security professionals.

We’re actively refining RoM to ensure it remains a practical, defensible, and actionable framework for security investment justification. If you’d like to test the RoM calculator and provide feedback on how we can improve it, contact us (or message me on LinkedIn)— we’d love your insights.

To learn more, you can read the full white paper and join HackerOne’s webinar, “Quantify the Financial Impact of Cybersecurity with Return on Mitigation,” on March 12, 2025. In this webinar, we’ll discuss real-world applications of RoM and how you can use it in your organization!

How do you justify a cybersecurity investment? It’s a question every security leader struggles with. The problem is that the traditional Return on Investment (ROI) model simply doesn’t work in cybersecurity. Unlike traditional investments that generate direct revenue, security spending is all about risk reduction, breach prevention, and avoiding financial losses.

But how do you quantify the value of something that hasn't happened?