How to Scope a Penetration Test: A Checklist for SaaS Teams
The scope of a penetration test decides what it can find. A test scoped too narrowly gives you a clean report and a false sense of safety. Scoped too broadly, it gets expensive and shallow. Here is how to get it right.
Start with what attackers can reach
List everything an outsider could interact with:
- Domains and subdomains: app, API, admin, staging, marketing and documentation sites.
- APIs: public REST or GraphQL APIs, mobile backends, webhooks and partner integrations.
- Authentication surfaces: login, signup, password reset, SSO and OAuth flows.
- Cloud assets: storage buckets, serverless functions, exposed databases and load balancers.
- Network services: open ports on your IP ranges.
Forgotten assets, such as an old staging server or a test subdomain, are where real attackers often get in. Include attack surface discovery in scope if you are not sure you know everything.
Decide on authenticated testing
Most critical SaaS vulnerabilities live behind the login: broken access control, IDOR, privilege escalation and business logic flaws. Unauthenticated testing will miss them. Provide:
- At least two accounts per role, so testers can check whether user A can access user B's data.
- Accounts in two separate tenants or organisations, to test cross-tenant isolation.
- An admin or elevated account, if admins exist, to test privilege boundaries.
Define environments
- Production gives the most realistic results but needs care around data and availability.
- Staging is safer but only useful if it matches production closely.
Many teams test staging for intrusive tests and production for configuration and exposure checks. Whatever you choose, document it in the report.
Rules of engagement
Agree in writing on:
- Testing windows and any blackout periods.
- Rate limits or load constraints.
- Out-of-scope actions, such as denial of service or social engineering.
- Emergency contacts if a critical issue is found mid-test.
- How test data should be handled and cleaned up.
Scoping for compliance
If the report is evidence for SOC 2, ISO 27001 or PCI DSS, align scope with the system described in that programme. Auditors notice when the system description lists five services and the pentest covered one.
A quick scoping checklist
| Question | Why it matters |
|---|---|
| Have we listed every domain and subdomain? | Unknown assets are common entry points |
| Are APIs included, not just the web UI? | APIs often lack the checks the UI enforces |
| Do testers have multiple accounts and tenants? | Needed to find access control flaws |
| Are cloud accounts included? | Misconfiguration is a leading breach cause |
| Is there a retest? | Proves fixes and closes the loop |
Skipping the scoping call
Traditional scoping takes meetings and weeks. SecurityInfinity starts with automated attack surface discovery, so agents find your subdomains, APIs and exposed services, then test them in parallel. No agents to install and no scoping call required. Start free.
Frequently asked questions
Should third-party services be in scope?
You can only test systems you own or have permission to test. Third-party SaaS platforms usually prohibit testing without approval, but your configuration of them, such as public sharing settings, can be reviewed.
Is a larger scope always better?
No. Depth matters more than breadth. A deep authenticated test of your core product beats a shallow scan of everything.
How do I scope a test for a mobile app?
Include the mobile backend APIs, which are where most serious mobile app vulnerabilities live, plus the app binary if client-side security is a concern.