How to scope a penetration test properly
Scoping by asset count is the standard approach and it is why so many tests return nothing useful. Counting IP addresses and applications produces a price, not a result, because it says nothing about what the tester is trying to achieve. A test scoped as fifty external hosts will get a shallow look at fifty hosts. A test scoped as prove whether a customer can read another customer's data will get five days on the thing that would actually end your week badly.
Why does scoping by asset count produce weak results?
Because effort divides across the list. Testers work in fixed time, and a scope containing forty applications gives each one a few hours, which is enough to run tooling and confirm the obvious. The same budget aimed at the three applications that hold data or grant privilege buys the multi-step work where real findings live. Breadth and depth are traded against each other in every engagement, and the scope document is where you make that trade explicitly rather than by accident.
Asset counting also invites a specific failure: the supplier prices the surface you described, and the surface you described is the one you already know about. Anything undocumented, inherited, or spun up by a team outside the conversation stays outside the test, which is exactly where uncomfortable findings tend to be.
A more useful frame is to name the outcomes you would consider unacceptable, then let the tester decide which assets are on the path to them. Two or three objectives, written plainly, will restructure a proposal more than any amount of asset inventory detail.
What has to be in the scope document?
Six things, and most disputes after a test trace back to one of them being absent. The table below is the minimum set worth agreeing in writing before any work starts, because each one has a predictable failure mode when it is left implicit.
| Scope element | Why it matters | Common mistake |
|---|---|---|
| Objectives, stated as outcomes | Directs effort towards what would actually hurt | Listing assets instead, so effort spreads thin |
| Targets, by hostname, URL and account | Prevents testing something you do not own | Naming a domain that resolves to a shared platform |
| Environment: production or a copy | Determines what testing is safe and what is realistic | A staging copy with different data and different config |
| Exclusions and prohibited techniques | Keeps denial of service and social engineering out unless intended | Silence, then an argument about an outage |
| Credentials and roles to be supplied | Most of the surface is behind a login | Agreeing accounts but not who provisions them |
| Retest terms and the window they apply to | Decides whether verification costs extra later | Discovering the retest is a separate purchase order |
What should you deliberately leave out?
Anything you cannot act on, and anything you do not own. Excluding a third party SaaS platform is usually not a choice, because their terms forbid you testing it and their contract with you is the correct instrument for assurance instead. Excluding denial of service simulation is normal and sensible unless resilience is specifically the question, because proving you can be knocked over rarely tells you anything the team did not suspect.
Social engineering, phishing and physical intrusion are separate exercises with separate consent requirements, and folding them into a technical test dilutes both. If you want them, buy them as their own engagement with its own rules and its own briefing of whoever needs to know.
The exclusion that deserves the most thought is production. Testing a staging copy is safer and produces findings about staging. If the copy has different configuration, different data volumes, different integrations or a different authentication provider, the report describes a system you do not run. Where production testing genuinely is not possible, record the differences between the two environments in the report, so future readers know what the test could not have seen.
How do you scope a containerised or cloud-hosted system?
Scope it by trust boundary rather than by asset, because in a container estate the interesting question is not what is exposed but what happens after one workload is compromised. The useful objective is stated as an assumed breach: given code execution inside this pod, what can be reached. That single sentence brings the service account permissions, the cluster API, the instance metadata endpoint, network policy and secrets handling into scope without you having to enumerate any of it.
Cloud accounts need their own decision. Testing your own resources in a major cloud is generally permitted under the provider's customer testing policy, with denial of service simulation and anything touching shared or provider-managed infrastructure excluded or requiring a separate process. Policies change, so read the current one and keep a copy with the engagement paperwork rather than relying on what was true at the last test.
Include the control plane you actually use. A Kubernetes test that covers workloads but not the CI pipeline that deploys them, or the registry that stores images, misses the shortest route an attacker has to production. If the pipeline holds credentials that can deploy, it is part of the attack surface whether or not it appears in an asset register.
Who has to authorise a penetration test?
Whoever owns the systems, whoever owns the data, and whoever owns the infrastructure it runs on, which is frequently three different parties. Written authorisation from your own organisation is what makes the testing lawful rather than unauthorised access, and it needs to name the targets, the dates, the techniques permitted and the people who may perform them. Verbal approval from a project sponsor is not sufficient.
Where a system is hosted or operated by a third party, their permission is a separate requirement, and managed service contracts commonly restrict testing or require notice. The same applies in reverse if you are the host: your customers may need your authorisation, and your other tenants have not consented to anything.
Practical detail that gets forgotten: tell your own monitoring and response people, or decide deliberately not to. If your detection team is unaware, you will learn something real about your alerting, and you will also potentially trigger an incident response at cost. Both are legitimate choices. Making the choice by omission is not.
What questions expose an under-scoped proposal?
Ask how many days are manual and how they will be spent. A proposal that quotes a total duration without splitting testing, chaining, reporting and retesting is hiding the ratio, and the ratio is the product. Ask what the tester expects to spend the first day on, because if the answer is tooling and reconnaissance across a long asset list, the depth is already gone.
Ask what they would cut if you halved the budget. A supplier with a view will tell you which target holds the risk and offer to concentrate there. A supplier without one will offer to test everything less thoroughly, which is the worse outcome dressed as flexibility.
Then ask what is explicitly out of scope in their proposal and why. The answer separates firms that have thought about your system from firms that have priced a template. It also surfaces the assumptions you will otherwise discover in the report, when the phrase not tested appears next to something you assumed was covered.
Common questions
- What should a penetration test scope include?
- Objectives stated as outcomes rather than asset lists, the specific targets by hostname and URL, whether testing runs against production or a copy, the techniques and systems explicitly excluded, the credentials and user roles you will supply with named provisioners, and the retest terms including how long they remain valid. Every dispute after an engagement traces back to one of these being left implicit rather than written down.
- Should a penetration test run against production?
- Production gives the only findings that certainly apply to what you run, and it carries operational risk that must be managed with agreed windows, a contact who can stop the test, and exclusion of destructive techniques. A staging copy is safer but produces findings about staging. If configuration, data volumes, integrations or the authentication provider differ, record those differences in the report so readers know what the test could not have seen.
- How do you scope a Kubernetes penetration test?
- Scope it by trust boundary using an assumed breach objective: given code execution inside a given pod, what can be reached. That single framing pulls in service account permissions, the cluster API, the instance metadata endpoint, network policy and secrets handling without enumerating assets. Include the CI pipeline and image registry, because credentials that can deploy to production are part of the attack surface whether or not an asset register lists them.
- Do you need permission to run a penetration test?
- Yes, and typically from more than one party. Written authorisation from your own organisation naming targets, dates, permitted techniques and testers is what separates testing from unauthorised access. Third party hosts and managed service providers usually require their own approval, and many contracts restrict testing or demand notice. Cloud providers permit customer testing of customer-owned resources under a policy that excludes denial of service and shared infrastructure.
- How many days should a penetration test take?
- It depends on the objectives rather than the asset count, which is why proposals quoting days per host tell you little. The number that matters is how many of those days are manual testing rather than tooling, reporting and administration. Ask a supplier how they would spend a halved budget: a considered answer names the one target holding the risk, while an unconsidered one offers to test everything less thoroughly.
- Should you tell your security team about the test?
- It is a deliberate choice with consequences either way. Informing them avoids a costly incident response and lets them support access and monitoring. Not informing them tests whether your detection actually works, which is valuable but should be a decision made by someone senior enough to accept the disruption. What causes problems is neither deciding nor telling anyone, so an alert fires and a genuine response begins mid-engagement.
