Penetration Test Scoping and Rules of Engagement: What to Define Before You Sign
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.
Most penetration test problems come from undefined expectations, not from testing itself. When the scope says 'our web application at app.example.com' without defining whether it includes authenticated functionality, mobile APIs, and staging environments, the tester makes assumptions. When the rules of engagement do not specify escalation for critical findings, a remotely exploitable RCE sits in the tester's queue until the final report. When the authorization document is signed by someone without authority, the test creates legal risk for the testing firm.
The planning that happens before the first test packet is sent determines whether the engagement produces actionable security intelligence or an expensive list of vulnerabilities that does not answer your security questions. This guide covers what to define, why each element matters, and the documents you need before work begins.
Scope definition: precision prevents disputes and gaps
A well-written scope document should be specific enough that both the client and the tester would independently reach the same answer about whether any given system is in-scope. Ambiguous scope language — 'the production environment,' 'our web application,' 'external-facing systems' — creates gaps where the attacker's real path exists but was not explicitly tested, and creates disputes when the tester bills for time spent on a system the client thought was out-of-scope. Scope definition follows three steps: listing in-scope targets with CIDR notation or explicit URLs, listing explicit exclusions with the business reason for each, and resolving all technique ambiguity by requiring explicit authorization for social engineering, exploitation, persistence, and exfiltration before testing begins.
In-scope definition: be specific about targets and test types
For network testing: list CIDR ranges explicitly (192.0.2.0/24, 198.51.100.0/27) rather than 'the production network.' For web application testing: list every URL pattern that is in-scope (https://app.example.com/*, https://api.example.com/v1/*) and specify whether authenticated testing (with provided credentials) is included. For cloud testing: specify AWS account IDs, GCP project IDs, or Azure subscription IDs and which services within those accounts are testable. For red team engagements: specify which attack paths are authorized (phishing, credential attacks, physical access, cloud, on-premises) and which are excluded. The scope should be specific enough that the tester would not need to ask 'is [X] in scope?' more than once.
Out-of-scope exclusions: prevent production disruption
Explicitly exclude any system where testing would cause unacceptable disruption. Common exclusions: production databases (testing should use a staging database with production-like data), third-party services you do not own (Stripe, Salesforce, your payment processor — testing these without their permission violates their terms and may be illegal), executive personal devices (if red team includes endpoint testing), industrial control systems (if present), and DoS/DDoS testing (unless explicitly authorized with a specific maintenance window). For each excluded system, explain why it is excluded so the tester understands the business constraint and can flag if their findings create a dependency on an out-of-scope system.
Authorized technique list: resolve ambiguity before testing begins
Enumerate which test techniques are explicitly authorized: is social engineering permitted? Phishing? Vishing? Physical access attempts? Password spraying against Active Directory? Exploitation of found vulnerabilities (not just identification)? Data exfiltration simulation? Persistence establishment? Each organization has different risk tolerance for these techniques. Grey-listing (not explicitly authorized, but not prohibited) creates mid-engagement disputes. Resolve ambiguity in the scope document: if social engineering is not explicitly listed as authorized, it is prohibited. If exploitation is not explicitly authorized, testers identify vulnerabilities but do not exploit them. If persistence is not authorized, testers stop at initial access.
Rules of engagement: the behavioral contract
Rules of engagement answer the question: what happens when something unexpected occurs during the test? The most consequential scenarios are a tester discovering evidence of a real active compromise by a third-party attacker, finding a critical remotely-exploitable vulnerability that was not anticipated in scope planning, or accidentally accessing data outside the authorized scope. Without pre-defined procedures for each scenario, the tester must make real-time judgment calls that may not align with what the client would have wanted. The rules of engagement document resolves all of these in advance by defining the contact list and escalation paths, the testing window, and the communication protocol for during-test questions.
Contact list and escalation matrix
Include a named contact list with mobile phone numbers (not just email) for: primary technical contact (answers questions about specific systems), security/incident response contact (notified of critical findings), business executive contact (emergency stop authority), and the tester's project manager and technical lead. Define escalation by finding severity: informational findings go in the report, medium and high findings go in a weekly update, critical findings require same-day phone call to the technical contact. Define what constitutes an 'emergency stop' condition: evidence of active third-party compromise, accidental production data access, or a finding that would immediately cause regulatory notification requirements if disclosed.
Testing windows and communication protocol
Specify when testing can occur: business hours only (reduces disruption, allows your team to respond to anomalies in real time), after-hours only (reduces impact on performance but limits your team's ability to respond), or 24/7 (maximum efficiency but requires that your on-call team is pre-briefed). Define the communication channel: encrypted messaging (Signal group for the engagement team) is recommended for sharing sensitive finding details during the test. Specify check-in cadence: daily status update via agreed channel even if no significant findings. This prevents the client team from wondering whether testing is occurring and prevents the tester from going dark for a week.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
A penetration test's value is determined before the first packet is sent. Define scope precisely enough that no system's inclusion is ambiguous — list IP ranges, application URLs, and cloud account IDs explicitly. Define rules of engagement that specify escalation paths for critical findings, testing windows that protect production availability, and communication protocols that keep your team informed throughout. Obtain a signed authorization document from someone with actual authority before any testing begins. After the test, require a debrief call and schedule a retest of critical findings after remediation to verify fixes are effective. The planning investment is small relative to the cost of a test that disrupts production, misses your actual attack surface, or produces a findings list that does not answer your security questions.
Frequently asked questions
What should a penetration test scope document include?
A complete scope document specifies: (1) In-scope targets — specific IP ranges (CIDR notation), application URLs, API endpoints, AWS account IDs, or other precisely identified targets. (2) Out-of-scope targets — specific IP ranges, systems, or techniques explicitly excluded (production databases, third-party integrations, DoS testing). (3) Test type — black box (no prior knowledge), grey box (limited information), white box (full credentials and architecture knowledge), and which test methodologies are authorized (OWASP, PTES, NIST). (4) Authorized test techniques — whether social engineering, phishing, physical access, and wireless testing are included. (5) Testing timeframe — start date, end date, and acceptable testing hours. (6) Geographic restrictions — whether tests can be conducted from specific countries. A scope document with ambiguity creates disputes about findings and creates legal risk for the tester.
What are rules of engagement and what must they specify?
Rules of engagement (ROE) define how the test will be conducted, what the tester can and cannot do, and what happens when specific situations arise. Essential ROE elements: escalation procedure for critical findings (who to contact, how, and within what time when a critical vulnerability is found or a real attacker's presence is detected), point of contact list with names, phone numbers, and authority levels, communication channel for during-test questions (usually an encrypted channel like Signal or ProtonMail), reporting requirements and timeline, data handling requirements (what data the tester can collect, how it must be protected, and how it must be destroyed after the engagement), and criteria for test suspension (conditions under which the tester must stop and contact the client immediately).
What is the legal authorization document and why is it critical?
The legal authorization document (sometimes called the letter of authorization or statement of work) explicitly grants the penetration tester permission to test the specified systems. Without it, testing is unauthorized access under the Computer Fraud and Abuse Act in the US and equivalent laws in other jurisdictions. The document must: be signed by someone with actual authority to authorize access to the systems (not just a security manager — often requires CTO, CISO, or legal counsel approval for external systems), specifically name the IP addresses or URLs being tested, specify the authorized test period, and identify the testing company or individual by name. The tester should carry a copy of this document throughout the engagement and be prepared to provide it to law enforcement or hosting providers if testing triggers abuse reports.
How do I define scope to avoid testing gaps without over-scoping?
Start with your attack surface: what can an external attacker reach without any prior access? This defines your external network scope (public IP ranges, internet-facing application URLs). Then define what an authenticated attacker with stolen credentials could reach: authenticated application functions, internal APIs, VPN-accessible systems. Then define what a compromised insider could reach: internal network segments, privileged system access paths. Map these three attacker scenarios to specific IPs, URLs, and accounts in your scope document. Common scoping gaps: forgetting to include APIs when testing web applications, excluding development environments that share infrastructure with production, and omitting third-party services that the application depends on and that the tester should test for authentication vulnerabilities.
How should critical findings be escalated during the test?
Define a critical finding escalation procedure before the test begins. A critical finding is: a vulnerability that is actively being exploited by a third-party attacker (real active compromise discovered during testing), a vulnerability that would result in complete system compromise if exploited and that is exposed to the internet, or a vulnerability that affects systems explicitly excluded from the scope (the tester discovers an in-scope system that has a trust relationship with an out-of-scope system). Escalation procedure: the tester contacts the designated emergency contact (mobile phone, not email) immediately, describes the finding in enough detail to assess impact without sending sensitive data over an insecure channel, and waits for client direction before continuing. Do not specify that testers should just document and continue — a remotely exploitable critical vulnerability should be reported the same day it is found.
Should I give the penetration tester credentials and access to make testing more efficient?
Grey box or white box testing (providing credentials and architecture documentation) is generally more cost-effective than pure black box testing for most organizations. Black box testing spends significant time on reconnaissance that you could shortcut by providing network diagrams, API documentation, and test accounts. Authenticated testing (providing valid credentials with different privilege levels) allows the tester to focus on the most impactful vulnerabilities — privilege escalation, IDOR, business logic flaws — rather than spending the engagement timeline attempting to guess their way past authentication. Provide: low-privilege test accounts, API documentation, network topology for the in-scope environment, and results from your previous pen tests to avoid duplicating prior findings. Withhold: production system credentials, actual user PII, and financial data.
How do I ensure the penetration test results are actually useful?
Define your test objectives before signing: what questions do you need the test to answer? Examples: 'Can an unauthenticated attacker on the internet access our customer database?' 'Can a low-privilege employee escalate to domain admin?' 'Does our WAF stop common injection attacks?' The objectives determine test focus. Without explicit objectives, testers produce a comprehensive findings list that may answer questions you did not have while missing the question you care about most. After the test: require a debrief call where the tester walks through critical findings with your engineering team, not just a written report. Require remediation validation: schedule a retest of critical and high findings after remediation is complete, included in the original contract, to verify fixes actually work.
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.