A penetration testing scope is the documented boundary that maps every system, account, and process you plan to test against the business assurance goals and legal permissions behind the engagement. The single rule that governs good scoping: align every target you test to a specific risk or compliance objective, and get written permission before anyone touches it. The rest of this guide shows how to build that boundary properly, from stakeholder questions to sign-off.
TL;DR:
- Name each target by identifier, including domains, IP ranges, applications, APIs, cloud resources, privileged accounts, and integrations; assign testing depth to its risk objective.
- Record exclusions alongside included assets, especially third party infrastructure, denial of service, physical access, and unapproved social engineering; have both parties initial them.
- For cloud and SaaS systems, focus testing on configurations, access, application logic, and data handling you control; review independent attestations instead of probing provider infrastructure.
- When full coverage is impractical, choose samples across operating systems, patch levels, business functions, and privilege tiers, and document why each represents a wider group.
- Before testing, name approvers and escalation contacts, set blackout windows, and separately approve social engineering or live credential tests; record scope changes before testing resumes.
Table of Contents
- What Belongs Inside a Penetration Testing Scope
- What Falls Outside Scope, and Why That Matters
- Building the Scope Before Testing Starts
- Rules of Engagement and Permission to Test
- Scoping Cloud, SaaS and Third-Party Components
- Why Sampling Needs Its Own Justification
- How Scope Decisions Drive Timeline and Cost
- Documentation, Sign-Off, and Handling Scope Changes
- How Zero Through Scopes Penetration Tests Across Multiple Sites
- Scoping Mistakes That Keep Showing Up
- Getting Your Scope Right With Expert Support
- FAQ
- Sources
What Belongs Inside a Penetration Testing Scope
A workable scope names the technical targets precisely: IP ranges, domains, web and mobile applications, APIs, network segments, and cloud resources such as storage buckets or managed databases. Vague entries like “the main network” invite disputes later, so each item needs an identifier a tester can actually point a tool at.
Beyond the technical footprint, scope should capture data sensitivity and privileged access points. Cardholder data environments, admin consoles, and service accounts with elevated rights are frequent targets because compromising them causes the most damage.
Process and integration points matter just as much as endpoints, including new risks from AI integrations like prompt injection attacks addressed by prompt injection defense. CI/CD pipelines, configuration management layers, and monitoring tooling often sit outside the obvious attack surface but carry real risk if left unchecked.
Finally, scope should state testing depth, not just breadth:
- Surface testing: identifies exposed services and obvious misconfigurations quickly.
- Deep testing: includes credentialed access, privilege escalation attempts, and lateral movement.
- Hybrid approaches: apply deep testing to critical assets and surface testing elsewhere to manage cost.
Depth decisions should trace back to what you are trying to prove, whether that is compliance coverage or resilience against a specific threat scenario.
What Falls Outside Scope, and Why That Matters
Most engagements explicitly exclude certain targets and techniques, and naming them protects both sides from confusion once testing starts.
- Third-party infrastructure you do not own or control, including SaaS platform internals and shared hosting environments operated by vendors.
- Denial-of-service testing, which risks taking down production systems without delivering proportional security insight.
- Physical security testing, such as attempting building access, unless specifically agreed and planned for separately.
- Social engineering against staff who have not consented, which raises both legal and ethical concerns if not pre-approved.
Explicit exclusions do two things. They stop scope creep, where a tester drifts into systems nobody agreed to touch, and they protect you from liability if something breaks during testing. An exclusion that is assumed rather than written down tends to surface as a dispute after the fact, usually when a system goes offline and nobody can point to the clause that ruled it out.
Document exclusions in the same artifact as the inclusions, not as a separate afterthought, and have both parties initial that section specifically. A short rationale next to each exclusion (why it is out, and under what conditions it could be added back) saves time if the engagement needs to expand later.
Building the Scope Before Testing Starts
Good scoping is a conversation, not a form someone fills out alone. NCSC’s guidance on penetration testing recommends involving risk owners, technical staff, and the testing team together, and specifies that the scoping output should cover technical boundaries, test types, timeframe, and effort in resource days.
- Identify stakeholders: pull in the risk or compliance owner, technical leads for each system, legal counsel if contracts are involved, and a representative from the testing team.
- Ask ownership questions: who owns each system, which services are business-critical, what test windows avoid peak usage, and what level of service disruption is acceptable.
- Collect artefacts: network diagrams, data-flow maps, asset inventories, and any prior test reports that show what has already been covered.
- Draft the boundary: convert the answers into a written scope statement with explicit inclusions, exclusions, and depth per target.
- Validate with testers: have the testing team review the draft for gaps, unrealistic timelines, or targets that need more detail before work begins.
The SANS pen-test scope worksheet offers a practical format for walking through these questions with system owners, turning abstract scoping goals into concrete fields you can fill in during a single meeting.
Pro Tip: Bring last year’s inventory list to the first scoping meeting. Half the questions answer themselves once people see what changed.
Rules of Engagement and Permission to Test
Scope defines what gets tested. Rules of engagement (ROE) define how testing happens, and permission to test is the document that makes it legally sound.
A permission-to-test document should spell out:
- Named authorities on both sides who can approve changes or halt testing.
- Liability terms covering what happens if a system is disrupted during authorized activity.
- Blackout windows when testing must pause, such as month-end processing or peak retail periods.
- Escalation contacts available around the clock in case something goes wrong mid-test.
Sensitive techniques need separate, explicit approval rather than a blanket “test everything” clause. Social engineering campaigns, live credential testing, and persistence techniques that mimic real attacker behavior each carry distinct risk, and CREST’s Defensible Penetration Test guidance treats scoping as a collaborative phase where this kind of detail gets agreed before work starts, not improvised during it.
Change requests during an active test need a recorded process too: a short form or email thread confirming what changed, who approved it, and when. Skipping this step is one of the most common reasons engagements end in disputes about what was actually authorized.
Scoping Cloud, SaaS and Third-Party Components
Cloud and SaaS components need a different scoping logic than on-premises systems, because you rarely control the full stack. The shared-responsibility model usually puts infrastructure security on the provider and configuration, access control, and data handling on you, which is also where most testable risk lives.
- Test what you control: identity and access configurations, application logic, and data handling built on top of the platform.
- Use attestations instead of testing provider internals: independent certifications substitute for probing infrastructure you cannot legally or technically test.
- Prepare test accounts and monitoring: provisioning representative accounts ahead of time helps surface data flows that are not obvious from architecture diagrams alone.
- Define representative accounts for sampling: pick accounts that reflect real privilege levels rather than test-only configurations.
NCSC’s cloud provider guidance recommends relying on third-party validation evidence for provider-side controls and focusing testing effort on the components your organization actually manages. Many organizations discover during scoping that a meaningful share of their cloud footprint sits outside what they can legally test, which makes attestation review as important as the technical test plan itself. For estates spread across several locations, scoping security testing across multi-site environments often means repeating this cloud boundary exercise per region rather than assuming one answer covers every site.
Why Sampling Needs Its Own Justification
Testing every server, endpoint, and account in a large estate is rarely practical, which is why representative sampling is standard practice for bigger engagements. The method only holds up if the sample is chosen deliberately and the reasoning is written down.
- Select for diversity, not convenience: include different operating systems, patch levels, and business functions rather than whatever is easiest to access.
- Match account sampling to privilege tiers: a sample should include standard users, administrators, and service accounts, not just one tier.
- Document the methodology: record why each sampled item represents a broader group, and keep that justification on file for audits.
- Know when sampling is not enough: regulatory environments or known high-risk assets usually call for full coverage instead of a sample.
Retaining the sampling rationale matters as much as the sample itself, since an auditor or certification body will ask why a given server stood in for fifty others.
How Scope Decisions Drive Timeline and Cost
Breadth, depth, and intensity each push resource days up or down, and resource days are the main unit NCSC’s guidance uses when talking about scoping outputs tied to effort. A wider IP range, a more complex application, or credentialed testing that digs into privilege escalation all add time.
- IP and domain counts: more targets generally mean more testing days, though not in strict linear proportion.
- Application complexity: a multi-role application with several user tiers takes longer to test thoroughly than a static site.
- Credentialed testing: adds time because testers need provisioning, briefing, and often multiple privilege levels to work through.
- Retesting: budgeting a follow-up round to verify fixes avoids a second full-price engagement later.
Threat-led scoping, where targets are chosen based on realistic attack scenarios rather than testing everything equally, tends to concentrate budget on what matters most instead of spreading it thin.
Documentation, Sign-Off, and Handling Scope Changes
A defensible engagement produces a consistent set of artifacts, and skipping any of them tends to surface as a problem during an audit or a dispute later.
- Scope statement: the full list of inclusions, exclusions, and depth per target, agreed by both parties.
- Rules of engagement and permission to test: the legal and operational documents covering authorities, liabilities, and escalation contacts.
- Sample justification: the record showing why any sampled systems or accounts represent the broader estate.
- Final report: severity ratings, proof of exploitation where relevant, and a remediation roadmap tied to each finding.
- Sign-off record: written confirmation from the risk owner that the report and remediation plan are accepted, retained for audit purposes.
When testing uncovers something that needs a scope change mid-engagement, the right move is a documented statement-of-work amendment rather than an informal verbal agreement, so the change has the same paper trail as the original scope.
How Zero Through Scopes Penetration Tests Across Multiple Sites
We start every engagement by tying the proposed scope to a stated assurance goal, whether that is a compliance deadline or a specific threat scenario, before a single IP address gets added to the list. When operations span several locations, the scope incorporates cloud-aware sampling and permission to test is formalized with named approvers and escalation contacts at each site.
For multinational estates, we keep evidence retention consistent across regions so a sample justification collected in one country holds up the same way in an audit conducted in another. Scope documents are version-controlled, so every change request has a paper trail back to the original agreement.
Scoping Mistakes That Keep Showing Up
The same five mistakes account for most scoping disputes we see. Treating scope as a one-time document instead of something to revisit each engagement. Skipping legal review of the permission-to-test paperwork because “we did this last year.” Letting depth decisions default to whatever the testing team assumes rather than what the risk owner actually needs. Leaving cloud components out entirely instead of scoping what you do control. Forgetting to document why a sample is representative until someone asks during an audit.
- Write the scope statement down, every time, even for a repeat engagement.
- Get legal eyes on the permission-to-test document before signing.
- Tie depth choices to a named risk or compliance objective.
- Scope your side of the shared-responsibility line in cloud environments.
- Keep the sample justification on file from day one, not after the fact.
Pro Tip: If you cannot explain in one sentence why a system is in scope, it probably needs more thought before testing starts.
— Shirish
Getting Your Scope Right With Expert Support
Scoping a penetration test properly takes input from people who do it regularly, and that is exactly what we bring to a scoping workshop. We work through your estate with you, mapping technical targets to assurance goals before drafting the permission-to-test paperwork, so nothing gets tested without a documented reason and a signed approval.
- Scoping workshops: we sit down with your risk owners and technical leads to build the boundary before testing starts.
- Penetration testing: delivered against the agreed scope, with resource days and depth matched to your objectives.
- Managed SOC and SIEM services: extend assurance beyond a point-in-time test with ongoing detection once testing wraps up.
If you want a scope built around what actually matters to your business rather than a generic checklist, book a penetration testing scoping session with our team and get a documented plan before any testing begins.
FAQ
How do you scope a penetration test?
Start by identifying stakeholders (risk owners, technical leads, and testers), then list technical targets with identifiers like IP ranges and domains, agree on exclusions, and document everything in a scope statement signed by both parties. The SANS scope worksheet is a practical tool for walking through this with system owners.
What are the main stages of a penetration test?
Most methodologies follow planning and scoping, reconnaissance, scanning and vulnerability identification, exploitation, post-exploitation analysis, and reporting. The OWASP Testing Framework breaks these phases down further for web application testing specifically.
What does scope mean in security testing?
Scope in security testing is the agreed boundary of what will and will not be examined, covering specific systems, applications, data, and accounts along with the depth of testing applied to each. It exists so testers and clients agree on targets and limits before any work starts.
What is included in a cardholder data environment test scope?
Under PCI DSS penetration testing guidance, scope must cover the cardholder data environment perimeter, critical connected systems, and the segmentation controls that isolate that environment from the rest of the network. Segmentation testing specifically verifies that isolation actually works as designed.
How do you handle scope changes mid-engagement?
Scope changes should go through a documented statement-of-work amendment rather than a verbal agreement, with both parties confirming the change in writing before testing continues. This keeps the paper trail consistent with the original permission-to-test documentation and avoids disputes about what was authorized.
Sources
- CREST Defensible Penetration Test (CDPT) guidance
- Penetration testing — NCSC
- PCI DSS penetration testing guidance
- SANS pen-test scope worksheet
