Imagine sending the same application URL to three pentest providers. One prices the public website. Another includes signed-in users. The third includes the API and staff portal too. You now have three prices for three different jobs.

You don't need a perfect inventory to avoid this. You need a short description of what the product does, who uses it, and which parts are included. The rest can be worked through together.

A useful first sentence: "We run a subscription app with customer workspaces, a staff portal, and a REST API. We need the report before our October customer review." Add the details below; don't start with a list of vulnerability names.

1. Say why you need the test

A release check and a customer security review may involve the same app, but the deadlines and reporting needs can differ. Explain who will read the report and what decision it needs to help them make.

If a customer supplied requirements, share their exact wording. Put the report deadline in the brief, then leave room before it for testing, fixes, and verification. A report describes the systems and period tested; it cannot promise permanent security or another company's approval.

2. List the parts, then explain how they connect

List your customer app, staff portal, API, authentication service, and any separate regional or older deployments. Mark each one as included, excluded, or background context. Give the environment and owner, not just the URL.

A rough diagram helps. Show what the browser calls, where uploaded files go, and which service sends exports or webhooks. A small interface can hide a lot of work behind one button.

Keep third parties separate. Your payment callback handling may be in scope; the payment provider's systems are not automatically included. Anything you don't own needs the appropriate owner's permission before active testing.

Minimum asset inventory

  • Applications, portals, and hostnames, with owner and environment
  • API base URLs, versions, protocols, and available specifications
  • Authentication, upload, export, webhook, and administrative entry points
  • First-party components, third-party dependencies, exclusions, and known shared infrastructure
  • Features released recently or expected to change during the test

3. Explain who can do what

Use your product's real role names. For each role, write down what it can read, change, approve, export, or delete. Include staff access and service accounts if they're part of the test. "Admin and user" is too vague when support staff can act on a customer's behalf.

For a multi-tenant app, prepare at least two controlled test tenants. Explain team and project inheritance, shared resources, and what should happen when someone leaves. Those relationships matter as much as the permission attached to one role.

Plan dedicated accounts and working SSO or MFA access for each relevant role. The SaaS pentest readiness checklist covers the setup.

4. Make APIs and integrations visible

Share the API specification or request collection you already have. Note outdated sections, older versions still in use, and operations available to mobile clients or service accounts but absent from the browser.

Describe the integrations that move data or change an account: webhooks, SSO, payments, exports, and background jobs. For each, say who configures it and which controlled resources can be used during testing.

Then flag the workflows you most want checked. Perhaps refunds need two approvals, or a suspended workspace must lose export access. Write down the rule. The tester shouldn't have to infer how your business is supposed to work.

5. Agree on the limits before testing

Use staging when it represents the code and controls you need assessed. Document differences from production, especially authentication, integrations, and security settings. Production testing needs controlled records and explicit safety limits.

Write down the dates and time zone, permitted activity, rate limits, evidence handling, and stop conditions. Name someone who can fix access and someone who can respond to an urgent finding. India-based teams arranging a remote test can use our India VAPT brief to cover IST coordination, data rules and report deadlines.

Decide explicitly how to handle destructive actions, denial-of-service testing, social engineering, real customer data, and third-party systems. Don't leave these to assumption. Record whether the web application firewall stays enabled or whether agreed allowlisting is used.

6. Explain what makes your product complex

Page count is a poor estimate of testing time. A provider needs to understand:

  • 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.

Also agree what the tester receives. Black-box work starts with limited internal information. Grey-box work includes user access and useful documentation. Source-assisted work adds code context. Choose the approach that fits the question you need answered.

Ask for the testing and reporting windows, access assumptions, and scope-change terms in writing. Our web and API service description is a starting point for that conversation.

7. Agree on the report and follow-up

Ask for a sample report. Can an engineer follow a finding, understand the impact, and see where to apply a fix? Can a customer reviewer see exactly what was tested and what was left out?

Agree on the walkthrough, urgent-alert channel, and support after delivery. For the re-test, specify the eligible findings, deadline, included rounds, and possible outcomes. It checks the agreed fixes; it doesn't cover a newly built feature by default.

Use what a good penetration test report should include when reviewing the sample.

8. Put it in one brief

A few clear paragraphs are enough to start. Mark anything you don't know yet.

Web & API pentest scope brief

  1. Business reason and deadline: what decision the assessment supports and when evidence is required.
  2. Assets: applications, APIs, environments, integrations, and explicit exclusions.
  3. Access: roles, tenants, test accounts, authentication methods, and available documentation.
  4. Priority workflows: sensitive data, payments, administration, sharing, exports, and recent changes.
  5. Safety: permitted environment, test window, rate limits, prohibited actions, contacts, and stop conditions.
  6. Outputs: report audiences, urgent-alert process, walkthrough, remediation support, and re-test expectations.

Send the same brief to each provider. If a proposal leaves one of these points unanswered, ask before comparing the totals.

Have a rough scope?

Send it over, even if a few details are missing. Our web application and API penetration testing pages explain the usual starting points. We can work through the open questions with you.

Request a pentest proposal Draft your scope first