Every CISO has lived this nightmare.

You’re sitting in a budget planning meeting, and you know your security program needs investment—maybe it’s headcount, maybe it’s tooling, maybe it’s that pen test you’ve been pushing off because you “don’t have budget.” You open your mouth to make the case, and you’re immediately caught in the paradox:

If you say “we’re insecure,” you look incompetent.

If you say “everything’s fine,” you don’t get budget.

It’s a knife’s edge. Say too much, and leadership questions why you haven’t fixed these problems already. Say too little, and they assume security is “handled” and allocate your requested budget to the sales team’s new CRM.

And here’s what makes it worse: You’re often asking for money to prevent something that hasn’t happened yet. You’re not selling a feature customers are demanding. You’re not fixing a broken revenue stream. You’re asking for investment in invisible success - and that’s a tough sell to a CFO who measures everything in ROI.

So how do you thread this needle? How do you justify security budget without undermining your own credibility?

The answer is in the framing. And more specifically, it’s in understanding that there are three fundamentally different types of security spending—and each requires a completely different justification strategy.

Use the Security Budget Requestor Tool (and PPTX creator)

https://adversis.github.io/security-budgets/

Three-Bucket Budget Framework

First, stop presenting your security budget as a monolithic “security needs.” That tells leadership nothing about why you need it or what happens if you don’t get it. Instead, break security requests into one of three buckets:

Bucket 1: Table Stakes aka The Cost of Doing Business

What it is: Compliance requirements, basic security hygiene, and non-negotiable controls that every company your size should have.

Examples:

• Basic security tooling (EDR, SIEM, vulnerability scanning, IAM tools, training)
• Mandatory penetration testing or audits for customer contracts
• SOC 2 audit and compliance maintenance
• Incident response capabilities

Language:

“This isn’t about whether we should do it—it’s about the cost of operating in our industry. Without centralized security solutions, we’re operating blindly and at high risk. Without SOC 2, we can’t sell to enterprise customers. Without annual pen testing, we can’t answer security questionnaires. This is the baseline cost of being a credible vendor.”

Why this works: You’re not asking for permission to spend—you’re explaining a cost structure. It’s like asking for budget for payroll taxes or business insurance. Of course you need it. The only question is whether leadership wants to be in business.

The CFO conversation:

“Here’s our table stakes security spend: $180K annually. That covers compliance audit, required testing, and basic tooling. This is the cost of selling to enterprise customers. If we don’t spend this, we lose deals. Last quarter alone, we had 4 prospects require SOC 2—that’s $400K in pipeline.”

Notice you’re not saying: “We’re insecure.” You’re saying: “This is what it costs to operate at our stage.”

Pro tip from Part 1: If you’re budgeting for annual penetration testing (which should be in this bucket), frame the timing strategically: “We budget for annual pen testing timed about two months before board meetings, giving us time to remediate findings and present clean results. This lets us use compliance requirements as a demonstration of security maturity.”

See what happened there? You just elevated a “table stakes” expense into something that makes you look strategic. Same test, better framing.

Bucket 2: Risk Reduction aka The Insurance Premiums

What it is: Proactive security investments that reduce the likelihood or impact of a breach.

Examples:

• Additional offensive security testing beyond annual requirements (product security reviews, red team assessments, purple team exercises)
• Security headcount growth
• Advanced security tooling (CSPM, CNAPP, advanced threat detection)
• Architecture improvements (zero trust work, improved segmentation)
• Bug bounty programs

Language to use:

“We’re not required to do this, but it materially reduces our risk of breach. Think of it like insurance—we’re paying a fraction now to avoid a much larger cost later. Based on industry breach data, the average cost of a breach for a company our size is $4.2M. This $200K investment reduces our likelihood of breach by X%.

In fact, last year our threat intelligence led us to resolve the very thing that led to a significant breach at XYZ competitor likely costing them significant time and money, not to mention reduced customer trust.”

Why this works: You’re speaking the language of risk management and ROI. CFOs understand insurance. They understand paying a small amount now to avoid a catastrophic cost later. You’re not saying “we’re vulnerable”—you’re saying “we’re being prudent.”

The CFO conversation:

“Our current security posture is compliant and meets basic standards. However, companies of our size in our industry experience breaches at a rate of 1 in 3 over a 5-year period. The average breach costs $4.2M in remediation, legal, customer notification, and lost business. I’m proposing $250K in additional security controls that, based on industry data, reduce our breach likelihood by 40%. That’s a 6:1 return if we avoid a single incident.”

The key data points you need:

