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