Scope & Rules of Engagement: From Bug Bounty to Enterprise Pentest

Introduction

When you move from hunting on public bug bounty platforms to performing a full-blown enterprise penetration test, the scope and rules of engagement (ROE) become the contract that protects both the tester and the client. A well-defined scope tells you exactly what you may touch, while the ROE outlines the conduct, reporting cadence, and legal safeguards. Failing to respect these boundaries can lead to legal repercussions, damaged relationships, or even financial penalties.

In the real world, organizations treat scope as a risk-management instrument. A single out-of-scope request can trigger a service outage, leak sensitive data, or violate compliance frameworks such as PCI-DSS or GDPR. Therefore, mastering scope definition and ROE creation is essential for any security professional who wants to operate at scale and maintain credibility.

Prerequisites

• Fundamentals of Bug Bounty Hunting - understanding public platforms, disclosure policies, and bounty structures.
• Basic Penetration Testing Methodology - reconnaissance, enumeration, exploitation, post-exploitation, and reporting.

If you are comfortable with tools like Nmap, Burp Suite, and Metasploit, and you have written at least one vulnerability report, you are ready to dive deeper into scope management.

Core Concepts

Scope and ROE are two sides of the same coin:

1. Scope Boundaries - a list of assets (IP ranges, domains, applications, APIs) that are explicitly in-scope or out-of-scope. This also includes time windows, testing techniques (e.g., social engineering), and any exclusions (e.g., production databases).
2. Rules of Engagement - the procedural contract that defines how the test is conducted, how findings are reported, communication expectations, and legal indemnities.

Both documents are negotiated before any testing begins. They are living artifacts; changes must be tracked through a formal Scope Change Management process.

Below is a high-level diagram (described in text) that illustrates the relationship:

Client ⇄ Scope Definition ⇄ ROE ⇄ Tester ⇄ Execution ⇄ Reporting ⇄ Review ⇄ Closure

The arrows indicate iterative feedback loops; any deviation triggers a change request.

Defining Scope Boundaries (in-scope vs out-of-scope assets)

Effective scope definition starts with a clear asset inventory. Ask the client for a CMDB export or a simple spreadsheet that lists:

• IP address ranges (CIDR notation)
• Fully qualified domain names (FQDNs)
• Application endpoints (REST, GraphQL, SOAP)
• Third-party services (SaaS, Cloud APIs)
• Critical data stores (databases, file shares)

Once you have the list, classify each entry as:

Example snippet of a scope definition in YAML:

in_scope: - ip_range: 10.10.0.0/16 description: Internal web applications - domain: "app.example.com" description: Production SaaS portal
out_of_scope: - ip_range: 10.10.255.0/24 description: Production database cluster (no DDoS) - domain: "admin.example.com" description: Admin console - no credential-spraying

Notice the explicit prohibition of DDoS on the database cluster - a common clause to protect availability.

Crafting a Rules of Engagement (ROE) Document

The ROE is the legal and operational contract. A typical ROE contains the following sections:

1. Purpose & Objectives - why the test is being performed.
2. Scope Definition - reference to the asset list.
3. Testing Window - start/end dates, allowed hours (e.g., 0800-2000 UTC).
4. Allowed Techniques - e.g., network scanning, password-spraying, phishing, physical social engineering.
5. Prohibited Techniques - e.g., denial-of-service, destructive payloads, zero-day exploitation without prior consent.
6. Communication Plan - primary contacts, escalation matrix, incident reporting channels.
7. Reporting Requirements - format, severity rating system, delivery timeline.
8. Legal & Liability - indemnity clauses, jurisdiction, confidentiality.
9. Scope Change Procedure - how to request additions/removals.

Below is a minimal ROE template you can adapt:

# Rules of Engagement (ROE)
## 1. Purpose
Perform a black-box penetration test of the web-application layer to identify exploitable weaknesses.

## 2. Scope
Refer to **Scope-Definition.yaml** attached.

## 3. Testing Window
2024-06-01 08:00 UTC → 2024-06-07 20:00 UTC. Testing outside this window requires prior written approval.

## 4. Allowed Techniques
- Network scanning (Nmap, masscan)
- Web application fuzzing (Burp Intruder, wfuzz)
- Credential-spraying (limited to 5 attempts per account)

## 5. Prohibited Techniques
- Denial-of-service attacks
- Exploits that modify or delete production data
- Social-engineering on executive staff without explicit consent

## 6. Communication Plan
| Role | Name | Email | Phone |
|------|------|-------|-------|
| Primary Contact | Alice Smith | alice@example.com | +1-555-0100 |
| Escalation Lead | Bob Jones | bob@example.com | +1-555-0111 |

## 7. Reporting
Findings must be submitted in PDF and CSV format within 48 hours of discovery. Severity follows CVSS-v3.1.

## 8. Legal
Both parties agree to indemnify each other for claims arising from authorized activities. Jurisdiction: State of California.

## 9. Scope Change
Requests must be submitted via **scope-change-request.pdf** and signed by both parties before execution.

