Cost guide

What determines the cost of a penetration test?

Penetration-test cost is driven by the breadth and complexity of the authorized work. The systems, environments, roles, tenant boundaries, workflows, APIs, integrations, access conditions, operating restrictions, reporting needs, and retest path all matter. Commercial terms are determined after the buyer’s requirement and likely scope have been reviewed.

A broader engagement costs more because more work must be planned, performed, validated, and reported—not because it buys a better testing standard. Two proposals are comparable only when they describe substantially the same job.

Primary references: CREST Penetration Testing Guide, NIST SP 800-115, OWASP testing guidance

Published by Trespass Security

The first misconception

“One application” is not a unit of work.

An application can be a small public surface or a collection of customer, administrator, support, API, identity, and integration paths.

The useful question is not how many product names appear in the request. It is how much authorized behavior the tester must understand and exercise.

Two companies can both request “one web application pentest” while asking for completely different amounts of work.

What creates the work

The total is built from scope, depth, access, and delivery.

Asset counts matter, but they are only useful when paired with what each asset does, who can use it, how it connects to the rest of the system, and what the requester expects to receive.

Systems and environments
Applications, APIs, administrative interfaces, network paths, cloud components, staging systems, and production systems create different targets and boundaries.
Roles and tenant models
Each user type, privilege level, organization boundary, support path, and administrative function may introduce behavior that must be tested separately.
Workflows and business logic
Registration, approvals, payments, file handling, account recovery, data exports, and other sensitive workflows require more than counting pages or endpoints.
APIs and integrations
Documented endpoints, authentication methods, identity providers, mobile clients, and connected services affect coverage and authorization.
Access and readiness
Working accounts, documentation, allowlisting, remote access, representative data states, and available technical contacts keep the approved work reachable.
Operating constraints
Production restrictions, narrow testing windows, off-hours requirements, sensitive actions, multiple locations, and third-party permissions change how the work must be performed.
Evidence and follow-through
Report audiences, required documentation, live review, remediation questions, and the agreed retest path are part of the engagement—not an afterthought.

A simple comparison

Same application count. Different engagement.

Scroll horizontally to read all columns →

Illustrative requests using no client data
Decision	Request A	Request B
Target	One web application with a documented API.	One web application, an administrative interface, and supporting APIs.
Access	Two ready user roles in a test environment.	Six roles across multiple tenant types, with SSO and support access.
Workflows	Core account and data-management paths.	Approvals, billing, file handling, exports, and privileged operations.
Constraints	Stable environment and agreed weekday window.	Production-only paths, narrow windows, and prohibited data-changing actions.
Evidence	Standard report, findings review, and agreed retest.	Additional audience needs, evidence mapping, and coordinated review participants.

The label at the top of both requests is the same. The systems, paths, constraints, and delivery work underneath it are not.

Not a quality ladder

A narrower scope should not mean a lower testing standard.

Scope changes how much work is included. It should not create tiered versions of whether the work is controlled, investigated, and documented properly.

Defined authorization
The permitted systems, actions, timing, contacts, evidence handling, and stop conditions are written down.
Human investigation
Potential findings are examined in context rather than passed through as raw tool output.
Useful reporting
The report states the scope, work performed, findings, evidence, limitations, risk, and practical remediation direction.
A path through the findings
The buyer can review the results, ask engagement questions, and understand the agreed remediation-retest process.

Faster clarity

The best way to reduce uncertainty is to expose it early.

Do not spend a week inventing precise asset counts you cannot defend. Send what the requester said, what your team knows, and where the boundaries are still unclear.

A capable provider should turn that context into targeted scoping questions instead of sending you back to design the engagement alone.

Send enough for a useful proposal

You do not need a finished scope. These details help the provider identify the remaining decisions.

Who requested the test and what evidence do they expect?
Which applications, APIs, environments, networks, or other systems may be involved?
Which user roles, privilege levels, and tenant types matter?
Which sensitive workflows, integrations, and administrative paths are likely included?
What access, accounts, documentation, and environments can your team provide?
Which third parties, production restrictions, locations, or testing windows affect the work?
What is the hard deadline, and what must exist by that date?
What report audience, review, remediation, and retest expectations are already known?

Compare the same job

When two proposals are far apart, compare the assumptions before the totals.

A lower total may cover less work. A higher total may include work the requester never asked for. Neither conclusion can be made from the number alone.

Are the same systems, environments, interfaces, and locations included?
Are the same roles, tenant boundaries, workflows, and integrations covered?
Do both proposals make the same access and readiness assumptions?
Are testing restrictions, excluded activities, and third-party boundaries equally clear?
Do the reports contain comparable evidence, limitations, and remediation direction?
Are findings review and retesting handled the same way?
Do both schedules reach the same external evidence deadline?

After approval

Changes to the job can change the commercial terms.

New assets, unavailable prerequisites, broken access, added roles, changed environments, different testing windows, newly required locations, or additional retest work can alter the engagement after the original proposal.

Make the assumptions visible before approval. When something changes, update the scope, schedule, and commercial terms together so the team does not keep working from an obsolete plan.

The expensive surprise is usually not a line in the proposal. It is discovering later that an important system, role, or deliverable was never included.

Next step

Bring the requirement. We’ll help define the work.

Send who asked, which systems may be involved, what evidence they expect, and the deadline. We will identify the decisions needed before commercial terms can be proposed.

Get a pentest