How we scope in under two minutes

The traditional way to price a pentest looks like this. You fill in a contact form. Someone from sales replies within two business days to schedule a 30-minute discovery call. On the call they ask about your stack, your compliance drivers, and the vague shape of what you want tested. They send you a scoping spreadsheet with 40 fields. You fill it in with the help of an engineer whose calendar you have to steal an hour of. They come back with follow-up questions. Two more emails. Finally, on day 17, you get a PDF quote — usually a range, usually with an asterisk that says the price will be finalised after a "detailed scoping workshop."

This is bad for everyone. It is bad for the buyer, who is spending organisational time on procurement instead of security. It is bad for the seller, whose senior engineers are stuck in scoping calls instead of actually testing anything. And it is bad for the industry, because it creates the impression that penetration testing is a bespoke consulting engagement rather than a well-understood repeatable service.

We spent about eight months looking at every quote we had ever written and asking a boring question: what actually drove the price? Not what did we say drove the price, but what — statistically — correlated with the number at the bottom. The answer was, roughly, four things.

The four things that actually drive pentest price

Asset count and type. A single-tenant B2B web app takes different work from a multi-tenant SaaS with mobile clients. A cloud environment with three AWS accounts takes different work from one with 47. Almost all pricing variation comes from how many things there are to test and what kind of things they are.

Size and complexity. A web app with 20 endpoints is not the same as one with 800. An API with a single authentication scheme is not the same as one with SAML plus OAuth plus API keys. We approximate this with a small number of buckets — S, M, L, XL — that a customer can pick from a menu with concrete anchors ("fewer than 50 endpoints" is S, "several hundred, multi-tenant" is L). This is not perfect. It does not need to be perfect. It needs to be within 15% of the correct number, which it is.

Authentication depth. Whether an app has multiple roles that need to be tested against each other is a huge multiplier. Testing a single-user app is one test. Testing a role matrix of admin/manager/user/guest against every resource is a combinatorial explosion of tests. We ask a single question: how many meaningfully different roles does the app support? One is easy. Two is medium. Four or more is a Large.

Compliance driver. SOC 2, ISO 27001, PCI DSS, and HIPAA all require slightly different framings of the same underlying work. The testing is largely the same; the report and the evidence packs differ. This adds a fixed increment, not a multiplier.

That is it. That is the entire rubric. When we plotted our historical quotes against these four inputs, they explained more than 90% of the price variance we had ever quoted. Everything else was noise — sales-cycle-length noise, deal-desk-approval noise, discount-strategy noise — none of which is relevant to what the actual work costs.

The form

Once we knew what actually mattered, the form was obvious. Four questions. A live price that updates as you answer. A locked-in start window on the last screen. No sales call required — unless the customer wants one, in which case there is a button for that too.

The math is boring on purpose. Base price per asset type, multiplied by size bucket, multiplied by auth depth, plus the compliance increment. If you were a customer, you could reconstruct our pricing rubric from ten quotes and a spreadsheet. That is the point. We would rather be legible than clever.

Why other firms don't do this

The obvious question is why nobody else in the space prices this way. Some do — a handful of newer firms have similar instant-quote flows — but the majority still route everything through a sales team. There are two honest reasons.

First, it is genuinely more work up front. You have to actually build the pricing rubric, defend it internally, and be disciplined about not adding "exception" pricing when a senior AE wants to close a big deal at a strange number. It took us longer to design the pricing form than it did to build any single feature in our testing platform.

Second, opaque pricing is a margin lever. When customers do not know what a fair price is, some of them pay more than they should. Instant, published pricing gives up that lever. We made the calculation that we would rather have a hundred customers who felt they got a straight deal than fifty who felt they got hustled — and, so far, that math has worked out.

If you want to see the rubric in action, our order form is at /order. It takes about the amount of time it takes to make coffee.