Security Budget Planning Guide: Allocation and Return on Investment

Most security budgets are last year's spend plus inflation, defended line by line, with no clear link to the risks the money is meant to reduce. That makes them easy to cut, hard to grow and impossible to evaluate. This guide covers the whole security budget rather than a single project: how to structure it, how to rank competing investments, how to use return on security investment (ROSI) honestly, how to benchmark spend using public data, and how to handle tool rationalisation, zero-based budgeting, headcount and cuts. It is written for CISOs, security leaders, GRC teams and the finance partners who work with them. For a single initiative see the Business Case Guide; for the CISO's wider remit see the CISO Guide: First 90 Days.

Key takeaways

• Build from the risk register, not last year's ledger. Every material line should trace to a ranked risk, a regulatory obligation or the cost of running controls you already depend on.
• Separate run, change and contingency. Run costs keep controls alive, change costs reduce risk, contingency pays for the bad day; mixing them hides what a cut really removes.
• Use ROSI to compare options, not to prove value. ENISA's own ROSI paper warns the result is an approximation that "can be easily manipulated"; ranges and consistent inputs matter more than the headline percentage.
• Benchmark with care. Public data such as ENISA's NIS Investments study gives context (security at 9% of IT budgets among surveyed EU organisations), but your own risk, regulation and architecture decide the right figure.
• Make the board choose the risk. Present funding options with the residual risk of each, and record any funding shortfall as an explicit risk decision rather than a silent gap.

What a security budget should contain

A budget that finance and the board can read separates spend by purpose and by accounting treatment. The ENISA NIS Investments study defines security budgets as capital and operating expenditure on hardware, software, personnel, contractors and outsourcing, which is a useful scope to adopt so internal figures can be compared over time.

• Capex and opex: the shift to SaaS and managed services moved most security spend into operating expenditure. Capital treatment still applies to on-premises hardware and, depending on accounting policy, some implementation labour. Agree the rules with finance before planning, because the same project can look cheap or expensive depending on which line it lands in.
• Identity security spend: show identity (IAM, PAM, IGA, secrets and non-human identity governance) as its own line. Identity controls are often split across IT, cloud and security budgets, and nobody sees the total. See the Identity Security Programme Guide.
• Hidden security spend: security features bundled into cloud, productivity or network contracts are real spend. Tag them so tool rationalisation can see them.
• Discrete line item: NIST SP 800-53 SA-2 (Allocation of Resources) asks organisations to establish a discrete line item for security and privacy in programming and budgeting documentation, and PM-3 asks that the resources needed for the security programme be included in capital planning and investment requests, with exceptions documented.

The budget planning cycle

NIST CSF 2.0 outcome GV.RR-03 states that "adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies". The cycle below makes that outcome auditable.

1. Start from the risk register. Pull the ranked cybersecurity risks, their owners and current exposure. NIST IR 8286B (Prioritizing Cybersecurity Risk for Enterprise Risk Management) adds priority, response type, response cost and status to each register entry, so cost and risk sit side by side. See the Risk Register Template.
2. Cost the run base. List every control already in operation and what it costs to keep. This is the floor: cutting below it removes protection that exists today.
3. Add mandatory change. Regulatory deadlines, contractual commitments and audit findings with due dates. In ENISA's 2025 study, 70% of respondents named regulatory compliance (NIS2, the Cyber Resilience Act, DORA) as the main investment driver, so expect this layer to be large.
4. Rank discretionary change. Score each proposed project on the risk it reduces, its cost and its dependencies (see the next section).
5. Build funding options. Present at least three levels (for example, run plus mandatory; plus top-ranked change; full roadmap) with the residual risk each leaves.
6. Agree and record. The approved level becomes the plan; unfunded risks go back to the register as accepted, with an owner and a review date.
7. Track in year. Report spend against plan and delivered risk reduction quarterly; re-prioritise when the threat picture or the business changes (CSF GV.OV-03, ID.IM-01).

Prioritising security investment

No organisation can fund everything. NIST IR 8286B describes the logic plainly: "capital and operating expenses will likely be applied to those risks with the highest priority", and one optimisation method ranks risks from most to least impactful and tallies response costs "until funding is exhausted". The remaining risks need an explicit decision.

• Proactive and reactive investment: ENISA's 2025 study found 29% of respondents cited proactive risk mitigation as a driver against 26% citing past incidents or near misses. Reactive money arrives after a breach and tends to buy the control that would have stopped the last attack. Keep a standing proactive line so spending is not only incident-led.
• Foundations before features: asset inventory, identity hygiene, logging and backup recovery underpin nearly every other control. Rank them on the risk reduction they enable across other projects, not only on their own.
• Security investment roadmap: turn the ranking into a three-year roadmap with one-year detail. Each item names the risk it reduces, the metric that will show it worked, the run cost it adds in later years and the tools it will retire.

