# Scoping and Requirements Gathering Scoping defines what is approved for testing. Requirements gathering defines what the client expects from the assessment. Together, they convert a vague request into a controlled engagement. ``` Test our network. ``` This is not a usable scope statement. The tester needs specific targets, exclusions, limits, access requirements, and expected deliverables. *** ## Order of Scoping Decisions Scoping should move from general purpose to specific permission. 1. Define the objective. 2. Identify approved targets. 3. Identify excluded targets. 4. Confirm the environment. 5. Understand business context. 6. Define testing limits. 7. Confirm access requirements. 8. Clarify authenticated and password testing. 9. Agree on scope change handling. 10. Save the scoping notes. This order prevents the tester from collecting random details without knowing how they affect the test. *** ## Scope Controls Permission Scope is the boundary of authorization. If an asset is not clearly in scope, it should not be tested. This includes domains, subdomains, IP addresses, cloud assets, APIs, accounts, wireless networks, and third-party services. {% hint style="warning" %} Discovered does not mean authorized. Newly discovered assets must be confirmed before testing continues against them. {% endhint %} *** ## Objective The objective explains why the assessment is being performed. Common objectives include: * Assess internet-facing exposure. * Validate internal network security. * Test a web application. * Test API authorization. * Assess Active Directory attack paths. * Validate segmentation controls. * Support compliance requirements. * Confirm remediation of previous findings. The objective affects the test type, scope, access level, testing depth, evidence, and report structure. A public exposure test is not planned the same way as an internal Active Directory assessment. *** ## In-Scope Assets In-scope assets should be written in a way that another tester can understand without asking again. Useful scope items include: * IP ranges. * Domains and subdomains. * URLs. * APIs. * Mobile applications. * Wireless networks. * Active Directory domains. * Source repositories. * Cloud accounts. * Provided test accounts. Bad scope: ``` Test the company network. ``` Better scope: ``` External penetration test against 203.0.113.0/28 and app.example.com during the approved testing window. ``` Specific scope is easier to test, defend, and report. *** ## Exclusions Exclusions should be as clear as approved targets. Common exclusions include: * Third-party systems. * Customer environments. * Payment processors. * Cloud provider infrastructure. * Production data modification. * Denial-of-service testing. * Phishing. * Physical access. * Persistence. * Data exfiltration. Exclusions prevent the tester from relying on assumptions during testing. They also protect systems that may be related to the client but not authorized for assessment. *** ## Environment Confirm the environment before testing. The target may be production, staging, development, UAT, lab, external perimeter, internal network, or cloud-hosted infrastructure. Production testing requires stricter limits because normal test activity can affect business operations. Staging may reduce risk, but it may not match production data, integrations, security controls, or user behavior. *** ## Business Context Business context explains why a finding matters. A vulnerability in a public payment application is not equivalent to the same issue in a temporary test system. Useful context includes: * What the system does. * Who uses it. * What data it handles. * Whether it is internet-facing. * Whether it is business-critical. * Whether compliance requirements apply. * Whether there were recent incidents or major changes. This context supports severity decisions later. *** ## Testing Limits Testing limits define what must be controlled or avoided. Common limits include: * Testing hours. * Request rate. * Fragile systems. * Account lockout rules. * Password attack restrictions. * Denial-of-service restrictions. * Production change restrictions. * Social engineering exclusions. Do not rely on memory for these limits. If a technique may disrupt the environment, it needs clear approval. *** ## Access Requirements Access should be ready before the testing window. This may include: * VPN access. * IP allowlisting. * Test accounts. * API keys. * Source code access. * OpenAPI files. * Architecture diagrams. * Mobile builds. * Sample data. * Wireless credentials. Access should be tested before active testing starts. Approved testing time should not be lost on avoidable access issues. *** ## Authenticated Testing Authenticated testing should define the accounts, roles, permissions, and test data available to the tester. For web and API assessments, role comparison is often necessary. Many authorization issues only appear when comparing users, roles, tenants, or object owners. Confirm: * MFA behavior. * Password reset rules. * Account creation rules. * Privilege change rules. * Tenant separation. * Object ownership expectations. * Test data ownership. Authenticated testing should not be treated as simply “login and test.” The value comes from comparing what different users can do. *** ## Password Testing Password testing needs explicit approval. This includes password spraying, brute force testing, credential stuffing, default password checks, and password reuse testing. Before testing, confirm: * Target accounts. * Excluded accounts. * Lockout threshold. * Lockout duration. * Rate limits. * Approved wordlists. * Monitoring expectations. * Notification requirements. {% hint style="danger" %} Password testing can lock accounts, trigger incident response, or disrupt business users. Do not perform it unless it is clearly approved. {% endhint %} *** ## Scope Changes Scope changes must be traceable. A scope change may add a new subdomain, remove a fragile system, approve authenticated testing, extend the testing window, or allow a technique that was previously restricted. Record: * What changed. * Who approved it. * When it was approved. * Why the change was needed. * Whether it affects the timeline or deliverables. Verbal approval should be followed by written confirmation. *** ## Notes to Keep Scoping notes should prove what was approved. Keep: * Approved targets. * Excluded targets. * Testing window. * Originating tester IP addresses. * Provided accounts. * Access requirements. * Restricted techniques. * Emergency contacts. * Reporting expectations. * Retesting expectations. * Scope change approvals. The tester should be able to defend every tested target. *** ## Mistakes to Avoid Common scoping mistakes include accepting vague targets, ignoring third-party services, forgetting APIs, assuming discovered assets are in scope, skipping account lockout rules, starting before access is ready, and failing to save written approvals. The most serious mistake is treating scope as flexible without written approval. *** ## References * [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment](https://csrc.nist.gov/pubs/sp/800/115/final) * [PCI SSC Penetration Testing Guidance](https://www.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://reaper.gitbook.io/my-penetration-test-guide/methodology-and-planning/pre-engagement-activities/scoping-and-requirements-gathering.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.