What is penetration testing as a service?

The traditional penetration test is a consulting project. You scope it in a call, wait for a slot in the firm's calendar, testers work for a fixed window — often one to two weeks — and some days later you receive a PDF report. You then fix what it found, and if you want proof the fixes worked, you buy a retest, or you wait until next year's engagement and hope.

That model has two structural problems for any business shipping software regularly. First, the report describes a system that no longer exists: by the time you read it you have deployed new code, added a subdomain, changed a cloud permission. Second, the cost structure discourages verification. Retests are billed, so remediation frequently goes unproven, which is exactly the part an auditor or an enterprise customer cares about.

PTaaS is the commercial answer to both. Instead of buying a project, you subscribe to a service. Instead of receiving a document, you get access to a portal where findings appear as they are confirmed, remediation guidance sits alongside each finding, and requesting a retest is a button rather than a purchase order.

It is easy to dismiss the portal as packaging. In practice the platform changes who inside the business can act on security findings, which is usually the bottleneck.

A PDF report has one audience: whoever commissioned it. A platform can push a confirmed finding into Jira with a severity and an owner, notify a Slack channel, expose an API so your own dashboards can count open issues, and produce an export an auditor will accept. That difference is why engineering-led organisations tend to prefer PTaaS even when the underlying testing quality is comparable.

The mechanics are more standardised than marketing suggests. Almost every platform follows the same five stages, and the differences between vendors show up in how much of each stage is automated.

Vendors use the same three letters for very different products. Some PTaaS platforms are primarily an automated engine with a human review layer; others are a testing team with a platform attached. Both can be the right purchase — but they are not interchangeable, and the price difference is rarely the honest signal.

Ask exactly four things and the category sorts itself out. How many hours of human testing are included, and how often? Which classes of finding does the automated engine explicitly not attempt? Is retesting unlimited or capped? And what does the platform produce that an auditor will accept as evidence?

A vendor whose answer to the first question is 'our engine covers that' is selling continuous vulnerability scanning. That is a legitimate and often sensible product — it is simply a different one, and the distinction matters because automation is strong at known-vulnerability detection and weak at reasoning about whether your permission model can be abused.

Subscription testing is bounded by its scope. Because pricing is typically per target, the commercial incentive is to declare fewer targets — which is precisely how the forgotten staging server escapes assurance. Attack-surface discovery is the counterweight, and not every PTaaS platform includes it.

It also does not remove the need for specialist engagements. Complex business-logic testing, a hardware or embedded product, a large bespoke internal estate, a red-team exercise measuring your detection and response — these remain scoped consulting work. PTaaS is the standing assurance layer underneath them, not a replacement.

Finally, no platform makes you compliant. Frameworks require that testing happens, that findings are risk-assessed and that remediation is tracked. A PTaaS subscription produces excellent evidence for all three, but the obligation stays with you.

The model pays off fastest for organisations with a moderate, changing internet-facing estate and no in-house penetration testers: SaaS companies answering enterprise security questionnaires, regulated small businesses, and managed IT providers who need to show continuous assurance across a client base.

It suits large enterprises less as a whole-programme answer and more as one layer. Where a mature security function already runs validation and red-teaming, PTaaS tends to cover the perimeter continuously so specialist capacity can be spent elsewhere.

If you have no asset inventory at all, start earlier in the chain. Testing a list you cannot vouch for produces confident reports about the wrong systems.