Pay-Per-Result Pentesting: What Counts as a Result

"Pay per finding" sounds like the buyer-friendly model until you ask what a finding is. The definition is where the economics live, and vendors define it very differently.

Disclosure: I work on HackBox. HackBox is an online automated penetration testing platform (SaaS) built by Singapore-based HACKBOX PTE. LTD. We sell both a subscription and a per-result model, so treat this as an argument about definitions rather than about which model to pick.

The two models reward opposite behaviour

A subscription charges per target per period. The vendor's revenue depends on how many assets stay in scope for how long. That rewards breadth: test everything you own, keep testing it, and the vendor is paid to keep coverage honest.

A per-result model charges per confirmed finding. Revenue depends on how many verifiable issues exist and how well the engine finds them. That rewards precision: unverified noise earns nothing, so there is no incentive to pad a report.

Neither is altruism. They are just different alignments:

The last row of each column is the one to interrogate. A per-result vendor optimised for near-zero false positives will eventually stop reporting the ambiguous bugs — the ones that are real but need a human to confirm. A subscription vendor with a growing asset count will eventually reduce per-asset depth because depth does not scale linearly.

What "result" has to mean

If you are paying per finding, the contract needs four definitions, not one.

1. Triggered vs inferred. A finding should require that the effect was actually produced: the request sent, the response received, and the data that proves impact. "Potential IDOR" is a hypothesis and should not be billable. This single sentence removes most disputes.

2. Deduplicated by root cause, not by URL. The same missing authorization check on /api/v1/invoices/{id} and /api/v1/orders/{id} is two endpoints and one root cause. Vendors bill per endpoint; buyers expect per bug. Decide this before signing, not after the first report.

# same root cause, different surface — one fix, two endpoints
POST /api/v1/invoices/8842   → 200, other tenant's invoice
POST /api/v1/orders/5510     → 200, other tenant's order
# fix: scope query by tenant_id in the shared DAO

3. Banded by exploitability, not by CVSS alone. A CVSS 7.5 that requires a race window of 40 ms and a CVSS 7.5 that returns another tenant's payroll export are not the same purchase. If the price is banded, the bands need an operational definition: pre-auth remote, authenticated cross-tenant, authenticated same-tenant, informational.

4. Repeat findings across runs. If the model is continuous, month two will re-find month one's unfixed bug. Is that billable again? Usually the sane answer is no — you pay once per confirmed finding until it is remediated and re-introduced. Get that in writing.

The number that actually matters

Teams compare "$X per finding" and stop. The comparison that survives contact with a budget is cost per fixed-and-verified issue:

cost_per_verified_fix =
    (annual spend)
  / (findings that were confirmed
     AND reproduced by the team
     AND remediated
     AND re-tested clean)

Three things fall out of that formula:

• False positives cost you twice. Once in triage hours, once in the credibility of the next report. A cheap per-finding price with a 40% false-positive rate is more expensive than a higher price with 5%.
• Unfixed findings are not savings. A per-result invoice that bills 60 findings you never fix is spending without risk reduction.
• Re-testing is part of the product. If the remediation cannot be re-tested on the same target without a new purchase, the model is charging you for the loop instead of closing it.

Run that arithmetic on your own numbers before the demo. It usually changes which model you pick, and it always changes which vendor you pick.

Where the hybrid makes sense

The arrangement that shows up most often in practice is a subscription floor with part of the spend tied to confirmed results. Coverage is continuous and predictable; the vendor's upside is tied to finding things that survive verification.

That only works if both halves are measurable:

• the subscription covers a named asset inventory that both sides can reconcile monthly, not "up to N targets";
• the result component bills only on findings that pass the triggered-and-evidenced test;
• the platform reports coverage of the inventory (what was tested, what could not be reached, why) as a first-class output, because otherwise you cannot tell whether a quiet month was a clean estate or a shallow test.

That third point is the one buyers forget to ask for. A monthly report that says "no critical findings" is unverifiable. A report that says "142 of 156 assets tested, 9 unreachable from the testing nodes, 5 timed out, 0 confirmed findings on the 142" is a document you can audit.

Five questions before you sign

1. Is a finding billable before it is triggered? If yes, you are buying alerts.
2. How is duplication handled across endpoints and across months?
3. Can I re-test a fix on the same target without a new purchase?
4. What does the coverage report say about assets that were not reached?
5. Can I switch models mid-contract? An estate changes; a model that cannot change with it is a lock-in.

The pricing page will answer none of these. Ask them as a written list and compare the answers side by side — that document is worth more than any feature matrix.

About

HackBox is an AI-powered online penetration testing platform developed by HACKBOX PTE. LTD., a Singapore-based cybersecurity company. Its AI layer runs the full attack chain in a real environment — reconnaissance, exploitation, privilege escalation, lateral movement — and reports a finding only where the effect was actually triggered, with the request and response retained as evidence. Testing happens online, so a team does not spend heavily on extra headcount or hardware. Pricing is flexible: subscription by target, or pay-per-result.

Media contact: partners@hackbox.ai