Scoping
What a penetration test costs
Nobody can price a penetration test without knowing what is in it, which is why the figure you want is not on anybody honest page. What can be explained is the list of things that move it - so you can predict your own number, and read a quote well enough to know what is missing from it.
8 min read
Key takeaways
- Price follows scope, not hours on a rate card. The size and complexity of what is tested is the variable that matters, and everything else is secondary.
- The biggest single driver is usually the number of distinct user roles and authentication paths, not the number of pages or endpoints.
- A quote without a retest is not cheaper, it is smaller. Verifying a fix is part of the work, and paying for it separately later costs more.
- Two quotes that differ by a lot are usually not testing the same thing. Compare the scope statements before the totals.
- A supplier who quotes without asking what you built is quoting for a scan, whatever the document calls it.
Why nobody publishes a figure
A penetration test is not a product with a unit price. The same phrase covers a two-day look at a marketing site and a three-week engagement against a payments platform with four user roles, a partner API and an internal network behind it. Any figure that covers both is either so wide it tells you nothing or is quietly attached to the smaller one.
That is the reason a supplier asks questions before quoting, and it is worth knowing what those questions are - our guide to scoping a penetration test lists them. It is also why a published price should make you curious rather than relieved.
What a printed price usually means
Where a supplier does advertise a fixed low figure, it generally buys an automated scan with a report template around it. That is a legitimate product and it is not a penetration test - it finds what a tool recognises and nothing that requires chaining two things together. If the price appeared before anyone asked what you built, that is what is being sold.
What actually moves the number
These are roughly in order of impact. The first two account for most of the variation between two engagements that sound similar on a call.
| Factor | Why it moves the number |
|---|---|
| User roles and auth paths | Every additional role multiplies the authorisation testing, because each one has to be tried against every other one. Two roles is not twice one role, it is the pairs between them. Usually the single biggest driver. |
| Functional surface | Distinct workflows, not page count. Fifty pages of content is small; five pages that move money, upload files and invite users is not. |
| Type of testing | A web application, an API, a mobile client and an internal network are different skills and different time. Combining them in one engagement is usually cheaper than buying them separately because the reconnaissance is shared. |
| Access provided | A black box test spends time discovering what a white box test is told on day one. Giving a tester credentials, documentation and source access buys depth with the same budget. |
| Environment | Testing production carries constraints and care that a staging environment does not. Testing a staging environment that differs from production carries a caveat instead. |
| Retest and reporting | Verifying fixes and producing the report format your auditor wants is real work. If it is not in the quote, it is not free, it is later. |
Day rate against fixed price
Both exist in this market and they distribute risk differently. A day rate means you carry the risk that the work takes longer than estimated. A fixed price means the supplier carries it, and has priced accordingly.
The thing to watch on a day rate is what happens when the days run out mid-engagement, because the answer decides whether you get a finished test or a paused one. The thing to watch on a fixed price is what counts as scope creep, and whether finding more attack surface than expected turns into a change request. We quote fixed on scope and treat surface we did not expect as our problem rather than an invoice, which is stated on the pricing page.
What is often missing from a cheaper quote
Two quotes rarely differ because one supplier is greedy. They differ because they are for different work. These are the items most often absent from the lower one.
- A retest. Without it you have a list of problems and no evidence any of them were fixed, which is the artefact an auditor actually asks for.
- Manual testing of business logic. Automated coverage is cheap; the findings that matter are the ones a tool cannot describe.
- A report in the format you need. If your auditor wants it mapped to a framework, producing that later is a second piece of work.
- Access to the tester. Being able to ask the person who wrote a finding what they meant is worth more than it sounds when your engineer disagrees with it.
- Anything after the report. A test that ends when the PDF arrives leaves the rest of the year uncovered.
How to compare two quotes
Compare the scope statements first and the totals last. If the scope statements are not comparable, the totals are not either, and the cheaper document is usually the one that scoped less.
- Do both name the same systems, the same roles and the same environment?
- Do both say how many days of testing, or does one say only a price?
- Is the retest included in both, and is it hand-verified or a rescan?
- Does either exclude something material - the API behind the app, the admin role, the internal network?
- What does each say happens if more attack surface turns up partway through?
If a quote cannot answer those, that is the answer. And if you want to know what the deliverable looks like before you commit, how to read a penetration test report walks through what you should expect to receive.