• Industry breach statistics (Verizon DBIR, IBM Cost of a Data Breach Report)
• Cybersecurity insurance reports
• Average or median costs of breach for your company size
• Specific risk reduction this investment provides

How your pen test feeds this narrative:

If you ran a pen test recently (see Part 1 about timing it strategically), you can use the findings to make this case without looking incompetent:

“Our recent penetration test validated that our core controls are working—we had zero critical findings. However, the test identified 6 areas where additional hardening would reduce our attack surface. These weren’t vulnerabilities that require immediate remediation, but they represent risk we can proactively address. I’m proposing we invest in closing these gaps before they become part of a critical attack path.”

See the difference? You’re not saying “we’re vulnerable.” You’re saying “we’re good, and here’s how we get better.”

An even smarter play: Use year-over-year pen test data to show your security spending is working.

“Three years ago, our pen test identified 12 high-severity findings. Last year, 6. This year, 2. Our security investments are measurably reducing risk. To continue this trajectory and address the 2 remaining highs, plus harden our defenses to remove this class of vulnerability entirely, I’m requesting $300K.”

That’s not asking for budget because you’re failing. That’s asking for budget because you’re succeeding and want to keep the momentum.

Bucket 3: Business Enablement aka Making More Money Faster

What it is: Compliance investments that unlock revenue and the opportunity to bundle real security capability into them.

You don’t need to explain ROI for FedRAMP, HITRUST, SOC 2, or ISO 27001 to your CFO. When sales says “we need SOC 2 to close enterprise deals” or “FedRAMP unlocks federal,” the business case is self-evident.

The fight isn’t whether to get the certification. It’s whether you invest the minimum to check the box or spend incrementally more to build actual capability. That delta is where good CISOs earn their keep.

Examples of the bundle

• SOC 2 requires good audit logging. You can use the cheapest SIEM that satisfies auditors, or spend 30% more on one that actually enables detection and response. The auditor doesn’t care, but the attacker does, and your SOC does, and post-breach, your CFO will appreciate it whether they know it or not.
• FedRAMP requires access controls. You can implement them manually, or invest in GRC automation that makes your second certification 60% cheaper and your ongoing compliance sustainable.
• HITRUST and everything else require incident response. You can write a policy doc, or use this as cover to build a real IR capability with tabletop exercises and retainers. Saves you headaches and stress, grows your team, and demonstrates mature capabilities to clients and auditors.

Language to use:

“We’re doing FedRAMP regardless—that decision’s made. The question is whether we do it in a way that leaves us with checkbox compliance and technical debt, or whether we spend slightly more to build infrastructure we’ll use for the next five certifications and actually improve our security posture. The marginal cost is small. The marginal value is enormous.”

Or:

“The audit doesn’t care whether our SIEM is good—it cares that we have one. But we’re going to operate this thing for five years. The cheap SIEM requires 1.5 FTEs to manage and tune. The better one requires 0.5. Over three years, that headcount difference dwarfs the licensing delta.”

You’re not justifying compliance. You’re justifying the quality of the compliance investment. The CFO already approved the project—now you’re negotiating scope. That’s an easier conversation than starting from zero.

Where this gets hard:

• Headcount to operationalize what you’re building (a SIEM nobody monitors is an expensive log archive)
• GRC tooling that has no audit requirement but makes everything cheaper and easier to maintain long-term
• Going beyond the control baseline when the auditor would pass you without it

For these, you need a different frame—one built on operational efficiency or risk reduction rather than revenue enablement. But whenever possible, bundle them into the compliance project that’s already approved.

How pen testing fits in Bucket 3:

Remember in Part 1 when we talked about the “Product Security Story” window—testing before launches? That belongs here.

“We’re launching our enterprise tier next quarter. To credibly sell to enterprise customers, we need to test and validate security before launch. This $40K pen test investment prevents us from launching with vulnerabilities that could kill deals. One lost enterprise deal costs us six figures in ARR. The test pays for itself if it prevents a single security objection from closing.”

The Master Budget Presentation: Putting It All Together

Now that you have three buckets, here’s how you present your total security budget ask.

And present it something like this:

“Our total security budget request for next year is $1.19M, broken into three categories.

$500K is table stakes—the cost of operating in our market. This covers SOC 2 maintenance, core tooling, insurance, and incident response capability. Without this, we can’t sell to enterprise customers or maintain compliance.

$440K is risk reduction—proactive investments including a dedicated security hire and quarterly testing cadence. Industry data shows companies our size have a 1 in 3 chance of breach over 5 years at an average cost of $4.2M. This spending reduces that likelihood meaningfully.

