Not because the problem went away. Not because the ideas weren't valuable. But because, as an industry, we never actually agreed what PTaaS meant in the first place. That's the real issue.

PTaaS: the most poorly defined term in AppSec?

I've said this before, and I still believe it: PTaaS is one of the most poorly defined terms our industry has produced. At its peak, it was used to describe everything from:

• Traditional pen testing with a portal

• Continuous testing models

• Bug bounty-style delivery

• Automated scanning with dashboards

• Fully managed, integrated security workflows

That's not a category. That's a catch-all. And when a term tries to mean everything, it ends up meaning very little.

The uncomfortable truth: most "PTaaS" wasn't that different

If we strip it back, most organisations still buy penetration testing for the same reasons they always have:

• Compliance requirements

• Customer assurance

• A need for independent validation

That core service hasn't fundamentally changed. You still need skilled people assessing systems, identifying risk, and producing meaningful outputs. So when vendors positioned PTaaS as something entirely new, it often wasn't. In many cases, it was: Pen testing… but with a portal.

Where PTaaS actually did add value

That doesn't mean PTaaS was meaningless. It just means the value was often in the wrong place. The real opportunity was never about replacing the test itself. It was about everything around it.

Because if you've spent any time in AppSec, you know where the real friction is:

• Getting a test scoped and booked

• Navigating paperwork and approvals

• Waiting on availability

• Chasing updates during delivery

• Receiving a static PDF that doesn't fit your workflows

• Starting the whole process again for retesting

That's where PTaaS had (and still has) genuine potential:

• Digital-first workflows

• Integrations into engineering tooling

• Faster retesting cycles

• Better visibility across the lifecycle

• Less manual overhead on both sides

That's meaningful. That's progress. But a portal alone doesn't get you there.

The SaaS illusion: why "as a Service" doesn't quite fit

Part of the confusion comes from the "as a Service" label. SaaS works because software scales. It delivers continuous value, continuously.

Pentesting doesn't behave like that. The "before" and "after" of a test can be streamlined with software. But the "during" (the actual testing) is still fundamentally human. It doesn't compress neatly into a scalable, always-on model.

That tension led to two outcomes:

• Some vendors leant heavily into automation to scale delivery

• Others rebranded traditional services without changing much at all

Neither of those fully delivers on the SaaS promise.

Continuous testing: the idea that got tangled in PTaaS

Another concept that became entangled with PTaaS is continuous testing. On paper, it makes sense. One of the biggest limitations of penetration testing has always been that it's a point-in-time snapshot.

So naturally, the industry asked: What if we could see security posture over time?

That's a valid question. But it only works if the model supports it. If you're running one pentest a year and plotting trends, you're not getting meaningful insight. You're getting noise.

Continuous visibility only works when it's paired with:

• Sufficient testing frequency

• Real coverage of change

• Context around how systems evolve

Without that, "results over time" becomes a marketing phrase, not a capability.

Did PTaaS fail, or did it fragment?

I don't think PTaaS failed. I think it fragmented. The ideas behind it didn't disappear, they evolved into clearer categories:

• Workflow-driven security platforms

• Continuous testing models

• Attack surface management

• Crowd-sourced testing

• Automated scanning with prioritisation layers

What PTaaS tried to bundle together has since been broken apart and defined more precisely. Which is, ultimately, a good thing.

The risk buyers still face

The problem is that the ambiguity hasn't fully gone away. Today, you can still buy something labelled as "modern pen testing" or "PTaaS" that is, in reality:

• A basic automated scan

• Wrapped in a dashboard

• Sold at pen test pricing

And that's where organisations get caught out. Because the label suggests maturity, but the delivery doesn't always match.

What PTaaS should have been

If we were to define PTaaS properly, not as a buzzword, but as a meaningful model, it would look something like this:

End-to-end digital experience

Not just report delivery, but scoping, execution, triage, and retesting.

Reduced operational friction

Less manual coordination, faster turnaround, easier repeatability.

Integration into engineering workflows

Findings that flow directly into how teams actually build and fix software.

Transparency of delivery

Clear distinction between automated and human-led testing.

Flexibility in how testing is delivered

Traditional, distributed, or continuous — depending on need.

That's a model worth building. But it's not what most people meant when they said PTaaS.

The bigger lesson for AppSec

PTaaS is a useful case study in how our industry adopts change. We're quick to rename things. Quick to signal innovation. But slower to define what "better" actually looks like in practice.

The reality is buyers don't need more buzzwords, they need clarity, consistency and outcomes that align with how modern engineering actually works.

The demand that drove PTaaS hasn't gone anywhere. If anything, it's stronger than ever: make security testing easier to consume, easier to integrate, and more aligned to how software is built today.

That's still the problem to solve.

Final thought

PTaaS didn't disappear because it wasn't valuable. It disappeared because we never agreed what it was.

And in doing so, we missed an opportunity to define clearly what modern penetration testing should actually look like.

Possibly a lesson for the future as we enter the next wave of AppSec innovation.