What Actually Drives Penetration Testing Pricing (And Why There's No Industry-Wide Framework)

Why There’s No Standard Pentest Price List

I get some version of this question on nearly every discovery call: “We got quotes from three vendors and they’re nowhere near each other, how do we know who’s right?”

It’s a fair question, and the honest answer isn’t that someone’s padding their margin or someone else is cutting corners, though sometimes that’s true. More often, the spread exists because a pentest quote isn’t a price for a standardized unit of work. It’s a proxy for a set of scope decisions that never line up the same way twice across vendors, or even across two engagements from the same vendor.

There’s no industry-wide rate card because there’s no industry-wide definition of what “a pentest” includes. Ask ten firms to quote a web application test and you’ll get ten different assumptions baked into the number: how many user roles get tested, whether authenticated and unauthenticated paths are both in scope, whether the API is tested as its own surface or folded into the app, how many retests are included, and what the final report actually looks like when it lands in your inbox.

That’s not vendors being evasive. It’s the nature of the service. A pentest is closer to a consulting engagement than a commodity purchase, and the price reflects the shape of the work, not a fixed catalog item. Buyers who go in expecting a rate card end up comparing numbers instead of comparing what those numbers actually buy. I want to walk through the four variables that move the number more than anything else, scope type, environment size, testing depth, and what happens after the report is delivered, so you can interrogate any quote you receive instead of guessing at whether it’s fair.

Scope Type Sets the Baseline

The first variable is what’s actually being tested, and it matters more than most buyers expect going in. Web application, internal network, external network, mobile application, cloud infrastructure, these aren’t interchangeable line items with a shared hourly rate. Each one requires different tooling, different methodology, and a different amount of manual analysis to do properly.

A web application penetration test involves manually walking through business logic, authentication flows, session handling, and access controls, often role by role. A cloud infrastructure test means assessing IAM configurations, storage permissions, network segmentation, and misconfigurations across a provider’s control plane, work that looks nothing like testing a network of on-prem servers.

An internal network test is often where the real surprises live, unmanaged devices that never make it onto anyone’s radar as a risk until someone actually looks. Our case study on two internal network engagements walks through exactly that: a leased printer and a data centre UPS, both still running factory default credentials, both invisible to anyone who hadn’t gone looking at the unmanaged edges of the network.

Scope type determines the skill set and time commitment required, and I price accordingly. A quote for a web app test and a quote for a network test are not directly comparable numbers even if they arrive in the same dollar range. They’re answering different questions about your environment.

Environment Size Multiplies the Estimate

Once scope type is set, the next lever is how much of that scope actually exists. This is where buyers most often underestimate what they’re asking for. The number of in-scope IP addresses, endpoints, API routes, or distinct user roles doesn’t just nudge the price, it multiplies it, because manual testing time scales with surface area, and manual time is the actual product being priced.

A web app with a single user role and a handful of core workflows is a fundamentally different engagement than the same app with five role tiers, each with different permission boundaries that need to be individually tested for privilege escalation. A network with 50 live hosts is a different job than one with 500. This is also where automated tooling and manual testing diverge most sharply. A scanner can sweep a large IP range quickly. A tester manually verifying that a finding is real, chaining it with another weakness, and confirming actual business impact cannot compress that time the same way. Manual testing is slower by design, because it’s answering “can this be exploited” rather than “does this look like a known signature.”

When you get a quote, the environment size assumptions behind it should be explicit. If a vendor hasn’t asked how many IPs, endpoints, or roles are in scope before quoting, that’s worth noticing. A number produced without that conversation is a guess, not an estimate.

Depth of Testing: Vulnerability Assessment vs. Full Manual Pentest

This is the variable that moves price by an order of magnitude, and it’s also the one most frequently blurred in sales conversations. A vulnerability assessment and a full manual penetration test are not two tiers of the same service. They answer different questions, and pricing them as if they’re interchangeable is where a lot of buyer confusion starts.

A vulnerability assessment is largely automated: scanning tools identify known weaknesses, flag missing patches, and surface misconfigurations against a database of signatures. It’s fast, it’s useful for a baseline, and it has a real place in a security program. But it tells you what might be wrong, not what an attacker could actually do with it. A full manual pentest goes further: a tester actively attempts to exploit findings, chain them together, escalate privileges, and demonstrate real business impact, the same way an actual adversary would approach your environment. The difference between penetration testing and vulnerability scanning isn’t a matter of degree, it’s a difference in the question being answered.

Methodology matters here as a baseline for what “full depth” even means. My approach is grounded in the Penetration Testing Execution Standard (PTES), and for web and SaaS engagements, the OWASP Testing Guide (OTG v4.2). Those frameworks exist precisely because “pentest” has no universal definition otherwise, they establish what a thorough engagement actually covers, from reconnaissance through exploitation to reporting. When you’re comparing quotes, ask each vendor what methodology they follow and whether the engagement is a VA relabeled as a pentest, or the real thing. If a number looks unusually low relative to others quoting the same scope, this is often why.

What’s Included After the Test: Report Quality and Retesting

A pentest doesn’t end when the testing stops. It ends when the vulnerabilities found are actually fixed and verified, and that closing step is where a surprising number of engagements quietly fall short. Buyers evaluating quotes tend to focus entirely on the testing phase and treat everything after as an afterthought. It shouldn’t be. What happens after the test is part of what you’re paying for, not a bonus.

Two things matter here: the report itself, and the retesting terms. A report that lists findings with CVSS scores and no narrative context is not the same deliverable as a board-ready report that explains business impact in language a non-technical stakeholder can act on. If a report can’t be understood by the people who need to prioritize remediation, its value drops regardless of how good the testing behind it was. This is also a place where buyers don’t have to take a vendor’s word for it. EliteSec makes sample reports available across web application, internal network, and Gamified TTX engagements specifically so prospects can evaluate deliverable quality before signing anything. Any vendor should be willing to show you a redacted sample. If they won’t, ask why.

Retesting is the other half. Finding a vulnerability and confirming it’s actually fixed are two different services, and a lot of vendors quietly stop delivering after the first report lands, leaving remediation verification as an unbilled afterthought or a separate paid engagement. Every engagement I run includes five free retests over twelve months, because retesting is where the value of a pentest either gets realized or gets lost. If a quote doesn’t specify retesting terms, ask directly: how many retests are included, over what period, and what happens if a fix doesn’t hold up the first time.

Certifications and Accreditation as a Proxy for Rigor

Certifications get dismissed sometimes as marketing badges, but for buyers evaluating a quote, they’re one of the few externally verifiable signals of process rigor available before you’ve worked with a firm. A much cheaper quote is often cheaper because it skips the overhead that these credentials represent, not because the vendor found a more efficient way to deliver the same rigor.

CREST accreditation, for example, requires demonstrated methodology, quality controls, and tester competency that are independently assessed, not self-declared. CREST accreditation exists because the industry needed a way to verify that a firm’s process holds up to scrutiny, not just its sales pitch. Company-level certifications like ISO 27001:2022 signal that the vendor’s own information security management practices meet an audited standard, which matters given that you’re handing a pentest firm access to your systems and findings. Individual certifications on the testing team, CISSP, CISM, OSCP, OSWP, indicate hands-on, verified skill. OSCP in particular requires passing a 24-hour practical exam built around real exploitation, not a multiple-choice test.

None of this means the cheapest quote is automatically the wrong choice or the most certified vendor automatically the best fit. But when you see a wide price gap for what looks like the same scope, checking which certifications and accreditations sit behind each quote will usually explain a meaningful part of the difference.

Who’s Actually Doing the Work

One more factor rarely shows up on a scope document but shows up clearly in the findings: who’s actually running the engagement. A test staffed by whoever’s available that week produces different results than one led by a named, accountable senior tester who has personally run the methodology dozens of times before. This isn’t about pedigree for its own sake, it’s the difference between a tester following a checklist and a tester who knows where organizations tend to hide risk, the printer nobody thought to patch, the UPS still on factory credentials, the role permission that was supposed to be temporary and never got revoked.

Founder-led or senior-led delivery tends to cost more because that level of attention doesn’t scale the way junior staffing does. It’s worth asking directly in any vendor conversation: who is actually running this engagement, and what’s their direct experience with this scope type. The answer tells you as much about the quote as the number does.

A Checklist for Evaluating Any Quote You Receive

Before comparing dollar figures across vendors, run every quote through the same set of questions:

• Scope type: Is this web app, network, mobile, cloud, or a combination? Are the boundaries of what’s in and out of scope written down explicitly?
• Environment size: How many IPs, endpoints, API routes, or user roles did the vendor account for when producing this number? Did they ask, or did they guess?
• Testing depth: Is this a vulnerability assessment, a full manual pentest, or something blended? What methodology does the vendor follow, and can they name it?
• Report quality: Will you receive a sample report before signing? Does the deliverable translate findings into language your leadership and auditors can actually use?
• Retesting terms: How many retests are included, over what timeframe, and what happens if a remediation doesn’t hold?
• Certifications and accreditation: What does the vendor hold at the company level and the individual tester level, and can they explain what each one actually verifies?
• Who leads the engagement: Is there a named, accountable senior person running this, or is staffing assigned based on availability?

A vendor who can answer all seven without hesitation is quoting from a real process. A vendor who gets vague past the first two questions is quoting from a template.

The Bottom Line

The fastest way to make vendor comparisons make sense is to walk into those conversations already clear on your own scope, rather than letting each vendor define it differently for you. EliteSec’s free Pentest Readiness Assessment is built for exactly this: seven questions that produce a scorecard and tier rating so you know what you’re actually asking for before a vendor quotes it.

The next quote you get won’t come with a rate card attached, and it shouldn’t. But now you know exactly what to ask before you decide what it’s worth.

If you want to see what a full-depth engagement actually produces, EliteSec’s sample reports across our services are available on request, no obligation attached.