31 October 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)
Penetration testing as a service (PTaaS): what you get, what you give up, and how to buy it well
PTaaS packages penetration testing into a platform with a subscription, a dashboard and retests on demand. Done well, it gives a release-heavy engineering team continuous assurance. Done badly, it is a vulnerability scanner with a new name. This guide explains the model, where it fits, where a scoped engagement still wins, and how to tell the two apart before you sign.
What penetration testing as a service is
Penetration testing as a service, usually shortened to PTaaS, is a delivery model rather than a test type. Instead of commissioning a single scoped engagement that ends in a PDF report, the buyer subscribes to a platform through which testing is requested, tracked and consumed. Findings appear in a dashboard as they are confirmed, each one can be pushed to Jira, GitHub or ServiceNow through an integration, a developer can request a retest of a single finding from the same screen, and the testing itself runs either continuously (a standing team that keeps probing as releases ship) or on demand (a scoped cycle you trigger when you need one). The report still exists, but it becomes an export of live data rather than the deliverable itself.
The model emerged because the traditional annual pentest fits badly with how software is now shipped. A SaaS platform that deploys to production several times a day can have a materially different attack surface six weeks after the test than it had during it. PTaaS answers that with shorter cycles, faster feedback to the people who write the code, and a continuous record of what was tested when. Those are real advantages, and they are the reason the model has grown from a niche offering in 2018 to a standard procurement category in 2026.
The complication is that the term covers two very different things. Some PTaaS vendors deliver human-led testing by certified testers through a platform. Others deliver automated scanning with a thin layer of human triage and call it penetration testing. The platform looks the same in both cases. The difference is in who is doing the work, how much of it is manual, and whether an auditor will accept the output. This article is about buying the first kind without accidentally paying for the second. For the underlying question of what automation can and cannot find, see our separate guide to manual versus automated penetration testing.
What a PTaaS platform typically includes
The components are consistent across vendors. The quality of each one is not.
Continuous or on-demand cycles
Either a standing allocation of tester days spread across the year, or scoped cycles you trigger per release, per quarter or per compliance deadline. The commercial model is usually a 12-month subscription.
Findings dashboard
Vulnerabilities appear as they are confirmed, with severity (usually CVSS v3.1 or v4.0), evidence, reproduction steps and remediation guidance. Status is tracked per finding: open, in remediation, retest requested, closed.
Ticketing and pipeline integration
Jira, Azure DevOps, GitHub Issues, ServiceNow, Slack and Teams integrations push findings to where engineers already work. Some platforms expose an API so findings can gate a deployment pipeline.
Retests on demand
A developer marks a finding as fixed and a tester verifies it, usually within a few business days, without a new statement of work. This is the feature engineering teams value most.
Tester access
Direct messaging with the testers during the cycle, so a question about a finding is answered by the person who found it rather than an account manager.
Compliance exports
Attestation letters, scope statements and report exports formatted for SOC 2, ISO 27001, PCI DSS or customer security questionnaires, generated from the live dataset rather than written once.
PTaaS versus a scoped manual engagement
Neither model is better in the abstract. They optimise for different things, and most mature programmes end up using both.
| Aspect | PTaaS (subscription, platform) | Scoped manual engagement |
|---|---|---|
| Cadence | Continuous or several cycles per year | One engagement, typically annual or per major release |
| Depth per cycle | Shallower per cycle, broader across the year; depends heavily on tester days allocated | Deep on the agreed scope; days are concentrated |
| Scope definition | Rolling; assets added and removed through the platform | Fixed in a statement of work before testing starts |
| Findings delivery | Real time, per finding, into ticketing | Report at the end, sometimes with critical-finding escalation during the test |
| Retest | On demand, included in most subscriptions | Scheduled, often a separate line item |
| Who tests | Varies: named certified testers, a rotating pool, or primarily automation with triage | Named testers, usually senior, agreed up front |
| Best fit | SaaS and product teams shipping frequently; multiple applications; ongoing customer assurance | Complex or regulated systems, first-time tests, internal networks, red-team-adjacent objectives |
| Audit evidence | Strong if the vendor documents manual coverage per cycle; weak if it is scanner output | Strong: a dated, scoped, signed report with named testers |
How to tell platform-driven scanning from human testing
The dashboard will not tell you. These five checks will.
1. Ask for the finding types from the last three cycles
Authorisation flaws between tenants, business-logic abuse, chained medium-severity issues that together give account takeover, SSO misconfigurations and race conditions are found by people. Missing headers, outdated libraries, TLS configuration and reflected cross-site scripting on a parameter are found by scanners. If the sample is all the second category, you are looking at a scanner with a human filter.
2. Ask how many tester hours each cycle contains, and who delivers them
A credible vendor states the manual effort per cycle in hours or days and names the testers and their certifications (OSCP, OSWE, OSEP, CREST CRT or CCT, GXPN). If the answer is a platform tier name rather than a number, the manual component is probably small. Ask whether the same testers return each cycle; continuity is what makes continuous testing find deeper issues over time.
3. Ask which methodology the manual work follows
Human testing is organised around a methodology: the OWASP Web Security Testing Guide (WSTG) and OWASP API Security Top 10 2023 for applications, PTES or NIST SP 800-115 for the overall process, OWASP MASTG for mobile. A vendor whose manual work follows a methodology can show you the test cases covered and not covered in each cycle. One that cannot is running tools.
4. Read the evidence on a sample finding
A human-found vulnerability comes with a narrative: what the tester tried, why it worked, what the business impact is, and how an attacker would chain it. A scanner finding comes with a template description and a request-response pair. The quality of the remediation guidance is the second tell; generic advice means nobody who understands your application wrote it.
5. Check what the attestation letter actually attests
Request a sample attestation letter and read the scope and method paragraph. It should state that manual penetration testing was performed, by whom, against which assets, during which dates, following which methodology. If it says the assets were 'assessed' or 'monitored' and does not name testers, your SOC 2 auditor or enterprise customer will notice the same thing you just did.
Questions to ask a PTaaS vendor before you sign
Put these in the RFP. Written answers are easier to hold a vendor to than a demo.
- Who performs the testing: named employees, a vetted freelance pool, or offshore partners, and which certifications do the people assigned to our account hold
- How many manual tester hours or days are included per cycle and per year, and what happens to unused allocation
- What is in scope per cycle, how is scope changed, and how is coverage of each asset documented so we can show an auditor what was tested when
- Which methodology governs the manual work (OWASP WSTG, API Top 10, MASTG, PTES, NIST SP 800-115) and can we see the per-cycle test-case coverage
- What does the attestation letter say, who signs it, and will it satisfy SOC 2 CC4.1 and CC7.1 evidence requests, ISO 27001:2022 controls A.8.8 and A.8.29, and PCI DSS v4.0.1 Requirement 11.4 if those apply to us
- Where is our data stored and processed: the platform's hosting region, the testers' locations, data retention after the subscription ends, and whether evidence containing our customers' data ever leaves the EU or the US as required
- How are retests handled: turnaround time, whether they are unlimited, and whether a retest is performed by a tester rather than a re-scan
- How are critical findings escalated during a cycle, and what is the response time for a question to the testers
- What does the exit look like: can we export every finding with evidence in a usable format when the subscription ends
When PTaaS fits, and when a deep scoped test fits better
PTaaS fits organisations whose attack surface changes faster than an annual cycle can follow. A SaaS company deploying weekly, a product team maintaining several customer-facing applications and APIs, or a scale-up that needs to show prospects a current attestation letter every quarter all benefit from testing that keeps pace with release. The on-demand retest alone can shorten the time a confirmed vulnerability stays open from months to days, and the integration into ticketing removes the step where findings are copied out of a PDF by hand. For those teams, the question is not whether to use the model but how to make sure the manual component is real.
A scoped manual engagement fits better when depth matters more than cadence. Internal network and Active Directory testing, assumed-breach scenarios, OT and hardware, complex authorisation models, regulated environments where the scope statement will be read by a supervisor, and anything adjacent to red teaming (objective-based testing against detection and response) all need concentrated senior effort against a fixed, agreed scope. A first-ever penetration test is also usually better run as a scoped engagement: the organisation learns what a thorough test looks like before it buys a subscription to a lighter version of one.
Mature programmes combine the two. Continuous testing covers the applications that change constantly; an annual deep engagement covers the infrastructure, identity layer and anything the continuous cycles cannot reach, and a red team exercise every one to two years tests whether the whole thing holds up against an adversary with objectives. Our guide to how often penetration testing should be performed sets out the cadence by asset type.
What auditors and enterprise customers accept as evidence
SOC 2 does not prescribe penetration testing by name, but auditors routinely request it as evidence for CC4.1 (monitoring activities) and CC7.1 (detection of vulnerabilities and configuration changes), and most Type II reports describe an annual penetration test as a control. ISO 27001:2022 Annex A control A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance) are satisfied by documented, repeatable testing of in-scope systems. PCI DSS v4.0.1 Requirement 11.4 is the strictest: it requires a documented methodology (11.4.1), internal and external penetration testing at least every 12 months and after significant changes (11.4.2 and 11.4.3), correction and retest of exploitable vulnerabilities (11.4.4) and segmentation testing (11.4.5). In every case the auditor wants the same things: scope, dates, method, named qualified testers, findings, and evidence of remediation.
PTaaS can provide all of that, and sometimes more conveniently than a traditional report, because the dated record of what was tested in each cycle is generated automatically. It fails when the vendor cannot say how much of a cycle was manual, or when the attestation letter describes scanning. Enterprise procurement teams reviewing a vendor's trust center increasingly ask for a summary letter from the testing firm that names the testers and the methodology; make sure your PTaaS provider can produce one your largest customer will accept.
How HackersHub delivers continuous testing
We offer continuous penetration testing as a retainer: an agreed allocation of senior tester days per quarter, delivered by named OSCP-certified testers who stay assigned to your environment, against a rolling scope you control. Findings are delivered as they are confirmed, into your ticketing system if you want them there, with evidence written by the person who found the issue. Retests are performed by a tester, not a re-scan, and critical findings are escalated the same day. Every cycle closes with a dated scope statement and a signed attestation letter that names the testers, the methodology (OWASP WSTG, OWASP API Security Top 10, PTES, NIST SP 800-115 as applicable) and the manual effort delivered, so your auditor and your customers can rely on it.
Where a client also needs the depth of a scoped engagement, for the internal network, the identity layer or a red team exercise, we run it alongside the retainer with the same team. Pricing is on scope and allocation, agreed in writing after a scoping call; we do not publish a rate card. Michael van Mameren leads the continuous testing practice and is named on every attestation we issue.
Frequently asked questions
Continuous testing with named testers, not a scanner with a dashboard
A 30-minute scoping call establishes the assets, the cadence and the tester allocation that fit your release cycle. You receive a written proposal with named OSCP testers, the methodology and the attestation terms. Talk to an expert.