Most security teams I speak to are running somewhere between 20 and 40 security tools. Some are running a lot more. And when you ask them a simple question, which of those tools actually covers lateral movement detection right now, the answer is almost always the same. It takes a spreadsheet, a few calls to product owners, and a couple of days.

That is not a failure of the team. It is just what happens when a security stack grows organically over years, through different budget cycles, different teams, different threat priorities, and the occasional acquisition thrown in for good measure.

But the cost of that complexity is real. And most of it is hidden.

The overlap problem is bigger than most people think

When security teams audit their stacks properly, the numbers are usually surprising. Not because anyone has been irresponsible, but because the way enterprise security procurement works almost guarantees overlap.

A new threat category emerges. A vendor pitches a solution. The budget gets approved. The tool gets deployed. Three years later the original threat has evolved, two other tools in the stack now cover the same capability, and nobody quite remembers when that happened.

Multiply that pattern across endpoint, network, cloud, identity, and application security over a decade and you start to understand why most large organisations are paying for the same capability from two or three different vendors without realising it.

Most large organisations are paying for the same capability from two or three different vendors without realising it.

The financial cost is obvious. Overlapping tool licences are dead money. But the operational cost is less talked about and arguably more damaging.

When you have multiple tools covering the same capability, you get duplicate alerts, inconsistent data, and security teams spending time correlating noise instead of responding to real threats. The more tools you run, the harder it becomes to maintain expertise across all of them. And the harder it becomes to answer the question that matters most: where are we actually exposed right now?

The gap problem is the other side of the same coin

Overlap and gaps tend to travel together. A stack that has grown organically over years almost always has both. You are paying twice for some capabilities and not paying at all for others.

The gap problem is harder to see because it requires understanding two things at once: what your tools actually cover in practice, and what the current threat landscape actually looks like. Most teams have a reasonable handle on their tools. Very few have a clear, up to date picture of both simultaneously.

Frameworks like MITRE ATT&CK exist precisely to solve this problem. They give you a common language for describing attacker techniques and a structure for mapping your defences against them. The challenge is that mapping your entire stack to MITRE manually, keeping it up to date as products evolve, and interrogating it with specific questions is an enormous amount of work.

Which means most teams do it once, maybe annually, and the results are out of date within months.

The tribal layer is where it gets complicated

Here is the part of this problem that never comes up in vendor conversations but comes up constantly when I speak to security architects and CISOs.

Even when you have a clear technical picture of your stack, what tools you have and what they cover, you still do not have the full picture. Because a huge amount of information about how your security environment actually works is locked up in people's heads.

The product owner who knows that the EDR tool has been configured in monitoring-only mode since the last incident and nobody has changed it back. The network team who know there is a legacy segment that was excluded from the NGFW rollout because of a compatibility issue three years ago. The cloud team who knows that the CASB only covers two of the five cloud environments because the integration for the others never got finished.

A huge amount of information about how your security environment actually works is locked up in people's heads.

None of this shows up in a product inventory. None of it shows up in a framework mapping exercise. It only surfaces when you actually talk to the people who work with the tools day to day.

The problem is that doing that at scale is genuinely hard. A thorough interview programme across a large organisation, covering every relevant product owner, every team that touches security tools, every business unit that has its own configuration decisions, takes weeks. And the output is usually a mix of notes, spreadsheets, and email threads that is difficult to synthesise into anything actionable.

So most teams do a partial version. They talk to the people they can easily get to, make some assumptions about the rest, and move forward with an incomplete picture. Not because they are cutting corners, but because the full version is not practically achievable with the resources available.

What good looks like

The teams that manage this well tend to do a few things differently.

They treat capability mapping as a continuous process, not a project. A point-in-time mapping exercise is useful but it starts degrading the moment it is finished. Products get updated. Configurations change. New tools get added. The teams that stay on top of their coverage treat it as something that needs to be maintained, not completed.

They map to threats, not just to compliance frameworks. Compliance frameworks are important but they are not the same as threat coverage. A stack that is fully compliant with a given standard can still have significant gaps against the actual techniques being used by attackers right now. The best teams use threat-focused frameworks like MITRE ATT&CK alongside their compliance requirements.

They go beyond the product inventory to understand how tools are actually being used. The difference between what a tool is capable of and what it is actually doing in your environment can be enormous. Configuration decisions, integration gaps, licensing limitations, and the way different teams use the same tool all affect real-world coverage. The teams that understand this are the ones who can answer the hard questions with confidence.

They build in a systematic way to capture what people know. The tribal layer matters. The best security teams find ways to systematically surface the knowledge that is distributed across their organisation rather than relying on the few people who are easy to reach.

Where to start

If you are a security architect or CISO reading this and thinking that your organisation has some version of this problem, the honest answer is that most do. The question is whether you have enough visibility to know where the gaps and overlaps actually are.

A good starting point is to pick one area of your stack, endpoint for example, and try to answer three questions honestly.

•       How many tools do we have that contribute to endpoint protection in some way?

•       Which MITRE ATT&CK techniques are we actually covered against, and how confident are we in that assessment?

•       Is there anything about how those tools are configured or used day to day that the product inventory would not tell you?

If you can answer all three with confidence and without a significant amount of manual work, you are in better shape than most. If you cannot, that is a useful data point about where the visibility gaps actually are.

The good news is that this problem is solvable. It requires the right combination of data, tooling, and a systematic approach to the tribal layer. But the first step is having an honest picture of where you actually stand.

Try it yourself

If you want to start mapping your own stack against MITRE ATT&CK and other frameworks, the Capability Exchange is free to use. No account required to explore. It covers over 13,000 vendors and 27,000 products with more than a million data points, so whatever your stack looks like, the coverage data is there.

Capability.Exchange — The independent registry for cyber capability.