Pentest as a Service Compared: Five PTaaS Delivery Models

Imagine two teams buying pentest as a service and receiving very different services. One got a portal that hosts a consultancy's PDF. The other got a code-aware system that tests regularly and supports retesting after fixes. Same label, different product.

That is the problem with shopping for PTaaS by logo. PTaaS is a delivery wrapper: a portal, an API, a findings queue, a retest button. It says nothing about who does the testing, what they can see, or how a finding gets proven. Those questions decide whether you find the IDOR in your billing endpoint or ship it.

This post compares five delivery models: crowdsourced, consultancy portal, scanner-led, autonomous AI, and code-aware continuous. We compare overlapping approaches, not vendors, and we skip pricing. We also say plainly where Borg is the wrong fit, because a comparison where our model wins every row is not a comparison.

What PTaaS actually is: a portal around a pentest, and why the model matters more than the logo

Strip the marketing and pentest as a service is typically a delivery layer built around things such as scoping and scheduling tests, tracking findings, and managing remediation or retesting. The testing underneath can be a human consultant, a crowd of freelancers, an automated scanner, an autonomous agent, or some mix.

So two PTaaS vendors can be nothing alike. The portal looks the same in a demo. What differs is the engine behind it, and the engine decides what you actually learn about your application.

For many engineering teams, some of the most consequential bugs sit in auth flows, authorisation, tenant isolation, billing and business logic. Finding them often benefits from application context and offensive reasoning. A tester with source access and knowledge of the application's roles can investigate a broken object check more directly than a tester working without that context, although black-box testing can also uncover issues such as IDOR. For the background, read our post on what code-aware application security testing is.

Stop comparing dashboards. Compare five things for each model: who tests, what context they have, how a finding is validated, how often testing happens, and what happens after you fix something. The rest of this post does that.

Who each model is best for (up front, no fake balance)

Here is the short version before the detail.

Crowdsourced is best for teams that want broad, opportunistic coverage of a public-facing target and already have triage capacity to sort the reports.

Consultancy portal is best for teams that need a signed report from named testers on a fixed date, usually for a customer, auditor or regulator. It is also the right pick for a novel, high-stakes flow where you want an experienced human reasoning about it live.

Scanner-led is best for teams that want broad, repeatable automated coverage for issues such as known vulnerabilities, common weakness patterns, misconfigurations and exposed services. It is a useful coverage floor, but it is not the same thing as a penetration test.

Autonomous AI is best for teams that want fast, repeatable testing of a live application without waiting for a consultant's calendar, and that can give the tester a target and credentials or let it generate its own user contexts.

Code-aware continuous is best suited to fast-shipping teams with authenticated apps and APIs, particularly where authorisation and business logic are important risks and the application changes regularly.

The categories overlap. Many teams combine models, for example using a human-led test when they need a formal report and continuous testing between scheduled engagements. Picking one does not lock out the other.

The five delivery models: crowdsourced, consultancy portal, scanner-led, autonomous AI, code-aware continuous

1. Crowdsourced. A platform gives a pool of independent testers access to an agreed scope, sometimes with testers working in parallel and compensation based on accepted findings, bounties or time-boxed engagements. Coverage can be broad, but the level and consistency of testing can vary by programme and tester. Testing is often black-box, although the amount of context provided depends on the programme. Many platforms provide triage or validation before findings reach the customer, but the workflow varies by provider. We covered the trade-offs in Bug Bounty Alternatives.

2. Consultancy portal. A traditional pentest firm may put a portal in front of its engagements. A named consultant or small team often tests for a fixed window, using a black-box or grey-box approach with test accounts where appropriate. The humans performing the test typically validate the issues they report, and the engagement commonly produces a formal report. The portal can add live findings and retest requests, although the underlying cadence is often still organised around discrete engagements.

3. Scanner-led. An automated scanner commonly runs on a schedule, sometimes with a layer of human review. Automated scanning is generally strong at identifying known patterns at scale and weaker at contextual business logic. A conventional scanner may not understand, without explicit context and test logic, whether user A should be allowed to see user B's invoice. See Autonomous Pentesting vs Vulnerability Scanning for what each finds.

4. Autonomous AI. An agent plans and runs attacks against a live target without a human driving each step. Context varies a lot by product: many work black-box, some take credentials. Probe validation quality hardest here, because an agent that reports plausible but unproven issues just recreates the scanner noise problem.

5. Code-aware continuous. The tester reads source, maps the attack surface, generates test cases and executes them autonomously, with mechanisms for retesting fixes. Source context can make it easier to investigate authentication, authorisation and business-logic issues that conventional automated scanning may struggle to assess.

