I've walked into environments with $200,000 in annual security tooling spend and nobody checking the alerts.
SIEM running but nobody reading the dashboards. EDR deployed on every endpoint but alerts going to an inbox that nobody monitors. Vulnerability scanner producing weekly reports that get filed in a folder and forgotten. Cloud security posture tool generating 400 findings that pile up in a backlog nobody triages. DLP solution flagging data exfiltration attempts that nobody reviews.
The tools didn't fail. The process did. Nobody owned it.
How this happens
The pattern is the same at every company where I've seen this play out. It starts with a legitimate concern: a close call, a customer question, a board member asking about security, an auditor finding a gap.
Someone decides to buy a tool to address it. The tool gets purchased. It gets deployed. It starts generating data. The team feels good because there's a new logo on the security overview slide and a new dashboard they can screenshot for the next board meeting.
Then nothing happens.
Nobody was assigned to monitor the tool's output. Nobody was trained on how to use it. Nobody defined what constitutes an alert worth investigating versus noise. Nobody built a process for triaging findings, assigning remediation, tracking resolution, and verifying fixes. The tool runs. It generates data. The data goes nowhere.
Six months later, another concern arises. Maybe a different vulnerability. Maybe a different customer question. Another tool gets purchased. Same pattern. More data. More dashboards. More noise. Nobody watching any of it.
After a few rounds of this, the company has a respectable security tooling budget, an impressive list of vendor logos, slides that look professional in board presentations, and functionally the same security posture they had before any of it was deployed. Maybe worse, because now they have a false sense of confidence.
I've seen this at companies with $500K ARR and companies with $50M ARR. The scale changes. The pattern doesn't.
The fundamental question
Before you buy another security tool, ask one question: is someone actually using what we already have?
Not "is it deployed." Not "is it generating data." Not "does it show up on our security architecture diagram." Is a human being looking at the output, making decisions based on what it shows, and taking action when something needs attention?
If the answer is no for any of your current tools, buying another one is adding noise to an already noisy environment that nobody is listening to.
The security tool graveyard
Do an honest inventory of your current tooling. For every security tool you're paying for, answer these questions:
Who owns this tool? Not who signed the contract. Who is responsible for monitoring its output, acting on findings, and maintaining the configuration? If the answer is “the engineering team” or “everyone” or nobody can name a specific person, nobody owns it.
When was the last time someone acted on an alert from this tool? Not viewed a dashboard. Actually investigated an alert, determined whether it was a true positive, and either resolved the issue or documented why it was acceptable. If the answer is “I don't know” or “months ago,” the tool isn't providing security. It's providing a line item.
Is the tool configured correctly for your environment? Many security tools are deployed with default configurations and never tuned. A SIEM with default correlation rules generates hundreds of alerts per day, most of which are false positives. After a week of noise, the team stops looking. A properly tuned SIEM generates a manageable number of high-fidelity alerts that actually warrant investigation.
What's the process when a finding is identified? Is there a documented workflow for triage, assignment, remediation, and verification? Or does someone look at the alert, say “we should fix that,” and then everyone moves on? Without a defined process, findings don't get fixed. They get acknowledged and forgotten.
Are there findings that have been open for more than 90 days? Pull up the backlog. If there are hundreds of unresolved findings that have been sitting there for months, the tool is generating a to-do list that nobody is working through. That's not a tool problem. That's a process and prioritization problem.
What to do about it
After the inventory, you'll probably find that half your tools are generating value and the other half are generating invoices.
Kill the tools nobody uses. Cancel them. Save the money. If nobody has looked at the output in 6 months, the tool isn't doing anything for your security posture. It's providing comfort and costing money.
Invest in the tools that work. Redirect the budget from cancelled tools toward making the remaining tools operationally effective. That means training for the people who use them, tuning the configurations to reduce noise, building response processes for when findings are identified, and allocating dedicated time for monitoring and triage.
Assign clear ownership. Every tool needs an owner. Not a team. A person. The owner is responsible for monitoring, triage, escalation, configuration maintenance, and reporting. If nobody owns the tool, it decays.
Build the process before buying the product. Before you evaluate a new tool, define the process it will support. What problem are you solving? Who will operate the tool? How will findings be triaged? What's the response workflow? What does success look like? If you can't answer these questions, you're not ready for the tool.
Consider managed services. If you don't have the staff to monitor and triage security tools in-house, a managed detection and response (MDR) service handles it for you. They monitor your EDR, SIEM, or cloud security tools 24/7, triage alerts, and escalate real threats. It's not cheap ($3,000 to $10,000+ per month depending on scope), but it's cheaper than paying for tools that nobody watches.
Then, if there's still a genuine gap that no current tool addresses, buy the new tool. But only after you've confirmed that someone will own it, a process exists to act on its output, and the team has the time and skill to operate it.
The deeper issue
The tool-buying pattern is a symptom of a deeper problem: security without ownership. When nobody owns the security program, the default response to any security concern is to buy something. A tool is a tangible action. It shows up on a budget line. It produces dashboards. It feels like progress.
But tools don't provide security. People using tools provide security. A $50,000 SIEM with nobody watching it provides exactly as much protection as no SIEM at all. A $5,000 EDR with someone who monitors alerts, investigates anomalies, and responds to threats provides real security.
The most important security investment isn't a product. It's a person who owns the program, maintains the tools, drives the processes, and keeps everything running week to week.
Farbod Fakhrai is the founder of Com-Sec, a cybersecurity and compliance consulting firm supporting startups and growth-stage companies.