The most honest artifact in most security programs is the tool inventory, and almost nobody has looked at it recently. When I finally sit down and list every product the security function pays for — the agents on the endpoint, the consoles the analysts log into, the scanners, the posture tools, the point solutions bought to close a single audit finding three years ago — the count is always higher than anyone guessed. Seventy is not an exaggeration for a mid-market program that has been buying steadily for a decade. It is a common number, and it is the wrong number to be proud of.
Here is the number that matters more. Take those seventy tools and map each one to the control it actually delivers — the security outcome it exists to produce — and the list collapses. In every stack I have walked, the tools outnumber the distinct controls by an order of magnitude. Seventy tools, nine controls. The other sixty-one are overlap, redundancy, and things bought to make a specific person feel better in a specific quarter.
The instinct, when the stack feels incoherent, is to buy one more thing to tie it together. I want to argue for the opposite discipline: rationalize the stack by control coverage and integration cost, not by feature lists. The license fee is the cheapest part of a security tool. The expensive part is the integration engineering, the console staffing, and the alert fatigue — and none of those show up on the order form.
Count the controls, not the tools
Start with the mapping exercise, because it reframes everything that follows. A control is a security outcome, not a product. "Detect malicious activity on the endpoint" is a control. Whatever you bought to do it is a tool. The point of the exercise is to stop letting vendors define your architecture by their product categories and start defining it by the outcomes you are accountable for.
When I do this, the seventy tools sort into a short list of control families. The exact taxonomy matters less than the fact that it is short — the 18 CIS Controls or the NIST CSF functions will get you there just as well — but the families I keep landing on look like this:
- Identity and access. SSO, MFA, identity governance, privileged access, and the non-human identities nobody inventoried. This is where the largest tool count and the largest real risk both tend to live.
- Endpoint protection and response. The agent on the laptop and the server. One control. Frequently two or three products, sometimes fighting each other for the same hooks.
- Network and perimeter. Firewalls, WAF, segmentation, egress control.
- Vulnerability and configuration management. Scanners, patch orchestration, and cloud posture management, which is the same control pointed at a different substrate.
- Data protection. Classification, DLP, encryption, and key management.
- Detection and response. Log aggregation, the SIEM, the SOAR playbooks, the telemetry pipeline.
- Email and web. The secure gateway, the phishing controls, the browser-isolation experiment someone is still paying for.
- Application and code security. Static and dynamic analysis, software composition, secrets scanning in the pipeline.
- Governance and evidence. The GRC platform, the policy manager, the thing that produces audit artifacts.
Nine families. Seventy tools. The redundancy is not hidden once you sort this way — it is the whole picture. Three products in the vulnerability family that overlap on most of their coverage. Two endpoint agents because a migration was never finished. A posture tool per cloud when one would span both. You do not find this in a feature comparison. You find it in the mapping.
The cost is integration, not the license
The reason sprawl is expensive has almost nothing to do with subscription fees, which is why cutting it by hunting for the cheapest renewals never works. The real cost of a security tool is its fully loaded cost of ownership, and three components dominate.
The first is integration engineering. Every tool has to be wired into your identity provider, your logging pipeline, your ticketing system, and your data model, and then kept wired as all four of those change underneath it. That is standing engineering work, and it scales with the number of tools, not the number of controls. Ten products in one control family means ten integrations to build and ten to maintain, for one outcome.
The second is console staffing. Every pane of glass implies a human who is fluent in it — who knows its quirks, tunes its rules, and triages its alerts at two in the morning. A small team cannot be expert in seventy consoles, so most of them get watched badly or not at all, which means you are paying for coverage you do not actually have. A tool nobody has the attention to operate is not a control. It is a line item and a false sense of security.
The third is alert fatigue, and it is the one that quietly breaks detection. Every redundant tool adds its own stream of findings, most of them low-signal, all of them competing for the same analyst attention. The widely cited pattern in security operations is that a large fraction of alerts are never reviewed, and duplicate tooling makes that worse by design — the same event arrives three times, scored three different ways, and the analyst learns to ignore all three. You did not buy more security. You bought more noise to hide the signal in.
This is where a cost-transparency discipline earns its keep. The TBM framework — Technology Business Management — exists to map spend to the capabilities it delivers rather than to the vendors it flows to. Apply that lens to the security stack and you stop asking "what does this tool cost" and start asking "what does this control cost, all in, across every tool that touches it." That number is the one worth defending in a budget review, and it is almost never the number on the invoice.
Rationalize by coverage and overlap, not feature lists
Once the tools are mapped to controls and loaded with their real cost, the rationalization is a portfolio decision, and there is a serviceable framework for it borrowed from application portfolio management: Gartner's TIME model — Tolerate, Invest, Migrate, Eliminate. Run each tool through it, but make the sort on control coverage and integration cost, never on which product has the longer feature list.
- Invest in the tool that covers the most of a control family with the fewest integration seams. Depth and native reach beat a marginal feature the competitor demoed well.
- Migrate the workloads off the overlapping products in that family onto the one you chose to invest in — deliberately, and proving coverage as you go.
- Eliminate the redundant tool only after the coverage is proven, never before, because a gap you created is worse than the overlap you were trying to remove.
- Tolerate the handful of point solutions that genuinely have no substitute and no overlap. Every stack has a few. The goal is to shrink that list honestly, not to pretend it is empty.
The feature list is the trap in every one of these decisions. Vendors compete on features because features are what fit in a demo, and a security team under pressure will rationalize keeping a second tool because it does one thing the first one does not. Almost always, that one thing is not a control you are accountable for — it is a nice-to-have that costs a full integration and a full console to keep. Coverage of the outcomes you own is the only feature that counts.
Overlap is not defense in depth
The objection I hear every time is that overlap is defense in depth, and cutting it weakens the program. This deserves a real answer, because defense in depth is a genuine principle and it is also the most abused phrase in security budgeting.
Defense in depth means deliberately layering controls that fail in different ways, so that when one is bypassed another still holds. Two independent controls across two different failure modes is depth. Two endpoint agents from two vendors, running on the same host, fighting for the same kernel hooks, tuned by the same overworked analyst, is not depth — it is one failure mode covered twice, plus a second agent's worth of instability and cost. Accidental redundancy is not a layered defense. It is a single point of failure you are paying double to maintain.
The honest test is whether the overlap was designed or inherited. Designed redundancy — a second detection path chosen on purpose to catch what the first misses — earns its place. Inherited redundancy — two tools in the same family because a migration stalled or a champion left — is just cost wearing the costume of prudence. Most of the overlap you will find is the inherited kind, and calling it defense in depth is how it survives every budget cycle.
What consolidation actually buys
A smaller, coherent stack is not merely cheaper. It is more secure and more defensible, and both of those matter more in regulated work than the savings do.
Start with attack surface. Every tool in the stack is itself a non-human identity with standing, privileged access to your environment — an API key, a service principal, a set of read permissions across your accounts. Seventy tools is seventy vendors inside your perimeter, seventy supply-chain relationships, seventy credentials that can be stolen or misused. Consolidation is not only a budget move; it is a reduction in the number of trusted third parties who can hurt you. That framing lands with a board in a way that a savings number does not.
Then there is the audit story. I run security and DevOps for a fintech that serves more than 1,500 financial institutions, which means our controls get examined by people who are paid to be skeptical — SOC 2 auditors, FFIEC-minded partners, due-diligence teams. The worst answer to "show me how you manage vulnerabilities" is a tour of four overlapping consoles that mostly agree. The strong answer is one control, one owner, one place the evidence lives. A rationalized stack is easier to attest to because there is less of it to explain, and provable beats claimed every time someone is deciding whether to trust you.
And there is the attention dividend. When the analysts are watching nine coherent control planes instead of seventy consoles, the alerts they see are more likely to be real and the hours they spend are more likely to matter. That is the return that never appears in the FinOps spreadsheet and is worth more than the ones that do.
Where to start
You do not need a consolidation project on the roadmap to begin. You need the inventory and the discipline to read it honestly. Map every security tool you own to the control it delivers, and count the controls. Load each control with its real cost — integration, staffing, and the alerts nobody reads — not its license fee. Rationalize by coverage and overlap, invest in one tool per control family, and eliminate the rest only after the coverage is proven. And stop calling inherited redundancy defense in depth.
If you have run this exercise, I want to hear how the count came out — how many tools, how many controls, and which control family turned out to be the most crowded. And if you have a genuine defense-in-depth overlap you would never cut, tell me why it earns its place. Leave a reply; the interesting cases are always the ones that argue back.
