The scope document is the most consequential decision in a penetration testing engagement. Everything the test produces (findings, evidence, compliance documentation) is bounded by the scope. A clean report on a poorly defined scope does not mean the organisation is secure. It means no exploitable vulnerabilities were found in the surface the vendor was allowed to test.
Most scope problems fall into one of three categories. The scope is too narrow: critical attack surfaces are excluded, leaving unknown risk. The scope is vague: the vendor fills ambiguity in their favour, testing the easiest surfaces and leaving harder ones untested. Or the scope does not match the compliance obligation: the test was designed for security improvement rather than compliance evidence, and neither goal was met well.
This guide walks through every scope dimension as a practical decision: what to include, why it matters, what gets missed when it is not addressed, and what good looks like in the scope document.
Before engaging with individual scope dimensions, establish the principle: the scope document is a binding agreement that determines what the tester is authorised to test and what they are not. Ambiguity in the scope document resolves against you as the buyer, because the vendor will interpret unclear boundaries conservatively to avoid exceeding authorised access.
A well-written scope document should allow any two parties to read it and independently reach the same conclusions about whether a specific system, technique, or target is in scope. If it cannot pass that test, rewrite it before signing.
The most fundamental scope question: exactly which systems, applications, IP addresses, and URLs are included in the assessment?
What to enumerate explicitly:
For web application testing: the base URL and all subdomains in scope, including staging and administrative interfaces if they should be tested. Do not rely on "the web application and associated infrastructure": this is the single most common source of scope disputes.
For network testing: specific IP ranges or subnets, not "the internal network." If the assessment should cover all systems on 10.0.0.0/8, state that. If it should cover only the server VLAN at 10.1.0.0/24, state that.
For API testing: enumerate specific API endpoints or OpenAPI/Swagger documentation location if the full API surface is in scope. If only the public-facing API is in scope and the internal API is not, state both explicitly.
What gets missed when systems are defined vaguely:
Unknown and unmanaged assets. The forgotten subdomain running an outdated CMS. The development environment exposed to the internet. The cloud storage bucket with public access. These are the assets most likely to produce high-severity findings, and they are most likely to be excluded from scope when the scope document was built from the organisation's own asset inventory rather than from attacker-perspective discovery.
What a real web application penetration test should cover maps the twelve coverage dimensions that comprehensive web application scope requires. Network penetration testing: what it covers and how it's done covers what comprehensive network scope should include.
For application testing, scope definition must specify every user role that should be tested and confirm that credentials exist for each one before testing begins.
Why this matters: Authorization testing requires operating simultaneously as multiple users with different permission levels. A tester with only a standard user account cannot test whether standard users can reach administrator functions. A tester with only an administrator account cannot test whether the application correctly restricts what standard users can access.
What to specify:
Every user role the application supports that should be tested. For a typical SaaS application: unauthenticated visitor, standard user, team administrator, billing administrator, organisation owner, support staff, and system administrator. Each requires a separate test account.
Confirm that test accounts exist, that they have realistic permissions (not artificially elevated beyond what the role should have), that they work in the test environment before testing begins, and that multi-factor authentication is either configured on the test account or that MFA bypass is explicitly addressed in the rules of engagement.
What gets missed: Untested user roles leave entire permission boundaries unexamined. The finding that a billing administrator can access another organisation's payment data only appears if the billing administrator role is in scope and tested.
Modern applications expose most of their functionality through APIs. Web application scope that does not explicitly include API testing leaves the most technically interesting surface out of scope.
API types that require explicit scoping:
REST APIs: list the base URL and documentation location. Specify whether all endpoints are in scope or only a subset.
GraphQL: explicitly include if the application uses GraphQL. GraphQL testing requires specific methodology for introspection, query complexity, and resolver-level authorization testing that differs from REST testing. See API vulnerabilities standard penetration tests miss for the eight classes that need explicit coverage.
WebSocket connections: if the application uses WebSocket for real-time functionality, specify whether WebSocket message-level security is in scope.
Third-party API integrations: if the application integrates with payment processors, identity providers, or other third parties through APIs, specify whether the integration points are in scope or whether testing stops at the application's own API surface.
What gets missed: A web application with a clean test result but an untested API that exposes the same data through unauthenticated endpoints is not secure. It just has a clean report on an incomplete scope.
Which environment should be tested: production, staging, development, or some combination?
The tradeoff:
Production testing provides the most accurate picture of what an attacker would face. It tests the actual running system with actual data, actual configurations, and actual network controls. The risk is that active exploitation in production can cause disruption.
Staging testing is safer but may not accurately reflect production security posture if the staging environment has different configurations, different data, or different access controls. Many organisations run staging environments that are not maintained with the same security diligence as production.
What to specify: Which environment is in scope, what the differences between it and production are (if staging), and whether any production systems should be included even in a primarily staging-focused assessment.
What gets missed: Testing a staging environment that has debug mode enabled, weaker authentication requirements, or permissive CORS configurations produces findings that may not exist in production and misses findings that only appear in production configuration. Verify that the test environment is representative before scoping it as the primary target.
Out-of-scope definitions are as important as in-scope definitions. A scope document that lists what is in scope without explicitly documenting what is out of scope leaves ambiguity about adjacent systems.
Common explicit exclusions:
Third-party vendor systems the organisation does not control: cloud providers (AWS, Azure, GCP infrastructure itself), SaaS tools, payment processors.
Legacy systems that are too fragile for active exploitation and would require a separate engagement with lower-intensity methodology.
Specific IP addresses or systems that belong to third parties co-hosted in shared infrastructure.
Systems in scope for a separate concurrent engagement.
Why this matters: A tester who discovers a system adjacent to the defined scope faces a choice about whether to test it. Without explicit exclusions, they may interpret the scope as permitting testing of anything reachable from an in-scope system. With explicit exclusions, the boundary is clear.
The scope document should specify which testing techniques are permitted and which are not. This is the rules of engagement dimension.
What to address:
Automated scanning: is automated vulnerability scanning permitted? If so, are there scan rate limitations to avoid impacting production systems?
Active exploitation: is active exploitation of discovered vulnerabilities permitted to prove impact, or should testers stop at identification and report potential vulnerabilities?
Social engineering: is phishing, vishing, or physical intrusion testing in scope?
Denial-of-service techniques: is DoS testing explicitly excluded? (It almost always should be for production systems.)
Destructive techniques: is deletion or modification of data permitted, or only read access demonstration?
What gets missed: A scope that permits "comprehensive security testing" without specifying permitted techniques leaves the tester making judgment calls that may not align with the organisation's expectations. Testers who interpret "comprehensive" narrowly conduct less impactful tests. Testers who interpret it broadly may conduct techniques the organisation did not intend to authorise.
Test type (black box, grey box, white box) is a scope decision that shapes every other dimension. Black box vs. white box penetration testing: what's the difference covers the trade-offs in detail, but the scope implications are worth stating here.
Grey box (the most common default): Credentials provided, basic architecture context provided, no source code. Reduces reconnaissance time while maintaining realistic attacker perspective. Appropriate for most first and recurring assessments.
White box: Full information including source code, documentation, and all credentials. Maximum finding density per engagement hour. Appropriate for pre-release testing, high-security environments, or when source-assisted testing is specifically needed.
Black box: Target URL or IP range only, no credentials or prior context. Maximum realism for external attacker simulation. Appropriate for external perimeter validation but less efficient per hour of engagement.
If the assessment is intended to satisfy a compliance framework obligation, the scope must be designed to satisfy that framework's specific requirements.
PCI DSS Requirement 11.4 requires testing of the external and internal cardholder data environment. The scope must cover those systems specifically, and the scope document should map to the CDE boundary defined in the organisation's PCI DSS documentation. PCI DSS penetration testing requirements explained covers the exact scope requirements.
SOC 2 requires testing that covers the system described in the SOC 2 report. The penetration test scope should align with the system description scope.
ISO 27001 requires testing aligned to the ISMS scope.
What gets missed: A penetration test scoped for security improvement and a penetration test scoped for compliance evidence are different documents. The security-improvement scope may cover the highest-risk surfaces. The compliance-evidence scope must cover the specific surfaces the compliance framework designates. If neither is designed to satisfy the other's requirements, the organisation ends up with a test that improves security but fails audit, or passes audit but misses the highest-risk surfaces.
What is inside a VAPT report covers how the scope statement appears in the report and what auditors check when reviewing scope against framework requirements.
Duration should follow from scope, not the other way around. A common error is defining a budget first and then asking the vendor to define scope that fits within it. This reliably produces under-scoped engagements.
What to specify:
The engagement duration in working days of active testing (separate from report writing time).
The report delivery timeline after active testing concludes.
The retesting timeline: when can retesting be requested after a fix is deployed, and what is the turnaround time for retest confirmation?
Scope and duration relationship: A mid-complexity web application with four user roles, a REST API, and a GraphQL interface requires at least ten working days of thorough testing. A vendor who quotes four days for the same scope is either delivering an automated scan or deprioritising depth significantly. Use the scope to validate the quoted duration, not the other way around.
How much does penetration testing cost? covers the cost implications of each scope dimension. Continuous penetration testing and how it differs from annual pentests covers when continuous testing replaces or supplements point-in-time scoped assessments.
Once a scope document is drafted, review it against these questions before signing:
Can two people independently read this document and agree on whether any specific system is in scope? If not, the boundary language is unclear.
Does the scope cover the systems most important to the security question being asked? If the goal is understanding external attack surface, does it include all external-facing systems? If the goal is protecting customer data, does it include all systems that touch customer data?
Does the scope align with any applicable compliance framework requirements?
Are all exclusions explicitly documented with reasons?
Is the test type specified, and does it match the security objective?
For a full pre-engagement checklist that includes scope confirmation alongside credentials, rules of engagement, contacts, and legal authorisation, the penetration testing checklist before you start covers every item.
For penetration testing services in the US and VAPT services where the vendor guides scope definition as part of the pre-engagement process, or PTaaS where continuous coverage replaces the per-engagement scoping process for ongoing application security, the 10x Pentest platform covers both models. See pricing for engagement options or get in touch to discuss what scope is appropriate for your security program objectives.
Q1. What is penetration testing scope?
Penetration testing scope defines exactly what systems, applications, user roles, environments, and techniques are included in a penetration testing engagement. The scope document creates the boundary within which the tester operates: everything inside scope is tested; everything outside scope is not tested. The scope decision is the most consequential choice in a penetration testing engagement because it determines what the report reflects and what risk remains unexamined.
Q2. How do you define the scope of a penetration test?
Define scope across nine dimensions: the specific systems and assets to be tested (by URL, IP range, or system name); the user roles and credentials needed for each; the API and integration surfaces to include; which environment (production or staging); what is explicitly excluded; which testing techniques are permitted; the test type (black box, grey box, or white box); any compliance framework requirements that define mandatory coverage; and the engagement duration and timeline. Each dimension requires explicit decisions rather than general descriptions. Vague scope language ("the web application and associated infrastructure") should be replaced with specific enumeration.
Q3. What happens when penetration testing scope is too narrow?
A narrow scope produces findings only for the surfaces that were tested. Systems or attack surfaces outside scope carry unknown risk that the report cannot address. The most common consequence: an organisation receives a clean report on a narrowly scoped application and concludes it is secure, while an adjacent API, a forgotten subdomain, or a poorly segmented network segment contains the vulnerability a real attacker would exploit. The report is accurate but incomplete, and the incompleteness is invisible in the report itself.
Q4. Should production or staging environments be tested?
Production testing provides the most accurate representation of actual attacker-facing security posture because it reflects real configurations, real data, and real network controls. Staging testing is safer but may not reflect production security if the environments differ in configuration. The recommended approach is to scope the environment that most accurately reflects what an attacker would face: typically production for external-facing systems with appropriate constraints on destructive techniques, and staging for internal testing where the test environment is confirmed to match production configuration. Confirm explicitly which environment is in scope and what the significant differences are.
Q5. How does compliance change penetration testing scope?
Compliance frameworks that require penetration testing often specify mandatory scope coverage. PCI DSS requires testing of external and internal cardholder data environment systems. SOC 2 expects testing aligned to the system description in the SOC 2 report. ISO 27001 expects testing aligned to the ISMS scope. When a test is intended to produce compliance evidence, the scope must be designed to satisfy the framework's specific coverage requirements, not just the security team's assessment of the highest-risk surfaces. These are often the same, but when they differ, both requirements must be addressed, either in a single comprehensive engagement or in separate targeted assessments.
Cloud security assessments cover IAM configuration, network controls, storage access, workload security, and logging. This guide maps what each domain tests and what findings look like.
Tejas Dhokane Aug 26, 2026 
Penetration testing without a complete rules of engagement document is a legal and operational risk for both sides. This guide covers every clause and what goes wrong when it is missing.
Tejas Dhokane Aug 26, 2026 
Third-party risk assessment programmes use penetration testing evidence in two ways: requiring it from vendors, and producing it for customers. This guide covers both roles and how to evaluate vendor pentest reports.
Tejas Dhokane Aug 26, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
