pentest-scope

---

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:

Account	Role	Credentials delivery
test_user@example.com	Standard user	Via encrypted email before engagement
test_admin@example.com	Admin user	Via encrypted email before engagement

In-scope techniques:

• Reconnaissance (passive and active)
• Vulnerability scanning
• Web application testing (OWASP Top 10)
• Authentication bypass attempts
• Privilege escalation
• Lateral movement (if internal network in scope)
• Social engineering (if explicitly included)
• Physical access testing (if explicitly included)

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

• Legal authorization is referenced (signed doc or MSA clause)
• Objectives are specific with measurable success criteria
• In-scope targets listed with IPs or URLs - no ambiguity
• Test accounts specified with roles
• Out-of-scope systems explicitly listed
• Prohibited techniques explicitly listed
• Testing window with exact start/end times and timezone
• Source IPs from which all test traffic must originate are listed
• Emergency stop contact is available 24/7 during window
• Deliverables defined with severity classification and deadline
• Data handling restrictions for real customer PII documented