$250K is business enablement. HITRUST certification unlocks healthcare customers we currently can’t pursue. This is growth spending.

Of the $1.19M total, $750K has direct business justification through compliance requirements or revenue enablement. Note that IANS research shows security budgets have increased across companies of our size by an additional .2% of revenue over the past 5 years.

What’s our appetite for risk reduction versus growth investment?”

What you just did:

• You didn’t say “we’re insecure”
• You gave leadership control (they can cut risk reduction if they want, but they understand the tradeoff)
• You anchored most spending to non-negotiable requirements or revenue impact
• You spoke in business terms (ROI, market access, compliance)

Using Your Pen Test Results Without Shooting Yourself in the Foot

This is where you can mess up. You get your pen test results back, and you’re tempted to use them to justify budget: “Look at all these findings! We need more money!”

But that makes it look like you didn’t know these problems existed or haven’t been doing your job.

Here’s a better way to use pen test findings for budget justification.

Strategy 1: A “Proactive Discovery” Frame

“Our annual penetration test—which we strategically timed 8 weeks before our board meeting to allow remediation time—identified 2 high-severity findings and 8 medium findings. Both highs were remediated within 10 days using existing resources. Of the 8 mediums, 6 were quick fixes we’ve already addressed. The remaining 2 require architectural changes that fall outside our current budget scope. I’m requesting $75K to address these architectural gaps properly.”

What you’re communicating:

• You planned this (strategic timing)
• You handled the urgent stuff (highs remediated quickly)
• You handled most of it within the existing budget (6 of 8 mediums)
• You’re being strategic about what requires new investment (architectural changes)

You found problems. You fixed most of them. You’re asking for budget for the hard stuff.

Strategy 2: A “Continuous Improvement” Frame

“We’ve been running annual pen tests for three years. Here’s our trend:

Year 1: 12 high findings, 28 medium findings

Year 2: 6 high findings, 18 medium findings

Year 3: 2 high findings, 14 medium findings

Our security investments are working—we’ve reduced high-severity findings by 83%. To continue this trajectory and achieve our goal of zero high findings next year, I’m requesting $200K for the following improvements...”

What you’re communicating:

• Your security program is measurably improving
• You have data-driven goals (zero highs next year)
• You’re asking for budget to continue success, not fix failure

This is strategic budget justification. You’re using the pen test to show progress, not problems.

Strategy 3: A “Risk Acceptance” Frame

A nuclear option, but sometimes you need it.

“Our penetration test identified 3 findings that require significant investment to remediate properly: [list them]. I’ve calculated the cost to remediate at $150K. If we don’t get this budget, I need leadership to formally accept these risks, understanding that if exploited, the potential impact is [describe impact]. I’m comfortable documenting this as an accepted risk if that’s the business decision, but I need it to be an informed decision.”

What you’re communicating:

• You’ve identified the problems
• You’ve calculated the fix
• You’re putting the decision on them
• You’re professional about it (not threatening, just documenting)

Most of the time, leadership will find the budget. Because “formally accept risk” sounds much worse to them than “$150K.”

‍

Use the Security Budget Requestor Tool (and PowerPoint creator)

https://github.com/Adversis/security-budgets

‍

The Mistakes That Make You Look Bad

Let’s talk about what NOT to do:

Fear-Based Request

“If we don’t get this budget, we’re going to get breached.”

You sound like you’re fear-mongering. Also, breaches happen even to well-funded security teams. You’re setting yourself up for failure.

Vague Request

“We need more security budget because threats are increasing.”

No specifics, no justification, no business impact. Of course threats are increasing. That’s not a strategy.

Everything-Is-Broken Request

“Our pen test found 47 vulnerabilities and we need budget to fix them.”

You just told leadership you didn’t know you had 47 problems. That’s not a budget request; that’s a competence question.

Tool-Focused Request

“We need budget for [fancy security tool].”

Leadership doesn’t care about tools. They care about outcomes. What does the tool enable? What risk does it reduce? What revenue does it unlock? What does it free us up to focus on instead?

Comparison Ask

“Company X spends 8% of IT budget on security and we only spend 4%.”

You’re comparing yourself to an unknown company with unknown risk profile, unknown revenue, and unknown context. It’s meaningless.

A Useful Budget Document

Most budget requests are either too technical (eyes glaze over) or too vague (hard to evaluate). Try this structure.

Slide 1: Executive Summary

• Total budget request: $X
• Categories: Table Stakes ($X), Risk Reduction ($X), Business Enablement ($X)
• Expected outcomes: several bullet points
• Business impact if not funded: several bullet points

Slide 2: Table Stakes Detail