Keep the ROE concise—overly verbose contracts often cause delays in approval.

Obtaining Legal Authorization & Authorization Letters

Even the best-written ROE is meaningless without a signed legal instrument. Most enterprises require a formal Letter of Authorization (LoA) that includes:

• Tester’s legal name and company.
• Exact scope (copy of the YAML or spreadsheet).
• Testing dates and time zones.
• Signature lines for both client and tester.
• Notarisation (optional but recommended for cross-border engagements).

Below is a Python script that auto-generates a simple LoA PDF using reportlab:

import datetime
from reportlab.lib.pagesizes import LETTER
from reportlab.pdfgen import canvas

def generate_loa(tester, client, scope_file, start, end, output='LoA.pdf'): c = canvas.Canvas(output, pagesize=LETTER) width, height = LETTER c.setFont('Helvetica-Bold', 14) c.drawString(72, height - 72, 'Letter of Authorization') c.setFont('Helvetica', 12) y = height - 120 lines = [ f"Tester: {tester}", f"Client: {client}", f"Scope File: {scope_file}", f"Testing Window: {start} UTC to {end} UTC", f"Date Issued: {datetime.datetime.utcnow().strftime('%Y-%m-%d %H:%M UTC')}", "", "Signature (Tester): _______________________", "Signature (Client): _______________________", ] for line in lines: c.drawString(72, y, line) y -= 20 c.showPage() c.save()

# Example usage
generate_loa( tester='Acme PenTest Ltd.', client='Globex Corp.', scope_file='Scope-Definition.yaml', start='2024-06-01 08:00', end='2024-06-07 20:00'
)

Running the script produces a signed-ready PDF that can be emailed to the client’s legal department. Always retain a copy for your own records.

Asset Classification and Impact Rating

Not all assets are created equal. Classifying assets helps you prioritise testing effort and tailor reporting language. A common framework is:

When you discover a vulnerability, map it to the asset’s classification to adjust severity. For example, a low-severity XSS on a public marketing site may stay “Low”, whereas the same XSS on a login portal (High) could be “Critical”.

Below is a Bash one-liner that merges asset classification with Nmap results:

#!/usr/bin/env bash
# assets.csv: ip_range,classification
# Example line: 10.10.0.0/16,Critical
while IFS=, read -r cidr class; do echo "Scanning $cidr ($class)" nmap -sV -oG - $cidr | grep '/open/' | awk -v c="$class" '{print $2, c}'
done < assets.csv

Communication Channels and Incident Reporting Procedures

Clear communication prevents surprises. Define at least two channels:

• Primary Channel - usually a dedicated Slack or Microsoft Teams thread, monitored 24/7 during the testing window.
• Escalation Channel - phone numbers (pager duty) for critical incidents such as service disruption.

Incident reporting must include:

1. Timestamp (UTC), affected asset, and severity.
2. Brief description of the observed impact (e.g., "Web service returned 500 after injection").
3. Immediate mitigation recommendation (e.g., "Temporarily disable endpoint /api/v1/submit").
4. Contact details of the tester handling the incident.

Sample incident email template:

Subject: [URGENT] Incident - Potential Service Disruption on 10.10.5.12
To: ops@example.com
Cc: security@example.com

Hi Ops Team,

At 2024-06-02 14:37 UTC I triggered a SQL error on which caused the backend service on 10.10.5.12 to return HTTP 500 for all subsequent requests. This appears to be a DoS-like effect caused by an un-handled exception.

Recommended immediate action:
- Restart the affected service (PID 3421).
- Apply a temporary input length check on the `q` parameter.

I will continue testing once the service is restored.

Regards,
John Doe
Acme PenTest Ltd.

Document the communication flow in the ROE and obtain sign-off from the client’s incident response lead.

Scope Change Management

Scope creep is the enemy of a well-structured engagement. Implement a formal Scope Change Request (SCR) process:

1. Request Submission - tester fills out SCR form (asset, justification, risk assessment).
2. Impact Analysis - client’s security and legal teams evaluate the request.
3. Approval / Rejection - documented decision with signatures.
4. Update ROE & Scope Document - version-controlled (e.g., v1.2).
5. Communication - notify all stakeholders of the change and revised timelines.

Below is a simple JSON schema for an SCR that can be integrated into a ticketing system (Jira, ServiceNow):

{ "request_id": "SCR-2024-001", "requested_by": "john.doe@acme.com", "date": "2024-06-03", "new_asset": { "type": "domain", "value": "new-api.example.com", "justification": "API added after original scoping phase" }, "risk_assessment": { "impact": "Medium", "likelihood": "Low", "mitigation": "Testing limited to GET endpoints" }, "approval": { "status": "pending", "approved_by": null, "signature": null }
}

Enforce that no testing occurs on the new asset until the status is "approved".

Practical Examples

Scenario 1 - Bug Bounty Program Expansion

A startup runs a public bug bounty on its public website but now wants to include its internal API. The security team follows these steps:

