What should a web application pentest scope include?
Name the application surfaces, user roles, APIs, important workflows and environment to be tested. Then agree authorization boundaries, exclusions, communication, reporting and retesting. “Test our website” leaves too much room for different interpretations.
Scope around what users can do
Our suggested worksheet starts with actions and permissions. A single domain can contain very different areas: a public site, an authenticated application and a support console. Ask whether each is included and how its relevant roles will be represented.
OWASP’s Web Security Testing Guide is a useful technical reference. If a provider refers to it, ask which version and applicable coverage it means. A reference to the guide is not itself a list of the work agreed for your application.
A practical scope worksheet
On a small screen, scroll the table sideways to see every column.
| Area | Write into the brief |
|---|---|
| Assets | Named application URLs, API surfaces and included supporting systems |
| Roles | Customer, tenant administrator, support and other relevant access levels |
| Workflows | Invitations, exports, uploads, billing or other important actions |
| Environment | Production or representative test environment, with differences recorded |
| Boundaries | Authorized owner, excluded systems, stop conditions and contacts |
| Deliverables | Interim notification, final report, findings discussion and retest terms |
Example: an invoicing SaaS application
A fictional invoicing application has a public signup flow, a tenant workspace and an internal support console. Its buyer writes separate lines for each area. Exporting invoices and inviting a colleague are named as important workflows, while an externally operated payment processor is explicitly outside the buyer’s own test authorization.
This is a scoping illustration, not a testing procedure. The point is to reveal assumptions before the work starts: can the provider access each included role, and does the environment represent the behavior the buyer needs assessed?
What changes should trigger a scope discussion?
If a new API, role or important workflow appears before the engagement, ask whether the agreed work still covers it. If the test environment differs materially from production, record that difference and ask how it affects the conclusions.
Keep a final scope copy with the report so a later reader can understand what the findings describe. This also makes future quotes easier to compare: additions and exclusions become visible instead of being hidden inside a changed price.