Complexity is the new attack surface: Why a fragmented security stack slows you down
Ask most IT leaders why they bought their most recent security tool, and the honest answer is rarely “it was part of the plan.” More often, it was after a compliance audit finding, an incident that became a wake-up call, or a renewal conversation with an insurer. But instead of a proactive security strategy, this usually results in a fragmented security stack stitched together – tools that each made sense on their own, but were never quite designed to work as a whole.
IBM and Palo Alto Networks found that organisations running fragmented security tools took 72 days longer to detect a threat, and 84 days longer to contain one, than organisations running a more joined-up setup. It’s not just an enterprise problem anymore. It just needs a handful of products that don’t talk to each other, and most small and mid-sized businesses already have exactly that.
Why the stack grows one scare at a time
That’s not a criticism of anyone’s judgement. It’s simply what reactive security looks like. Every purchase solves the problem in front of you, and nobody ever goes back to check whether the last five purchases still make sense together.
“Businesses usually spend money on multiple tools, but what’s important is having the system set up in the right way and running optimally for what you're trying to achieve.”
A firewall bought in year one and an endpoint tool bought in year three may both be doing exactly what they were designed to do. But if nobody has considered how they work together, the business is left managing two pieces of a security environment rather than one joined-up picture.
The blind spots hiding in the gaps
We’re not making the argument that fewer tools necessarily mean good and more tools means bad. Complexity becomes a security problem specifically when a business can’t effectively operate, integrate and govern the tools it already has – that is when nobody’s quite sure what each one is doing, where their coverage overlaps, where the real gaps sit, or whether the team responsible actually has the capacity to run the environment as a whole.
There isn’t a magic number of security products that suddenly makes an environment unsafe. Plenty of businesses run a dozen well-managed tools without incident. Plenty of three-tool setups are quietly falling over. The count was never really the point.
But when you operate a fragmented security stack, you’ll inevitably create blind spots that attackers tend to exploit. This also creates another problem we recently touched on – alert fatigue and a false sense of security. When dashboards and activities from five different tools inundate you, and response efforts sit in silos, alerts stay disconnected, and information that could have been genuinely useful never quite turns into something anyone can act on in time. We’ve explored the difference between having information and having meaningful visibility in more detail in this article.
How confident are you in your cybersecurity?
Answer 10 questions and find out! You’ll get a score at the end of the quiz, along with personalised recommendations that you can apply to improve your cybersecurity posture.
The attack surface itself got bigger
It’s also worth saying, in fairness to every business that’s ended up here, this isn’t purely about poor planning. The world your tools are defending genuinely got more complicated over the last decade, often faster than anyone could keep up with.
Cloud and SaaS tools multiplied. Remote and hybrid work spread where work actually happens far beyond a single office network. Third-party integrations connected businesses to suppliers, platforms and vendors that now sit somewhere inside the attack surface too.
You can see that shift in how security testing itself has had to change shape. A few years ago, an annual penetration test was the expected standard – book it once a year, tick the box, move on. That’s no longer considered enough. Many businesses have moved to continuous vulnerability assessments, checking infrastructure every few hours rather than once a year, precisely because the attack surface doesn’t hold still long enough for an annual snapshot to stay accurate.
Each of those shifts came with its own recommended tool, dashboard, and login. Cumulatively, that’s exactly how fragmentation happens.
What managing complexity actually looks like
None of this is an argument for consolidating everything into a single platform either. Context matters – a specialist tool that does one job brilliantly is often worth the extra login, and trading real capability for the appearance of simplicity just swaps one kind of risk for another. What actually seems to work is less about the tools themselves and more about a handful of habits around them:
- Map by capability, not by product. Rather than a list of tool names, group what you have by what it actually protects – identity, endpoints, email, data, network. Genuine overlaps and gaps become far easier to spot when you look at coverage this way.
- Give each capability an owner, not just each tool. Someone accountable for knowing whether each security domain is properly covered end to end.
- Test the handoffs, not just the tools. Run a realistic scenario occasionally and trace whether information actually moves from one system to a person who can act on it, not just whether each tool individually did its job in isolation. This is usually where the real gaps turn up.
- Revisit the picture when something changes, not just once a year. A new tool, a retired one, a new SaaS platform, a change in the team – each is a natural moment to update the map, rather than waiting for an annual review to catch up on everything at once.
Once complexity is understood in those terms, it becomes something a business can manage. Left unexamined, it quietly becomes another attack surface in its own right.
Where this leaves you
The pattern in this blog isn’t new – we’ve been exploring this in our ebook. A business assumes its security stack provides coverage, the same way it might assume a backup would restore cleanly, or a dashboard would catch what actually mattered. The assumption is just untested, and a tool stack is one of the easiest places for that gap to hide, because on paper, more tools look exactly like more protection.
The fix was never buying less or buying more. It’s asking the same question this keeps coming back to, this time pointed at your own stack. Not “do we have the right tools,” but “do we actually know what they’re doing together?”
That’s the thinking behind our Prove & Protect guide, which looks at some of the assumptions businesses make about their security and what happens when you start testing them.
