Introduction

I've sold most of the labels this industry has tried on. Penetration testing, then continuous testing. More recently, AI pentesting, and unified AppSec platform (because unified apparently sells better than accurate). I pitched most of these myself, to real CISOs, in real rooms, and the label always bought me about ten minutes of attention. Then came the same question, whichever label was on the slide that quarter: not 'is this AI-powered,' not 'is this continuous,' just, how do I actually know where the business risks are.

None of the labels ever answered that, because none were built to. They described an activity; testing, scanning, pentesting, when what the CISO actually needed was a decision. Closing that gap took three years, and it's why, this year, we stopped calling ourselves any of the old names.

I wrote a few weeks ago about the gap I keep finding in rooms full of CISOs: hands going up when I ask who's responsible for security, most going back down when I ask who felt genuinely confident nothing critical shipped on their watch. That gap is still the reason Cytix exists.

Three years, one question

We're three years old now, sitting inside NCC Group and KPMG’s own continuous application security offering. Whatever we called ourselves each quarter, the question underneath never changed: which of the thousand software changes going out this month actually need someone's attention, and can we point to why if a board or a regulator asks. A label built around testing can't answer that. A label built around a decision can. So we retired the old names, not because they were dishonest exactly, more because they described the wrong layer of the problem. We're not a test you buy once a year. We're not a platform you bolt scanners onto and hope. We're the thing that decides, for every software change, whether it matters, and keeps the record of why.

For years the industry's pitch has been to put a scanner in front of a human, so the human only sees what got flagged. Fine, as far as it goes. The honest next step is to put something in front of the scanner too, deciding where it should even look before it runs, otherwise you're just running the same net over everything and calling that intelligence.

Say a change lands, an endpoint added to a service that handles customer data. We read the change itself, not the ticket describing it. I've sat through enough meetings where the two didn't match. We pull in what we already know about that service, what it touches, what's been found there before. Then we make the actual call: does this matter enough to need a human, and if so, what kind of look? A specific test, a threat model, a full review. Most of the time the honest answer is no, and that's the product working, not us being lazy. When the answer's yes, it gets routed properly instead of everything getting thrown at everything.

Judge and jury

I get asked, reasonably, whether a system like this ends up making the actual security calls. It doesn't, and it shouldn't. We're not the judge. What we do is make sure there's a jury's worth of evidence behind whatever decision your team makes, so it's a decision you can defend rather than a guess you're hoping holds up. A tool that quietly starts approving things on your behalf is a different, much riskier product than one that makes sure every decision, including the ones where nothing happens, has a reason attached to it.

What this means if you're evaluating any of this, including us

Here's what I'd actually do, sitting where you're sitting. Ignore the category on the slide, ours included. Ask one question: when this tells you a change didn't need attention, can you see why, and would that reasoning survive being read out to a board or a regulator. If the answer's no, you've bought an activity, not a decision, whatever it was called on the way in.

That's the whole case for Cytix stripped down. We didn't call for change because the market wanted a fresher label. We changed because the old ones had stopped describing what we'd actually built, which is a way to qualify and act on software change risk, and because a CISO shouldn't have to translate 'AI pentesting' into 'can I defend this decision' every time they talk to us.

Here's to the next chapter.

Ben