The short answer
Scoping a penetration test means deciding four things before any testing starts: which systems are in scope, how much knowledge and access the tester is given, what techniques are permitted, and what the report has to prove. Get those four right and the test finds what matters. Get them wrong — the usual failure — and you receive an accurate report about the wrong thing.
Almost every disappointing penetration test was decided before anyone touched a keyboard. The environment was a stripped-down staging copy. Credentials never arrived, so two of the three user roles went untested. The scope excluded the legacy integration that an attacker would have gone for first. None of these are testing failures; they are scoping failures, and they are avoidable.
This guide sets out how to scope a test properly, whoever ends up delivering it.
Start with the question, not the asset list
The most common way to open a scoping conversation is with an inventory: three web applications, a mobile app, a /24 of external addresses. That is useful later. It is the wrong place to start, because it answers what exists rather than what matters.
Start instead with the question you actually need answered. In practice it is nearly always one of these:
- "Can an anonymous attacker on the internet get in?" — an external infrastructure and perimeter test.
- "If one laptop is compromised, how far does that get?" — an internal or assumed-breach test.
- "Can one customer of our platform reach another customer's data?" — an authenticated application and multi-tenancy test.
- "Is this new release safe to launch?" — a targeted application test against the changed functionality.
- "Can we satisfy this customer, insurer or auditor?" — a scoped test producing a shareable, dated attestation.
Each of those leads to a materially different engagement. A test scoped to answer the first question will not answer the third, no matter how well it is executed. If your provider does not ask which of these you are buying, that is informative in itself.
Choose the test type
The main types, and what each is genuinely for:
| Type | Answers | Typically needs |
|---|---|---|
| External infrastructure | What is exposed to the internet, and what can be done with it unauthenticated | IP ranges, domains, permission from the hosting provider |
| Internal infrastructure | How far a foothold spreads — lateral movement, privilege escalation, domain compromise | Network access (on site or via a jump host), a standard user account |
| Web application | Access control, business logic, injection, session handling within a specific application | A URL, credentials for every role, a test environment that mirrors production |
| API | Object-level authorisation, token handling, rate limiting, validation gaps between API and UI | Specification (OpenAPI/GraphQL schema), tokens for each role, example requests |
| Cloud configuration | Identity and permission design, exposed storage, segmentation, escalation paths | Read-only audit role in the tenant, an account list, architecture notes |
| Mobile application | Local data storage, transport protection, client-side controls, and the backend behind it | Installable build (not just a store link), test accounts, backend in scope too |
| Social engineering / phishing | Whether people report attacks, and how far a successful lure gets | Written authorisation at executive level, agreed staff-treatment rules |
| Red team | Whether your detection and response actually work against a determined adversary | Mature controls already in place, a small group of aware stakeholders, a longer window |
Do not buy a red team engagement as your first test. A red team measures detection and response. If you have not yet run a penetration test, the answer is already known — everything will be found and nothing will be detected — and you will have paid a premium to learn it. Red teaming is what you do after remediation has matured, not instead of it.
Decide how much the tester is told
Three conventional levels, and the trade-off is always time:
Black box
No prior information beyond the target. Attractive because it "simulates a real attacker", but the simulation is misleading: a real attacker has unlimited time and no scope boundary, while your tester has ten days. A meaningful portion of that window is spent rediscovering things you could simply have told them. Black box is appropriate when the question is specifically about what an outsider can discover.
Grey box
Credentials for each role, an architecture overview, and a description of what the system does. This is the right default for most application testing. It puts the effort into finding flaws rather than into reconnaissance, and it reflects a realistic threat model: attackers routinely start with valid credentials from phishing, reuse or a leak.
White box
Full access including source code, configuration and design documents. Highest coverage per day spent, and the best choice for high-assurance systems — payment flows, authentication services, anything cryptographic. It costs more per day and requires a provider comfortable reading your stack.
A useful rule: withhold information only when the value of the test depends on it being withheld. Otherwise you are paying a professional to guess at things you already know.
Define the scope precisely
Scope should be written down in unambiguous terms, because ambiguity is resolved conservatively during testing — and conservatively means "not tested".
In scope, stated exactly
- Fully qualified domain names and URLs, including any subdomains and admin interfaces you want covered.
- IP addresses and CIDR ranges, with a note on which are yours and which belong to a provider.
- Cloud accounts, subscriptions or projects by identifier.
- Application user roles — every role, named, with credentials for each.
- APIs, with their specification and any non-obvious endpoints.
- Mobile builds and the platforms they must be tested on.
Out of scope, stated just as exactly
- Third-party SaaS you do not own and are not authorised to test.
- Shared infrastructure where your hosting agreement forbids testing.
- Systems belonging to customers or partners.
- Any technique excluded by agreement — denial of service is excluded by default in most engagements.
Testing anything you do not own or have written authorisation to test is a criminal offence in most jurisdictions, including under the UK Computer Misuse Act 1990. That authorisation has to come from someone entitled to give it. If a system is hosted by a third party, check their testing policy: the major cloud providers now generally permit testing of your own resources without advance approval, but all of them impose limits — denial-of-service testing in particular — and the details change, so read the current policy rather than relying on what was true two years ago.
Choose the environment honestly
Production gives the truest answer. Staging is safer. The decision matters more than people expect, because staging environments diverge from production in exactly the ways that hide findings: different configuration, weaker or absent data, missing integrations, a WAF that is not there, debug endpoints that are.
If you test staging, the requirement is that it is a genuine mirror — same versions, same configuration, same integrations, representative data volumes — and that the report states clearly which differences remain untested. A test of an environment that materially differs from production is a report about a system you do not run.
If you test production, agree the safeguards: a testing window, a named contact reachable throughout, an agreed pause signal, exclusion of destructive techniques, and awareness that the test will generate alerts. Tell your monitoring provider — or deliberately do not, if measuring detection is part of the point, in which case say so in the rules of engagement.
Write the rules of engagement
The rules of engagement are the document that turns an intention into an authorised, bounded exercise. At minimum it should record:
- Authorisation — who is permitting the testing, and evidence they are entitled to.
- Scope — in and out, as above, with the version and date.
- Testing window — dates, and whether out-of-hours testing is required or forbidden.
- Excluded techniques — denial of service, destructive payloads, social engineering of named individuals, physical entry.
- Data handling — what happens to any data encountered, where it is stored, when it is destroyed.
- Emergency contacts — reachable on both sides during the window.
- Escalation triggers — critical findings reported immediately rather than held for the report, and what happens if the tester finds evidence of a pre-existing compromise.
- Source addresses — the tester's IPs, so you can tell testing traffic from real attacks.
- Retest terms — whether verification of fixes is included, and for how long after delivery.
That last point is worth negotiating deliberately. A test without a retest tells you what was wrong; a test with a retest tells you what is still wrong, which is the thing you actually needed to know.
Size the engagement realistically
Effort is usually quoted in tester-days. There is no universal formula, but the drivers are consistent: the number of distinct user roles (each role multiplies access-control testing), the number of unique functional areas rather than pages, the amount of custom business logic, the number of integrations, and the level of assurance required.
Two warning signs when comparing quotes. A quote that is dramatically cheaper than the others usually reflects fewer days, and fewer days means less coverage — the scope has quietly shrunk rather than the price. And a quote given without any scoping questions is a price for an unknown quantity of work, which cannot be a meaningful number.
Insist that the proposal states the number of tester-days and what is included: reporting time, the walkthrough, the retest. Reporting is typically a substantial share of the total effort, and a proposal that omits it is not cheaper, only less complete.
Questions to ask any provider
Including us. A provider who is uncomfortable with these is answering the question.
- Who specifically will test, and what is their background? Certifications such as OSCP, CREST registrations or membership of a scheme like NCSC CHECK indicate assessed competence. Ask about the individuals, not the company's certificate wall.
- What proportion is manual? If the methodology is a scanner plus a triage pass, you are buying a scan.
- Which methodology do you follow? Expect a named answer — OWASP WSTG and ASVS for applications, PTES or NIST SP 800-115 for infrastructure — not "our proprietary approach".
- Can I see a sample report? Redacted, but real. The report is the deliverable; judge it before you buy it.
- How are findings prioritised? A provider that ranks purely by CVSS without contextualising to your business will hand you a list you cannot sequence.
- Is a retest included? And for how long after delivery.
- What happens if you find a live compromise? There should be an immediate, defined escalation path.
- How is our data handled and destroyed? Ask for the retention period in writing.
- Do you carry professional indemnity insurance? A reasonable question for work that touches production systems.
What to prepare before day one
Anything missing at the start becomes lost testing time, and lost testing time is the most expensive kind. Have ready:
- Signed rules of engagement and authorisation.
- Working credentials for every role, tested the day before — not the morning of.
- Accounts exempted from lockout policies that would otherwise stop testing on the first afternoon.
- Tester source IPs allow-listed where a WAF or geo-block would otherwise dominate the results.
- A named technical contact who can answer a question within the hour.
- Documentation you already have: architecture diagrams, API specifications, a note of anything fragile.
After the report
A penetration test produces value at the point of remediation, not at the point of delivery. Three things convert a report into an improvement:
A walkthrough. Get the tester in front of your engineers. The questions that matter — is this exploitable behind our gateway, does this affect the other service too — do not get asked of a PDF.
Root cause, not instance. If three findings share a cause, fix the cause. A missing authorisation check in one endpoint usually means the pattern is missing, not the line.
A verified retest. A finding is not closed because a ticket is closed. It is closed when someone has demonstrated that the original attack no longer works and that the fix did not open something adjacent.
Finally, decide the cadence. An annual test against a continuously deployed system describes an application that no longer exists by the time you read it. For teams shipping regularly, a smaller recurring scope — tied to significant changes — usually produces more risk reduction than one large yearly exercise.
Related reading
- SecIQ penetration testing services — what we cover and what you receive.
- API authentication methods — the authentication failures that come up most in API testing.
- ISO 27001 readiness — where testing fits into a certification programme.