Scope decides what a penetration test can find and what its report can be used to claim. The four decisions that matter are which systems, which environment, how much access the tester gets, and what is explicitly out of bounds.
A penetration test is a fixed amount of expert time. Scoping is how you decide where that time goes, and it is the highest-leverage conversation in the whole engagement.
Four decisions do most of the work.
1. Which systems
Not "our product". A list: hostnames, applications, API surfaces, cloud accounts, and the roles that exist within them.
The useful filter is where the damage would be. What holds customer data. What handles money. What has authorization logic complicated enough that nobody is completely sure it is right. A marketing site on a separate host is rarely worth testing time, and it routinely ends up in scope because it was on the list of domains.
If the test has to support an audit, this list needs to be compared against the audit's own scope document: the SOC 2 system description or the ISO 27001 scope statement. A report that does not cover the system the audit covers is evidence about something else.
2. Which environment
Staging that genuinely mirrors production is the best answer. Production is the honest answer when staging does not mirror it.
The failure mode is a staging environment that differs in the ways that matter: different authentication, seeded data with no realistic relationships, feature flags in different states, a payment integration pointing at a sandbox. Findings from that environment may not apply to production, and findings that exist only in production will not be found at all.
Worth confirming explicitly: does staging use the same identity provider, the same authorization code path, and the same infrastructure configuration. If the answer is no to any of them, say so during scoping rather than discovering it in the report.
3. How much access the tester gets
This is where the most budget is won or lost, and the intuition runs backwards.
Withholding information does not make the test harder for an attacker, who has unlimited time. It makes it harder for the tester, who has five days. A black box engagement spends a significant share of the budget on discovery, producing a report that reflects what was reachable in the time available rather than what is actually wrong.
For most buyers the right answer is grey box or white box: credentials for every role, two separate tenants, and a walkthrough of the parts of the product that matter. Source access on top of that removes the remaining guesswork.
Black box earns its place in one situation: when the specific question is what an uninformed outsider can reach, or when detection and response are being tested as much as the system.
4. What is out of bounds
Written down, before anything starts. Typically: no denial of service, no social engineering unless separately agreed, no testing of third party systems you do not control, no destructive operations against production data, and a defined testing window.
The one that gets overlooked is authority. Testing a system you do not own is not authorized because your customer asked for it. A SaaS platform you integrate with, a payment processor, a managed service: those belong to someone else, and their terms govern whether they can be tested.
The three mistakes that waste time
Scoping by asset count instead of by risk. Fifty static marketing pages and one authenticated application are not equivalent testing surfaces, but a scope defined by hostname count treats them as though they are.
Providing one account. Authorization is where the serious findings live, and testing it requires at least two accounts per role and two separate tenants. A single admin account makes the most valuable class of finding structurally impossible to discover.
Leaving bot protection on. A WAF or rate limiter that blocks the tester means you paid to test the WAF. If it is in scope, test it deliberately and separately; if it is not, allowlist the tester and say so in the report so the auditor knows what the coverage claim rests on.
What to hand over on day one
- Credentials for two accounts per role, across two tenants
- A walkthrough of where the money and the sensitive data are
- An API specification, or a collection of real requests
- Confirmation of which environment is in scope and how it differs from production
- Signed rules of engagement, with the excluded systems and techniques listed
- A contact who can answer a question within a few hours
That last one is worth more than it looks. A tester blocked on an environment question for a day has lost a fifth of the engagement, and nobody gets that day back.
Questions people ask
Should a penetration test run against production or staging?
Staging, when it genuinely mirrors production in authentication, authorization and infrastructure configuration. Where it does not, findings may not apply to production and issues unique to production will not be found. In that case, scope production carefully with destructive operations excluded.
How many accounts should you give a penetration tester?
At least two per role, across two separate tenants. Authorization flaws are the highest-impact class of finding in multi-tenant software, and testing them requires being able to attempt access from one account to another account's data.
Should you turn off the WAF during a penetration test?
Allowlist the tester unless the WAF itself is deliberately in scope. Otherwise the engagement measures how well the WAF blocks the tester rather than what is wrong with the application, and the report should state which choice was made.