For each line item:

• What it is
• Why it’s required (compliance, customer contracts, industry baseline)
• Cost
• What happens if we don’t fund it

Slide 3: Risk Reduction Detail

For each line item:

• What it is
• What risk it addresses
• Likelihood and impact of that risk
• Cost vs. potential loss avoided
• Supporting data (industry stats, pen test findings, etc.)

Slide 4: Business Enablement Detail

For each line item:

• What it is
• What revenue/market/opportunity it unlocks
• Cost vs. potential revenue impact
• Timeline to value

Slide 5: Alternatives and Tradeoffs

If we can’t get full funding, here are prioritization options:

• Option A: Fund Table Stakes only ($X) - maintains compliance, no improvement
• Option B: Fund Table Stakes + Business Enablement ($X) - maintains compliance, enables growth, accepts current risk level
• Option C: Fund Table Stakes + Risk Reduction ($X) - maintains compliance, improves security, delays market expansion”

This works because it’s scannable, speaks business language, gives leadership choices, and clearly shows the consequences and tradeoffs of not funding.

The Long Game: Building Budget Credibility Over Time

Getting budget is easier if you have a track record of spending it well.

Year 1: You ask for $500K. You get $300K. You spend it efficiently, show measurable results, and don’t come back mid-year asking for more.

Year 2: You ask for $700K. You get $500K. You reference Year 1’s results. You show how that $300K reduced risk by X%. You’re asking for more because you proved the first investment worked.

Year 3: You ask for $900K. You get $700K. You have a three-year trend line showing security improvement. Your pen test results are better year-over-year. You haven’t had a breach. Leadership trusts you.

The pattern: Every year, you’re asking for more. But every year, you’re justifying it with results from previous investment. You’re not saying “we’re broken.” You’re saying “we’re good, and here’s how we get better.”

How pen testing supports this:

If you’re doing what we discussed in Part 1—timing your pen tests strategically for maximum impact—you create an annual rhythm of demonstrable security improvement:

• Q2: Pen test conducted
• Q3: Findings remediated, results presented to board
• Q4: Budget planning begins, you reference pen test results as proof of security program maturity
• Q1: New fiscal year, new budget, new security improvements funded

The pen test becomes your annual report card. And if your grades are improving, budget requests get easier.

Real-World Example: Complete Budget Justification

Let’s walk through how this all comes together.

Context: Mid-sized SaaS company, 300 employees, $40M ARR, selling to enterprise customers. CISO has been in role for 18 months.

“I’m requesting $847K for security in FY2026, up from $620K in FY2025. Here’s the breakdown:

Table Stakes: $397K (up from $380K)

• SOC 2 Type II audit: $35K
• Annual penetration testing: $20K
• Security awareness training: $30K
• Core security tooling (EDR, SIEM, vuln scanning, IAM): $200K
• Compliance automation platform: $50K
• Cyber insurance premium: $62K

This is the cost of operating in the enterprise SaaS market. Against our $7.2M IT budget, this request represents 11.8%—below the 13.2% industry benchmark per IANS Research 2024.

Risk Reduction: $300K (new investment)

Last year’s budget was right-sized for a $30M mid-market company. Since then: ARR grew 34%, we added 47 enterprise customers with breach liability clauses, and engineering shipped 3 major features expanding our attack surface.

• Security engineer ($185K): We have one engineer supporting 300 employees. Backlog includes secrets management (4 months overdue, two credential exposure incidents already), vendor review automation, SIEM tuning, and container security.
• Targeted pen testing ($60K): Three major releases planned—API gateway, analytics dashboard, SSO/SCIM. One focused test per release before production.
• IR retainer ($55K): Pre-negotiated 4-hour SLA. Without it, we’re calling firms cold at emergency rates during an active incident.

Business Enablement: $150K (new investment)

• StateRAMP authorization: $125K
• Pre-launch security testing: $25K

Seven qualified opportunities ($2.1M pipeline) are stalled without StateRAMP. At a conservative 25% close rate, that’s $525K ARR against $125K—4.2:1 return, plus ongoing access to the government market.

Total: $847K. $397K maintains current posture. $300K scales to match growth. $150K enables a new market.

If constrained: Cut the IR retainer for $792K total. Acceptable given low incident history, but revisit after any significant incident. Do not cut the engineer—the secrets management debt is an active vulnerability.”

The Conversation Prep: What They’ll Ask You

When you present this budget, here are likely questions you’ll get - and how to answer them:

Q: “If I give you $700K, what do you cut and what breaks?”

