Security budgets are larger than they have ever been. Security outcomes have not improved in proportion. The explanation, in most cases, is not a shortage of technology. It is a failure to distinguish between buying tools and designing controls.
These are not the same activity. Conflating them is the most expensive mistake a security programme can make.
How tool-first thinking takes hold
Tool procurement is concrete. It produces something visible: a contract, a deployment, a dashboard, a set of alerts. It can be reported to leadership. It satisfies the instinct to act.
Control design is abstract until it is not. It requires a clear understanding of the risks the organisation actually carries, the threat actors relevant to its context, and the behaviours the organisation wants to prevent, detect, or recover from. It requires that someone makes decisions about what matters before spending money on the means to address it.
In practice, many organisations skip this step. A peer organisation reports a breach. A vendor presents a solution. A regulator recommends a class of technology. The tool is procured. The control objective it was supposed to serve is never written down, which means it can never be evaluated, and the tool’s contribution to security posture is never measured.
What gets wasted and why
The waste in security budgets is rarely dramatic. Tools are not unused, they are deployed, they generate output, they are managed. The waste is more subtle: tools that solve problems the organisation does not have, tools that duplicate coverage already provided elsewhere, tools that require operational capacity the organisation cannot sustain.
SIEM platforms that ingest everything and alert on everything produce noise that exhausts the teams responsible for reviewing it. Endpoint tools deployed broadly across an estate where the actual risk is concentrated in a small number of systems. Identity products implemented without a corresponding identity governance programme to give them meaning.
In each case, the tool is functioning as designed. The control it was supposed to contribute to was never properly defined. The result is a security stack that is technically sophisticated and strategically incoherent.
The governance failure underneath
Tool proliferation is a symptom. The underlying condition is a governance model that has not established clear accountability for control design.
Control design requires that someone own the answer to a specific question: given our risk profile, our operating context, and our regulatory obligations, what outcomes are we trying to achieve and how will we know if we are achieving them? That question cannot be answered by a vendor. It cannot be answered by a framework alone. It requires judgment about the specific organisation.
When this accountability is absent, procurement decisions fill the vacuum. Vendors provide control frameworks aligned to their products. Frameworks provide control catalogues that can be checked rather than evaluated. The organisation accumulates tools without accumulating capability.
What decision-makers must accept
Boards and executive teams that review security investment proposals face a structural disadvantage. Technology is specific and auditable. Control effectiveness is not. It is far easier to approve a purchase order than to interrogate whether the purchase serves a defined control objective.
The discipline required here is uncomfortable. It means asking, before any procurement, what control objective the tool supports, how that objective was derived from the organisation’s actual risk profile, and how the tool’s contribution will be measured. It means accepting that some tool categories are not appropriate for the organisation’s context, regardless of what peers are buying.
It also means recognising that the most expensive security programmes are not always the most effective ones. The difference between a well-designed control environment and an accumulation of tools is not primarily a budget question. It is a governance question. Organisations that answer it clearly tend to spend less and achieve more.
Security budgets are not wasted because technology is poor. They are wasted because the governance structures required to make good technology decisions are not in place. Fixing that requires less procurement and more design.
