Key Takeaways
- Start with your business objectives before deciding what type of penetration test you need.
- Internal and external penetration testing answer different security questions. Whether you need one or both depends on your objectives and environment.
- Clearly define both in-scope and out-of-scope assets before testing begins.
- Agree Rules of Engagement, including testing windows, exploitation limits and escalation procedures.
- A penetration testing provider should ask detailed scoping questions and require written authorisation before testing takes place.
On this page
- How Do You Define Your Penetration Testing Objectives?
- What Type of Penetration Test Do You Need?
- How Should Different Asset Types Be Scoped?
- What Authentication and Access Will Testers Need?
- Should You Use Black Box, Grey Box or White Box Testing?
- Which Assets Should Be Included in the Penetration Test Scope?
- What Should Be Out of Scope?
- What Are Rules of Engagement?
- What Information Does a Penetration Testing Company Need Before Providing a Quote?
- Why Is Written Authorisation Important?
- Scope Your Penetration Test with OmniCyber
- Related Questions
How to Scope a Penetration Test
Scoping a penetration test is the process of defining what will be tested, how it will be tested and what the assessment needs to demonstrate before an engagement begins. To scope a penetration test effectively:
- Define your objectives
- Identify the systems and access paths to be tested
- Choose the testing perspective, whether internal, external or both
- Define what is in scope and out of scope
- Agree the Rules of Engagement
A well-defined scope gives testers enough information to plan an effective assessment and provide an accurate quote.
How Do You Define Your Penetration Testing Objectives?
Your penetration testing objectives should explain why you are carrying out the assessment and what you need it to demonstrate. This might be to meet a compliance requirement, validate security controls or assess a specific attack scenario.
Clear objectives help determine the scope, methodology and reporting requirements.
Start with why you need the test, since this shapes everything that follows. Common drivers include:
- Compliance validation, such as ISO 27001, PCI DSS, NHS DSPT or DORA
- Preparing for a customer or auditor request
- General security assurance
- Testing a specific attack scenario
It is also useful to define what a successful assessment needs to establish. For example, you might want to understand whether an internet-facing system can be compromised, whether a standard user could gain access to privileged information, or whether your security controls meet a particular customer or compliance requirement.
If a compliance framework is driving the test, confirm what that framework requires. Some frameworks specify particular testing frequencies, scope or evidence requirements. This helps ensure the engagement provides the evidence you need rather than a generic assessment that falls short at audit.
What Type of Penetration Test Do You Need?
The type of penetration test you require depends on the systems being assessed, the level of access being simulated and the security questions you want answered.
One of the first decisions is whether the assessment needs an internal perspective, an external perspective or both.
Internal vs External Penetration Testing
External penetration testing simulates an attacker with no prior access, assessing systems exposed to the internet such as firewalls, VPNs, public-facing servers and internet-facing applications.
Internal penetration testing starts from the assumption that an attacker, compromised device or malicious insider already has access to the internal environment. It assesses what they could achieve through techniques such as privilege escalation, lateral movement and access to sensitive systems.
The two approaches answer different questions. External testing helps determine how an attacker might gain access from the internet, while internal testing examines what could happen after an internal foothold has been established.
Whether you need one or both should be determined by your objectives, environment, risk profile and any applicable compliance requirements.
How Should Different Asset Types Be Scoped?
Web applications, mobile applications, APIs and network infrastructure have different testing requirements and should be identified separately when defining the scope.
For a web application, the scope should specify important functionality and the number of user roles that need to be tested. Authenticated applications may require access as several different roles to properly assess authorisation controls.
Important functionality might include:
- Payment functionality
- File uploads
- User-generated content
- Administrative functionality
- Integrations with other systems
API testing should identify the endpoints to be tested, the authentication method and any relevant documentation. Undocumented or legacy endpoints can easily be overlooked during initial scoping, potentially leaving part of the attack surface untested.
For example, a web application scope might include one customer-facing application, three authenticated user roles and its associated API, while excluding a third-party payment platform that is managed by another provider.
Being this specific helps both the organisation and the testing team understand exactly what the engagement covers.
What Authentication and Access Will Testers Need?
Authentication requirements should be agreed before testing begins.
Consider:
- How many distinct user roles or permission levels exist?
- Should each role be tested separately?
- Will testers receive dedicated test accounts?
- Does the registration or authentication process itself need to be assessed?
- Are there third-party authentication or single sign-on integrations?
- Is multi-factor authentication enabled?
- Are privileged or administrative accounts included?
The answers can materially affect the amount of testing required.
For example, testing an application using only a standard user account is different from assessing authorisation across standard users, managers and administrators. Each role can expose different functionality and potential privilege boundaries.
Providing this information during scoping allows the testing provider to estimate the required effort more accurately.
Should You Use Black Box, Grey Box or White Box Testing?
The amount of information and access given to testers should also be agreed during scoping.
- Black box: Testers begin with little or no prior knowledge of the system, more closely reflecting an attacker without inside information.
- White box: Testers receive extensive information such as architecture documentation, technical details and, where relevant to the engagement, source code.
- Grey box: Testers receive partial knowledge or access, such as a standard user account or selected technical information.
The right approach depends on what you want the assessment to demonstrate.
Grey box testing is commonly used where authenticated access forms part of the assessment because it allows testers to spend more of the available testing time examining security controls rather than attempting to discover information the organisation could provide upfront.
Which Assets Should Be Included in the Penetration Test Scope?
A penetration test scope should include the systems, applications and services needed to answer your security objectives. It should also clearly document anything intentionally excluded.
Depending on the engagement, in-scope assets could include:
- External-facing infrastructure such as websites, VPNs and mail servers
- Internal network segments
- Web applications
- Mobile applications
- APIs
- Cloud infrastructure such as AWS, Azure or GCP
Avoid defining scope solely around the newest or most visible system. Older infrastructure, administrative interfaces and supporting services can form part of the same attack path and should be considered when deciding what needs to be assessed.
A practical scope might look like:
In scope: Two external IP ranges, one customer web application, three authenticated user roles and 35 documented API endpoints.
Out of scope: Third-party payment processing, denial-of-service testing and a legacy production server that cannot tolerate active testing.
This level of detail reduces ambiguity before the engagement starts.
What Should Be Out of Scope?
Defining exclusions is just as important as defining what will be tested.
Common exclusions can include:
- Third-party hosted services
- Fragile legacy systems
- Systems where the organisation does not have authority to permit testing
- Specific production systems where particular testing techniques would create unacceptable operational risk
- Denial-of-service or other disruptive testing techniques
Exclusions should be explicitly documented rather than assumed.
This is particularly important where an application depends on third-party infrastructure. The organisation commissioning the test might have permission to test its own application but not the underlying systems or services operated by another provider.
What Are The Rules of Engagement?
Rules of Engagement define how the penetration test will be carried out.
Scope defines what can be tested. The Rules of Engagement define the conditions under which that testing takes place.
These should normally cover:
- Testing windows
- Permitted testing techniques
- Exploitation limits
- Communication procedures
- Escalation contacts
- Stop conditions
Agreeing these conditions before testing starts helps both the organisation and the testing team understand how the assessment will be conducted and where the boundaries lie.
What Information Does a Penetration Testing Company Need Before Providing a Quote?
A penetration testing provider needs enough technical and organisational information to estimate the time, effort and expertise required for the assessment.
The exact information depends on the engagement, but typically includes:
- The objectives of the test
- The systems, applications or networks in scope
- The number of IP addresses, applications or API endpoints
- The number of authenticated user roles
- Relevant technologies and integrations
- Whether testing is internal, external or both
- The required testing approach and depth
- Any significant exclusions or operational restrictions
- Reporting or compliance requirements
- Whether retesting is included once identified vulnerabilities have been remediated
Two organisations asking for a penetration test of a “web application” could require substantially different levels of effort. A small application with one user role and limited functionality is very different from an application with multiple privilege levels, dozens of API endpoints, file uploads, payment functionality and several external integrations.
This is why an accurate quote depends on understanding the scope rather than simply knowing the type of penetration test required.
Why Is Written Authorisation Important?
Penetration testing should not begin until the testing provider has clear written authorisation from the organisation responsible for the systems being assessed.
The authorisation should confirm the agreed scope and permission to conduct the testing activities described in the engagement.
This is particularly important when third-party infrastructure or services are involved. Permission from the organisation commissioning the test does not necessarily provide authority to test systems owned or operated by another party.
Any third-party approval requirements should therefore be identified during scoping rather than after testing has started.
Scope Your Penetration Test with OmniCyber
Every effective penetration test starts with an effective scope.
OmniCyber is CREST-certified for penetration testing and an approved Crown Commercial Supplier. Each engagement begins with a structured scoping process to understand your objectives, identify the systems and applications relevant to the assessment and define a scope that reflects your security requirements and business risks.
Rather than starting with a generic testing checklist, the scope is built around what you need the assessment to demonstrate and the systems required to answer those questions.
Related Questions
Do I need internal and external penetration testing, or just one?
Internal and external testing assess different attack paths. Whether you need one or both depends on your objectives, environment, risk profile and any compliance or customer requirements.
How does penetration test scope affect cost?
The size and complexity of the scope directly affect the testing time required, and therefore the cost.
What if I don’t know what needs testing yet?
You do not need to arrive with a completed penetration testing scope. A good provider should use the discovery and scoping process to understand your objectives, identify relevant systems and help determine what needs to be included.
Ready to scope your test? Request a Scoped Pen Test Quote and speak to a CREST-certified tester about your environment.
Jennifer Goulbourne
Jennifer is a Digital Marketing Executive at OmniCyber Security, where she's responsible for engaging the company's existing customer base across digital channels and creating helpful resources on threat intelligence and security operations for cybersecurity professionals and business leaders.
