How to Scope a Penetration Test to Get Findings You Can Actually Act On
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
A pen test that was scoped to satisfy a compliance requirement produces compliance-satisfying output: a report that confirms the engagement was conducted, lists a set of findings, and provides a certificate of completion. Most of the findings were already on the vulnerability scanner report. The test lasted three days and covered the same external-facing web application it covered last year.
A pen test that was scoped to answer a specific security question produces a different kind of output: attack paths you did not know existed, findings in the internal systems that the scanner cannot reach, and sometimes a demonstration that your assumed controls are not operating as assumed.
The difference between these two outcomes is almost entirely in how the scope was written -- before the test begins. This guide covers how to define the three questions that produce a useful scope, which engagement type matches which security question, the rules of engagement that protect production, and how to evaluate a pen test vendor proposal for scope quality.
The Three Questions That Define a Useful Scope
A useful pen test scope answers three questions that compliance-driven scoping typically does not ask:
Question 1: What is the most damaging thing an attacker could do to us? This is the "crown jewel" question. For a financial services firm, it might be unauthorized wire transfer initiation. For a healthcare organization, it might be bulk export of patient records. For a SaaS company, it might be cross-tenant data access. For an e-commerce company, it might be fulfillment system manipulation that allows free goods. Defining the most damaging outcome shapes the test objective: "can a tester reach this outcome?" is a more useful test question than "what findings exist in our external web application?"
Question 2: What is the most likely path an attacker would take to reach that outcome? Work backward from the worst-case outcome to the most likely attack path. If the worst outcome is bulk patient record export, the likely paths are: authentication bypass in the patient portal, SQL injection in the data export API, compromise of a developer account with database access, or phishing of an admin-level user followed by internal access. The pen test scope should explicitly include these paths.
Question 3: What assumptions should the tester start with? A black-box test assumes the attacker has no prior knowledge. A gray-box test assumes the attacker has user-level credentials or application documentation. An assumed-breach test assumes the attacker has already compromised an internal endpoint. Each starting assumption produces a different kind of finding. Choose the starting assumption that matches the threat scenario you are most concerned about, not the one that produces the cleanest "we blocked them at the perimeter" report.
Engagement Types and When to Use Each
Black-box external network test. The tester has no prior knowledge of the target and tests only externally accessible systems (internet-facing IPs, public domains). Best for: validating that your external attack surface is hardened against opportunistic attackers. Limitation: most sophisticated attackers are not starting from black-box external positions -- they have access to breach data, OSINT, and in many cases a phishing foothold. Black-box findings are the ones your vulnerability scanner already surfaces. Use this test type for compliance documentation or as a baseline; do not rely on it to find sophisticated attack paths.
Gray-box application test. The tester has application credentials (typically at user and admin privilege levels) and may have access to application documentation, API specs, or source code. Best for: finding business logic vulnerabilities, authorization failures, and API security issues that automated scanners miss because they require understanding the application's intended behavior. This produces findings that are significantly more relevant to your actual threat model than black-box surface scanning.
Internal network test. The tester starts from inside the network (connected via VPN or on-site) and attempts to reach high-value internal targets. Best for: validating your internal segmentation, lateral movement defenses, and the value of assets an attacker could reach after phishing a single employee. This is the test that tells you what happens after the perimeter is breached -- the scenario that describes most successful breaches.
Assumed-breach test. The tester starts with a foothold already established: a compromised endpoint, valid user credentials, or a specific level of access that simulates post-initial-compromise. Best for: testing detection and response capabilities, internal segmentation, and the blast radius of a credential compromise or endpoint compromise. This is the test that answers "how bad is it if they get in?" rather than "can they get in?"
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
How to Write a Scope Statement That Produces Useful Findings
A scope statement that produces useful findings has five components:
Explicit objectives. State what the test should attempt to achieve, not just what systems it should test. "Determine whether an authenticated user can access records belonging to other organizations (cross-tenant access)" is an objective. "Test the customer portal" is a target, not an objective. Objectives tell the tester what success looks like from the client's perspective.
Target systems with specificity. List the specific systems in scope: IP ranges, domain names, application URLs, API endpoints, or Kubernetes cluster names. Also explicitly list what is out of scope to prevent the tester from spending time on systems that are not relevant to the test objective (third-party SaaS tools, recently acquired systems pending integration, or systems belonging to a separate business unit).
Attacker starting assumption. Define what credentials, access, or information the tester starts with. For an application test: which user roles will the tester have credentials for (read-only user, standard user, admin user)? For an assumed-breach test: which endpoint is compromised and at what privilege level?
Engagement duration. Specify the number of tester-days dedicated to the engagement. A meaningful application security test of a mid-complexity application requires at least 40 hours of tester time. A test scoped to 16 hours produces a surface scan and a check of common vulnerabilities. Be explicit about hours so vendors cannot underbid with a low-quality short engagement.
Success criteria. Define what a successful test looks like. "The tester demonstrates ability to access another tenant's data" or "the tester demonstrates lateral movement from an unprivileged endpoint to the production database" are success criteria. "The tester finds critical vulnerabilities" is not -- it is ambiguous and allows the tester to define their own bar.
Rules of Engagement That Protect Production Systems
Rules of engagement define what the tester is permitted to do and what is prohibited. They protect production systems from unintended disruption while preserving the test's value.
Data exfiltration during testing. Testers should not exfiltrate real data even if they can. The demonstration of access to a data source is sufficient -- actual data export creates liability and unnecessary exposure. Specify: "Tester should demonstrate access to the data source and document the access path. No actual data exfiltration of real records is permitted."
Denial of service testing. Unless you have explicitly provisioned a test environment for it, prohibit denial of service testing. "No testing of denial of service conditions against production endpoints" is standard language.
Notification and escalation. Specify who the tester contacts if they discover a critical vulnerability during the engagement and what the escalation path is. A tester who finds an RCE in a production-facing system on day one of a five-day engagement should have a clear path to notifying you immediately rather than waiting for the final report.
Time window restrictions. Specify when active testing is permitted. "Active testing permitted Monday through Friday, 8am to 6pm Eastern Time" prevents a tester from running an intensive scan during your peak traffic period and creating unintended performance impact. Alternatively, schedule intensive phases during low-traffic windows.
Production versus test environment. If you have a staging environment that mirrors production, specify which environment is in scope. Tests against a staging environment that diverges significantly from production produce less relevant findings. Tests against production carry more risk. The decision should be explicit in the scope document.
Evaluating a Pen Test Vendor Proposal for Scope Quality
The vendor proposal response tells you whether the vendor understood the scope or templated a generic response. Four indicators of scope quality in a proposal:
Did they echo your objectives back in their own language? A vendor that understood your scope will describe how their testing methodology connects to your stated objectives: "given your objective of testing cross-tenant access, our application assessment will specifically focus on multi-tenant isolation controls in the API authorization layer and the data access patterns in the database queries." A vendor using generic language ("we will test for OWASP Top 10 vulnerabilities") has not engaged with your objectives.
Are they proposing an appropriate engagement type and duration? If you asked for a gray-box application test targeting business logic vulnerabilities and the proposal allocates 16 hours, the test will produce scanner-equivalent output. A responsible vendor will push back on duration if it is insufficient to meet the stated objectives. A vendor that accepts any timeline without comment is optimizing for the sale, not the outcome.
Do they describe how they handle findings during the engagement? A quality vendor has an escalation path for critical findings discovered during testing and specifies how they will communicate with you during the engagement rather than only at report delivery. Radio silence during a 5-day engagement is a red flag.
What does their deliverable include? The report should include: executive summary (non-technical), technical finding descriptions with proof-of-concept steps, risk rating with justification (not just CVSS score), remediation recommendation with specificity, and a re-test commitment for critical findings. A proposal that describes deliverables in vague terms ("comprehensive report") is not committing to report quality.
Getting More Value From the Same Engagement
Two practices extract more value from a pen test engagement than the standard findings-list report format:
Debrief session before the report. Request a live debrief with the pen test lead before the written report is delivered. In the debrief, ask the tester to walk through the attack path they found most significant -- the one that surprised them or that they think deserves the most attention. This conversation often surfaces context that does not make it into the written report: why they chose this attack path, what they tried that did not work, and what the most realistic exploitation scenario looks like from the tester's perspective. Written reports compress this context in the interest of brevity.
Ask for the "near miss" findings. Request that the written report include a section on attack paths the tester explored that did not succeed -- what they attempted, how close they came, and what stopped them. Near-miss findings often indicate controls that are working but are one misconfiguration away from failing. Tracking near-miss findings as a category gives you a preventive prioritization list rather than a purely remediation-focused list.
Schedule a re-test for critical findings. Include re-test verification for critical and high findings in the contract rather than treating it as an optional add-on. A re-test confirms that the remediation actually addresses the vulnerability rather than the cosmetic symptoms of it. Testers regularly find that remediations close the specific issue reported while leaving the underlying vulnerability accessible through a different attack path.
The bottom line
A pen test scoped around a compliance requirement produces compliance output. A pen test scoped around specific security questions -- what is the worst-case outcome, what is the most likely path there, and what assumptions should the tester start with -- produces findings that change how you prioritize your security investment. Write explicit objectives rather than target lists. Choose an engagement type that matches your threat model (gray-box and assumed-breach produce findings that black-box external tests do not). Specify duration sufficient to produce meaningful findings. Evaluate vendor proposals for whether they engaged with your objectives rather than templated a generic response. Extract additional value through a pre-report debrief, near-miss findings documentation, and contractual re-test verification for critical findings.
Frequently asked questions
How do I write a pen test scope that produces useful findings instead of scanner output?
Answer three questions before writing the scope: what is the most damaging outcome an attacker could achieve against your organization, what is the most likely attack path to that outcome, and what starting assumptions should the tester have? Use these answers to write explicit test objectives rather than target lists. 'Determine whether an authenticated user can access records belonging to other organizations' is an objective. 'Test the customer portal' is a target. Objectives tell the tester what success looks like and produce findings beyond what an automated scanner would surface.
What is the difference between black-box, gray-box, and assumed-breach penetration tests?
Black-box tests assume no prior knowledge -- the tester attacks only what is publicly accessible with no credentials or documentation. Gray-box tests provide user credentials and potentially documentation, allowing the tester to find business logic vulnerabilities, authorization failures, and API security issues that automated scanners miss. Assumed-breach tests start with a pre-established foothold (a compromised endpoint or valid user credentials) and test what an attacker can reach after initial access -- measuring internal segmentation, lateral movement, and blast radius rather than perimeter defenses. Most real-world breaches involve an assumed-breach scenario after initial credential theft, making assumed-breach tests the most realistic for organizations concerned about post-perimeter attacks.
Why does my pen test report look similar to my vulnerability scanner output?
When a pen test is scoped as an external black-box test with a short engagement window (2 to 3 days), the tester's most efficient path is running the same automated discovery and scanning tools that vulnerability scanners use, plus a manual review of the highest-severity findings. The result overlaps significantly with scanner output because the engagement was not scoped to go beyond scanner depth. A gray-box application test with 40+ hours of tester time produces qualitatively different findings: business logic vulnerabilities, chained attack paths, and authorization failures that automated scanners cannot identify because they require understanding the application's intended behavior.
How much time does a useful application penetration test require?
A meaningful application security test of a mid-complexity web application (10 to 30 distinct features or API endpoints) requires at least 40 hours of tester time. Simple single-purpose applications with a narrow attack surface may be tested meaningfully in 24 hours. Complex applications with extensive business logic, multi-tenant isolation, and multiple privilege levels may require 80 to 120 hours. A test scoped below 16 hours for a typical SaaS application produces scanner-equivalent output. If a vendor accepts a very short engagement window without comment on the scope implications, they are not engaging with the quality of the findings.
What rules of engagement should a penetration test scope include?
Five rules are standard: no actual data exfiltration of real records (demonstrating access is sufficient), no denial of service testing against production endpoints unless a dedicated test environment is provisioned, an escalation path for critical findings discovered during the engagement (the tester should notify you immediately, not wait for the final report), active testing time window restrictions (business hours only if production impact from intensive scanning is a concern), and explicit definition of which environment is in scope (production versus staging). A vendor that does not propose rules of engagement in their contract or proposal is not following standard engagement practice.
What should I look for in a pen test vendor proposal?
Four indicators of proposal quality: the vendor echoes your stated objectives back in their own words with specific methodology notes (not generic 'OWASP Top 10' language), they propose engagement duration sufficient to meet the stated objectives and push back if the budget implies insufficient time, they describe their communication and escalation process during the engagement rather than only at report delivery, and their deliverable description includes executive summary, technical findings with proof-of-concept steps, risk justification, specific remediation recommendations, and re-test commitment for critical findings.
How do I get more value from a penetration test engagement?
Three practices extract additional value: request a live debrief with the pen test lead before the written report -- the conversation surfaces context (why they chose specific attack paths, what they tried that did not work) that the written report compresses away. Ask for 'near-miss' findings in the report: attack paths the tester explored that did not succeed, how close they came, and what stopped them -- these indicate controls that are working but are vulnerable to single misconfiguration. Include contractual re-test verification for critical and high findings -- re-tests confirm remediation addresses the underlying vulnerability rather than just the specific reported issue.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.