What does a penetration test cost? A breakdown of what drives the price

It is the first question almost every buyer asks, and the one most testing firms are strangely reluctant to answer. Some of that reluctance is commercial. Most of it is structural: a penetration test is a fixed quantity of skilled human time pointed at a target, and until someone understands the target, nobody can say how much time it will take.

That said, “it depends” is not an answer. What follows is what it actually depends on, so you can predict roughly where your engagement will land before you ever request a quote.

Price is a function of tester-days

Almost every legitimate penetration test is priced the same way underneath: number of tester-days × day rate, plus a fixed allowance for reporting. Everything else in this article is really a discussion of what pushes the day count up or down.

Day rates vary considerably by region, by the seniority of the person actually doing the work, and by whether you are buying from a boutique or a large firm with a sales layer to fund. But the day count is the part you can influence, and it is the part that most buyers never think to interrogate.

As a rough calibration: a tightly scoped test of a single web application typically runs somewhere in the range of five to ten tester-days. An external perimeter test of a modest estate is often shorter. A full red team engagement is measured in weeks, not days. If a quote implies two days for something that should take eight, the difference is not efficiency — it is coverage you are not getting.

The five variables that move the number

1. Scope size

The obvious one, but it is measured less obviously than people expect. For a web application, the meaningful unit is not pages — it is distinct functionality and distinct user roles. An application with fifty near-identical CRUD screens and one role is smaller than an application with eight screens and five roles, because every role boundary multiplies the authorization testing surface.

For infrastructure, the unit is live hosts and exposed services, not IP ranges. A /24 with six live hosts is a small engagement.

2. Depth and methodology

A test that runs tooling and validates the output is a fundamentally cheaper product than one where a tester manually works through business logic, chains findings and attempts to reach real impact. Both get called a penetration test. Only one of them finds the flaws that matter.

3. Testing model

Black box costs more for less coverage. Every hour a tester spends rediscovering your architecture from the outside is an hour not spent testing it. Grey box — where you supply credentials for each role, plus basic documentation — is nearly always the better value, and it is what most experienced buyers ask for by default.

White box, with source access, costs more per day but finds the deepest issues. It is worth it for high-assurance targets and rarely worth it for a marketing site.

4. Retesting

Check whether remediation retesting is included or billed separately. A test that finds problems and never verifies the fixes is half a service, and firms differ enormously here. Some include a retest window of thirty to ninety days; some charge a fresh engagement fee.

5. Reporting and evidence requirements

If you need a report that will satisfy a SOC 2 auditor, an enterprise client’s vendor security review or a cyber insurance questionnaire, say so upfront. Producing attestable, evidence-backed documentation takes real time. It is not a formatting exercise.

Why the cheapest quote is usually the most expensive

The failure mode is not that a cheap test finds nothing. It is that a cheap test finds a plausible-looking list of medium-severity issues, you remediate them, you feel covered, and the thing that actually gets you breached was never in scope to begin with.

Some signals that a quote is cheap because the work is thin:

• A fixed price offered before anyone asked what you are running.
• No named methodology, or a vague gesture at “industry standards” without specifying OWASP, PTES, NIST or equivalent.
• No sample report available, even redacted.
• Turnaround measured in hours. Real testing does not work that way.
• Findings that will be delivered as raw scanner output with severities untouched.

Questions worth asking every vendor

• How many tester-days are allocated, and how are they split between testing and reporting?
• Who is doing the work, and what are their certifications and experience?
• What proportion of the test is manual?
• Is remediation retesting included, and for how long?
• Can I see a redacted sample report before committing?
• What happens if you find a critical issue mid-engagement — is there a defined escalation path?

The sample report question is the highest-signal one on that list. A report shows you exactly what you are buying: whether findings are reproduced with real evidence, whether remediation guidance is specific to your stack or copied from a template, and whether anyone thought about business impact at all.

How to spend less without buying less

Three genuinely effective levers, in order of impact:

• Scope precisely. Test the payment flow, the authentication stack and the admin surface properly rather than testing everything shallowly. Breadth is what you sacrifice first, not depth.
• Provide credentials and documentation. Grey box buys you more coverage per day than black box, every time.
• Run a scan first, then test. Clear the known and the trivially patchable with a vulnerability assessment, then point expensive human hours at what tooling cannot reach.

What does not work is compressing the timeline. Asking for the same scope in half the days does not buy a faster test; it buys a shallower one, and you will not be able to tell the difference from the report.