1. Generate an updated Scope-Definition.yaml that adds the API CIDR.
2. Draft an ROE amendment that explicitly permits API fuzzing but disallows credential-spraying on admin endpoints.
3. Obtain a signed LoA from the legal department.
4. Publish the new scope on the bounty platform with a clear "effective date".

This prevents bounty hunters from unintentionally attacking production admin consoles.

Scenario 2 - Enterprise PenTest with Social Engineering

An enterprise hires a third-party firm to test its employee phishing resilience. The ROE contains:

• Allowed technique: simulated phishing emails using a pre-approved template.
• Prohibited technique: credential-harvesting sites hosted on the corporate network.
• Escalation contact: CISO’s mobile phone, 24/7.

During execution, a tester discovers that a phishing email caused a critical service outage because an employee accidentally executed a PowerShell script. The tester follows the incident reporting procedure, notifies the escalation channel, and the client immediately isolates the affected workstation, avoiding a larger breach.

Tools & Commands

• Nmap - for network discovery within defined CIDR ranges.

  nmap -sS -p 80,443 -oA scan_results 10.10.0.0/16

• Burp Suite - for web application scanning and intruder attacks, respecting the "allowed techniques" section.
• Jira/ServiceNow - to track SCR tickets using the JSON schema above.
• ReportLab (Python) - to auto-generate LoA PDFs.
• Slack API - to send automated status updates.

  import os, json, requests
  
  def send_status(msg, channel='#pentest-status'): payload = {'channel': channel, 'text': msg} headers = {'Authorization': f"Bearer {os.getenv('SLACK_BOT_TOKEN')}"} r = requests.post('https://slack.com/api/chat.postMessage', json=payload, headers=headers) return r.json()
  
  send_status('Scanning of 10.10.0.0/16 completed - 23 hosts alive.')
  

Defense & Mitigation

From the defender’s perspective, a well-crafted scope and ROE also help you:

• Identify unauthorized testing activity (out-of-scope traffic) via IDS/IPS signatures.
• Set up temporary “canary” assets that trigger alerts if accessed.
• Maintain audit logs that map tester IPs to approved activities - useful for compliance.

Regularly review and tighten scope definitions after each engagement to reduce attack surface for future tests.

Common Mistakes

• Over-broad scope - Including entire data centers leads to accidental service disruption.
• Missing time-window constraints - Testers may run scans overnight, causing unexpected load.
• Vague ROE language - “No destructive testing” without defining “destructive” invites interpretation.
• Skipping legal LoA - Some organizations rely on informal email approvals; this is risky.
• Failing to version scope documents - Changes get lost, leading to disputes.

Mitigation: Use checklists, templates, and a version-control repository (Git) for all scope-related artifacts.

Real-World Impact

In 2022, a major financial institution suffered a $2 M penalty because a penetration test inadvertently accessed a production payment gateway that was not listed in the scope. The regulator cited “failure to define clear boundaries”. This illustrates why meticulous scope management is not just a best practice—it’s a legal safeguard.

Conversely, a well-documented ROE enabled a health-care provider to run a comprehensive social-engineering campaign without violating HIPAA, resulting in a 45 % improvement in employee phishing awareness.

My experience shows that organizations that treat scope as a living document reduce incident-response overhead by up to 30 % and improve tester-client trust.

Practice Exercises

1. Exercise 1 - Draft a Scope Document
   • Obtain a mock asset list (5 IP ranges, 3 domains).
   • Classify each asset as Critical/High/Medium/Low.
   • Export the list to YAML and generate a PDF LoA using the Python script provided.
2. Exercise 2 - Build an ROE
   • Using the markdown template, fill in allowed and prohibited techniques for a web-app test.
   • Identify three communication channels and draft an incident email.
3. Exercise 3 - Simulate a Scope Change
   • Create a JSON SCR to add a new sub-domain.
   • Use a mock Jira ticket (you can use a free account) to track the request.
   • Update the YAML scope and re-run the Nmap scan snippet to see the new asset appear.

Document your findings in a short report (1-2 pages) and compare the original vs. updated scope.

Further Reading

• OWASP Testing Guide - Chapter 13: Scope & Rules of Engagement.
• PCI DSS Requirement 12 - Maintain a policy that defines testing scope.
• “Legal Aspects of Penetration Testing” - SANS Whitepaper (2023).
• ISO/IEC 27001 Annex A.12 - Technical vulnerability management.

After mastering scope, explore advanced topics such as Red Team Engagement Contracts and Continuous Attack Surface Management (ASM).

Summary

• Scope defines *what* you can test; ROE defines *how* you test it.
• Use explicit asset inventories, classification, and impact ratings to avoid ambiguity.
• Formal LoA and signed ROE protect both tester and client legally.
• Establish clear communication channels and incident reporting procedures.
• Implement a rigorous Scope Change Management process to control creep.
• Apply templates, version control, and automation (scripts) for repeatable, auditable engagements.

These practices turn a penetration test from a risky adventure into a controlled, repeatable, and valuable security assessment.