Pentest Process: Scoping
What is scoping?
Scoping is the first phase of a penetration test, during which a pentester and an organization formally define which systems may be tested, how the testing will be conducted, and what constitutes a successful outcome. This phase is often referred to as the planning or pre-engagement stage, as it establishes both the technical and legal boundaries of the engagement.
In the sections that follow, scoping is broken down into a set of core components. Each component helps ensure that the penetration test is conducted in a controlled, authorized, and well-defined manner, with clear expectations around scope, execution, and success criteria.
Rules of Engagement
Rules of Engagement (RoE) define the legal authorization and operational conditions under which a penetration test is performed. They confirm that testing activities have been formally approved and establish the constraints that govern how, when, and by whom testing may be carried out. RoE exist to protect both the organization and the tester by ensuring that all actions taken during the engagement are intentional, traceable, and within agreed boundaries.
A well-defined RoE typically specifies the approved testing window, escalation and emergency contacts, evidence handling requirements, and expectations for reporting and communication. It may also outline conditions under which testing must be paused or stopped, such as service instability or unexpected impact. This is critical, as the RoE serves as a legal document that protects both the organization and the tester and may also be used to establish liability if testing activities cause disruption and are not conducted in accordance with the agreed terms.
Engagement Type
Penetration tests are commonly categorized as black box, grey box, or white box engagements, based on the level of information and access provided to the tester at the start of the assessment. These engagement types define the tester’s starting position and are closely tied to authentication scope.
In a black box engagement, no credentials or internal knowledge are provided. Grey box engagements typically include limited information or low-privileged credentials, while white box engagements may involve multiple accounts, roles, or some network architecture context.
Each model serves a different purpose, so it is vital that the engagement type is clearly defined and agreed upon before testing begins.
Core Scoping Elements
The following elements define the practical boundaries of a penetration test, starting with authentication scope, then outlining in-scope and out-of-scope assets, and concluding with authorized time-based constraints.
Authentication Scope
Authentication scope defines who the tester is permitted to act as during the engagement and is typically determined by the agreed engagement type. It specifies whether credentials are provided, the privilege level of those accounts, and the systems or applications where they may be used. At a minimum, authentication scope should clearly state whether testing is performed without credentials, with a single low-privileged user, or with multiple roles or accounts. This is typically documented using clear, contractual language, for example:
The tester shall be provided with the credentials “user1@examplecorp.local”, which are designated as a low-privileged domain user account and are explicitly included within the authorized scope of this engagement. Use of these credentials is limited to enumeration of directory objects, access to network resources ordinarily available to the account, and identification of misconfigurations or excessive permissions associated with its assigned privileges.
This level of specificity ensures that the tester’s actions are clearly bounded and auditable, and that any access obtained beyond the defined authentication scope can be confidently attributed to a genuine security weakness rather than assumption.
In-Scope vs Out-of-Scope Assets
In a pre-engagement document, one of the most critical items to be defined is the distinction between in-scope and out-of-scope assets. These definitions establish the technical boundaries of the engagement and determine where testing is permitted to occur. This may include specific IP subnets or ranges, applications, and systems explicitly approved for assessment. Below is a list of assets that are typically classified as in-scope or out-of-scope during a penetration test:
| In-Scope Assets | Out-of-Scope Assets |
|---|---|
| Certain external IP ranges owned by the organization | Third-party infrastructure (cloud services, vendors) |
| Internal network subnets | Payment processing systems |
| Public-facing web applications | Production databases with sensitive live data |
| APIs and backend services | Legacy or unstable systems |
| VPN gateways and remote access services | Monitoring, logging, or SOC systems |
| Active Directory domains or specific OUs | Personal or employee-owned devices |
| Test or staging environments (if approved) | Systems explicitly excluded in the RoE |
Note: This list is simply a general reference based on common scoping practices across typical penetration testing engagements. Actual in-scope and out-of-scope assets will vary depending on organizational risk tolerance, and the assessment objectives.
During enumeration, a tester may identify routes, DNS records, or hosts that reference systems outside the defined scope. For example, an engagement may specify the following boundaries:
10.10.10.0/24— in scope172.16.0.0/16— in scope after VPN accessDevelopment subnet— explicitly excluded
Discovered assets that fall outside these boundaries must not be exploited. Instead, their existence and potential exposure should be documented in the penetration testing report with sufficient detail to clearly communicate risk, impact, and recommended remediation to both technical and business stakeholders.
Authorized Testing Window
In addition to asset boundaries, scoping may also impose time-based constraints on testing activity. For example, an organization may only authorize penetration testing for a defined period with certain explicitly defined conditions:
Testing is permitted only between 10:00 pm and 05:00 am local time to minimize impact on business operations. Testing is not allowed during scheduled maintenance windows or critical business events. Any activity detected outside the approved testing window will be treated as unauthorized and immediately reported.
Defining authorized testing windows in this manner ensures that testing activity is predictable, clearly distinguishable from genuine security incidents, and aligned with the organization’s operational constraints.
Allowed and Disallowed Techniques
A penetration test or security assessment is not a capture-the-flag exercise. Unstable or improperly tested tooling can disrupt services, corrupt data, or damage systems. When conducted irresponsibly, such actions can result in serious operational and legal consequences for both the tester and the organization. For this reason, it is essential to clearly define which techniques are permitted and which are explicitly disallowed for the engagement.
These techniques may include password spraying, brute-force attempts, exploitation of known vulnerabilities, privilege escalation, web scraping, lateral movement or attack chaining, aggressive port scanning, credential harvesting, and Denial of Service (DoS) techniques. Each technique should be explicitly permitted, restricted, or disallowed to prevent ambiguity. If a technique is not clearly allowed, it should be treated as disallowed by default.
Clearly documenting these boundaries ensures that testing remains controlled and aligned with the organization’s risk tolerance. It also ensures that any impact demonstrated during testing can be directly traced to an approved action performed within the agreed scope of the engagement.
Success Criteria
Success criteria define what constitutes an acceptable and meaningful outcome for the penetration test. Rather than focusing on the number of vulnerabilities identified or systems accessed, success should be measured by demonstrable risk and impact within the agreed scope. This may include unauthorized access to sensitive data, privilege escalation beyond the initial authentication scope, compromise of critical systems, or the ability to abuse trust relationships or business logic.
Clearly defining success criteria ensures that both the tester and the organization share a common understanding of the engagement’s objectives. It also provides a basis for evaluating results, prioritizing remediation, and determining whether the assessment has effectively answered the security questions it was intended to address.
Moving into Reconnaissance
With all the above conditions defined and agreed upon by both parties, the assessment can now proceed into reconnaissance and enumeration phase. This is where the tester begins mapping the attack surface and identifying viable attack paths within the agreed scope. How this phase is conducted largely determines the effectiveness of everything that follows and is the focus of the next article in this series.