The Boardroom Question That Breaks the Room
It arrives at every board meeting now. Sometimes framed diplomatically. Sometimes not.
“We’ve increased the security budget every year for five years. We have more tools than we can count. We have certifications. We have a SOC. We passed every audit. So why, when I read the news, do I keep seeing companies just like ours — same size, same industry, same investment level — announcing breaches?”
The CISO shifts. The slide deck has answers for every technical question. It doesn’t have a good answer for this one.
Because the honest answer is uncomfortable.
The money isn’t the problem. The way the money is being spent is the problem.
Global cybersecurity spending crossed $215 billion in 2024 — Gartner. Breach frequency hasn’t declined proportionally. The average breach cost hit $4.88 million — IBM 2024. Mean time to detect an intrusion: 194 days — Mandiant. Mean time to contain after detection: 73 days — IBM.
The industry spent more money than ever, moved faster than ever, deployed more tools than ever — and the attacker still had an average of 267 days from entry to containment.
Something fundamental is broken in the relationship between security spending and security outcomes. This blog is about what it is — and what actually fixes it.
The Spending Trap: Why More Budget Doesn’t Mean More Security
The security spending model has a structural flaw that the industry rarely discusses honestly: it optimizes for the purchase of capability, not the delivery of outcomes.
Buying a tool creates a measurable, defensible event. A vendor is selected. A contract is signed. A deployment is announced. A dashboard gets a new tile. The budget cycle records a security investment, and the organization can point to something tangible.
Whether that tool reduces breach probability is a separate question — one that most organizations never formally measure, because measuring it requires defining what “reduced breach probability” looks like and then testing whether the tool actually produces it.
The result is a spending model that is simultaneously massive and largely unvalidated. Tools are purchased because threats exist. Tools are deployed because vendors promise protection. Tools are renewed because removing them feels riskier than keeping them. At no point in this cycle does anyone systematically ask: is the cumulative effect of this spending actually making the organization harder to breach?
The data says, in most cases, the answer is no — or at least not proportionally. And the reason has nothing to do with the quality of individual tools.
The Five Real Reasons Spending Doesn’t Stop Breaches
Reason 1: You’re Defending Against Last Year’s Attack
Security tools are built reactively. Vendors observe attack techniques in the wild, build detection for them, release updates, and push them to customers. The gap between a technique entering active attacker use and appearing in your detection stack is measured in weeks to months.
Sophisticated attackers — particularly the organized criminal groups and nation-state actors responsible for the most expensive breaches — don’t wait. They rotate techniques specifically to stay ahead of detection updates. They study vendor detection methodologies and adjust their approach to stay below the signature and behavioral threshold that would trigger an alert.
Living Off the Land — using native system tools like PowerShell, WMI, and certutil for malicious purposes — became the dominant attack methodology precisely because it exploits the gap between what detection tools watch for (known-bad external tools) and what attackers actually use (trusted internal ones). It’s been documented extensively since 2017. It still works, at scale, in 2026 — because detection logic for it requires behavioral baselining that most organizations haven’t built.
The spending is buying yesterday’s protection. The attacker is operating today’s technique.
Reason 2: The Tools Aren’t Integrated — They’re Installed
There is a meaningful difference between a security stack that is installed and a security stack that is integrated.
An installed stack has tools deployed across the environment, each generating its own alerts, its own telemetry, its own dashboards. Each tool does its job within its domain. None of them share data in a way that would allow a cross-domain attack chain to be detected as a unified event rather than as seven separate, individually low-confidence findings across seven separate consoles.
An integrated stack has unified data flowing from every tool into a correlation layer that can identify the attack chain: the initial phishing email in the email gateway, the credential use in the identity platform, the lateral movement in the NDR, the privilege escalation in the endpoint agent, the data access in the DLP, and the exfiltration in the proxy — assembled into a single coherent picture that reads as an attack, not as six unremarkable events.
The average enterprise runs 45 to 70 security tools. The average enterprise has not built the integration architecture that makes those tools operate as a system rather than as a collection of independent point solutions.
Spending on tools without investing in integration is spending on puzzle pieces without building the puzzle. Each piece has value. Without the complete picture, the attacker who moves across the seams between pieces is invisible to every tool individually — which means invisible to the organization.
Reason 3: The Detection System Was Never Tested Against a Real Attacker
Ask most CISOs whether their detection stack would catch a Kerberoasting attack against their Active Directory environment. Most will say yes. Ask them for the evidence.
The evidence rarely exists.
Organizations deploy tools and assume coverage based on vendor documentation, feature lists, and the theoretical alignment between what the tool is designed to detect and what the attacker is designed to do. What they rarely do is test that assumption — run an actual Kerberoasting simulation against their actual environment with their actual configuration and measure whether their actual detection stack fires.
Breach and Attack Simulation — the practice of running realistic adversary techniques against production environments and measuring detection outcomes — consistently finds coverage gaps in organizations that believed they were comprehensively protected. Not marginal gaps. Meaningful gaps. Techniques used in the majority of enterprise breaches, undetected by tools specifically purchased and marketed as detecting them — because the tool wasn’t tuned to the specific environmental characteristics of that organization’s deployment.
A security program that has never been tested against adversarial behavior is a hypothesis, not a capability. The breach is the test. Organizations that test before the breach find the gaps while they’re cheap to close. Organizations that test during the breach discover the same gaps at $4.88 million per finding.
Reason 4: The Human Layer Is Underfunded Relative to the Technology Layer
Security technology spending dwarfs security operations spending in most organizations. The ratio is sometimes ten to one: ten dollars on tools for every dollar on the people and processes that operate them.
The consequence is a security architecture that has more capability than it has capacity to use. Tools deployed at 38% of their feature capacity — Gartner 2024 — not because the remaining 62% isn’t valuable but because there isn’t enough analyst time, detection engineering expertise, and operational bandwidth to configure and maintain it.
An EDR running on default sensitivity settings because nobody has had time to tune it to the environment is providing a fraction of the protection it could provide. A UEBA platform collecting behavioral data but with no analyst who has the expertise to interpret anomaly scores is not providing behavioral detection — it’s providing a data collection service.
Security tools don’t protect organizations. Security tools operated by skilled, adequately resourced people protect organizations. The industry’s persistent underinvestment in the human layer — in analyst training, in detection engineering, in threat hunting, in tabletop exercises — is directly correlated with the gap between what the technology budget implies and what the security program actually delivers.
The 3.5 million unfilled cybersecurity positions globally — ISC2 2026 — are not filled by spending more on tools. They’re filled, or partially compensated for, by investing in the people already in the organization and by using managed services to access expertise that can’t be hired.
Reason 5: Compliance Has Replaced Security as the Organizing Principle
The compliance industry is very good at defining what controls organizations should have. It is structurally limited in its ability to verify whether those controls actually work against real attacks — because compliance audits test control existence, not control effectiveness, for reasons that have more to do with audit scalability than security philosophy.
The organizations that organize their security programs around compliance as the primary objective end up with programs that are very good at passing audits and inconsistently effective at stopping attacks. Controls exist because they’re required, not because they’ve been validated as effective for the specific threat profile of that specific organization in that specific industry.
The attacker targeting your organization in 2026 is not reading your compliance reports. They’re looking for the gaps between the controls you documented and the coverage those controls actually provide — the service account that the identity governance policy was supposed to catch but didn’t because the policy was written for the audit, not the environment. The unmonitored cloud workload that’s outside the CSPM’s configured scope. The credential in the deprecated repository that nobody reviewed because the credential management procedure covered production systems and this one wasn’t classified as production.
Compliance sets a floor. Security requires building above it. Organizations that have confused the floor for the ceiling are consistently the ones asking why the spending isn’t stopping the breaches.
What the Breached Organizations Had in Common
Post-incident analyses of major breaches in the last three years reveal a consistent pattern across organizations that were spending significantly on security at the time of the breach.
They had tools but not visibility. Assets existed outside the monitoring scope of every deployed tool. The attacker found and used them. The detection stack never saw them.
They had alerts but not investigation. The detection system flagged anomalous behavior. The alert sat in a queue alongside hundreds of others. Analyst capacity didn’t reach it before the attacker reached the next objective.
They had policies but not practice. The incident response plan existed. Nobody had run through it in over a year. When the incident occurred, the sequence of steps that should have been reflex required people to read a document — at the moment when reading a document was the last thing the team had time for.
They had certifications but not validation. SOC 2 Type II. ISO 27001. PCI DSS compliance. None of these certifications had been tested against actual adversary behavior in the 12 months preceding the breach. The controls that passed the audit didn’t perform as expected when an attacker actually tried them.
They had budget but not accountability. Large security budgets spent across dozens of tools and vendors, with no consistent measurement of what each dollar was producing in actual risk reduction. Budget conversations focused on what was purchased. Nobody was accountable for whether the purchases were working.
These are not technology failures. They are program design failures — structural gaps in how the security investment was organized, measured, and validated.
The Spending That Actually Reduces Breach Probability
The organizations that spend less than industry average and breach less than industry average are not lucky. They’ve made a different set of choices about where their security investment goes.
They validate before they accumulate. Before purchasing a new tool, they test whether existing tools, properly configured, already provide the coverage. They use BAS platforms to measure their actual detection coverage rather than inferring it from vendor feature lists. When they find gaps, they close them with configuration and tuning before they consider purchasing something new.
They invest in integration, not just installation. They’ve built the data correlation layer that makes their tools work as a system. XDR platforms. SOAR automation that acts on alerts rather than just enriching them. SIEM detection rules that fire on attack sequences rather than individual events. The puzzle is assembled, not just purchased.
They treat detection as an engineering discipline. Detection rules are continuously maintained against current threat intelligence. ATT&CK coverage is mapped, measured, and tracked. Stale rules are retired. New techniques are incorporated within weeks of entering active use. The detection capability reflects the current threat landscape, not the landscape of the year the rules were written.
They practice response. Quarterly tabletop exercises. Annual red team engagements. Purple team exercises that measure detection and response simultaneously. The incident response plan is muscle memory, not a document. The Golden Hour is practiced, not improvised.
They measure outcomes, not activity. Mean Time to Detect. Mean Time to Respond. ATT&CK technique detection coverage. Validated control effectiveness percentage. Red team findings per engagement, trended over time. These are the metrics that tell you whether the security investment is working — not alert closure rates, patch compliance percentages, and certification status.
Redirecting the Spend: Where the Marginal Dollar Has the Highest Impact
For organizations looking to improve the relationship between what they spend and what they get, the highest-impact investments are consistently not the ones that appear first in vendor marketing.
Highest impact — underinvested in most organizations:
Continuous validation — BAS platforms running weekly or monthly against production environments cost $30,000–$60,000 annually. They measure what your stack actually detects. Without this, every other security investment is operating on unvalidated assumptions.
Threat hunting — Proactive, hypothesis-driven investigation that goes looking for what automated tools aren’t catching. Surfaces 30–50% of significant incidents missed by automated detection — Mandiant. Requires analyst time and threat intelligence, not additional tooling.
Detection engineering — Continuous development, testing, and maintenance of detection rules mapped to current ATT&CK techniques. The capability that determines whether your tools actually catch the attacks targeting you, rather than the attacks of three years ago.
Tabletop and purple team exercises — $40,000–$80,000 annually for exercises that validate response capability and surface detection gaps before a real attacker does. The cheapest form of breach prevention available.
Identity governance — Continuous lifecycle management of every human and machine identity, with automated anomaly detection and privileged access controls. Addresses the primary attack vector in 80%+ of breaches at a cost that is a fraction of the breach it prevents.
Lower impact — overinvested in most organizations:
Additional perimeter tools in categories already covered. Compliance-driven purchases that satisfy auditors without closing real coverage gaps. Tools purchased in response to specific incidents without validation that they close the gap the incident revealed. Renewals of underutilized tools that are auto-approved because nobody reviewed utilization before the renewal date arrived.
The Measurement Infrastructure That Changes the Conversation
The CISO who can’t answer “why are we still getting breached despite the spend” is missing a measurement infrastructure — not a security program. The security program may be genuinely good. Without measurement, it’s impossible to demonstrate that it is, or to identify specifically where it isn’t.
Building the measurement infrastructure is not a large investment. It’s a design choice.
Four metrics, reported quarterly, change the entire boardroom conversation:
1. ATT&CK Detection Coverage % — of the top 30 techniques used against your industry, what percentage does your stack have validated detection for? Tracked quarterly, it shows whether coverage is improving or drifting.
2. Mean Time to Detect (MTTD) — measured from first evidence of attacker activity to confirmed detection, across all incidents in the quarter. Benchmarked against the 194-day industry average, your number tells the board whether you’re ahead of or behind the curve.
3. Validated Control Effectiveness % — of controls tested in the last BAS assessment, what percentage performed as expected? This is the honest answer to “are the tools working” — not the deployment percentage, but the effectiveness percentage.
4. Remediation Velocity on Critical Findings — average days to close critical security findings from identification to verified closure. This measures whether the organization is winning or losing the race against the remediation backlog.
These four numbers, together, answer the board’s question honestly. Not “we’re covered” — but “here is what we can detect, here is how fast we detect it, here is how effective our controls are when tested, and here is how quickly we close the gaps that testing reveals.”
That’s a risk management report. It’s what every board deserves and what most boards never receive.
The Bottom Line
The question — “we’re spending millions, why are we still getting breached?” — has an answer. It’s just not the answer that vendor marketing, compliance frameworks, or comfortable board presentations are built to deliver.
The spending isn’t working because it’s organized around the purchase of capability rather than the delivery of outcomes. Because tools are installed rather than integrated. Because coverage is assumed rather than validated. Because compliance has replaced security as the organizing principle. Because the human layer that makes tools effective is chronically underinvested relative to the technology layer that looks impressive on architecture diagrams.
None of these are unfixable. All of them require the same first step: honest measurement of the gap between what the spending claims to provide and what it actually delivers when an adversary actually tries.
The organizations that close that gap are not the ones with the largest budgets. They’re the ones that decided to measure outcomes instead of activity — and then built the program around what the measurement revealed.
The board question isn’t an accusation. It’s an opportunity.
Answer it honestly, with evidence, and it becomes the mandate to build the program that actually works.
Answer it with the same comfortable metrics that justified the spending in the first place — and wait for next year’s version of the same question.
Your Next Move
Every blog in this series has addressed a different piece of why security spending doesn’t always produce security outcomes — detection gaps, visibility failures, response delays, tool sprawl, compliance confusion, and dashboard illusions.
→ Read next: The Dashboard Illusion: Why a “98% Secure” Score Is a Dangerous Lie — the measurement problem that sits at the root of every spending-without-outcome failure in this series.
→ Ready to build the measurement infrastructure that answers the board’s question with evidence? A security effectiveness assessment maps your current spending against validated outcomes — ATT&CK coverage, control effectiveness, detection and response metrics — and shows you exactly where the investment is working and where it isn’t. Let’s talk.