Most disappointing penetration tests fail before a single request is sent. The scope was too vague, too wide for the days bought, or missing the one system that actually holds the risk. Scoping is the cheapest place to improve a test, and it is work the buyer can do well with a little structure.
Begin with the question, not the asset list
A scope that says "test our website" invites a generic engagement. A scope that says "can a customer on the basic plan read another customer's invoices?" gives testers a target and gives you a yes-or-no outcome to report upward. Write down two or three questions like these before you list a single URL.
Useful framing questions include:
- What would hurt most if an outsider reached it: customer data, payment flows, admin consoles or production infrastructure?
- Who are you worried about: anonymous internet users, paying customers, partners with API keys, or a compromised employee laptop?
- Why now: a new release, a customer security questionnaire, an audit, or a recent incident?
- Who will read the report, and what decision will they make with it?
The answers decide test type. Questions about tenant isolation point to a web application pentest or API pentest. Questions about a stolen laptop point to an internal network pentest and an Active Directory review.
Build an inventory testers can size
Providers estimate effort from countable things. Give them numbers rather than adjectives. The table below shows the details that matter most for common target types.
| Target | What to count or describe | Why it changes effort |
|---|---|---|
| Web application | User roles, main workflows, number of distinct pages or screens, file uploads, payment steps | Each role multiplies authorisation checks |
| API | Endpoints or operations, authentication methods, whether a specification file exists | A current specification saves discovery time |
| Mobile app | Platforms, backend APIs shared with web, offline storage, device features used | Two platforms roughly doubles client-side work |
| External network | Live public IPs and hostnames, exposed services, VPN or remote access gateways | Ranges with few live hosts are quick; busy ranges are not |
| Internal network | Sites, subnets, approximate host count, domains and trusts | Segmentation and domain size drive enumeration time |
| Cloud | Accounts, subscriptions or projects, main services in use, identity setup | Many accounts with different owners take longer to review |
Mark anything explicitly out of scope as well. Shared hosting, payment processors and SaaS platforms you do not control usually belong on that list unless you hold written permission to test them.
Decide what the testers will know
The knowledge level is a budget decision as much as a realism decision. Black box testing spends days on discovery. Grey box testing hands over accounts and documents so time goes on finding weaknesses. White box adds source code and design material for the deepest coverage. Our guide to black, grey and white box testing covers the trade-offs in detail.
For most first engagements, grey box gives the best return: create two accounts for every role. With a pair of same-level users, testers can confirm that records belonging to one stay invisible to the other.
Write rules of engagement everyone signs
Rules of engagement protect both sides. They should be short, specific and signed by someone with authority over every system in scope. Cover these points:
- Authorisation. Written permission naming the targets, the testing window and the provider.
- Environment. Production, staging or both, and any data that must not be touched.
- Timing. Allowed hours and any change freezes or peak trading periods to avoid.
- Restricted techniques. Whether denial-of-service checks, account lockout testing or social engineering are allowed.
- Source addresses. The IPs testers will use, so your monitoring team can tell them apart from real attacks.
- Contacts and escalation. Who to call if something breaks, and how critical findings are reported during the test.
- Data handling. How evidence is stored, who sees it and when it is deleted.
Decide early whether your detection team should be told. Telling them avoids false alarms; not telling them gives a free check on whether anyone notices. Both are valid, but the choice should be deliberate.
Size the effort in tester-days
Effort follows from the inventory and the knowledge level. As a rough guide, a single web application with two or three roles is often five to ten tester-days, an API with a few dozen operations three to eight, and a small external perimeter two to four. Larger estates scale from there. Our article on how long a penetration test takes gives fuller ranges.
Be wary of two patterns. A quote far below others usually means more automation and less manual work. A quote far above others may hide padding or a misread scope. Ask each provider to show how they reached their number; good ones will explain it line by line.
If you want a quick sense-check before talking to anyone, the pentest cost calculator turns a scope into an effort estimate.
Prepare before day one
Lost days are expensive. Most delays come from accounts that do not work, firewalls that block testers, or staging environments that fall over. A week before testing:
- Create and test the accounts, API keys and VPN access the team needs
- Allow-list tester source addresses on WAFs and rate limiters if you want depth rather than a test of the WAF
- Confirm the target environment matches production closely enough to be meaningful
- Share specifications, architecture diagrams and known issues so testers do not rediscover them
- Name a technical contact who can answer questions within hours, not days
Common scoping mistakes
Testing everything a little
Spreading ten days across twenty systems produces a shallow scan of each. It is better to test the highest-risk systems properly this round and rotate the rest into later rounds.
Leaving out the API behind the app
Mobile and single-page apps are thin clients. The real controls live in the API. If the API is out of scope, most of the risk is too.
Forgetting the retest
Plan when fixes will land and when the retest will happen. A scope that ends at the report leaves the job half done. See the remediation and retesting guide for a workable process.
Writing the scope for the vendor's template
Scope around your own risk questions, then map them onto the provider's services, not the other way round. If you are running a formal tender, our list of pentest RFP questions helps you compare replies on equal terms.
Frequently asked questions
Who should own the scope on the client side?
One named person, usually a security lead or engineering manager, who can approve targets, arrange accounts and make quick decisions while testing is live. Committees slow engagements down.
Can the scope change once testing has started?
Small adjustments are normal and should be agreed in writing. Adding new systems usually means extra tester-days, so most providers issue a short change note rather than stretching the original effort.
Should we include third-party SaaS in scope?
Only where you hold permission to test it. Many vendors forbid testing of their platform, so focus on your own configuration and integrations and check each vendor's policy first.
Ready to turn your scope into a fixed-price proposal? Try the cost calculator or request a quote for a web, API or VAPT engagement.