A large security stack is not the same as a strong one. Tool sprawl is usually a symptom of three earlier decisions: buying to solve a gap without retiring what it replaced, buying to meet an audit finding, and letting each team buy for its own need. Cutting tools without fixing those causes will bring the sprawl back.
This article does not cite a figure for average tool counts. We could not reach a primary source we trust for one, and we will not repeat a number we cannot trace.
What sprawl costs, from the primary record
-
Blind spots that look like coverage. At Equifax, the House Oversight report says over 300 security certificates had expired, including 79 for monitoring business-critical domains. A monitoring device sat inactive for 19 months (GAO reported ten). The tool existed. Its maintenance did not.
-
Alerts nobody can act on. The Senate Commerce staff report on Target says the company appears to have failed to respond to multiple automated warnings. The report relies on media accounts, so treat the detail as hedged.
-
Unmanaged aging. The CBUAE regulation C 1/2026 Article 8.8 requires licensed financial institutions to manage ICT systems including those run by third parties, with a strategy and timeline to renew or discontinue obsolete and unsupported hardware and software.
Rationalize by capability, not by product
Our reading: the useful unit is the security capability. Examples are asset discovery, vulnerability assessment, identity enforcement, detection, response and data protection. List the capabilities, then list which tools provide each. Overlaps and gaps appear immediately.
| Step | Question | Evidence |
|---|---|---|
| 1. Map | Which tools deliver each capability? Which capabilities have no tool? | Inventory of tools and contracts |
| 2. Test | Does each tool deliver its capability today? | Test results (see Measuring Control Effectiveness) |
| 3. Compare | Where two tools overlap, do they fail differently? | Architecture review, failure modes |
| 4. Cost | What does each cost to run, including people? | License, integration and staffing cost |
| 5. Decide | Keep, tune, replace or retire | Decision record with owner and date |
NIST CSF 2.0 gives a vocabulary for the inventory. ID.AM-02 asks that inventories of software, services and systems be maintained. ID.AM-04 asks for inventories of services provided by suppliers. ID.AM-05 asks that assets are prioritized by classification, criticality, resources and impact on the mission. Your tool inventory is part of that.
Avoiding new blind spots
-
Test before you remove. Run detection and prevention tests for the capability on the tool you plan to retire. Repeat them on the remaining tool.
-
Map data flows. Tools feed each other. Removing one can silence an integration, a ticket flow or a log source. NIST CSF ID.AM-03 expects representations of data flows to be maintained.
-
Migrate in parallel. Run old and new together for a period you define before cutting over.
-
Check contracts and obligations. Exit terms, data return and regulatory evidence duties may apply. For CBUAE-licensed institutions, Article 13.11 requires viable contingency and exit plans for third-party arrangements material to Critical Operations.
-
Reassign the people. A smaller stack run by the same overloaded team can still fail. Move saved effort to tuning and testing.
Fix the causes
| Cause | Control |
|---|---|
| Buying to close a gap with no retirement plan | Every new purchase names the tool or process it replaces, or states that nothing is replaced |
| Buying to satisfy a finding | Audit findings are closed by evidence of effect, not by tool deployment |
| Team-level purchasing | One intake route for security tooling, with the capability map as the test |
| No owner for tuning | Every tool has a named owner and a scheduled test |
Decision
Decision: build the capability map before any renewal discussion. Do not start with a cost target. Start with what must be covered, then let the map show what you can remove.
What this evidence does not show
The public cases show that deployed tools can be ineffective. They do not show that fewer tools are safer. A smaller stack with no testing is not better than a larger one that is tested. We did not use any survey figure on tool counts.
A short test
Pick one capability, for example vulnerability scanning. List every tool that does it, who owns each, and the last test result. If you find more than one tool, ask which one you would trust if the others vanished.
Sources
-
US House Committee on Oversight and Government Reform, Majority Staff Report, The Equifax Data Breach, December 2018. Accessed 9 October 2026. oversight.house.gov/wp-content/uploads/2018/12/Equifax-Report.pdf
-
US Senate Commerce Committee, Majority Staff Report, A Kill Chain Analysis of the 2013 Target Data Breach, 26 March 2014. Accessed 9 October 2026. commerce.senate.gov/wp-content/uploads/media/doc/2014%200325%20Target%20Kill%20Chain%20Analysis.pdf
-
Central Bank of the UAE, Operational Risk Management Regulation C 1/2026, Rulebook. Accessed 9 October 2026. rulebook.centralbank.ae/en/rulebook/operational-risk-management-regulation
-
NIST Cybersecurity Framework 2.0 (CSWP 29), 26 February 2024. Accessed 9 October 2026. nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionBuild & Transform CybersecurityTurn a long list of projects into a lasting program.See how we work →Related service
Security Engineering & Optimization
Use this to plan a security tool retirement that keeps detection, evidence and ownership intact.