How to Justify an AppSec Budget to Management

Management approves a budget for application security when it sees not a list of tools but a reduction of specific risks in monetary terms, regulatory obligations and clear result metrics. Calculating a strict "ROI" for AppSec is hard, because the effect is prevented incidents. That is why the justification is built on loss scenarios, the cost of fixing issues at different stages, and measurable progress.

Why "ROI" in security is calculated differently

Unlike a product feature, security does not bring in revenue directly. Its value lies in reducing expected losses. That is why it is more honest to talk about reducing risk relative to cost, not about return on investment. The CEO, the CFO and the board usually ask: what will we lose if we do nothing; how much does it cost to reduce that by a given share; and how will we know that things have improved.

Step 1. Describe the risks in business language

Instead of "we have N critical vulnerabilities," show which business processes they affect:

• which systems process payments, personal data of customers, or commercial secrets;
• what happens in the event of a breach or downtime: service outage, fines, claims from customers and partners, reputational damage;
• which external requirements already apply: the regulator, standards (for example, PCI DSS — see requirements for payment page scripts), and contractual obligations to partners.

Start with the 3–5 most critical systems. It is easier for management to make a decision about specific assets than about "security in general."

Step 2. Rely on verifiable external data

The best-known open source on the cost of incidents is the annual IBM and Ponemon Institute report Cost of a Data Breach. On the page of the 2026 report, IBM gives a global average cost of a data breach of USD 4.99 million (a record, up 12% from the previous year), and notes that organizations that actively use AI and automation in security saved USD 1.93 million compared with those that did not.

Important caveats to state yourself, so that you do not lose the audience's trust:

• these are global averages across a sample of organizations; the real figure for your company can be either lower or significantly higher;
• the report covers data breaches in general, not only incidents caused by vulnerabilities in applications;
• always cite the year and the link to the report — a slide with a "figure without a source" will be the first thing picked apart.

For the region, complement the external data with internal data: your own incidents, penetration test results, auditor findings and mandatory regulatory requirements.

Step 3. Show the difference in the cost of fixing

The argument that "the earlier a vulnerability is found, the cheaper it is to fix" is understandable to management and is confirmed by practice. But do not cite "eye-catching" coefficients such as "100 times cheaper" without a source — their origin is often not verifiable. It is more reliable to calculate on your own data:

• take 5–10 recent vulnerabilities found during a penetration test or in production;
• estimate the labor for fixing them: analysis, code change, retesting, an unplanned release, communications;
• compare this with the labor needed to fix a similar vulnerability at the pull request stage — you will get such data in the SAST/SCA pilot.

Step 4. Formulate the formula for the effect

For a presentation, a simple and transparent model is enough. Use the annualized loss expectancy (ALE):

• ALE before = probability of an incident per year × size of the loss;
• ALE after = the same probability with the measures in place × the loss;
• Effect = ALE before − ALE after − the annual cost of the AppSec program.

All parameters are estimates, so show ranges (optimistic, base and conservative scenarios) and state the assumptions explicitly. Management values an honest model with caveats more than a "precise" figure that cannot be defended.

The second part of the effect is easier to calculate: reduced labor on manual checks, faster releases without emergency rollbacks, and preparation for audits with ready-made reports. The structure of costs for the denominator of this formula is covered in the article "How Much Does DevSecOps Cost".

Step 5. Choose metrics that will show progress

Metrics are needed both for the justification and for reporting after launch. A working set:

• Coverage: the share of applications and repositories connected to scanning;
• Time to remediation: the average time to fix critical vulnerabilities (MTTR);
• Accumulated debt: the number of open critical and high vulnerabilities and their trend;
• Blocking rate: how many builds were stopped by a quality gate and how many of them were fixed on time;
• Dependencies: the share of components with known vulnerabilities, and the presence of an SBOM (What Is an SBOM);
• Detectability: the share of vulnerabilities found before production, versus those found by a penetration test or in operation.

Agree with management on target values for 6–12 months. This turns the budget into a clear commitment.

Step 6. Propose a phased plan and a pilot

What reduces resistance to a decision is not a large figure but a limited first step with a measurable result. A typical structure:

1. A pilot on 1–2 critical applications; the goal is to get your own data on findings and labor effort.
2. Expansion to the remaining critical systems, with quality gates enabled.
3. Scaling to all development, with regular reporting.

The decision on the next stage is made based on the pilot metrics — for management, this limits the risk of an unsuccessful purchase.

Common mistakes in the justification

• Scaring without numbers. General frightening examples work once; after that you need your own systems and your own risks.
• Technical language. A manager does not need the names of vulnerability classes; they need the business effect.
• One "big" budget without stages. It is easier to postpone.
• Ignoring the cost of people and fixing. The CFO will notice them later and will doubt the rest of the calculations.
• Unverified data. Attach the name of the report, the year and a link to every external figure.

How to structure the presentation itself

A presentation structure that works well in practice fits into five slides:

• Situation. Which systems are critical and what is known about their vulnerabilities now (based on penetration tests, audits, the pilot).
• Risk. Loss scenarios for 3–5 assets and external benchmarks, with the source stated.
• Proposal. What exactly you plan to implement and in what order, without listing the tool features.
• Cost. Licenses, implementation, people, training and support by year; a breakdown by stage.
• Result. Metrics, target values and decision points: when you will come back for the next stage.

Separately, prepare an answer to the question "what if we buy nothing": describe which obligations under standards and contracts will remain unmet and which regulatory requirements you will not be able to cover. Often this answer turns out to be decisive.

How to handle objections

• "We have never had a breach." The absence of detected incidents does not mean the absence of vulnerabilities. Offer a pilot or a security assessment to get facts.
• "Developers will slow down." Show an "inform only" mode at the start and measure pipeline time; enable blocking gradually.
• "It is expensive." Move from the total amount to a phased plan and compare it with potential losses for your critical systems.
• "There are free tools." They exist, but they require time to maintain; compare the total cost of ownership, not the license price.

What to do after the budget is approved

The justification does not end with the decision. In 3–6 months, go back to management with a report on the agreed metrics: what coverage has been achieved, how many critical vulnerabilities have been closed, how the time to remediation has changed, and how many problems were stopped before production. If the numbers fall short of the plan, explain the reason honestly and propose an adjustment. Such transparency builds trust and makes it easier to approve the next stage of the program.

Frequently asked questions

Sources

• IBM: Cost of a Data Breach Report
• PCI SSC Blog: PCI DSS e-commerce requirements taking effect on 31 March 2025