Return on security investment (ROSI)

ENISA's Introduction to Return on Security Investment adapts the return on investment idea to loss prevention. It uses three inputs: single loss expectancy (SLE), "the expected amount of money that will be lost when a risk occurs"; annual rate of occurrence (ARO); and annual loss expectancy (ALE = SLE x ARO). A control's mitigation ratio is the share of that loss it is expected to prevent.

ROSI = (ALE x mitigation ratio - annual cost of the solution) / annual cost of the solution

ENISA's worked example: five virus incidents a year (ARO 5), each costing about 15,000 euros (SLE), a solution expected to block 80% of them at 25,000 euros a year. ALE is 75,000 euros, expected loss saving is 60,000 euros, so ROSI is (60,000 - 25,000) / 25,000, or 140%.

• Use ranges: run the calculation with low, central and high estimates for SLE, ARO and mitigation ratio. If the conclusion flips inside the range, the decision rests on judgement, and the paper should say so.
• Use your own data: ENISA advises extrapolating from the organisation's historical incident data rather than relying on a vendor study, and treating results as "guidelines rather than strict rules".
• Be consistent: calculate SLE the same way for every option, or the comparison is meaningless.
• Know the limits: ROSI suits frequent, measurable losses (fraud, malware clean-up, account recovery). For rare, severe events such as ransomware, use scenario-based quantification with loss ranges. See the Cyber Risk Quantification Guide.
• Value beyond loss avoided: some investments are justified by licence to operate, customer requirements (cited by 42% in ENISA's study) or operational savings such as automated access reviews. State these separately rather than forcing them into a ROSI figure.

Benchmarking security spend

Boards ask "what do others spend?" The honest answer is that benchmarks give context, not a target. Use public, methodologically documented sources and state their population.

• Security budget as a percentage of IT budget: ENISA's NIS Investments 2025 report (sixth edition, 1,080 respondents across all 27 EU Member States and the NIS2 high-criticality sectors, 83% large enterprises) found information security spending at 9% of IT budgets, with a median of 1.5 million euros. Cybersecurity staff were 10.6% of IT full-time equivalents, the lowest proportion the study has recorded, largely because IT teams grew faster.
• Board engagement: the UK Cyber Security Breaches Survey 2025/2026 (official statistics from DSIT) found that investment in cyber security was included in senior management updates for 69% of businesses, and 31% of businesses had a board member with explicit cyber responsibility (68% of large businesses).
• Exposure context: the same survey found 43% of UK businesses identified a breach or attack in the previous 12 months, rising to 69% of large businesses.

How to benchmark properly:

1. Define the ratio first: which IT spend is the denominator, and whether security staff in IT, cloud and product teams count. Ratios that use different definitions cannot be compared.
2. Compare with peers of similar size, sector and regulation, through sector bodies or information sharing groups, using the same definitions.
3. Track your own trend: spend per protected user, per critical application or per cloud account over three years often says more than any external ratio.
4. Pair spend with outcome. NIST SP 800-55 Vol. 1 lists "the percentage of the organization's budget devoted to information security controls" as an impact measure, but a ratio alone shows input, not effect.

Avoid headline percentages from surveys whose sample, method or sponsor you cannot check. A board that later learns a benchmark was a marketing survey will discount everything else in the paper.

Tool rationalisation and cost optimisation

Tool sprawl is the most common source of recoverable security spend. Rationalisation frees money for the roadmap and simplifies operations, but consolidation also concentrates dependency.

• Vendor consolidation trade-offs: fewer suppliers mean better pricing and fewer integrations, but a single supplier outage or compromise now affects more controls. Record concentration risk in the register and keep exit terms in contracts. See the Third-Party Risk Management Guide.
• Renewal calendar: savings are only real at renewal or termination dates. Keep a contract calendar with notice periods 6 to 12 months ahead.
• Security cost optimisation without cost reduction: automation (provisioning, rotation, evidence collection) often keeps spend flat while capacity grows. Report hours released alongside money saved.

Zero-based budgeting and handling cuts

A zero-based security budget starts every line at zero and requires each to be justified against current risk. It suits security after a merger, a major cloud migration or years of incremental growth, because it exposes lines that no longer map to a risk. It is labour-intensive, so many organisations apply it to one layer per year (for example, tools in year one, services in year two) rather than everything at once.

When budgets are cut, avoid percentage cuts spread evenly across lines. Instead:

1. Protect the run base for controls that cover the highest-ranked risks, and say which ones.
2. Offer cuts from the bottom of the ranked change list first, with the risk each leaves.
3. Take savings from rationalisation before cutting coverage.
4. Record every material reduction as a risk acceptance by the executive who owns the risk, with a date to revisit. CSF GV.RM-02 expects risk appetite and tolerance statements to be maintained; a budget cut that moves a risk outside tolerance needs a decision, not a footnote.

The UK Cyber Security Breaches Survey 2025/2026 recorded interviewees describing economic conditions straining cyber budgets, particularly in smaller organisations, and 34% of uninsured businesses said cyber insurance was not a budgetary priority. See the Cyber Insurance Guide.

Headcount planning

People are usually the largest run cost and the hardest to change quickly. Plan headcount from workload and coverage, not ratios alone.

• Coverage arithmetic: one seat staffed around the clock is 168 hours a week. At a 37.5-hour working week that is about 4.5 full-time equivalents before leave, sickness and training, so a single 24x7 seat needs five or more people. That is why most small and mid-sized organisations buy monitoring as a service. See the MDR Guide.
• Workload drivers: number of critical applications, cloud accounts, identities (human and non-human), suppliers to assess, audits per year and change volume. Tie each role to a driver so growth requests are explainable.
• Build, buy or borrow: keep architecture, risk ownership and incident command in house; buy repeatable volume (monitoring, testing); borrow specialist skills (forensics, red teaming) on retainer.
• Key person risk: budget for a deputy on identity, backup and incident response platforms so no single person holds the only knowledge.
• Skills and retention: include training and certification in the people line. See the Cybersecurity Careers Guide.

The funding request and board approval

A security funding request that survives finance review fits on two pages plus an appendix.

• Context: top five risks in business terms, recent incidents and near misses, regulatory deadlines.
• Options: three funding levels, each with cost (capex and opex, three-year view), risk reduced and residual risk.
• Recommendation: the level you recommend and why, including what it does not cover.
• Measures: the metrics you will report quarterly to show delivery.
• Appendix: method, assumptions, ROSI or scenario ranges, and sources for every external figure.

Real incidents help boards see scale: in the Marks and Spencer cyberattack, impersonation of a third-party user led to a cost of about £300 million, and the Jaguar Land Rover cyberattack shut down global production. Use them to illustrate impact, not to inflate likelihood. See the Board Cyber Risk Reporting Guide.

Measuring results and framework mapping

NIST SP 800-55 Vol. 1 (December 2024, superseding SP 800-55 Rev. 1) distinguishes implementation, effectiveness, efficiency and impact measures. Budget reporting should include at least one of each.

• Roadmap delivery: funded items delivered on time and on budget (implementation).
• Risk movement: exposure of the top ten register risks before and after funded treatment (effectiveness).
• Cost per protected unit: security spend per employee, per critical application or per cloud account, tracked over time (efficiency).
• Rationalisation yield: tools retired and recurring cost removed per year.
• Unfunded risk: number and exposure of risks accepted because of funding, with review dates (impact).
• Spend variance: actual against plan by layer, with reasons.

Common failure patterns

• Incremental budgeting: last year plus a percentage, so retired risks keep funding and new risks wait a year.
• Run costs forgotten: projects approved on implementation cost alone, then year-two subscriptions crowd out the next roadmap.
• Borrowed benchmarks: unsourced "industry average" percentages that collapse under board questioning.
• ROSI theatre: single-point estimates chosen to produce a large return, which erodes trust when losses do not appear.
• Silent shortfall: unfunded risks never recorded as accepted, so accountability falls on the security team after an incident.
• Tool sprawl from reactive buying: each incident adds a product; none are retired, and integration work consumes the team.

Practitioner checklist

• Split the budget into run, change, compliance, contingency and people layers, with capex and opex marked.
• Show identity security and security features bundled in other contracts as visible lines.
• Link every change item to a ranked risk, its owner and a success metric.
• Present three funding options with the residual risk of each.
• Record unfunded risks as accepted by the accountable executive, with review dates.
• Use ROSI with ranges and internal data; use scenario quantification for rare, severe events.
• Source every benchmark to a public, documented study and state its population.
• Keep a tool and contract calendar and review overlap 6 to 12 months before renewals.
• Plan headcount from workload drivers and coverage arithmetic.
• Report spend against plan and risk movement to the board quarterly.

Standards and references

• NIST: The NIST Cybersecurity Framework (CSF) 2.0
• NIST: IR 8286B, Prioritizing Cybersecurity Risk for Enterprise Risk Management
• NIST: IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management (ERM)
• NIST: SP 800-55 Vol. 1, Measurement Guide for Information Security: Identifying and Selecting Measures
• ENISA: Introduction to Return on Security Investment
• ENISA: NIS Investments 2025
• UK Department for Science, Innovation and Technology: Cyber Security Breaches Survey 2025/2026

Related NHI Mgmt Group resources: Business Case Guide · CISO Guide: First 90 Days · Cyber Risk Quantification Guide · Board Cyber Risk Reporting Guide · Identity Security Metrics Guide