Comparison table: who tests, context, validation, cadence, retesting, where findings land

Use this as a checklist for any vendor you talk to. The cells describe the model in general. Individual providers vary, so verify each row in writing.

Two rows deserve extra scrutiny. Finding validation is where models diverge most. Borg's pentest findings carry a confirmation type: Exploited (the attack ran end to end), Partial (evidence the issue is real, without a working exploit) or Static (confirmed by reading source code). Severity says how serious the issue is. Confirmation says how it was established. Ask any vendor for the equivalent. Our post on verified security findings goes deeper.

Human involvement is the row vendors dodge. Ask who actually touched your findings before they reached you.

Requirements to confirm with Borg: signed reports and specialist research

Two requirements deserve a direct conversation before you choose a provider.

You need a signed report from named testers on a fixed date. Some customers, auditors and regulators require a document attributed to a named human, covering a specific window and delivered by a specific date. Confirm the required format, attribution, scope and delivery date with Borg rather than assuming that a findings dashboard satisfies the requirement.

Your riskiest flow is novel and high-stakes. A first-of-its-kind protocol, an unusual settlement flow or a new cryptographic design may justify direct review by an experienced human researcher. Autonomous testing can be useful for recurring security problems, but should not be assumed to provide the same open-ended review. Our post on manual pentest vs AI pentest explores where humans can add value.

Borg offers expert-led Forward Deployed Security and an Enterprise embedded research service. The research service's scope and staffing are not public. Ask Borg whether the proposed engagement meets your specific reporting and specialist-review requirements.

Questions to ask any PTaaS provider before you sign

These work for any vendor in any of the five models. Ask them in the first call.

Who tests, exactly? Get a straight answer on how much is human, how much is automated, and who reviews a finding before it reaches you. Ask for a concrete account of the testing and review process.

What context does the tester get? Source code, API specs, roles, test accounts? A black-box tester can test authorisation behaviour, but without internal context may have less visibility into how the controls are implemented and which paths exist. Ask whether they need test accounts from you or generate their own contexts.

How is a finding proven? Ask for a sample finding with evidence and repro steps. Ask what distinguishes a confirmed exploit from a plausible inference, and whether that distinction is visible per finding.

What is the scope boundary? Full application, a diff, a set of URLs? Borg separates pentests from PR reviews: a pentest assesses the agreed application scope, while a PR review evaluates the relevant code changes before production. Know what each run actually covers. See Full Pentest vs PR Security Review.

How does retesting work? Is it a rerun against the live app, a code-change review, or a manual request? These are different guarantees. At Borg, automatic retests are off by default and require the Borg GitHub App and a linked pull request. When triggered by a merge, they review the merged diff rather than replaying an attack against the running application. Every vendor has details like that. Get them in writing.

Where do findings land? If they do not reach Jira, Linear or GitHub where your engineers already work, remediation can become harder to track.

What are the operational constraints? Egress IPs to allowlist, concurrent run limits, whether you can pause a run. Small constraints become real friction in month three.

Verdict: choose a consultancy portal if, choose code-aware continuous if

Consider a consultancy portal if you need a defined human-led engagement. Confirm whether any provider, including Borg, can meet your specific reporting and specialist-review requirements.

Choose crowdsourced if you have triage capacity, a public target, and want broad opportunistic eyes on it in addition to something more structured.

Choose scanner-led if you want a cost-effective hygiene floor for known vulnerabilities, common weakness patterns and misconfigurations. Do not assume that automated scanning satisfies a requirement for penetration testing; check the wording of the applicable compliance framework, contract or auditor requirement.

Choose autonomous AI if you want repeatable testing of a live application with less dependence on a traditional consultant engagement, and the vendor can show you proof per finding and clearly explain the level of human involvement.

Choose code-aware continuous if you ship authenticated apps and APIs weekly, your expensive bugs live in authorisation, tenant isolation and business logic, and an annual PDF is already stale by the time you read it.

One option is to combine two layers: a human-led test when someone needs paper, and a continuous model for everything between. That is a sensible answer, not a hedge.

Conclusion

Pick the delivery model before you pick the vendor. If your last pentest report is months old and your team has merged substantial changes touching auth, billing and APIs since, consider whether you also need security testing between scheduled reports. Borg runs agentic AI whitebox pentests and reviews PRs, with findings integrated into engineering workflows including Jira, Linear and GitHub, and with retesting available through its documented verification workflows. Book a demo to discuss your application and testing requirements, and ask us the questions from the checklist above. If you specifically require a signed report from a named tester, make that requirement clear when evaluating providers.