| name | pentest-scope |
| description | Write a penetration test scope document. Use when the user says "pentest scope", "pen test scope document", "penetration testing scope", "scope of engagement", "rules of engagement", "what to include in a pentest", "security assessment scope", "red team scope", "bug bounty scope", or needs to define the boundaries, objectives, and rules for a penetration testing engagement - even if they don't explicitly say "scope".
|
Overview
Based on Penetration Testing (Georgia Weidman) and The Hacker Playbook 3 (Peter Kim). A pentest scope document defines the contract between the organization and the tester: what systems can be tested, by what methods, during what window, and what is off-limits. Without a signed scope document, testing is unauthorized access. The scope doc protects both parties.
Weidman's rule: vague scope produces vague findings. The tighter and more specific the scope, the more actionable the results.
Workflow
Step 1: Write the engagement header
Engagement title: [company] Penetration Test - [type: web app / network / red team / etc.]
Engagement ID: [unique reference number]
Requesting organization: [company name]
Testing party: [internal team or vendor name]
Primary contact (client): [name, email, phone]
Primary contact (testing): [name, email, phone]
Legal authorization: [reference to signed authorization letter or MSA section]
Document status: [DRAFT / APPROVED / SIGNED]
Step 2: Define objectives
Be specific. Generic objectives produce generic reports.
Primary objectives:
1. Identify exploitable vulnerabilities in [specific system or application]
2. Determine whether an external attacker can reach [specific data or system]
3. Test the effectiveness of [specific control, e.g. WAF, MFA enforcement]
Secondary objectives:
- Identify misconfigurations in [scope area]
- Assess privilege escalation paths from authenticated low-privilege user
Success criteria: [what does a successful engagement look like - e.g. achieve RCE, exfiltrate sample data, reach DB server]
Step 3: Define in-scope targets
Be explicit. Everything not listed is out of scope.
In-scope systems:
| Target | Type | IP/URL | Notes |
|---|
| [app.example.com] | Web application | 203.0.113.10 | Production environment |
| [api.example.com] | REST API | 203.0.113.11 | Authenticated and unauthenticated endpoints |
| [10.0.1.0/24] | Internal network segment | — | Post-initial-access lateral movement only |
In-scope test accounts:
In-scope techniques:
Step 4: Define out-of-scope targets and restrictions
Out-of-scope systems (do not test):
- [list production databases by name or IP]
- [list third-party systems, payment processors, auth providers]
- [list any systems not owned by the organization]
- Shared infrastructure used by other customers
Prohibited techniques:
- Denial-of-service attacks against production systems
- Destructive actions (deleting data, wiping configs)
- Social engineering of employees unless explicitly in scope
- Physical access attempts unless explicitly in scope
- Exfiltration of real customer data (use test data markers only)
- Persistence mechanisms that survive system reboot
Data handling:
- Do not retain screenshots or samples of real customer PII after engagement
- All findings must be stored encrypted at rest
- Findings shared only with named contacts listed in Step 1
Step 5: Define rules of engagement
Testing window:
Start: [date and time with timezone]
End: [date and time with timezone]
Permitted hours: [e.g. business hours only / 24x7 / weekdays only]
Source IPs (all testing traffic must originate from):
[IP or range] - [tester name or organization]
[IP or range] - [backup / VPN exit node]
Escalation during testing:
If critical finding discovered: notify [name] at [phone] immediately, do not continue exploiting
If testing causes unintended outage: stop immediately, notify [name] at [phone]
Stop condition: any system unresponsive that was not already down at engagement start
Emergency stop contact: [name, phone - available 24/7 during engagement]
Step 6: Define deliverables
Deliverables:
1. Executive summary (for non-technical stakeholders)
- Risk posture overview
- Critical findings summary
- Prioritized remediation recommendations
2. Technical findings report
- Each finding: severity, description, evidence, reproduction steps, remediation
- CVSS scores for each finding
- Risk-ranked findings table
3. Raw tool output (optional)
- Scan logs, Burp project file, screenshots archive
Severity classification:
Critical: immediate exploitation, significant business impact (RCE, auth bypass, data breach)
High: exploitable with low complexity, significant data exposure
Medium: requires specific conditions, partial data exposure
Low: limited impact, requires chaining with other vulnerabilities
Informational: best practice gaps, no direct exploitability
Delivery format: [PDF / encrypted ZIP / portal]
Delivery deadline: [date, N business days after engagement end]
Retest: [included / not included / priced separately]
Anti-Patterns
1. Vague scope
Bad: "Test our web application."
Good: List exact URLs, IP addresses, test accounts, and the specific techniques permitted. Ambiguity puts the tester at legal risk and the organization at operational risk.
2. No stop conditions
Bad: Scope doc with no guidance on what to do if testing causes an outage.
Good: Explicit stop conditions, emergency contact available 24/7 during the window, and a clear escalation path for critical findings.
3. No source IP restriction
Bad: Testing can come from any IP.
Good: All testing traffic is restricted to specific source IPs listed in the engagement. This lets the client distinguish test traffic from real attacks in logs.
4. Shared production databases in scope
Bad: Scope includes production DB without restriction on data handling.
Good: Either exclude production DBs entirely, or explicitly restrict to test data and prohibit exfiltrating real customer records.
Quality Checklist
