There is a particular "look" security programmes get just before they fall apart.
Plenty of tools, dashboards, and a plethora of reassuring colours - but, absolutely no idea what actually matters. On the surface, everything appears mature. The organisation has invested. Vendors are deployed. Someone, somewhere, is proudly reporting that security is now "in a much better place" - until someone asks a real question.
The great comfort blanket of buying tools
Tool-led security programmes usually start with urgency rather than thought - a board is nervous, an audit is coming, or a customer asked an awkward question. How does the organisation respond? It does what feels decisive. It buys tooling to respond. Not because the problem is misunderstood, but because buying feels like progress. There is a contract, a roadmap, a kickoff call. Slides with words like "visibility", "coverage", and "enterprise-grade".
And just like that, the organisation feels safer.
Nothing has actually changed of course, but somehow, everyone sleeps better knowing there is now a new platform involved.
When activity masquerades as strategy
Once tools arrive, activity explodes.
- Alerts fire.
- Tickets are raised.
- Reports are generated.
Someone then builds a dashboard to prove how busy the team is. That doens't make much sense, so another dashboard is created to explain the first one….
The programme looks alive. Energetic. Productive, but not intentional.
No one can clearly explain which risks truly matter, articulate what the organisation is deliberately choosing not to fix, and arguably worst - nobody is confident who actually owns the uncomfortable decisions. But there are charts. Lots of them. They look impressive to a board, but only if someone actually understands the data they contain.
Tools are terrible at understanding reality
Security tools are very good at one thing: assuming the world is tidy. An example of these assumptions are:
- systems are owned.
- processes are followed.
- risk decisions are documented.
- environments reflect architecture diagrams.
Real organisations are becoming increasingly allergic to these assumptions.
- Legacy systems exist because "we cannot touch that".
- Cloud services appeared because someone needed to move fast.
- Exceptions were granted three years ago and never revisited.
- Controls were half-implemented because the deadline mattered more.
The tools dutifully report on what they can see, blissfully unaware that the most important risks live entirely outside their field of view.
This is not opinion dressed up as cynicism. Research consistently shows that organisational culture and leadership have more impact on security outcomes than the tools themselves. When ownership is weak and decisions are unclear, technology simply documents failure more efficiently.
Scrutiny is where the fantasy ends
Tool-led programmes always work best when nobody is looking too closely. Then scrutiny arrives and ruins the party.
An auditor asks why a control exists but is never enforced.
A regulator wants to understand how risk decisions are made.
An incident forces leadership to ask what they are actually exposed to.
Suddenly, abstraction stops "helping".
Dashboards cannot explain trade-offs.
Scores cannot justify risk acceptance.
Vendor language collapses under plain questions.
What happens if this system goes down?
Who decided this was acceptable?
Why did we not see this coming?
This is where the silence becomes deafening.
Security theatre does not impress when it matters
Security theatre thrives in calm conditions. It looks amazing in steering committees, produces impressive board packs, and gives the illusion of control without the inconvenience of judgement.
But resilience is not theatrical.
Resilience is knowing which systems hurt most when they fail, understanding which risks leadership is consciously accepting, and being able to explain decisions without hiding behind tooling.
You cannot outsource that to a platform, no matter how expensive it was.
Leadership is not a feature you can enable
Strong security programmes are not assembled from products, but built around people who understand risk, context, and consequence.
- They start with uncomfortable conversations.
- They define ownership before capability.
- They prioritise decisions over deployments.
Only then do tools make sense (or provide any semblence of it).
Used properly, tools support judgement. Used badly, they obscure the absence of it. And when scrutiny arrives (as it always does), the difference becomes painfully obvious.
Final thoughts
If your security programme looks impressive but feels fragile, trust that instinct.
When organisations collapse under scrutiny, it is rarely because they chose the wrong tool. It is because they tried to replace leadership with software and hoped nobody would notice.
This is exactly where Phenomlab steps in.
I help organisations strip away the theatre, reconnect security to real business risk, and rebuild programmes that can stand up to uncomfortable questions without flinching.
Less noise.
More clarity.
And decisions that still make sense when someone finally looks closely.
