What a good pentest scope looks like

A penetration test is only as good as its scope. Too narrow, and the test misses the paths an attacker would actually take. Too broad, and the testing days are spread so thin that nothing is examined in depth. Most disappointing pentests were decided before the first packet was sent, in a scoping call that listed some IP addresses and moved on.

This guide works for both sides of the table: the client deciding what to test, and the pentest company turning that into a plan.

Start with what you are protecting

The most useful scoping conversations start with outcomes rather than assets. What would hurt most if an attacker reached it? Customer data, the payment flow, the administration console, the build pipeline, the identity provider that everything trusts. Write that list first.

Then work outwards. For each item, which systems store it, process it, or can reach it? That second list is the beginning of a real scope, and it usually includes systems nobody thought of as security-relevant.

List every way in

Attackers do not follow the org chart. For each thing you are protecting, list the routes an attacker could use to reach it:

• Internet-facing applications and APIs, including the back end of the mobile app
• Remote access: VPNs, virtual desktops, bastion hosts and third-party support tools
• Identity: single sign-on, password reset flows, service accounts and API keys
• Cloud control planes, and the CI/CD pipeline that deploys into them
• Suppliers and integrations with standing access to your systems

Include the systems you would rather not mention. The legacy VPN, the staging environment that holds a copy of production data and the forgotten marketing site on the same domain are exactly where real attacks start.

Be explicit about what is out of scope

Exclusions deserve as much care as inclusions. Write down what is out of scope and why: a system owned by a third party who has not given permission, a fragile production database, a shared hosting platform. An exclusion without a reason tends to become permanent, and turns into a blind spot nobody remembers agreeing to.

Third-party services need particular care. Cloud providers publish testing policies, and most SaaS vendors require written permission before anyone tests their platform. Confirm both before testing starts, not halfway through.

Prepare before the scoping call

A scoping call goes faster, and ends with a better scope, when the client arrives with a few answers ready:

• An inventory of what is in scope: domains, IP ranges, applications, APIs and cloud accounts
• What has changed since the last test: new features, new infrastructure, a migration
• The findings from the last test, and which of them are still open
• Any compliance driver, such as PCI DSS, ISO 27001 or a customer's security questionnaire
• Who will provide accounts, answer questions and receive critical findings during the test

For the pentest company, the call is the moment to ask what would make the test a success for the client. The answer is rarely a long list of findings. It is usually confidence about a specific system, a launch or an audit, and the scope should be built around that.

Scope by test type

Each kind of test needs its own details:

• Web applications and APIs: the environments, user roles, main functions or endpoints, API documentation, and anything that sends email or takes payments
• External infrastructure: every internet-facing IP range and domain, including cloud-hosted services and anything a supplier runs on your behalf
• Internal networks: where the test starts (an office network point, a standard laptop or a VPN account) and which segments matter most
• Mobile applications: the builds for each platform, the back-end APIs they call, and whether rooted or jailbroken devices are in scope
• Cloud configuration reviews: which accounts or subscriptions, and read-only access for the reviewers

Choose the right depth

How much the testers are told changes what the test can find. A black-box test, with no inside knowledge, shows what an outsider sees, but spends days on discovery that you could have provided. A grey-box test, with accounts and documentation, spends that time on the application itself. A white-box test adds source code or architecture access, and finds the most for the time spent.

For most web applications and APIs, grey box gives the best value per testing day. Whatever the approach, provide test accounts for every role. Access control flaws hide between roles: what can a standard user do with an administrator's request, or one customer with another customer's identifier? One account cannot answer those questions.

Agree the rules of engagement in writing

Rules of engagement turn a scope into a plan that everyone can follow. At a minimum, they should cover:

• Testing windows and time zones, including any change freezes
• The source IP addresses the testers will use, so monitoring teams recognise them
• Techniques that need approval first, such as denial of service, social engineering or destructive payloads
• An emergency contact on each side who can pause testing within minutes
• How critical findings are reported during the test, rather than weeks later in the report

Agreeing these up front avoids the most common way testing days are lost: a tester blocked by a firewall, an expired account or an unanswered email.

Size it honestly

Testing time should follow the complexity of the target, not a round number. Useful signals are the number of user roles, the number of distinct functions or API endpoints, the integrations, and how much has changed since the last test. If the budget is fixed, narrow the scope and test it properly rather than covering everything lightly. A thorough test of the payment flow is worth more than a skim of the whole estate.

Plan the retest before you start

A finding is only closed when the fix is proven. Agree up front how retests are requested, how long after the report they are available, and what evidence closes a finding. Booking the retest at the start keeps remediation moving instead of drifting once the report lands.

Common scoping mistakes

• Scoping by IP range alone, without saying which applications run there
• Testing a staging environment that is nothing like production, or production when a faithful staging copy would do
• One test account for an application with five roles
• Leaving out the API because the web front end is in scope
• Finding out on the first morning that the testers' source IPs are blocked

A scope checklist

1. The assets and data the test protects, and why they matter
2. Every in-scope system, with addresses, URLs and environments
3. What is out of scope, with a reason for each exclusion
4. Written permission from third parties and cloud providers
5. Test accounts for every role, plus any documentation
6. Rules of engagement: windows, source IPs, approvals and contacts
7. How critical findings are escalated during testing
8. How and when retests happen

Keeping the scope in the record

In Cerberos Nexus, the scope, milestones and team sit in the project from the first day, and every required item on the methodology checklist has to be addressed before a pentest moves to reporting. When the client requests a retest from the Client Portal, the result is recorded against the original finding, so the report carries the retest history. See how penetration tests run in the platform.