Security Investment Through the Lens of Meaning
Security Investment Through the Lens of Meaning
By Julian Brownlow Davies | Meaning In the Signal, Week 9 | 6 June 2026
I have sat in rather a lot of security budget discussions over the years, on both sides of the table, and I have noticed that they almost all have the same shape. The CISO presents a landscape - coverage achieved, gaps identified, investment required to close them. The board or CFO interrogates the numbers. The conversation turns on coverage metrics: endpoint protection rate, percentage of the environment monitored, mean time to detect, maturity framework scores. Someone asks whether the number is going up or down. The CISO says it is going up. The budget is approved, or cut, or held flat, and everyone leaves with the comfortable sense that progress has been made in a direction, at least, if not at a pace.
What nobody in that conversation typically asks is whether any of it is working.
I do not mean “working” in the sense of whether the tools are functioning as advertised. They usually are. I mean working in the sense that matters: are we, as a result of this investment, materially more likely to prevent a breach that damages the things that cannot be replaced? Is the investment directed at the actual constraint on our security posture, or at the constraint we addressed five years ago?
Detection Investment Is Non-Bottleneck Investment
The argument I have been building across this series is that the security industry crossed an inflection point - some years back now - at which the bottleneck in security operations moved. It is no longer detection. Modern tooling finds things with impressive sensitivity and at impressive scale. The problem that faces the current state of security operations is not the inadequacy of what we find. It is the inadequacy of what we can do with what we find.
Eliyahu Goldratt’s central insight in The Goal was that improving any non-bottleneck element of a system does not improve the system’s overall throughput. It produces inventory in front of the actual constraint. In security operations, that inventory is the remediation backlog - the accumulating queue of findings that the analytical and engineering capacity of the organisation cannot clear at the rate they arrive. A typical enterprise vulnerability management programme generates findings at a rate several orders of magnitude above the organisation’s actual remediation capacity. The detection investment is efficiently producing something that the rest of the system cannot process.
The security budget, as currently structured in most organisations, is largely an investment in making that pile larger.
Compliance Is the Floor, Not the Programme
I anticipate the objection that security investment is not entirely discretionary - that regulatory frameworks impose specific requirements, and that a CISO in financial services cannot redirect their SIEM budget toward analytical capability because PCI-DSS requires the SIEM. This is true, and I do not dispute it.
But there is a category error embedded in this response that is worth naming. Compliance defines the minimum the regulator requires. It does not define the security programme. An organisation that meets its compliance requirements and then directs all remaining investment into additional coverage tooling is not being compelled into that choice by the regulator - it is making a decision, largely by default, that coverage is the thing worth buying above the compliance floor.
The question a CISO should be able to answer, and that boards and CFOs should be asking, is this: above the compliance floor, what is our additional investment buying, and is it buying comprehension or coverage? In most organisations, I suspect the honest answer is coverage - and the reason is not that comprehension investments do not exist, but that the institutional vocabulary for discussing them has not been developed. We do not have a well-established budget category for “the analytical capacity to determine which of our 40,000 findings actually matters.” We do have well-established budget categories for the tools that generated the 40,000 findings.
Comprehension Is Cheaper Than It Looks
This is where I think the CFO argument becomes genuinely interesting, and it is an argument the security industry has been slow to make.
Consider the economics of the current arrangement. An organisation investing substantially in vulnerability management might generate, across its stack, tens of thousands of validated findings per year. Its actual remediation capacity - constrained by engineering bandwidth, change management processes, and the operational cost of each fix - might be measured in the hundreds. The detection investment is producing findings at a rate the organisation structurally cannot act on. The marginal return on each additional finding, given that it joins a queue that will not clear, approaches zero.
Now redirect a portion of that investment toward comprehension: toward the contextual analysis that identifies which of those findings represents a credible path to a breach of the assets that actually cannot be replaced. The output is not more findings. It is confident prioritisation - the knowledge that these twelve vulnerabilities, not these twelve thousand, warrant immediate engineering attention, and here is why, and here is the evidence. The remediation capacity of the organisation has not changed. What has changed is how precisely that capacity is applied.
The security outcome improves. The cost, measured against the current detection investment, may well decrease. Meaningful security, it turns out, is more economically efficient security - not because comprehension capability is cheap to build, but because it directs existing remediation investment toward interventions that produce the return, rather than distributing it across interventions that produce the pile. This is, as I have argued throughout this series, not an especially radical idea. It is the Theory of Constraints applied to a budget conversation.
The Metric Missing from Every Board Report
Security reporting to boards is, in the main, coverage reporting. Percentage of environment monitored. Findings identified and closed. Maturity framework scores. Mean time to detect. These metrics tell you whether the detection apparatus is functioning. They say very little about whether the organisation is actually safer.
The metric I do not see in board security reporting - and I consider its absence a more significant governance gap than most audit committees appreciate - is something like this: of the material risks to our most critical assets, what proportion do we have sufficient contextual understanding to prioritise with confidence? Not “what have we found?” but “what do we understand well enough to act on?”
If the honest answer is “we are not sure,” that is, in a meaningful sense, the answer to whether the security programme is doing what it is supposed to do.
The boards and CFOs I find most worth working with are the ones who have developed the instinct to ask this second question - who have noticed the gap between the assurance a coverage metric provides and the assurance a comprehension metric would provide, and who have decided to close it. They are, in my experience, rarer than they should be. The vocabulary is unfamiliar. The metrics do not yet exist in standardised form. The vendor community has not, on the whole, made it easy to buy comprehension rather than coverage, because coverage scales and comprehension requires context that is specific to each organisation.
The constraint has moved. The budget has not. The investment thesis that made sense in the detection era - more tools, more coverage, more signal - does not produce the outcomes the meaning era requires. At some point, a CISO is going to walk into a board meeting and present a budget that looks considerably different from the one the board is used to seeing: fewer line items for coverage expansion, more line items for the analytical, contextual, comprehension-building work that coverage was always supposed to serve.
I think that CISO will have a more productive conversation than most.
The next time a security vendor tells you their product will help you find more, it is worth pausing briefly on the question they are not asking: what, exactly, will you do with it when you do?