A defensible scope is a shared description of the assessment, not a prediction that every test will take the same time. The goal is to surface effort-changing facts early enough to decide what to include, what to exclude, and what must be confirmed before approval.
This list is deliberately about web applications. It does not turn a standalone API, mobile application, external network or cloud review into a web-app estimate. Keep separate assessment types separate until you have evidence to calibrate them.
The checklist
Capture a short answer, its source, and whether it is confirmed. “Unknown” is a valid answer; it is a reason to preserve uncertainty or pause approval, not a reason to silently use the easiest assumption.
1. Boundary and access
- State the exact web properties, environments and paths included.
- Record whether testing is authenticated, unauthenticated or both.
- Identify production, staging or other constraints; do not assume equivalence.
- Confirm test-account ownership, account reset path, IP allowlisting, VPN and rate limits.
- Name explicit exclusions, including excluded hosts, modules and third-party systems.
2. Identity, roles and authorization
- Count materially different authenticated roles, not cosmetic job titles.
- Describe privilege boundaries: administrator functions, tenant administrators and support tooling.
- Ask whether users, tenants or organizations can invite, recover, impersonate or delegate access.
- Capture SSO, MFA, password recovery and external identity-provider behavior.
- Flag multi-tenancy and any cross-tenant data or administration flows for explicit review.
3. Workflows and data-handling surface
- List major business workflows rather than every screen: registration, onboarding, billing, approvals and recovery often matter more.
- Call out payment processing, file upload, user-generated content and exports.
- Identify sensitive or regulated data flows and any business-critical transaction path.
- Note asynchronous or stateful behavior: webhooks, background jobs, notifications and approval queues.
- Record third-party integrations that are in scope for interaction versus context only.
4. API and technical shape
- Identify APIs used by the application and an approximate endpoint count.
- Distinguish REST, GraphQL and custom interfaces where their authorization or discovery work differs.
- Ask whether browser and API authorization decisions are shared, separate or unknown.
- Document public endpoints, machine-to-machine flows, webhooks and client-controlled identifiers.
- Keep a technical inventory proportionate: precise enough to spot material surface, not a substitute for a test plan.
5. Delivery assumptions
- Reserve reporting time explicitly and state the expected report format and review path.
- State whether retest is included, its time allowance, expiry and what counts as a retestable change.
- Capture compliance-driven evidence, meeting, presentation or remediation-validation expectations.
- Record availability windows, change freezes and customer-response dependencies.
- Write the scope uncertainty that remains and the decision needed to resolve it.
Turn answers into an estimate
Keep the arithmetic legible. Start with testing effort, then make reporting, retest and coordination allowances visible. An effort range should widen when material facts are unknown; it should not be narrowed just because the customer has not answered yet.
Example estimate structure
Make each allowance inspectable
Expected effort = testing effort
+ reporting allowance
+ retest allowance
+ explicit delivery constraints
Price recommendation = max(
expected effort × day rate,
delivery cost ÷ (1 − target gross margin)
)This is a decision structure, not a universal coefficient set. Your day cost, day rate, margin target and effort rules belong to your firm. Preserve the assumptions alongside the final quote and record why a senior reviewer changed a recommendation.
What to do with a missing critical fact
Choose one explicit action: obtain the fact, write a bounded assumption and widen the range, price a separately defined option, or exclude the work. Do not bury a missing tenant model, administrator surface, endpoint range or retest expectation in a single effort number.
Request facts without asking for secrets
A customer should be able to answer a scope request without transferring pentest evidence. Ask for generalized architecture and workflow facts; avoid credentials, customer data, vulnerability information, source code, secrets and production exports in an ordinary scoping exchange.
Suggested opening
“To prepare an accurate web-application testing proposal, please describe the included application areas, user roles, major workflows, API use, integrations, environments and access constraints. Anonymous or generalized descriptions are sufficient for this stage. Please do not send credentials, secrets, vulnerabilities or customer data in your response.”
The list becomes commercially useful when the consultant reviews it with the customer, highlights unresolved decisions, and carries only the confirmed scope into the quote.
Sources and limits
- OWASP Web Security Testing Guide describes web-application test domains including identity, authentication, authorization, session management and configuration. Accessed 27 September 2026.
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment treats planning as the stage for defining scope, requirements, limitations, assumptions, resources and deliverables. Accessed 27 September 2026.
These sources support the categories of questions, not particular tester-day weights. ScopeMargin's current web-app coefficients are provisional hypotheses and should be calibrated against each firm's delivered work.