PTaaS for Pentest Firms: What It Means and How to Sell It

PTaaS (penetration testing as a service) is penetration testing delivered as a continuing service rather than a one-off project: findings reach the client through a portal as they are confirmed, fixes are retested on request, and testing recurs on an agreed programme. It is a delivery model, not a different kind of testing, so any consultancy with good testers can sell it under its own brand once its release discipline, retest capacity and pricing are built for it.

A delivery model, not a kind of testing

The testing inside a PTaaS engagement is the testing you already do: the same methodology, scoping, rules of engagement and written authorisation. What changes is everything around it: how findings reach the client, how fixes get verified, how the work is bought, and how long the relationship lasts between tests.

The label has been stretched. Some offers sold as PTaaS are mostly automated tool output behind a dashboard, which is a vulnerability scan with a login page. Do not compete with that on price. Say plainly that your service is people testing, delivered continuously.

Be careful with the word continuous. Unless testers are on the client's estate every week, the testing is periodic. What is continuous is visibility and access: the client can see the current state of every finding and get a fix verified at any point in the year. Sell that, because it is true.

What clients mean when they ask for PTaaS

"We want PTaaS" is rarely a specification. In our experience it means one or more of these:

Ask which of these they mean before you price anything. Most clients want two or three, and the cheapest to deliver, releasing findings as they are confirmed, is often the one they value most.

What changes: release, retest, visibility

Findings are released as they are confirmed. A finding goes to the client when it has been verified and reviewed, not when the report is finished. That turns QA from a document event into a finding event: a reviewer checks each finding within a day of it being written, rather than forty of them on a Friday afternoon. A critical still gets a phone call first, as on any test, and what to do when you find something critical mid-engagement applies unchanged. The portal records it. It does not replace the call.

Retests happen on request. The client asks for a retest when the fix is deployed, not when next year's test comes round. You need a turnaround you can keep, such as ten working days, a stated allowance of retests in the programme, and a record that shows each finding as fixed, still open or partly fixed. How to run a retest properly covers the evidence a retest needs.

The client can see the current state at any time. What has been released, what they have fixed, what is waiting for a retest, and every report you have delivered. Your portal becomes part of the service, and it carries your name or somebody else's.

Behind those three sit changes to how you run the firm: a reviewer available every day rather than at the end, retest capacity reserved in the schedule rather than squeezed in, and a named lead for each client who owns the relationship between rounds.

What does not change

• Authorisation, every round. Each testing window needs written authorisation from someone entitled to give it. A programme signed in January does not authorise testing of systems that did not exist in January.
• Scope and rules of engagement. Each round is scoped against the estate as it is, not as it was when the contract was signed.
• Methodology and evidence. The same standard of testing, and the same evidence behind every finding.
• The report. Auditors and customers still want a document. Releasing findings early does not remove the report. It turns the report into a summary of findings the client has already seen, which is a better report.
• The attestation letter for the client's auditor or customers, signed by a named person at your firm.
• Your duty of care with the data. Live findings in a portal are as sensitive as findings in a PDF, and easier to reach.

Pricing PTaaS as a service

There are three common shapes, and many programmes mix them.

An annual programme suits clients with fixed obligations. PCI DSS, for example, asks for internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, so the programme can be built around dates the client already has. Credits suit clients who know they need testing but not yet what. Retainers suit clients with a security team who will use you as an extension of it.

Price the days first and the service second. Start from your day rate and the days each round genuinely needs, add a retest allowance expressed in days or in retests per finding, and offer a modest discount for a year's commitment if you want one. Do not sell unlimited anything: unlimited retests become a free remediation helpdesk.

A worked example, with the numbers as illustrations rather than benchmarks: a SaaS client's year might be a six-day web application and API test before their main release, a two-day external round each quarter, and four retest days held in reserve. That is 18 days. At an illustrative £1,000 a day it comes to £18,000, which the client can pay as one annual fee or as £1,500 a month, with every round's dates agreed at signature.

The statement of work should state the rounds and their scope, how a round is re-scoped, the retest turnaround and allowance, how unused days are treated, how critical findings are reported, and what happens at renewal. Pricing testing work covers day rates and retainers in more depth.

Your brand, not a marketplace's

Ask whose name the client sees when they sign in to read their findings. If it is a platform vendor's, part of the relationship belongs to the vendor, and some vendors sell testing of their own. For a consultancy, the portal is where the relationship lives for most of the year, so it should be on your domain, in your colours, with email from your own address. What white-labelling actually buys a testing firm sets out the commercial case.

Your brand also carries something a rotating pool of testers cannot offer: continuity. The value of a PTaaS relationship is a team that already knows the estate, its quirks and its history. A pool sends whoever is free. A consultancy can promise the same lead tester for the year, so put that in the agreement and charge for it.

Where it goes wrong

• Selling "continuous" and delivering quarterly. The client will hold you to the word in the contract.
• Releasing unreviewed findings for speed. A false positive in a client portal is far more visible than one in a draft.
• Retests with no allowance or turnaround. Five-minute verifications that each take half a day to schedule will fill your calendar.
• Credits that expire unused. Your best client becomes an aggrieved one at renewal. Agree roll-over rules at the start, or schedule the days at signature.
• A portal nobody opens between rounds. If nothing happens for five months, the client stops signing in and the renewal goes back to procurement.
• Scope drift. Round three tests systems round one never covered. Re-scope and re-authorise every round.
• One reviewer for every client. Releasing as you go needs review capacity every day, not at month end.