A: Cut the IR retainer which is acceptable given our incident history. Cut compliance and government markets wait a year. Drop a pen test and just cover the two highest-risk releases, accept more exposure on the third. But that means: the government pipeline stays stuck, we’re exposed in a major incident, and one feature ships without adversarial testing. The engineer stays—that’s addressing active vulnerabilities, not theoretical ones.

Q: “You’ve had this backlog for months and nothing catastrophic happened. What’s actually at risk if we wait another year?”

A: Two credential exposures already happened. We caught both internally before customer impact—that’s luck, not control. The same vulnerability exists today. I can’t promise a breach if we wait. I can tell you the conditions for one are sitting in our git history and we’re choosing not to fix them.

Q: “You want X% more budget while the company grew Y%. Why does security need to outpace revenue growth?”

A: It doesn’t, long-term. This year’s delta is catching up to exposure we took on during growth. We added N enterprise contracts with breach liability clauses, which is new legal exposure, not just new revenue. If you want to reduce the security growth, we can cut the IR retainer. But the risk profile grew faster than revenue this year.

Q: “Didn’t we just spend money on security last year? Why do we need more?”

A: “Last year bought compliance and basic controls—table stakes to sell to enterprise. We’re now operating at industry standard. This year’s request is about moving from ‘compliant’ to ‘resilient’ and enabling the product roadmap. Last year we built the foundation. This year we’re building the house.”

Q: “How do I know this will actually make us more secure?”

A: “Three metrics I’ll report quarterly: mean time to remediate critical vulnerabilities (currently 12 days, target under 7), percentage of new features with pre-launch security review (currently 40%, target 100%), and open items on the secrets management migration (currently 12 services, target zero by Q3). Pen test findings are a lagging indicator—I care more about whether we’re catching things before external testers do.”

Q: “What happens if we don’t fund this?”

A: “Table stakes is non-negotiable- we can’t sell to enterprise without SOC 2. Risk reduction - we keep operating with known vulnerabilities in secrets management and an understaffed security team. I can’t give you a specific breach probability, but I can tell you we’ve had two near-misses this year. Business enablement - we can’t perform for state contracts, which delays a $5M market expansion. I need you to help me prioritize, but you should understand the tradeoffs.”

Q: “Can’t we just fix these findings with our current team/budget?”

A: “We’ve already addressed the findings that fit within our current budget and team capacity. The remaining issues require either specialized expertise or architectural changes that are beyond our current scope. I’m specifically requesting budget for the things we can’t do with current resources.”

Q: “Why is security always asking for more money?”

A: “Security is like every other part of the business—it scales with the company. Two years ago we had 100 employees and $15M ARR. Now we have 300 employees and $40M ARR. Our attack surface is 3x larger. Our customer security requirements are more stringent. Our product complexity has increased. Security spending should track to those changes. Commodity attacks are getting more sophisticated and bypassing standard controls. That said, I’m committed to efficient spending—here’s how our security cost per employee compares to industry benchmarks: [data].”

The Bottom Line

You don’t need to choose between looking competent and getting budget. You need to reframe the conversation.

Don’t position security budget as “fixing what’s broken.” Position it as “table stakes,” “risk management,” or “growth enablement.”

Position security spending as table stakes, risk management, or growth enablement—not “fixing what’s broken.” Translate technical findings into business terms: compliance requirements, revenue blocked, exposure reduced. Use year-over-year data to show improvement, not just problems.

The CISOs who get budget aren’t the ones who scare leadership. They’re the ones who make trade-offs explicit and let the business decide.

Your penetration tests—especially if you’re timing it strategically as we discussed in Part 1—is one of your best tools for this. It gives you concrete data, year-over-year trends, and proof that your security investments are working.

Want to see exactly how to structure your security budget request? We created a template that includes all three buckets, sample justification language, and the questions-and-answers section to prep you for the conversation.

‍

Use the Security Budget Requestor Tool (and PowerPoint creator)

https://github.com/Adversis/security-budgets

‍

About This Series

This is part 2 of our Strategic CISO Series—a collection of guides focused on turning operational security work into strategic wins.

Read the series:

• Part 1: Timing Your Security Assessment for Executive Impact
• Part 2: How to Say ‘We Need More Security Budget’ Without Saying ‘We’re Currently Insecure’ (you are here)

Coming up:

• Part 3: The Pre-Mortem Pen Test: Using Security Assessments to Accelerate M&A, Funding, or Major Launches
• Part 4: From Checkbox to Competitive Advantage: Positioning Your Security Posture Externally
• Part 5: The Quarterly Security Win: Manufacturing Visible Victories When Your Job Is Preventing Invisible Disasters

‍