Accurate scoping is one of the most important stages of a penetration testing engagement. It determines what will be assessed, how much testing effort is required, and whether the final results will provide meaningful assurance against the risks an organisation is trying to understand.
A scope that is too narrow may exclude important systems, user roles, or integrations. A scope that is poorly defined can also lead to inaccurate pricing, delays during the assessment, or gaps between what the organisation expected and what was actually tested.
The scoping process does not need to be overly complicated. However, it does require a clear understanding of the environment, the objectives of the test, and the systems that could materially affect security. Providing the right information at the outset allows the testing provider to recommend an appropriate methodology and allocate sufficient time to the areas that matter most.
Understanding the objective
The first question is why the penetration test is being commissioned. Some organisations require testing to support a compliance framework, provide customer assurance, or meet a cyber insurance requirement. Others are preparing to launch a new platform, reviewing a recent change, or seeking a clearer understanding of their current exposure.
These objectives influence both scope and methodology. A test focused on validating a customer-facing SaaS platform may require detailed assessment of authentication, authorisation, business logic, APIs, and tenant isolation. An infrastructure-led engagement may instead focus on exposed services, network segmentation, or the routes an attacker could use to move through an internal environment.
Understanding what a penetration test is for can help stakeholders define clear objectives before scoping begins. Penetration testing provides a focused assessment of selected systems at a particular point in time. It should therefore be aligned with the organisation’s most relevant risks rather than treated as a generic review of the entire technology estate.
Identifying the type of testing required
The next step is to establish which areas of the environment need to be assessed. Penetration testing can cover external and internal infrastructure, web applications, APIs, mobile applications, cloud environments, wireless networks, and other specialist technologies.
In some cases, the required test type will be clear. An organisation launching a new customer portal may primarily require web application and API testing. A business concerned about ransomware exposure may need an internal network assessment focused on privilege escalation and lateral movement.
More complex environments often require a combination of approaches. A modern SaaS platform, for example, may include a web application, supporting APIs, cloud infrastructure, administrative interfaces, and third-party integrations. Testing only the visible application could leave important parts of the attack surface unassessed.
A provider offering CREST-accredited penetration testing services should be able to help translate business concerns into a practical technical scope, particularly where the correct testing approach is not immediately clear.
Scoping infrastructure and networks
For infrastructure testing, scoping normally begins with a list of target IP addresses, hostnames, and network ranges. It is also useful to explain what these assets do and whether any systems require special handling because of their operational importance. This gives the testing provider a clearer view of the environment than an asset count alone and helps explain the expected attack surface of each asset.
The scope should clarify whether the assessment is external, internal, or intended to cover both perspectives. External infrastructure testing focuses on the systems and services available from the internet, while internal testing examines what an attacker could achieve after gaining access to the network. This may include testing network segmentation, identifying routes between systems, and assessing opportunities for privilege escalation or lateral movement.
Any exclusions, operational constraints, or systems that require agreed testing windows should also be identified at this stage so that they can be reflected in the methodology and testing plan.
Scoping web applications and APIs
Application scoping requires more contextual information. A URL alone rarely provides enough detail to estimate the size or complexity of an assessment. The provider will usually need to understand the main areas of functionality, the number of user roles, and whether the application includes separate administrative or management interfaces.
The number of pages or API endpoints can provide a useful starting point, but these figures do not always reflect testing effort accurately. A relatively small application with complex financial workflows or granular permissions may require more manual analysis than a larger but simpler platform.
Sharing supporting information such as architecture diagrams, API documentation, user guides, or brief product demonstrations can improve the accuracy of the scope. These materials help the testing team understand how components interact and where security-sensitive functionality is concentrated.
Explaining user roles and access levels
Authenticated applications should be scoped around the different types of users that can access them. This is particularly important for SaaS platforms, portals, and systems with administrative or sensitive functionality restricted by user type.
A testing provider will usually need to know how many distinct user roles exist and what each role is permitted to do. This might include standard users, account managers, organisation administrators, platform administrators, support staff, or other privileged users.
Testing multiple roles allows the assessment to examine whether access controls are enforced consistently. It also helps identify horizontal privilege escalation, where one user can access another user’s data, and vertical privilege escalation, where a lower-privileged account can reach restricted functionality.
In multi-tenant applications, test accounts may be needed across more than one organisation or customer space. This allows the tester to assess whether tenant isolation controls prevent users from accessing data or functionality belonging to another customer.
Describing APIs and integrations
APIs are now a central part of many application environments and should be considered explicitly during scoping. Organisations should identify whether APIs support the main web application, mobile clients, customer integrations, administrative functionality, or communication with external services.
Where available, API documentation such as an OpenAPI specification can substantially improve the quality of the scoping process. It helps establish the number of endpoints, authentication methods, available operations, and the types of data being processed.
Third-party integrations also need consideration. Payment providers, identity platforms, customer relationship management systems, file storage services, and workflow tools can all influence the application’s security model.
The aim is not necessarily to test every external supplier. Instead, the penetration testing provider needs to understand how the application communicates with those services and whether integrations introduce security-sensitive inputs, callbacks, permissions, or trust relationships.
Scoping cloud environments
Where cloud infrastructure forms part of the assessment, the provider will need more than a list of public endpoints. Useful information may include the cloud platforms in use, the number of accounts or subscriptions, the services deployed, and the level of access available to the testing team.
The required detail depends on whether the assessment is being performed from an external perspective or as an authenticated cloud configuration review. An external test may focus on the services exposed to the internet, while an authenticated assessment may examine identity permissions, storage configuration, network controls, and trust relationships.
Infrastructure diagrams can be particularly helpful in complex deployments. They allow testers to understand how applications, databases, storage services, identity providers, and management systems connect to one another.
Testing in staging vs production environments
Organisations should also confirm whether the assessment will be performed against staging or production. Both options can be appropriate, depending on the objective and the level of parity between the environments.
A staging environment may provide more flexibility and reduce operational risk. Production testing generally provides stronger assurance that the assessment reflects the environment that may be targeted.
Where staging is used, the provider should understand whether it mirrors production infrastructure, configuration, integrations, and access controls. Material differences can affect the relevance of the findings.
Any restrictions on testing should also be agreed during scoping. This may include systems that must not be disrupted, techniques that require prior approval, or specific testing windows. These constraints can be accommodated, but they need to be understood before the engagement begins.
Clarifying reporting and compliance requirements
Reporting expectations can influence the amount of work involved in an assessment. Most organisations require a technical report containing findings, evidence, risk ratings, and remediation guidance. Some also need an executive summary, compliance mapping, supplier questionnaires, or a formal letter confirming that testing has taken place.
It is useful to identify these requirements during scoping rather than after testing has been completed. This allows the provider to ensure that the reporting format supports the organisation’s intended use, whether that is internal remediation, customer assurance, audit evidence, or regulatory review.
Retesting requirements should also be discussed. Where remediation validation is expected, the proposal should explain whether retesting is included, how long it remains available, and what evidence will be provided once fixes have been confirmed.
How scope affects the cost
Testing cost is primarily driven by the time and specialist effort required to assess the agreed scope. The number of systems matters, but complexity, user roles, integrations, and testing depth are often more significant than asset counts.
Providing incomplete information can result in a proposal based on assumptions. If the environment is more complex than expected, additional time may be needed or parts of the assessment may receive less attention than intended.
A well-defined scope makes penetration testing cost more predictable and allows proposals from different providers to be compared on a more consistent basis. It also helps distinguish genuine differences in methodology from quotes that appear cheaper because they include less testing.
Common scoping problems and challenges
One of the most common scoping issues is focusing only on the most visible component of an environment. An organisation may request testing of a web application while excluding an API that handles most of its data and business logic. Similarly, an infrastructure scope may include public IP addresses but omit cloud-hosted services or administrative networks.
A common problem with web application scoping is underestimating the significance of user roles. Testing with a single account can provide useful findings, but it may not reveal whether privileges are enforced correctly across different users, customers, or administrative functions.
Older documentation can also cause problems where the application or infrastructure has changed significantly. Scoping information should reflect the current environment, particularly where recent releases, migrations, or integrations have altered the attack surface.
How can Sentrium help?
A well-defined scope improves more than pricing. It supports stronger testing outcomes, clearer reporting, and greater confidence that the resulting assessment reflects the organisation’s real security risk.
By defining scope clearly and engaging experienced providers of penetration testing services like Sentrium, organisations can ensure that testing delivers meaningful value while maintaining an appropriate balance between cost and assurance.
Ready to get a clear, tailored penetration testing quote? Complete our short form to request a quote based on your environment, scope, and security requirements.
If you would prefer to discuss your requirements first, contact our team to talk through your environment, scope, and testing objectives before requesting a penetration testing quote.
