How to scope a web & API pentest without buying the wrong test

The quality of a penetration test is constrained before testing begins. If the brief says “test our website” but omits the administrative portal, authenticated API, user roles, and tenant model, a vendor can produce a technically correct report while missing the paths that matter most. A better brief makes coverage, assumptions, and exclusions explicit enough that two proposals can be compared on the same basis.

1. Start with the decision the test must support

Write down why the assessment is happening. A pre-release test, enterprise procurement request, annual assurance exercise, and investigation of a risky new integration may involve the same application but require different emphasis and deadlines.

State the decision the report needs to unlock: approve a release, answer a customer questionnaire, prioritise remediation, or provide current security evidence. Include the date the final report is needed and whether a remediation window must fit before it. If a customer or auditor supplied requirements, share the exact wording rather than asking the tester to infer it.

A pentest can provide evidence about a defined system during a defined period. It cannot certify that a product is permanently secure or guarantee that another party will accept the report. Keeping that distinction clear produces a more credible statement of work.

2. Map the complete product boundary

Begin with every first-party component that participates in the user journey. Record production and test hostnames, customer and staff portals, API base URLs, file stores, authentication domains, callback endpoints, and any separate legacy or regional deployments. Identify which are included, excluded, or present only to explain architecture.

Then describe relationships. Does the browser call one API or several services? Is an administrative console reachable from the public internet? Can users upload files that another service processes? Do customer-controlled values appear in emails, exports, invoices, support tools, or webhooks? These transitions often matter more than the number of pages.

Third-party services need precise treatment. A payment provider or identity platform may be out of scope, while your configuration, callback handling, token storage, and application-side authorization remain testable. Obtain approval before including infrastructure you do not own, and record constraints in the rules of engagement.

3. List identities, roles, tenants, and trust boundaries

Authenticated coverage cannot be estimated from endpoint count alone. Provide a role matrix: anonymous visitor, invited user, standard member, manager, billing contact, tenant administrator, support operator, and any machine identities that can call the API. Use the names your product uses and explain what each role should be able to read, create, change, approve, export, or delete.

For multi-tenant products, prepare at least two controlled test tenants so horizontal access can be checked without touching customer data. Where hierarchy matters, include separate teams, projects, or organisations and describe inheritance rules. Also flag workflows that change privilege or ownership, such as invitations, account recovery, domain claiming, user removal, role changes, and resource transfer.

Supply dedicated accounts for each meaningful role rather than expecting the tester to repeatedly mutate one account. If single sign-on, multi-factor authentication, device checks, or approval steps are in scope, explain how the test identities will complete them. The SaaS pentest readiness checklist covers the operational preparation in more detail.

4. Make APIs and integrations visible

An API is not fully described by its public documentation. Share OpenAPI or GraphQL schemas, Postman collections, example requests, version information, and notes on undocumented endpoints still used by web or mobile clients. Identify authentication methods, token scopes, service accounts, object identifiers, pagination, bulk operations, uploads, exports, and asynchronous jobs.

List inbound and outbound integrations separately. For webhooks, describe who can register destinations, how messages are signed, whether delivery can be replayed, and what data is included. For OAuth or single sign-on, map the actors, redirect locations, account-linking rules, and expected trust decisions. For payment, messaging, storage, or analytics providers, state which application-side behaviours may be exercised safely.

Call out business-critical workflows that deserve abuse testing: trials and subscriptions, credits and refunds, approvals, invitations, document sharing, rate or quota enforcement, and workflows where two requests racing could produce an invalid state. A tester cannot prioritise domain-specific logic that is never explained.

5. Set safe operating rules before access is issued

Choose the environment deliberately. A representative staging environment reduces customer risk, but only if its code, configuration, identity model, and integrations behave like production. If production testing is required, define tighter limits and use controlled records. Document material differences so gaps are not mistaken for tested coverage.

The rules of engagement should name authorised source addresses where applicable, test dates and time zone, rate limits, prohibited actions, allowed test data, monitoring expectations, evidence-handling requirements, and an emergency stop process. Provide a technical contact and a separate escalation route for urgent findings. Agree how a critical issue will be communicated during testing instead of waiting for the report.

Be explicit about denial-of-service techniques, destructive actions, social engineering, persistent payloads, access to real customer records, and third-party systems. These are normally excluded unless separately authorised with appropriate safeguards. Also decide whether security controls such as a web application firewall remain enabled; the report should state the conditions under which testing occurred.

6. Describe the real effort drivers

A single-page interface can conceal hundreds of API operations, while a large marketing site may expose little authenticated logic. Useful sizing inputs include:

• Identity complexity: number of roles, privilege levels, tenant types, and authentication paths.
• Workflow depth: sensitive actions, approval chains, state transitions, and business-rule combinations.
• API breadth: versions, operations, object types, protocols, and machine-to-machine access.
• Trust boundaries: organisations, integrations, staff interfaces, uploads, exports, callbacks, and data stores.
• Change and access: release stability, documentation quality, account readiness, and environmental restrictions.

Clarify the level of knowledge the tester receives. A black-box exercise begins with little internal information and may suit a narrow external-attacker objective. A grey-box test supplies normal user access and useful documentation, allowing more of the available time to be spent on coverage and validation. Source-assisted work can add architecture or code context when that is part of the agreed method.

Ask vendors to show their assumptions, estimated test and reporting windows, and what triggers a scope change. The Balhence web and API service description shows the core coverage and the boundaries that should be agreed before a quote.

7. Specify what “done” means

Define the output before comparing prices. A useful report should identify the tested scope, dates, environment, access level, methodology, limitations, and unresolved coverage gaps. Each finding should include affected assets, prerequisites, repeatable steps, evidence, realistic impact, severity rationale, and remediation guidance appropriate to the system.

Agree whether you need an executive summary, technical walkthrough, machine-readable finding register, remediation support, or a closure letter. Set the channel and response expectation for urgent findings during the test. For the re-test, specify which original findings are eligible, the remediation deadline, how many verification rounds are included, and how partially fixed or unverified items will be represented.

Do not treat a re-test as a new assessment. It verifies agreed fixes against the original finding and scope; new features and major architecture changes require fresh coverage. Use what a good penetration test report should include to evaluate a sample deliverable before appointing a vendor.

8. Send a brief that can be quoted without guesswork

You do not need a perfect technical inventory to start a conversation. You do need to distinguish known facts from open questions. Copy this structure into your request:

A vendor should respond with a boundary you can inspect: what will be tested, what will not, how access changes coverage, which assumptions affect the quote, and what your team must provide before the clock starts. If those details remain vague, the proposals are not yet comparable.

Continue preparing

• What a good penetration test report should include
• The SaaS pentest readiness checklist
• Web and API pentest cost and pricing guide