"How much for a pentest?" is a fair question. But a URL and a page count don't tell a tester enough to price the work. Five screens might sit in front of customer workspaces, a billing system, several APIs, and a staff console.

This guide doesn't give a universal price range. Without a defined scope and current quotes, that would be guesswork. It explains what changes the effort, what to ask providers, and where a cheap-looking proposal can leave work out.

Ask this first: "How much of the quoted time is hands-on testing, and where do setup, reporting, and the re-test fit?" The total number of days means little without that breakdown.

1. How a provider puts the quote together

A provider estimates the effort for the agreed work, then prices that effort. Ask who's doing it, which assumptions the estimate relies on, and what would change the price.

A fixed fee can suit a stable scope. A time-box buys an agreed amount of work with stated priorities. A large product may need phases. In each case, ask what happens when the time runs out or the product turns out to be larger than described.

Work the quote should account for

  • Scope review and setup: confirming assets, access, architecture, exclusions, rules of engagement, and test data.
  • Hands-on testing: exploring attack surface, roles, workflows, APIs, trust boundaries, and product-specific abuse cases.
  • Validation and evidence: reproducing candidate issues, removing false positives, proving impact safely, and preserving useful evidence.
  • Reporting and communication: writing findings, explaining risk, providing remediation guidance, and escalating urgent results during the test.
  • Re-test and closure: verifying agreed fixes against the original findings and recording a clear outcome.

Confirm whether access troubleshooting, meetings, urgent alerts, and the walkthrough are included. Put re-test terms in writing; don't rely on "we'll take another look" from a sales call.

2. What makes the test take longer

Applications, APIs, and environments

Name the customer app, staff console, APIs and versions, and environments being assessed. Say whether deployments share the same code and controls or need separate checks. Don't count a staging and production copy as equivalent without discussing their differences.

Our web application penetration testing service covers the browser-facing questions; the API penetration testing service explains direct API coverage. The two overlap, but clicking through the browser isn't the same as assessing every agreed API operation.

Roles, tenants, and authorization boundaries

Two roles in one workspace and the same role in two workspaces answer different permission questions. Shared projects, billing users, and staff access add more relationships to assess.

Describe what each role can do and prepare controlled accounts for those relationships. When cross-tenant access is in scope, provide at least two controlled tenants with synthetic records.

Authentication and account lifecycle

List the sign-in methods and account changes your product supports: SSO, MFA, invitations, recovery, email changes, and session revocation. Each has its own rules and setup.

A tester also needs to complete those flows. Confirm access to test mailboxes and approval steps before the window starts, so paid testing time doesn't disappear into login support.

Integrations and trust transitions

Explain where an upload, webhook, payment notification, or linked identity changes something in your app. Following those relationships takes more work than reviewing an isolated endpoint.

Separate your implementation from the provider's platform. Your callback handling may be included while the third party remains excluded. Agree on controlled resources for the parts that will be exercised.

Business workflows and state

A workflow has rules beyond whether one request succeeds. What should a cancelled subscriber retain? Who can approve a refund? When does an invitation stop being valid? Explain these rules and the test data needed to reach each state.

If time is limited, rank the workflows. Name the ones that need depth and the ones that may receive lighter coverage. Put that tradeoff in the proposal.

Coverage references and test depth

The OWASP Web Security Testing Guide, API Security project, and Application Security Verification Standard help describe testing and requirements. A reference to OWASP alone doesn't say how much of your product will be examined. Ask how the provider applies it to the named scope.

Agree on access too: limited-context black-box testing, grey-box testing with accounts and documentation, or source-assisted work with code. These serve different questions and need different preparation.

3. Delivery choices that affect the quote

Environment quality and readiness

Changing builds, broken accounts, and missing test data can consume the window. Ask how delays are handled commercially. Use the SaaS pentest readiness checklist to prepare access and document differences from production.

Reporting and evidence requirements

Tell the provider who needs the report and whether you also need a walkthrough, finding register, or customer-facing summary. Those are delivery commitments, not automatic extras.

Read a complete finding in the sample. Our interactive sample pentest report is synthetic; the report checklist explains what to look for in the evidence and fix guidance.

Urgency and scheduling constraints

Give the date you need the report, not just when you'd like testing to start. A short deadline may change staffing, price, or scope. Ask which one changes, and leave time for fixes if your customer expects a re-test result.

Urgent findings need an agreed alert channel during testing. They shouldn't wait in a draft report until the delivery date.

Re-testing and remediation support

Check the eligible findings, expiry date, included rounds, and output. The result should say fixed, partially fixed, not fixed, or unable to verify, while preserving the original finding.

