Start with objectives, not asset lists
Good scoping begins with the question the test must answer. A compliance-driven web application test, a red-team exercise measuring detection, and a pre-launch review of a new API all demand different scopes. Agreeing the objective first prevents a mismatch between what the client needs and what gets tested.
The pre-engagement phase of PTES exists for exactly this purpose, and NIST SP 800-115 places planning ahead of discovery for the same reason.
Enumerate assets and environments precisely
List in-scope assets exactly: IP ranges and CIDR blocks, fully qualified domain names, specific applications and their user roles, mobile apps, APIs, and cloud accounts. Ambiguity here causes either wasted effort or accidental out-of-scope testing.
Decide which environment will be tested. Production carries the risk of disruption but reflects real exposure; staging is safer but must be a faithful mirror of production to be meaningful. Note any shared or third-party infrastructure that may require provider authorization.
- Record excluded systems and forbidden techniques (for example, no denial-of-service, no social engineering).
- Confirm ownership of every asset, especially cloud and SaaS components.
- For cloud platforms, check the provider's current testing policy before scanning.
Choose the testing perspective
The perspective determines how much information the tester starts with and which realistic attacker it simulates.
- Black box: no prior knowledge; simulates an external attacker but spends time on discovery.
- Grey box: partial knowledge such as credentials or documentation; balances realism with coverage and is the common default.
- White box: full access to source, architecture, and configuration; maximizes depth and is efficient for code and configuration review.
Set the rules of engagement
The rules of engagement (RoE) turn the scope into an operational agreement. It records testing windows, permitted and prohibited techniques, data-handling requirements, escalation and emergency contacts, and the stop condition for critical findings.
Written authorization is the non-negotiable core of the RoE. It confirms that an owner has approved the testing of the listed assets, which is what separates a penetration test from an offense.
- Define what happens if a critical vulnerability or an active compromise is discovered mid-test.
- Agree how sensitive data encountered during testing is handled and destroyed.
- Set communication cadence and a named point of contact on both sides.
Size the effort and lock the scope
Scope drives duration and cost. The number of applications, roles, endpoints, and IPs, combined with the chosen depth, determines the days required. Under-scoping produces shallow coverage; over-scoping wastes budget on low-value assets.
Once agreed, the scope is documented and signed. Changes during the engagement are handled through a controlled change process rather than informal expansion, so both coverage and authorization stay clear.
Related
FAQ
Should a penetration test run against production or staging?
It depends on risk tolerance and fidelity. Production reflects true exposure but risks disruption, so testing windows and safe techniques are agreed in advance. Staging is safer but only meaningful if it faithfully mirrors production configuration and data structures.
What is the difference between black, grey, and white box testing?
Black box gives the tester no prior information, grey box provides partial knowledge such as credentials or documentation, and white box provides full access including source and architecture. Grey box is a common default because it balances realism with efficient coverage.
What must the rules of engagement include?
At minimum: written authorization, in-scope and out-of-scope assets, testing windows, permitted and prohibited techniques, data-handling rules, escalation and emergency contacts, and a stop condition for critical findings.