Penetration test cost and pricing: 2026 buyer's guide

Penetration test cost is determined by the attack surface, depth of testing, access model and quality of evidence—not by the number of pages in the final PDF. In 2026, a credible quote should tell you what will be tested, how much expert time is allocated, which assumptions affect the price, and what happens after vulnerabilities are fixed.

This guide explains how penetration testing is priced, which scope decisions have the greatest impact and how to compare proposals without buying an automated scan presented as a manual security assessment.

How much does a penetration test cost in 2026?

There is no universal rate for “one pentest”. A small authenticated web application with a single user role is a different engagement from a multi-tenant SaaS platform with REST and GraphQL APIs, mobile clients, payment flows and an administrative back office.

For planning purposes, organisations usually buy one of three models:

• a fixed-price engagement based on a defined scope;
• a time-and-materials assessment with a capped number of tester days;
• a recurring programme that combines scheduled tests, retesting and support for major releases.

The fixed-price model works well when endpoints, roles, environments and exclusions are known. A day-rate model is more suitable for exploratory work, rapidly changing products or a first assessment in which the attack surface is not yet fully inventoried. A recurring programme is valuable when releases happen frequently and a report once a year would become stale within weeks.

Public market prices vary significantly by country, tester seniority and scope. Treat any range as a budgeting aid, never as a substitute for a technical scoping call. Two proposals with the same headline price may contain very different amounts of manual work.

The main factors that determine penetration test pricing

1. Attack surface

The tester must understand every exposed component: domains, APIs, mobile clients, network ranges, cloud services, administrative panels and third-party integrations. A marketing site and a customer portal may share a domain while presenting completely different risk.

Counting URLs is not enough. A single endpoint that accepts a complex document or triggers a financial workflow may require more work than dozens of static pages. For APIs, provide an OpenAPI specification, GraphQL schema or endpoint inventory. For mobile assessments, include both the application package and the backend services it calls.

2. Roles and authorisation boundaries

Authorisation testing grows with the number of meaningful roles and tenants. A platform with customer, manager, support, finance and administrator roles requires horizontal and vertical access-control testing across many combinations.

Multi-tenant isolation is particularly important. The tester needs at least two independent organisations and accounts to determine whether identifiers, exports, search, attachments and background jobs leak information across boundaries.

3. Test depth

A vulnerability scan identifies known patterns and exposed versions. A penetration test validates exploitability, chains weaknesses and examines business logic. A source-assisted review goes deeper by allowing the tester to inspect sensitive flows, configuration and control implementation.

Ask whether the quote includes manual authorisation tests, abuse cases, rate-limit assessment, session handling, file processing, integrations and business logic. A cheap engagement may exclude exactly the areas where damaging issues are found.

4. Access model

Black-box testing provides only public information and ordinary user access. Grey-box testing adds documentation and test accounts. White-box testing may include architecture, configuration and source code.

More information does not make the test easier in a way that reduces its value. It allows the tester to spend less time discovering the obvious and more time validating meaningful controls. For most product assessments, a grey-box approach gives the best balance of realism and coverage.

5. Environment and operational constraints

Production testing may require conservative payloads, maintenance windows and constant coordination. A staging environment is safer only if it accurately reflects production authentication, configuration and integrations. If it contains mocked controls, the result can provide false confidence.

Emergency availability, travel, on-site requirements, unusual equipment or testing outside normal hours can affect the quote. These conditions should be discussed before work starts.

6. Reporting and retesting

A useful report includes evidence, affected assets, reproduction steps, impact, likelihood, remediation guidance and prioritisation. Management needs a concise risk summary; engineers need enough detail to reproduce and fix each issue safely.

Retesting should be explicitly included or priced. It confirms that the root cause—not only the demonstrated payload—was removed and that the fix did not create a regression.

Typical penetration testing scopes

Web application pentest

The scope normally includes authentication, session management, access control, input handling, file uploads, business logic, server-side requests and security configuration. The number of workflows and roles matters more than the number of screens.

