Lesson 3.3

3.3: Budget Asks That Land

8 minutes

Budget Asks That Land

Most security budget asks get funded at about 60% of the number in the ask. That’s not because the program wasn’t worth the full amount; it’s because the ask was written in a way that made 60% feel reasonable. A well-written ask gets funded at 100% or gets declined with a specific reason. A poorly-written one gets haircut by default.

The difference is structure, not eloquence.

Asks that don’t work

These three phrasings will lose budget every time. If you recognize any of them in your own last quarter’s ask, rewrite before you submit the next one.

  • “We need more security budget.” No outcome. No date. No scenario. The CFO doesn’t know what success looks like, so they can’t approve it with a straight face. Maximum achievable: partial funding for political cover.
  • “We need a SOC.” This names a structure, not an outcome. A SOC is a means. What’s the end? “24/7 monitoring”? “Reduced MTTR”? “Ransomware containment inside an hour”? Each of those has different cost structures and different staffing implications. Asking for “a SOC” is asking the finance team to pick the scope, and they’ll pick the cheap one.
  • “Our NIST CSF maturity is Level 2 and we need to get to Level 3.” Maturity-model jumps are not outcomes. The framework is an assessment tool, not a budget instrument. “Level 3” costs different amounts in different sub-categories and the delta isn’t uniform. You’re asking a CFO to fund a number on a rubric, and they will ask — correctly — what the business actually gets for it.

Asks that work

A fundable ask has four elements, in this order.

1. A specific outcome tied to a business risk.

Not “improved MFA posture.” Instead: “reduce credential-compromise risk for engineering from current ~8% quarterly exposure to ~0%.”

2. A specific intervention that causes the outcome.

“Deploy FIDO2 hardware keys to 100% of engineering and IT admin, with conditional-access policies enforcing phishing-resistant MFA for all access to production systems.”

3. A specific number and timeline.

“$60K one-time for hardware and shipping; $8K/year ongoing for replacement and onboarding. Deployed to 100% of target population by end of Q2.”

4. A specific “if we don’t, then” scenario.

“If we don’t: the Scattered Spider pattern that hit MGM in 2023 — help-desk social engineering followed by MFA-fatigue on TOTP — remains live against us. We are currently vulnerable to that exact attack path. FIDO2 closes it.”

Four elements. Each one short. Together they form an ask a CFO can approve with confidence, a board can understand in forty seconds, and an engineering peer can sanity-check against their own system.

The “if we don’t, then” framing

The fourth element is the one most security leaders undervalue, and it is the one that most reliably moves the ask from “maybe” to “yes.” Funding decisions are made against counterfactuals. If you don’t provide the counterfactual, the CFO will invent one — and the one they invent will be more optimistic than yours, because they don’t know what you know.

Good counterfactuals are specific, named, and recent. “The Change Healthcare 2024 breach cost UnitedHealth ~$1.6B and took weeks to contain; the initial vector was a Citrix portal without MFA. We have 3 externally-exposed Citrix-equivalents that currently accept TOTP. FIDO2 closes that path.” Specific incident, specific control gap, specific fix.

Bad counterfactuals are abstract. “A breach could cost us a lot of money.” Everyone knows that. Saying it out loud makes you sound like a consultant. It does not move the ask.

A rule of thumb

Every ask should be short enough to fit on one page and specific enough that a year from now, you can write “we spent the $60K, we deployed to 100% of target, credential compromise dropped from 8% to 0.1%” as a follow-up slide. If you can’t write the follow-up slide in advance, the ask isn’t concrete enough yet. Rewrite.

The asks that get funded at 100% are always the ones where the follow-up slide is obvious before the money has been spent.