September at a growth-stage company is when the CFO opens the 2027 budget spreadsheet, pulls up the cybersecurity line, and starts asking questions nobody bothered to ask while it quietly renewed quarter after quarter. The CEO wants 15% margin expansion. The CRO wants two more AEs. The head of engineering wants a fourth product team. Something has to move. The security line, sitting between 0.5% and 1% of revenue for most B2B SaaS companies per IANS Research's 2026 benchmark, is the biggest un-defended budget block on the sheet.
In September 2024 I wrote the FY25 operating plan for a cybersecurity org running about $10.7M in annual spend. The plan landed. The CFO signed it, the CEO signed it, and it became the reference document the leadership team used for quarterly review through the year. It didn't land because the number was right. It landed because the frame was right. I'm going to walk you through that frame, tell you what I'd change if I were writing it again for 2027, and name the three line items that didn't exist on my 2025 sheet that every 2027 plan needs.
The frame that landed with the CFO
Every security budget I've seen fail walks into the CFO's office as a single number with an increase attached. The plan that landed did the opposite. It walked in as two numbers with a taxonomy in between.
Two budgets, not one. The plan opened with a Critical column and an All-In column. Critical was the compliance floor. The number required to keep audit obligations satisfied and keep the lights on. That number came in at $9.1M, roughly $1.6M under the prior-year plan of $10.7M. All-In was the full roadmap: Critical plus the risk-reduction programs the org should fund if the business wanted the risk register to shrink year over year. That number was $13.4M. The CFO didn't have to argue about whether we were asking for too much. The CFO got to decide, explicitly, how much risk to accept between $9.1M and $13.4M. That is a different conversation.
Every dollar tagged by work class. The plan split spend three ways using ABC nomenclature: A-work (operational and administrative — the run cost of the security function), B-work (enabling other engineering teams — the sidecars, SDKs, and gateways that make secure defaults easy for the platform team), and C-work (capitalized new capability — the programs that build controls that don't exist yet). C-work was the largest bucket at 42% of the 2025 plan, because we were still closing PCI DSS v4.0 gaps, but the CFO saw the split and knew immediately which dollars bought sustainability, which dollars unblocked other teams, and which dollars closed a specific known gap.
Every program scored against every other program on a common scale. Every capitalized program in that plan had an Impact × Likelihood score (1-5 on each axis, product 1-25) attached to it. Product Security carried a 20. Compliance Requirements carried a 16. Application Security, funded at $656K, carried a 16 — one of the largest line items on the sheet against one of the highest-scored risks. The scoring gave the CFO a way to compare programs side by side without having to relitigate the security team's judgment on each one, and it moved the conversation from "trust me" to "here is the sheet." That is why it worked. It is not what I would recommend today. A 5×5 rubric is a storytelling tool, not a risk-quantification methodology — the numbers on it are calibrated by security-team judgment, not by external benchmarks or historical loss data. If I were writing the plan again for 2027, I would swap the 1-25 column for a dollar-denominated Annualized Loss Expectancy per program, computed from FAIR decomposition against public benchmarks — the six-factor build the FAIR model post walks through, sized against my company's actual attack surface and record footprint. A CFO reading "$1.8M ALE on the current attack surface, dropping to $600K with this $325K program funded" makes a different, better decision than one reading "risk score 20, funded at $325K." Same disciplined comparison, real currency underneath it.
Halfway through the plan there was a table showing capitalized spend by risk severity — the programs sorted from highest risk score to lowest, with the funded dollar amount beside each. The line under the table read: "Why does it look like we're spending the most on the least impactful things? It's because we are. Most of the capitalized programs will be spent on delivering compliance requirements vs. true security risk reduction efforts." I said the quiet part loud. The CFO respected the honesty and signed the number. Every CFO knows their security team is spending most of its capital on compliance work. The plan that names it explicitly is the plan that gets trusted on the numbers that follow.
The actual FY25 numbers — what a real cyber operating plan looks like
The Critical column ($9.1M) broke into four rollups. Payroll at $2.8M — fill open reqs to 90% of mid-band, roughly $200K over prior-year actuals for one incremental role. Technology at $3.0M — 7% baked-in contract escalation on every existing renewal, no new tooling. Ops + Incidents at $1.2M — reactive SIRT budget sized against the prior year's tracked cost-per-incident (SEV1 $57K, SEV3 $113K, event handling $282K in the FY24 lookback). Capitalized work at $2.1M — the smallest bucket, because the compliance-only view of P0 meant only 55% of the roadmap was funded.
The All-In column ($13.4M) added $4.3M on top, mostly capitalized work: closing IAM re-architecture, funding the Paved Roads squad's full "security as code" agenda, staffing the training-and-awareness program properly. Between the two columns sat a section titled "What We're Not Doing (That We Probably Should Be)." That section named — in specific dollars — the IAM re-architecture ($4.2M deferred to J2L second-line assurance), the insider-threat program (unfunded despite recent named-vendor breaches at peer companies), and AI/ML in threat detection (explicitly deferred). It also named the reputational consequence of each deferral. That section, more than any other, is what the CFO read first.
Every program in the plan carried five tags: priority (P0 required by regulation or compliance; P1 KTLO to sustain existing services; P2 enable other business functions; P3 growth and maturity; P4 tech debt); work class (A-work operational, B-work enable-other-teams, C-work capitalized); theme (Standardization of Enterprise Security, Build Paved Roads, Security in Product & Business Initiatives); a comparability score (the 1-25 I used at the time — swap for dollar-denominated ALE per program if you're writing the 2027 version); and headcount need vs. current staff. Five tags per program. The CFO could filter the plan any of those five ways and get a coherent view. That is the mechanic that turns a security budget into a governance document.
The frame above ships as a working xlsx you can drop into your own FY27 planning cycle. Two-budget mode toggle (Zero-Based / Top-Down / Hybrid), FAIR-based ALE per program, KPI/KRI on every line, temporal pro-rata for partial funding and delayed hiring, and auto-generated board slide + CEO one-pager + CFO variance letter that flip narrative when the fixed spine exceeds the cap. Download the template — or start from a filled sample (Series C SaaS, -10% YoY cap) to see what a completed plan looks like.
Three line items the 2025 plan didn't have, and every 2027 plan needs
The plan I wrote for FY25 mentioned AI in exactly one place: the "What We're Not Doing" section noted that funding guidance left no room to incorporate AI/ML into threat management, which would make the org slower to detect and respond over time. That framing was correct for 2024. For 2027 it is dangerously incomplete. AI has moved from a topic the plan mentions to three line items the plan needs to fund explicitly, because each one appears on enterprise procurement questionnaires, on cyber-insurance renewals, or on the org's own risk register whether the plan names it or not.
My 2025 plan carried a leader-to-FTE ratio of 4::22 and asked for five incremental heads to close the P0 capacity gap. For 2027, ask a different question first: how many of your current FTE are doing work that a well-configured coding-agent or GRC copilot could offload 30-50% of? GitHub's 2023 developer-productivity study showed a 55% task-completion speedup with Copilot on controlled tasks; SPE-adjacent security-engineering work (writing secure-by-default sidecars, closing Snyk tickets, generating IaC modules) is exactly the profile that benefits most. Budget line: two incremental heads plus $150K/yr for coding-agent seats across the security-engineering squad plus $60K/yr for a GRC copilot targeted at questionnaire response. Same throughput as five incremental heads. Roughly $500K under headcount and a CFO who now sees you as an operator who thinks in leverage instead of headcount.
Every SaaS product your business uses now embeds an LLM, and every embed added an AI sub-processor to your data flow — often invisibly, via a UI toggle a business user checked without an intake review. This line item didn't exist on my 2025 plan and it needs to exist on every 2027 plan. Budget line: $60-120K/yr for AI sub-processor discovery and governance — an AI vendor register, an AI acceptable-use policy, monthly discovery scans of the SaaS estate, EU AI Act Article 12 logging alignment if the business has an EU footprint. This is the line item that earns the cyber-insurance premium concession carriers are now giving on AI-usage attestation (see the questionnaire post for what the concession looks like in the underwriting math), and it is what the "Do you have AI governance" checkbox on the SIG Lite starting in 2026 is actually asking about.
Deloitte's Center for Financial Services forecast AI-enabled fraud losses in the US banking sector rising from $12.3B in 2023 to $40B by 2027 — a 32% CAGR — driven largely by voice-cloned CFO impersonation and deepfake vendor-payment redirection. Every finance org I've talked with in 2026 has already caught at least one attempt. This is not a training-and-awareness spend. It's a workflow-hardening spend co-owned by security and finance. Budget line: $40-70K/yr for finance-workflow hardening — out-of-band callback on any wire above a defined threshold, dual-approval on any vendor-banking-detail change, a rotating shared phrase for exec-to-CFO comms, quarterly tabletop with the AP team. This lands on the security budget as joint headcount time, not as a tool spend. Frame it that way and it survives.
What to defend, what to cut
The 2025 plan's defense math was straightforward and it survives to 2027 with only minor updates. A dollar spent on a program that maps to a P0 priority, that has a named executive risk owner, and that a FAIR-based ALE estimate says is buying down more loss expectancy than it costs, is a dollar that stays. A dollar spent on a program that doesn't map to a specific compliance deliverable, a specific customer-facing outcome, or a defensible loss-reduction number is a dollar that either moves to the "What We're Not Doing" section explicitly (with the risk accept written into the record) or moves to second-line assurance if the org has that function.
Every one of those measures is a leading indicator, not a lagging one — an alert-fatigue ratio moves before the incident, evidence age moves before the auditor stalls, the sub-processor lag moves before the SIG finds it. Handing your CFO a dashboard row per line item on the 2027 sheet, showing the current value and the target, is how you get the September budget approved AND how you keep it approved through Q1 when the number gets pressure-tested. The continuous risk indicators pillar walks through the calibration discipline that makes those metrics actually predict something — auto-derived from your scanner stream, dependency graph, incident feed, and quantification numbers, scored against realized outcomes so you know which ones lead and which ones just look pretty on a dashboard.
The one thing every CFO gets wrong at Q4
Every CFO staring at the security line for the first time reaches for the same cut: reduce headcount by one, keep the tools. That is exactly the wrong move. Tools sit; people close deals. Cutting the second security operator and keeping the third SIEM makes the security lead the single point of failure on every enterprise deal that comes through in Q1 2027, and the deals lost because the security lead is buried do not show up on the security line — they show up on the sales line, on the next earnings call, without a name attached to the miss.
The right cut is inverted. Keep the two-person security team, consolidate the tool stack aggressively (a 12% cut is realistic after honest shelfware analysis), pass the tool savings through to the board narrative as ROI on security investment, and reinvest a portion into the three AI line items above. A stack-consolidation cut with headcount preservation reads to a board as maturity. A headcount cut with stack defense reads as capitulation.
The board is not asking "what should our security budget be." The board is asking "is our security budget producing revenue outcomes or is it a cost we tolerate." Answer the question they are asking. Show the enterprise deals security shipped last year. Show the questionnaire response times this year versus last. Show the audit-window compression. Then present the 2027 budget as a two-column plan — Critical and All-In — with dollar-denominated loss-expectancy math per program and a "What We're Not Doing" section that names the reputational cost of every deferral. CFOs who see that get their budgets approved with materially less pushback than CFOs who present security as a cost.
The 2027 number the CFO can defend upward
Flat to modestly up on people, flat to down 12% on tools after honest consolidation, up on evidence pipeline, and up on the three AI line items — funded partly out of the tool consolidation and partly out of the headcount leverage above. Total: flat to +3% year over year at Series C, held against 25%+ revenue growth. That is a security budget as a percentage of revenue that drops, the efficiency story the board wants to hear, while the absolute defense hardens against a threat landscape that added deepfake-driven finance fraud, AI sub-processor sprawl, and enterprise procurement's new AI-governance questions to what the plan needs to survive.
A CFO who walks into the September board meeting with a two-column plan, FAIR-based ALE per program, a named "What We're Not Doing" section, and three new AI line items sized against verified benchmarks walks out with the budget approved and the CEO happy. A CFO who walks in with "cut security by 20% and see what happens" is going to spend Q1 2027 explaining why an enterprise deal stalled at security review while the CEO cross-references the earnings guide. The two paths look identical on paper in September. They do not look identical in April.
Put the playbook to work
The two-budget frame, the ABC work classification, and the per-program risk scoring underneath this Q4 conversation are what the CFO guide to security budgeting walks through in full, and FAIR-based risk quantification is where the dollar numbers on the defense come from. vCISO Lite ships both (continuous evidence pipeline for the questionnaire response side, dollar-denominated risk quantification for the board defense side, an AI sub-processor register for the new line items, and audit-firm-portal access that shortens deal cycles) — compare pricing against the same budget you are defending. See how it fits into your 2027 budget conversation at vcisolite.com.