Why Cybersecurity Programs Keep Growing Without Reducing Business Risk

Most security programs grow because activity is easy to add and hard to retire. Risk falls only when spending changes the likelihood or impact of a specific loss. Few programs track that link, so budgets rise while exposure stays where it was.

How programs grow

Programs grow by accretion. An incident adds a tool. An audit finding adds a control. A new regulation adds a workstream. A peer’s breach adds a headcount request. Each decision is defensible alone. Together they produce a program shaped by past events rather than by the losses the business can least afford.

Nothing in this cycle asks whether a control still earns its cost. Controls rarely retire, so the program only gets bigger.

Four reasons risk does not fall with spend

1. Nobody has defined “enough.” Without a stated risk appetite, there is no point at which a security investment is finished. NIST’s Cybersecurity Framework 2.0 treats this as a governance task. Its Risk Management Strategy category expects risk appetite and tolerance statements to be set, communicated and maintained (GV.RM-02). It also expects cybersecurity risk to feed enterprise risk management (GV.RM-03). Where no one has written the appetite down, the CISO sets it implicitly through the budget request. That is a business decision made by the wrong person.

2. The metrics count work, not exposure. Patch coverage, training completion, tool deployment and alert volume all measure effort. A board can watch them rise for three years and learn nothing about whether a ransomware event is less likely or less damaging. The useful metrics show change in exposure: how many internet-facing systems carry a known-exploited vulnerability past the agreed deadline, how many privileged accounts still lack phishing-resistant authentication, whether the systems the business cannot lose have been restored from backup in a test.

3. Money follows what is visible and auditable. Controls that produce evidence for auditors get funded. Controls against the paths attackers use are funded unevenly. Verizon’s 2026 Data Breach Investigations Report puts vulnerability exploitation at 31% of initial access in the breaches it analyzed. A program can show strong endpoint coverage and a clean audit while a single unpatched external appliance sits outside both.

4. The risk register is a list, not a decision tool. A register that ranks risks high, medium and low does not tell an executive what to fund, what to accept or what to stop. Exceptions make it worse. A deferred fix gets approved for ninety days, renewed, renewed again, and eventually stops appearing in any report. The risk is still there. No one with authority over the business outcome ever accepted it.

A fifth issue sits underneath the other four. Security teams often carry risks that business owners created: a system launched without a recovery plan, a supplier chosen on price. If security owns the risk but cannot change the decision that created it, the program grows to compensate.

A hypothetical example

This is a composite scenario, not a documented incident.

A company doubles its security budget over three years. It adds endpoint detection, a new SIEM and a larger SOC contract. Every dashboard turns green. Meanwhile, a remote-access appliance on the network edge runs an old firmware version. Remediation requires a maintenance window the operations team keeps declining. The security team files an exception. It is renewed three times by security managers, never by the business unit that depends on the appliance.

An attacker uses a publicly known flaw in that appliance. The new detection tooling works as designed and raises alerts. The attacker already has valid access by then.

The spending was not wasted. It was aimed at what the program could measure, not at the loss the company was most likely to suffer.

What should change

1. Write appetite in business terms. Define the loss scenarios that matter (extended outage of a core system, regulated data exposure, payment fraud) with thresholds an executive can recognize. Get the board or executive committee to approve them.

2. Report on scenarios. Pick five to eight loss scenarios. For each, show how the main drivers of likelihood and impact moved since last quarter. Drop metrics that cannot be tied to a scenario.

3. Tie every material spend line to a scenario. If a tool or service cannot name the scenario it reduces, review it. Retirement should be a normal outcome of the budget cycle.

4. Make exceptions expire. Every exception needs a named business owner, a compensating control and an end date. When it lapses, the risk goes back to the owner for a decision, not back into a queue.

5. Move risk acceptance to the people who own the outcome. The CISO advises. The executive who owns the revenue, the system or the process accepts or funds the fix. NIST CSF 2.0 states that leadership is accountable for cybersecurity risk. Governance should reflect that in practice.

A test for the next budget cycle

Ask three questions before approving the next increase:

• Which loss scenario does this reduce, and by how much?

• What did we stop doing to make room for it?

• Who outside security has accepted the risk that remains?

A program that cannot answer these is growing by habit. One that can is managing risk.

---

Sources

• NIST, The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29, February 26, 2024: GV.RM-02, GV.RM-03, GV.RR, GV.OV. nvlpubs.nist.gov

• Verizon, 2026 Data Breach Investigations Report: vulnerability exploitation at 31% of initial access. verizon.com