Who this is for: IT managers and developers responsible for procuring or preparing for a web application penetration test. If you've never written a pentest scope before, this will save you time and money.
The scope is the test
A vague scope produces a vague pentest. When a client asks for "our web application tested", the tester has to make assumptions about what's included, what's off-limits, what authentication states to test, and how aggressive to be when chaining findings. Those assumptions affect the result — and not in a predictable direction.
Good scoping isn't bureaucratic overhead. It's the part of the process where the client and the tester agree on what risk actually looks like for this application, which determines whether the report will be useful.
What should always be in scope
For most web application tests, the following should be explicitly included unless there's a good reason to exclude them:
Authentication and session management
Every login flow, password reset mechanism, account lockout policy, and session token should be testable. Authentication is where the most impactful vulnerabilities tend to live. If you tell the tester to "avoid testing login to prevent lockouts", you've excluded the most interesting part of the application.
The solution to lockout concerns isn't to exclude authentication — it's to create dedicated test accounts and configure lockout thresholds that allow testing. This should be set up before the engagement starts.
Authorisation and access control
Horizontal privilege escalation (can user A access user B's data?) and vertical privilege escalation (can a regular user access admin functions?) are both in scope. These require test accounts at different privilege levels. If you only provide one test account, the tester can't assess this properly.
API endpoints
If your application has an API — and most applications do — the API is in scope. This includes endpoints consumed by your own frontend, mobile apps, and any documented or undocumented third-party integrations. Mobile app API backends are frequently forgotten at scoping and discovered during testing, which disrupts the timeline.
File uploads and processing
Any feature that accepts file input. These are consistently high-risk and frequently unpatched because developers focus on functional testing rather than adversarial testing of file handlers.
Common scoping mistakes
Excluding production without providing a staging environment
Testing a staging environment that doesn't reflect production is a waste of everyone's time. If staging is six months behind production in patches and configuration, the findings won't apply to what users actually interact with. If you can't test production, set up a staging environment that is genuinely production-equivalent — same WAF configuration, same third-party integrations, same database schema.
Scope creep in the other direction: testing everything
Scoping "the whole platform" without prioritising is also a problem. A complex application has hundreds of features. An engagement with a fixed timeline and unlimited scope means the tester either rushes through everything superficially or focuses on whatever they find interesting, which may not be what your actual risk looks like.
Better: define which user roles are highest risk, which data is most sensitive, and which features handle financial transactions or personal data. Start there.
Not specifying the threat model
Who are you worried about? An authenticated user attempting fraud? An unauthenticated external attacker? A malicious insider with legitimate system access? These scenarios require different testing approaches. The scope should specify the assumed attacker position.
What you need to prepare before testing begins
- Test accounts at each privilege level (admin, regular user, read-only, etc.)
- Explicit written authorisation signed by someone with authority over the systems
- Contact details for someone who can respond if the tester breaks something
- Staging or production access details, with confirmed environment equivalence
- Known exclusions: third-party components you don't own (e.g. payment processors), systems not in scope, testing time windows
- API documentation if available (Swagger, Postman collections)
Practical note: The most useful thing you can provide is a brief description of what the application does, who uses it, and what data it handles. This context shapes how the tester prioritises. Without it, they'll test the OWASP Top 10 and stop.
The "out of scope" clause
Every scope document needs explicit exclusions. Common ones: third-party SaaS tools your application integrates with (you don't have authority to test these), production databases during business hours, systems owned by other entities. If the tester finds an interesting-looking server during reconnaissance that isn't in the agreed scope, a clear exclusion list means you don't spend half a day on calls confirming what to do next.
After the scope is agreed
Don't treat scope as something fixed until delivery. If testing reveals a related system that looks critical, the tester should raise it. The question "is this in scope?" during an engagement should have a fast answer — designate someone on your side who can make that call without a committee.