A re-test verifies agreed repairs. It doesn't automatically assess a new API or a rewritten authentication system.

4. How to compare proposals

Send each provider the same brief. Put their proposals side by side and check the items below. Mark anything missing as an open question, not an assumed inclusion.

Proposal comparison checklist

  • Included assets: named applications, API hosts and versions, interfaces, and environments.
  • Identity coverage: anonymous access, supplied roles, controlled tenants, service accounts, and authentication paths.
  • Priority workflows: the sensitive journeys and trust boundaries that will receive manual attention.
  • Method and depth: how manual analysis, tooling, business-logic work, and safe validation will be combined.
  • Explicit exclusions: infrastructure, clients, third parties, destructive techniques, source review, or anything else not included.
  • Time and assumptions: expected test window, reporting window, access dependencies, release stability, and client responsibilities.
  • Deliverables: report contents, evidence level, urgent alerts, walkthrough, remediation support, and re-test terms.
  • Change process: who can approve a scope change and how its time, price, and delivery impact will be documented.

Ask each provider to write down their assumptions and commitments. "API testing included" leaves a lot open. "Authenticated testing of the documented v2 REST API using two supplied tenant roles, excluding load testing and the third-party payment platform" gives you something specific to review and agree on.

5. Hidden-cost checks and pricing red flags

The surprise is often work you thought was included. Check these points before signing:

  • Reporting sold separately: confirm that the quoted work includes a final report with evidence and remediation guidance.
  • Undefined API coverage: verify whether the API is tested directly, through the web client only, or not at all.
  • One account standing in for every role: confirm how vertical and horizontal authorization boundaries will be evaluated.
  • No allowance for access setup: establish what happens if accounts, documentation, or the environment are not ready.
  • Re-test ambiguity: define eligible findings, availability, rounds, outputs, and expiry before signing.
  • Rush delivery without a coverage tradeoff: ask how a compressed window changes staffing, depth, or prioritisation.
  • Vague "full coverage" language: request named boundaries, assumptions, and exclusions instead of an unlimited promise.
  • Finding-count or security guarantees: no honest provider can promise a particular result or permanent security state before testing.
  • Checklist-only methodology: confirm that testing includes product-specific roles, workflows, and business logic, not only generic automated checks.

A short proposal is fine if it answers the important questions. Move any promises made only on a call into the written agreement.

6. Agree on what happens if the product changes

A new role, API version, or sign-in method can change the work after the quote. Agree who approves scope changes and how time and price will be revised.

When a change arrives, choose explicitly: extend the work, replace a lower-priority area, or assess the new feature separately. Record the decision and tested build in the report. Quietly adding scope doesn't create extra testing time.

7. What to send when requesting a quote

Share what you know and mark the gaps. The web and API pentest scoping guide explains the details; this list is enough to begin:

Inputs to include with your quote request

  1. Objective: the release, risk decision, customer request, or assurance need the test must support.
  2. Dates: preferred test window, report deadline, release date, and expected remediation window.
  3. Applications: hostnames, interfaces, environment, major modules, administrative functions, and explicit exclusions.
  4. APIs: base URLs, versions, protocols, approximate operation groups, specifications, collections, and machine access.
  5. Identities: roles, privilege levels, tenant types, test-account availability, and authentication methods.
  6. Workflows: the sensitive actions, data paths, approvals, state changes, and recent features that matter most.
  7. Integrations: identity, webhooks, storage, payments, uploads, exports, callbacks, and third-party boundaries.
  8. Environment: production differences, release stability, rate limits, monitoring, allowed test data, and safety constraints.
  9. Documentation: architecture notes, role matrix, API schema, test data, known issues, and setup instructions.
  10. Deliverables: report audiences, evidence expectations, urgent communication, walkthrough, remediation support, and re-test needs.
  11. Change control: planned releases, likely scope changes, decision owner, and approval process.

If a blank document is getting in the way, the interactive scope planner gives you prompts and a brief to share. For a team in India, our remote penetration testing page adds time-zone, evidence-handling and reviewer questions to settle before requesting a quote.

8. Make the most of your testing budget

Prevent the delays you can control: working accounts, stable builds, current documentation, safe data, and an available technical contact. If the budget can't cover everything, agree on phases and record what's left out.

Consider your engineering time after delivery as well. A lower quote isn't necessarily a saving if the report leaves your team to reconstruct the evidence or work out what the tester meant.

Related services: Review the penetration testing services overview, then compare the dedicated web application and API penetration testing coverage pages against your product boundary.

Get a quote for your product

Tell us what you're building and when you need the report. We'll work through the web application and API testing scope with you, and explain what's included in the quote.

Request a pentest proposal Draft your scope first