The scope of a penetration test (also known as the scope of work) defines what will be tested, including the systems, applications, networks, or physical locations that are in scope, and what testing methods are authorised. Critically, it also defines anything that should be explicitly excluded from being tested.
A well-defined scope ensures that testers focus their efforts on the assets that are most important to the organisation whilst avoiding disruption to critical systems or access to out-of-scope resources.
What a penetration test scope includes
The exact contents vary by assessment type, but a scope document normally records:
- The targets. Specific IP address ranges, domain names, application URLs, or physical sites that testing is authorised against.
- Exclusions. Systems, third-party services, or functionality that must not be touched. Anything hosted by a third party usually needs their written permission before it can be included.
- Test accounts and access. User accounts for each privilege level being tested, VPN access, or credentials needed to reach an internal environment.
- Authorised techniques. Whether exploitation is permitted, whether denial-of-service and social engineering are in or out, and any restrictions on automated tooling.
- Testing windows. The dates testing runs, and whether activity is restricted to particular hours to avoid affecting production.
- Assumptions and constraints. Rate limits, WAF configuration, environment stability, and anything else that affects what testing can realistically achieve.
Scope of work and rules of engagement
The two terms are often used interchangeably, but they cover different things. The scope defines what is tested. The rules of engagement define how it is tested: permitted techniques, escalation procedures for critical findings, and emergency contacts. Together they form the technical and contractual basis of an engagement.
A web application might be in scope, while the rules of engagement determine whether authenticated testing is permitted and what the tester should do if they find evidence of an existing compromise.
How scope is agreed
Scoping is a conversation between your technical team and the testing provider, usually before any quote is issued. The provider asks what the environment contains, which parts carry the most risk, and what the assessment needs to prove. You decide what is in and what is out.
Getting this wrong in either direction is costly. Too narrow a scope misses vulnerabilities in adjacent systems, or fails to test attack paths that cross a boundary. Too broad a scope spreads the same number of testing days across more targets, which produces a shallower assessment, or may bring additional cost for fuller coverage.
For worked examples of how this plays out in practice, see our guides to scoping a web application penetration test and scoping a network penetration test. If you already know roughly what you need, you can request a quote and we will confirm the scope with you before anything is agreed.
Changing scope during a test
A pentest scope is not always fixed once testing begins, and there may be valid reasons to justify scope-creep. A tester may discover systems nobody knew were exposed, or may need to follow an attack path into a segment that was not originally listed.
Changes like these should be documented and approved through a formal change control process, with written authorisation given to the provider before testing continues. This keeps accountability unambiguous on both sides and prevents a tester from operating outside what was authorised.