A penetration-testing company can give you a credible fixed scope and timeline when it understands the assets, identities, workflows, environments, constraints and deliverables involved. You do not need to produce a perfect security dossier before requesting a quotation, but a URL and deadline are rarely enough. A concise scope pack prevents guesswork, reduces change requests and protects the high-risk parts of the product from being silently excluded.

For a founder or product head, the preparation can be lightweight. Assign one technical owner, collect the items below and mark unknowns openly. A good provider will use the gaps to ask focused questions rather than delay the process or pretend uncertainty does not affect effort.

1. Identify every target and how it connects

List the web applications, domains, APIs, mobile applications, administrative portals and relevant cloud or network surfaces. State which are in scope now and which are context only. Explain shared backends and integrations so the provider does not quote each client independently while missing the common authorization layer.

  • Production and staging URLs, API base URLs and relevant subdomains.
  • Android and iOS application identifiers, build delivery method and backend API.
  • Administrative or support interfaces that can affect customer data.
  • Third-party services and partner integrations, clearly marked as authorized or excluded.

If the inventory is incomplete, say so. Include discovery as an explicit activity and agree how newly identified assets affect scope.

2. Provide a role and tenant matrix

Count the identities the provider must compare: anonymous user, customer, manager, support agent, administrator, partner or other product-specific roles. For multi-tenant software, state how many organizations and membership combinations are needed. Mention impersonation, delegated administration, service accounts and account-recovery paths.

Authorization effort grows with meaningful role and tenant relationships. This information often changes a quotation more than the number of pages because the tester must verify what each identity can see and do across the same objects and workflows.

3. Name the critical business workflows

List actions whose abuse would create material harm: registration, authentication, recovery, onboarding, approvals, payments, refunds, bookings, credits, exports, sharing, file processing, invitations and administrative changes. Identify workflows that cross services or require multiple actors.

Do not attempt to write test cases for the provider. Explain the intended rules and business consequence. The tester should develop adversarial hypotheses from that context.

4. Describe the APIs and clients

  • API specifications, collections, schemas or developer documentation.
  • Authentication method, token lifecycle, scopes and required headers.
  • Documented and known undocumented endpoints used by browser or mobile clients.
  • GraphQL, WebSocket, webhook, asynchronous job or file-transfer interfaces.
  • Rate limits, pagination and operations that change or delete state.

An API collection accelerates setup but is not proof of complete attack-surface coverage. Tell the provider whether endpoint discovery and client traffic review are expected.

5. Choose and describe the environment

State whether testing will occur in staging, production or both. Describe important differences: build version, identity provider, edge controls, integrations, data, feature flags and infrastructure configuration. If production is included, provide business blackout windows, safe test hours, monitoring contacts and prohibited actions.

Confirm that the environment will remain stable. If releases continue during testing, agree how changes are communicated and whether affected areas must be retested.

6. Prepare access and test data

Explain VPN, allowlisting, MFA and account-provisioning requirements. Estimate the number of accounts per role and tenant. Use synthetic records where possible and identify any action that could reach real customers, money, messages or third-party systems.

You do not need to create all accounts before requesting a quote, but the provider should know who owns readiness and how long access normally takes. The delivery clock should begin only after agreed prerequisites work.

7. State the business trigger and deadline

Tell the provider whether the engagement supports a launch, customer review, audit, investment process, annual assurance, architectural change or incident follow-up. Provide the real decision date and distinguish it from a preferred start date. This context determines reporting format, prioritization and whether a focused scope is acceptable.

If an external party has acceptance criteria, share them. Requirements for assessor independence, methods, dates, evidence, retesting or a closure letter can change both schedule and deliverables.

8. Define the required outputs

  • Technical report with reproducible evidence and root-cause remediation.
  • Executive summary for risk and release decisions.
  • Critical-finding notification during testing.
  • Engineering walkthrough and clarification period.
  • Retest cycles and updated report, addendum or closure letter.
  • Customer-safe or audit-oriented artifact when genuinely needed.

A fixed quotation should include these outputs explicitly. Reporting and retesting require real effort and should not appear only after the first draft is delivered.

Identify prohibited techniques, rate limits, data-handling rules, retention requirements and third-party boundaries. Confirm who can authorize testing and who can request a pause. If regulated or sensitive data exists, involve the appropriate legal, privacy or compliance owner without sending unnecessary data to bidders.

NIST SP 800-115 emphasizes planning and rules of engagement before technical testing. Its testing guide is a useful reference for clarifying scope, personnel, schedule and authorized activity.

10. Share useful architecture context

A high-level diagram, technology stack, data-flow view and previous-test summary can reduce discovery time. Highlight recent changes, high-risk components and known limitations. Do not send source code, production secrets or sensitive customer data merely to obtain an estimate. Use secure sharing after the provider and access needs are validated.

What the vendor should return before you approve

  1. An unambiguous in-scope and out-of-scope list.
  2. Roles, tenant combinations, workflows and environments covered.
  3. Method and balance of automated support, manual testing and validation.
  4. Buyer prerequisites and the condition that starts the schedule.
  5. Testing, draft, review, final and retest milestones.
  6. Deliverables, clarification support and closure terms.
  7. Assumptions, uncertainty and a change-control mechanism.

Common scoping mistakes

  • Providing only the public URL and assuming all APIs and roles are included.
  • Counting screens while omitting authorization relationships and business workflows.
  • Treating mobile applications as independent from their backend APIs.
  • Requesting a fixed deadline before access and release readiness are understood.
  • Hiding known changes or constraints to obtain a lower quote.
  • Sending credentials or sensitive architecture through an unapproved channel.

The practical decision

Prepare a concise, honest scope pack and let the provider ask precise questions. The objective is not paperwork; it is a fixed agreement whose price and timeline correspond to real coverage. Unknowns should become assumptions or discovery work, not invisible risk transferred to the test window.

Share your VAPT scope with WIMD using the checklist above. We can turn it into an explicit asset, role, workflow and deliverable plan before confirming effort and dates.