How to Scope a Penetration Test: A Client's Checklist
A penetration test scope is the written agreement that lists every asset to be tested, the test types, the access the tester receives, the explicit exclusions, the rules of engagement, and the reporting and retest terms. CISA's Known Exploited Vulnerabilities catalog now tracks 1,779 vulnerabilities exploited in the wild, which makes a precise scope the difference between a report your auditors accept and one that proves too little. Clone Systems' automated external penetration tests start at $1,995 for one asset.
Your client walked into the scoping call with a network diagram. When you asked which decision the test was supposed to support, the answer was "just find the vulnerabilities." So the scope became whatever the vendor could quote for, and the report proved less than the client had intended. In scoping calls, we see this more often than any single technical gap: the scope document lists assets, but not the decision the test has to support.
That matters more in 2026 than it did two years ago. High-risk findings sat open for a median of 249 days at the laggards in Cobalt's 2026 analysis, versus 10 days at the top performers, based on 16,500 penetration tests [4]. A badly scoped test feeds that queue with findings nobody can act on, or misses the exact hole an attacker would walk through first. CISA added six more actively exploited vulnerabilities to its KEV catalog on November 10, 2026, including an XML external entity flaw in Cisco BroadWorks and an authentication bypass in Barracuda Email Security Gateway appliances [2]. If any of those products sit on your perimeter, you already know which assets belong in the next scope.
What Should Be in a Penetration Test Scope?
The scope statement must answer five questions before any testing begins: what the tester may touch, what kind of testing they will run, what access they receive, what is explicitly out of scope, and what the deliverable has to contain. Every element below has a job. Skip one, and you will argue about the missing piece after the test, when both sides have already spent money.
| Scope element | What it must answer | Typical requirement anchor |
|---|---|---|
| Assets and IP ranges | Exactly which systems, applications, and IP space are in scope, identified by FQDN or CIDR | PCI DSS 11.4.2 and 11.4.3 define internal and external scope [5] |
| Test types | External, internal, web application, API, wireless, social engineering | NIST SP 800-115 defines the testing methods and objectives [3] |
| Access level | Unauthenticated, authenticated, or domain admin; which credentials are provided | Gray box testing needs the credentials documented up front [6] |
| Exclusions | What the tester must never touch, and why | Exclusions must be written; verbal exclusions do not survive a report review |
| Rules of engagement | Time windows, escalation contact, abort conditions, data handling | NIST SP 800-115 covers test planning and authorization [3] |
| Reporting and retest | Deliverable format, severity scale, and whether fix verification is included | PCI DSS 11.4.4 requires retesting after fixes [5] |
The asset list is where most scopes fail. In our assessments, the gap between what a client believes is in their environment and what a scan actually finds is consistently larger than the client expected, which is exactly why the internal test matters (see our post on why internal penetration testing covers the majority of your servers).
What Do You Need to Prepare Before a Penetration Test?
You need four things: a current asset list, a written rules of engagement document, an escalation path, and a change window. NIST SP 800-115, the federal guide for security testing and assessment, is explicit that testing is a planned activity with documented objectives and authorization, not an improvisation [3]. The preparation work falls on your side of the table, not the tester's.
Here is the checklist we run through before every engagement. Save it as your own document and send it to your vendor with the RFP.
The 7-Point Penetration Test Scope Readiness Checklist
- Scope driver in one sentence. What decision does this test support: a PCI DSS audit, a SOC 2 evidence file, a cyber insurance renewal, an acquisition due diligence? Write it down; it decides everything that follows.
- Complete asset inventory. Every IP range, FQDN, application, and API endpoint you own, including forgotten test systems. If it is reachable, it is either in scope or explicitly excluded.
- Test types matched to the driver. External, internal, web application, API, or a combination. A single external test rarely satisfies a driver that involves an internal application or an API [1].
- Access decisions made. For internal or authenticated tests, decide which credentials you will provide and what level they carry. Unauthenticated black box work covers different ground than gray box work with a domain user [6].
- Exclusions written and justified. Every excluded asset gets a reason in the document. An exclusion without a reason becomes a gap an auditor will find.
- Rules of engagement agreed. Testing hours, the single named escalation contact, abort conditions, and how test data is handled and destroyed.
- Reporting and retest terms set. The severity scale you will use, the format your auditor expects, and whether retesting is included after you fix findings.
If you work through those seven points before you sign, the scope argument at the end of the engagement rarely happens.
Is a Penetration Test Scope Different From a Vulnerability Scan Scope?
Yes, and confusing them is how organizations end up with a scanner report and no test. A vulnerability scan scope is an inventory question: everything reachable gets probed for known weaknesses. A penetration test scope is an authorization question: what may a person actively attempt, and what must they prove? The two scopes overlap heavily, but the scan scope is almost always bigger, because a scanner has nothing to lose by touching one more host.
In our assessments, the most useful scoping exercise is to run the scan scope first and then deliberately shrink it to a test scope that maps to the scope driver. If the driver is PCI DSS, the scope has to line up with 11.4 (see our breakdown of PCI DSS requirement 11.4). If the driver is an API that recently had an incident, the API scope is the point, and the broader network is supporting cast. Our post on penetration testing versus vulnerability scanning covers the division of labor in more detail.
Can You Change the Scope After the Test Has Started?
You can, but only in writing. A scope change is a change to the agreement, so it belongs in a written change request that states what changed, why, and the effect on timeline and price. Verbal additions, like "oh, and the new staging environment," are how tests end up with findings nobody asked for and coverage nobody got.
Scope changes also have a compliance dimension. PCI DSS 11.4.2 and 11.4.3 require testing after any significant infrastructure or application change, not just on the annual calendar [5]. A major platform migration that lands mid-engagement is a legitimate scope change, and it may be the start of a new requirement to test the changed environment at all.
If you are comparing how different vendors price and handle scope, the penetration test cost guide breaks down what actually moves the number.
What Does PCI DSS Requirement 11.4 Require for Scope?
PCI DSS 11.4 is the one place where the scope document is also an audit artifact. The requirement family splits the work into internal, external, retest, and segmentation lines, each with its own frequency:
| PCI DSS requirement | What it requires | Where it lands in a scope document |
|---|---|---|
| 11.4.1 | A documented testing methodology covering the CDE and its boundaries | The methodology section of the SOW |
| 11.4.2 | Internal penetration testing at least every 12 months and after significant changes | Internal test scope: IP ranges and credentials [5] |
| 11.4.3 | External penetration testing at least every 12 months and after significant changes | External test scope: FQDNs and public IP space |
| 11.4.4 | Corrected vulnerabilities are verified by retesting | Retest terms inside the reporting section |
| 11.4.5 | Segmentation tested at least every 12 months (every 6 months for service providers) | A separate segmentation test line, if segmentation is your scope-reduction strategy |
Clone Systems sells both 11.4 halves online: automated external penetration testing starts at $1,995 for one asset, and automated internal tests start at $2,995 for 25 hosts, with retesting included.
How Clone Systems Can Help
Clone Systems runs penetration testing in three shapes: expert-led manual tests scoped to your environment, automated external and internal tests on a platform you can schedule, and continuous testing that keeps the scope current as your network changes. Automated external tests start at $1,995 per asset, authenticated web application tests start at $2,495, and expert-led manual tests are scoped to your specific drivers. See how Clone Systems compares with Pentera or with Intruder if you are choosing between platforms, and use the penetration testing buyer guide when you are evaluating more than one vendor. For the full service, see managed penetration testing services.
Frequently Asked Questions
What should be included in a penetration test scope? The scope statement must name every asset or IP range in scope, the test types, the access level the tester receives, the explicit exclusions, the rules of engagement, and the reporting and retest terms. Anything not named was never agreed, which is why exclusions belong in the document, not in a meeting.
What do I need to prepare for a penetration test? You need a current asset inventory, a written rules of engagement document, a named escalation contact, and agreed testing windows. NIST SP 800-115 treats all of this as part of test planning, so auditors expect it to exist before testing starts.
Is a penetration test scope different from a vulnerability scan scope? Yes: a scan scope is an inventory of everything to probe, while a test scope is an authorization of what a tester may attempt to exploit. The scan inventory usually starts the test scope, but the test scope must then be narrowed to the decision the test supports.
Can I change my penetration test scope after it starts? You can, through a written change request that records what changed and the effect on timeline and price. Verbal scope additions are not part of the agreement and create findings or gaps nobody asked for.
Does PCI DSS require both internal and external penetration testing? Yes. Requirement 11.4.2 requires internal testing and 11.4.3 requires external testing, both at least every 12 months and after significant infrastructure or application changes. They simulate different attacker positions, so one cannot substitute for the other [5].
Conclusion
A penetration test scope that lists assets but not the decision the test must support will produce a report that satisfies nobody. Work through the 7-point checklist before you sign, keep exclusions written and justified, and treat every mid-project change as a written amendment. If your next driver is a PCI DSS audit, an SOC 2 file, or an insurance renewal, start with the scope, not the price. You can request a scoping call on the Clone Systems contact page and get a scope document written against your actual environment.
References
[1] CISA, Known Exploited Vulnerabilities Catalog. 2026. https://www.cisa.gov/known-exploited-vulnerabilities-catalog [2] CISA, "CISA Adds Six Known Exploited Vulnerabilities to Catalog." 2026. https://www.cisa.gov/news-events/alerts/2026-11-10/cisa-adds-six-known-exploited-vulnerabilities-catalog [3] NIST, SP 800-115, "Technical Guide to Information Security Testing and Assessment." National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/115/final [4] Cobalt, "State of Pentesting 2026," data from 16,500 penetration tests. https://resource.cobalt.io/state-of-pentesting-2026 [5] Clone Systems, "PCI DSS Requirement 11.4 Penetration Testing Explained." https://www.clone-systems.com/pci-dss-penetration-test-requirement-11-4 [6] Clone Systems, "Black Box vs Gray Box vs White Box Penetration Testing." https://www.clone-systems.com/blog/black-box-vs-gray-box-vs-white-box-penetration-testing [7] Clone Systems, "Internal Penetration Testing: The Majority of Your Servers Your External Test Never Sees." https://www.clone-systems.com/blog/internal-penetration-testing-the-80-of-your-servers-your-external-test-never-sees [8] Clone Systems, "Penetration Testing vs Vulnerability Scanning." https://www.clone-systems.com/blog/penetration-testing-vs-vulnerability-scanning [9] Clone Systems, "Penetration Test Cost: What Moves the Number." https://www.clone-systems.com/blog/penetration-test-cost-what-moves-the-number [10] Clone Systems, "Managed Penetration Testing Services." https://www.clone-systems.com/managed-penetration-testing-services/