Setting a security budget

Security budgets are often set by taking last year's number and adjusting it, or by benchmarking against a percentage of IT spend that someone found in a report. Both produce a number. Neither produces an argument you can defend when finance asks what it buys.

A more useful approach is to allocate against what the money does: stopping things happening, noticing when they do, and dealing with them. Prevention, detection, response.

Why the three-way split helps

Most organisations, left to natural pressures, over-invest in prevention and under-invest in the other two. Prevention is easier to buy, easier to explain, and the products are better marketed.

The problem is that prevention has diminishing returns and a hard ceiling. Some proportion of attacks will get through regardless of spend. What determines the eventual cost is how quickly you notice and how competently you respond.

An organisation with excellent prevention and no detection has bought a good lock and no idea whether anyone is inside.

What sits in each

Prevention: endpoint protection, email filtering, patch management, access control, network segmentation, awareness training, secure configuration, vulnerability management.

Detection: log collection and retention, monitoring, whether operated internally or bought as a service, detection engineering and tuning, the people who look at alerts.

Response: incident response capability, retainers, forensics, backup and recovery infrastructure, tested recovery processes, tabletop exercises, and the plan itself.

Backup deserves a note: it usually sits in the IT budget rather than the security one, and it is arguably the most important line in the response column. Where it sits matters less than that someone has checked it is funded and tested.

A starting split

There is no correct ratio, and anyone who states one confidently is guessing. As a starting point for discussion, roughly half to prevention, a third to detection, the remainder to response is a defensible shape for an organisation with a reasonably mature prevention stack.

What matters more than the exact split is checking the shape against reality:

• If you have no detection capability at all, the next rupee is worth more there than on another preventive tool, almost regardless of the tool.
• If you have never tested a restore, response is under-funded no matter what the ratio says.
• If prevention is genuinely weak (unpatched systems, no endpoint protection, shared administrator passwords), fix that first. Detection on a fundamentally insecure estate produces a lot of true positives you cannot do anything about.

Building the argument for finance

The conversation goes better when the request is framed as risk reduction rather than capability acquisition.

Start from what would hurt. Which systems, if unavailable for a day, stop the business. What data, if exposed, creates a legal or contractual problem. This grounds the discussion in business terms.

State what you currently cannot do. "We would not know for several days" is a more effective sentence than "we lack SIEM coverage". Describe the gap as a consequence.

Give options, not a single number. Three tiers (minimum viable, recommended, comprehensive) with what each addresses and what it leaves unaddressed. This turns the conversation from yes-or-no into a choice, and finance teams engage far better with choices.

Include the running cost. The most common budgeting error is funding the purchase and not the operation. A detection platform with nobody to watch it is an expense, not a control. State the ongoing cost, including people, alongside the capital.

Say what you will stop doing. If the answer is no, what risk is being accepted. Not as a threat, but so the decision is made with its consequence visible. Record it afterwards.

The lines that are routinely under-budgeted

People. Tools without operators are shelfware. This is the single most common gap, because software is a purchase and people are a headcount decision made elsewhere.

Log retention. Storage cost scales with volume and retention period, and it is frequently sized to the budget rather than to the investigative requirement. When an incident turns out to have started before your retention window, the saving is revealed as false.

Testing. Penetration testing, tabletop exercises, restore tests. Easy to defer and the first thing cut, which means capability degrades invisibly.

Renewals and growth. Licence counts grow with headcount and cloud consumption grows with usage. A flat budget against a growing estate is a real-terms cut.

Exit and transition. If a provider relationship ends, moving costs money. Rarely budgeted and occasionally significant.

Reviewing rather than repeating

The strongest thing you can do for next year's budget conversation is to record, during this year, what the money prevented or shortened.

An incident detected in an hour rather than a week. A restore that worked. A vulnerability found by testing before it was found otherwise. A phishing campaign that generated reports from staff rather than clicks.

These are the only evidence that security spending works, and they are invisible unless someone writes them down as they happen. Without them, next year's conversation starts from the same place as this year's: a number, a benchmark, and an argument nobody can settle.