There’s a version of security consulting that looks great on paper. A pentest gets scoped, executed, and delivered as a PDF. The client receives it, files it somewhere, maybe fixes a few things, and everyone moves on until next year. The tools are there. The frameworks are there. The compliance checkboxes get ticked.
And yet — CISOs are still stressed. Dev teams and security teams still don’t talk to each other. Companies are spending six figures on tools and getting the same results they got without them. Reports that took weeks to produce sit in inboxes unread. Vulnerabilities that were “critical” on paper turn out to be irrelevant in context, while the ones that actually matter get buried in noise.
I spent the better part of four years inside this cycle — running pentests, sitting across from CISOs, working with dev teams, watching the same patterns repeat across industries and company sizes. Somewhere along the way, I stopped seeing individual client problems and started seeing systemic ones.
What follows is what I’ve learned. Not all of it is fully resolved. Some has been proven across multiple engagements. Some is still being built.
The pentesting delivery problem
Pentesting hasn’t meaningfully evolved in decades. The delivery mechanism is still a PDF report — emailed to a project manager, forwarded to someone technical, maybe opened, maybe not. The person who finds the vulnerability and the person who needs to fix it almost never talk to each other directly.
There’s also a cost problem hiding in plain sight. Writing the report takes days. Reviewing it takes more. Retests produce updated reports. The time spent on documentation that exists only to satisfy process is time nobody’s spending on actually improving security — and both sides pay for it without questioning it.
I saw a different model while working inside one of the largest cloud service providers. Their security engineers and dev teams operated in the same ecosystem — sharing scope, threat models, test plans, and results in real time. That became the question: if this works inside a tech giant, why can’t it work in consulting?
It can. It just requires rethinking what “delivery” means.
Status: Proven. Reproduced across multiple industries. Validated by a Big Four auditor, confirmed head-to-head against a well-known pentest-as-a-service platform, and independently described by a senior industry director as “Pentesting 2.0.”
Read the full story → The Pentesting Delivery Problem
The dev-sec friction problem
Security teams and development teams have been at odds for as long as both have existed. Security shows up, drops a list of problems, and leaves. Developers see it as criticism. Everyone treats it as someone else’s problem.
Frameworks exist to fix this — on paper. In practice, the friction is cultural, not procedural. You can’t document your way out of a trust deficit.
What I’ve seen work is making security a shared problem rather than an imposed one. Tickets with suggested fixes, not just findings. Threat models co-authored with the developers who actually know the system. At one engagement, the first call was genuinely adversarial. Six months later, it had turned into a working friendship. At another, a large enterprise described the shift as their DevOps and security teams collaborating for the first time — a cultural change, not a process one.
Status: Proven. Repeatedly. The pattern holds across different industries, team sizes, and levels of initial friction.
Read the full story → The Dev-Sec Friction Problem
The tool-dependency problem
The security tooling market has a product for every category. Most of them do what they claim — they find things. What doesn’t work is what happens after.
The problem isn’t that tools are bad. Some are excellent. It’s that organisations buy tools before they’ve built the foundation those tools need to be useful. A CSPM tool capable of powering proper risk management gets reduced to a ticket-flooding machine. A SAST platform generates hundreds of findings that nobody can prioritise because nobody has mapped which assets actually matter.
At one engagement, I recommended the client invest in process before tooling. The result was zero commercial tool cost — open-source covered what was needed, and the budget went into code reviews, developer enablement, and building a security culture that could sustain itself. Hundreds of confirmed issues dropped to a fraction of the original count.
The lesson wasn’t “tools are useless.” It was: get your basics right first, then add tools as a layer to strengthen what’s already working.
Status: Proven at scale in one major engagement. Whether it scales without sustained hands-on involvement is something I’m still working through.
Read the full story → The Tool-Dependency Problem
The play-pretend problem
This is the one that’s hardest to talk about because it implicates the entire consulting incentive structure.
Some organisations have everything — the frameworks, the tools, the policies, the budget. And yet nothing works. I’ve walked into engagements where three different copies of the same vendor report sat on a shelf, alongside frameworks that had never been operationalised. Risk registers that haven’t been updated since they were created. Third-party firewalls deployed in front of cloud environments that already have cheaper, better-integrated native alternatives — bought because a team had budget to spend, not a problem to solve.
The uncomfortable truth is that the consulting industry sometimes benefits from this. When the incentive is billable days rather than solved problems, there’s a structural pull toward documentation over operational capability.
The counter isn’t another framework. It’s building something that works — on a platform the teams actually use, measured by whether the problem is getting smaller, not by whether the report is getting longer.
Status: Proven in terms of the collaboration and operational VM breakthrough. The fuller vision — embedding risk management as an operational function across every engagement — is still in progress.
Read the full story → The Play-Pretend Problem
The thread that connects them
These problems look different on the surface — one is about reporting, another about tooling, another about culture, another about incentives. But they share a root cause: the security consulting industry has optimised for appearances over outcomes. Reports that look thorough but don’t get read. Tools that generate alerts but don’t reduce risk. Frameworks that satisfy auditors but don’t change behaviour. Teams that coexist in the same organisation but work against each other.
Each one was exposed not by studying the industry from the outside, but by sitting across from CISOs, developers, and security teams who were living with the consequences. The most important shift wasn’t technical — it was learning to ask “what’s actually bothering you?” instead of showing up with a predetermined solution.
That question — asked over early morning coffee calls, before the sales pitch, before the scope document — is what opened the door to every engagement where something meaningful got built. CISOs don’t need another vendor offering pentests. They need someone who understands that pentesting is often the smallest of their problems.
Uncategorized 
Leave a comment