API penetration test

REST, GraphQL and OAuth assessments focus on object-level and function-level authorisation, mass assignment, token validation, query complexity, rate limiting and business logic. Our API penetration testing checklist describes the coverage in detail.

Mobile application pentest

An Android or iOS test combines client analysis, local storage, platform controls, transport security, reverse engineering and backend APIs. Testing only the APK or IPA without its API leaves a major part of the attack surface unassessed. See the mobile application penetration testing guide.

Internal infrastructure and Active Directory

Internal testing examines segmentation, identity, shared credentials, service accounts, lateral movement and privilege escalation. The number of hosts is relevant, but architecture and identity complexity have a greater impact. Read more about Active Directory attack paths.

Cloud security assessment

A cloud engagement may cover IAM, public exposure, secrets, storage, logging, network paths and CI/CD identities. The price depends on the number of accounts, subscriptions, regions and services, and on whether configuration review is included. Our overview of common cloud security mistakes can help with pre-assessment preparation.

What a professional quote should include

A strong proposal should state:

• the applications, APIs, domains, ranges and environments in scope;
• roles, tenants and test accounts to be provided;
• testing approach and referenced methodologies;
• assumptions, exclusions and prohibited actions;
• planned duration and approximate expert effort;
• communication and escalation rules;
• report language and expected deliverables;
• whether a remediation workshop and retest are included;
• validity period of the result;
• how sensitive test data and evidence will be protected.

References such as the OWASP Web Security Testing Guide, NIST SP 800-115 and PTES are useful, but a methodology name alone does not prove coverage. The proposal must connect the method to your actual architecture and risks.

How to compare penetration test proposals

Create a comparison table instead of ranking quotes by total price. Include tester days, manual coverage, roles, environment, source access, reporting, retest, exclusions and tester qualifications.

Ask each supplier the same questions:

1. How many expert days are allocated to testing and reporting?
2. Which parts are automated and which are tested manually?
3. Are authorisation and business-logic abuse cases included?
4. Who will perform the work and what relevant experience do they have?
5. Will we receive reproduction steps and a technical remediation discussion?
6. Is retesting included, and how many rounds?
7. What can cause a change request or additional charge?

If the supplier cannot explain the scope in plain language, the report is unlikely to resolve the ambiguity later.

Warning signs of an unrealistically cheap pentest

Low cost is not automatically a problem. A focused assessment can be both economical and valuable. The warning signs are different:

• no scoping questions before the quote;
• an unlimited application described as a single fixed package;
• delivery within a few hours;
• no named tester or experience profile;
• only automated scanner output;
• no business-logic or authorisation testing;
• no evidence, remediation guidance or retest;
• a “certificate” offered regardless of findings.

Automated scanning is useful in a vulnerability-management programme, but it is not equivalent to adversarial manual testing. The distinction is explained in our article on vulnerability management.

How to reduce cost without reducing security value

Good preparation prevents testers from spending paid time on missing accounts, unstable builds and undocumented endpoints. Before the engagement:

• freeze the tested version or communicate planned releases;
• provide an asset and endpoint inventory;
• prepare accounts for every role and at least two tenants;
• make logs and a technical contact available;
• remove known critical defects that would block deeper testing;
• agree safe test data and prohibited operations;
• explain the highest-risk business workflows.

Use our penetration test preparation checklist to organise the evidence and access. Do not shrink the scope by removing critical functions simply to meet a budget. It is safer to split the work into risk-based phases and document what remains untested.

Penetration test cost as a risk decision

The cheapest report is expensive if it misses tenant isolation, account takeover or a payment-logic flaw. Conversely, the largest possible engagement is not always justified for a low-impact system. Price should follow risk, scope and the confidence required for a business decision.

A good outcome is not a long vulnerability list. It is a defensible answer to three questions: what an attacker can achieve, why the controls failed and which fixes reduce the most risk first. If you need a scope and transparent quote, contact Breachroad with your architecture, roles and target date.