Penetration Testing Rules of Engagement: Scope, Authorization, and Legal Boundaries

Penetration testing should begin only after the asset owner has provided explicit authorization and the scope and testing constraints are documented. The RoE records how that authorized testing may be conducted: which systems you may touch, which techniques you may use, who to call when something breaks, and how findings are reported.

This guide is for anyone building a lab who wants the legal framing before the first nmap scan, and for PenTest+ candidates who need engagement-management objectives in plain language. It is not a contract template and it is not legal advice.

What rules of engagement are

Rules of engagement (RoE) are the operational agreement—or testing plan—for a security assessment. They translate the business goal ("test our external attack surface before renewal season") into boundaries a tester can follow on a Tuesday night without guessing.

An RoE answers questions that scope alone leaves open:

• May we run password sprays against Azure AD, or only single-account lockout-safe attempts?
• Are denial-of-service tests forbidden entirely, or allowed against one staging load balancer?
• Who gets a phone call if we obtain domain admin at 2 a.m.?
• Where do we store packet captures that contain customer data?
• When must we stop and wait for written approval to continue?

The PTES pre-engagement phase treats RoE construction as a first-class deliverable, not a formality. NIST SP 800-115 frames the same idea as planning and authorization before any technical assessment activity.

How RoE differs from scope, SoW, and MSA

Students and new consultants often conflate four documents. Each has a different job:

The SoW might say "external network penetration test, two weeks, report due Friday." The RoE says 203.0.113.0/24 and app.example.com are in, payroll VLAN and production SAP are out, testing hours are 09:00–17:00 US/Eastern, and phishing is not authorized unless a separate addendum is signed.

For NDA, MSA, SoW, and target-selection detail, see penetration testing pre-engagement scoping. This page focuses on the RoE artifact itself.

What belongs in a signed RoE

Treat the RoE as a checklist both sides sign before any packet leaves your laptop. As a conservative testing practice, treat techniques not clearly authorized by the RoE or governing agreement as out of scope until the client confirms them.

The OWASP autonomous penetration testing standard publishes a machine-readable RoE template aimed at automated platforms. The field names differ from a Word PDF clients sign, but the ideas align: authorization, time boundaries, deny lists, rate limits, and escalation references should be explicit enough that nobody improvises mid-engagement.

Define in-scope and out-of-scope assets

Ambiguous scope is the most common source of pentest disputes. "Test our web presence" is not a scope line. A defensible list looks like a inventory, not a slogan.

In-scope examples:

• External IPv4 range 198.51.100.0/24 and IPv6 prefix documented in the appendix
• Hostnames www.example.com, api.example.com, vpn.example.com
• Azure subscription ID and resource group named in the SoW
• Mobile app package com.example.android build 4.2.1 delivered as APK

Out-of-scope examples:

• payroll.internal.example.com and the HR VLAN
• Customer production data in the live CRM tenant
• Third-party payment gateway (test only the integration point the client owns)
• Any IP responding on shared hosting outside the listed range

List exclusions with the same precision as inclusions. "Do not test anything else" is weaker than naming the payroll /24 and the backup datacenter link.

For lab work, the same habit appears in pentest lab requirements: Kali on 10.10.10.10, Metasploitable on .30, GOAD nodes on .20–.22, everything else off limits. Your isolated bridge provides the technical boundary for the lab.

Authorize techniques explicitly

As a conservative testing practice, treat techniques not clearly authorized by the RoE or governing agreement as out of scope until the client confirms them.

Techniques that should almost always be called out separately:

• Denial-of-service and resource exhaustion
• Social engineering (email, phone, physical)
• Ransomware or wiper simulation
• Password spraying above an agreed lockout threshold
• Wireless deauthentication or evil-twin attacks outside a lab SSID
• Testing through third-party APIs that rate-limit production tenants

Permitted techniques can be broad when the client accepts operational risk:

Permitted: automated vulnerability scanning, manual exploitation of
identified vulnerabilities, credential testing with provided accounts,
post-exploitation on in-scope hosts, lateral movement within listed
subnets, data exfiltration simulation to tester-controlled infrastructure.

Prohibited techniques should be equally plain:

Prohibited: denial-of-service, mass phishing, physical entry, testing
of out-of-scope IP space discovered during the assessment, modification
or deletion of production data, deployment of persistent backdoors after
report delivery without written re-authorization.

When you practice on Metasploitable 2 or GOAD in a private lab, you can authorize techniques against the systems you own and have intentionally placed in scope, while keeping traffic away from external or third-party systems. On a client network, the RoE must say so.

Testing windows, communication, and stop conditions

Time boundaries

RoE should name:

• Calendar start and end dates
• Allowed hours in the client's time zone
• Blackout windows (releases, audits, holidays)
• Whether weekend or overnight testing is permitted

Running a noisy scanner during month-end close when the RoE forbids it is both unprofessional and a contract breach, even if the scan is "safe."

Communication plan

Agree on:

• Daily or weekly status meetings
• A secure channel for evidence (encrypted email, client portal, not public Slack)
• Who receives critical findings first (usually technical lead plus security operations)

Tools such as Cervantes help track findings and reports per project, but they do not replace the RoE communication section. The RoE still defines who must be notified outside the tool.

Emergency stop

A well-designed RoE should include a stop procedure both sides understand before testing:

1. Client or tester invokes stop (phone number, email subject line, or codeword).
2. Tester ceases active exploitation within the agreed minutes.
3. Tester preserves logs, documents last action, and waits for written restart approval.

Stops happen when a scanner crashes a fragile SCADA gateway, when blue team mistakes you for a real attacker, or when legal counsel intervenes. A clear procedure keeps relationships intact.

Mandatory reporting during the engagement

RoE should define severity thresholds that trigger immediate notice, not only entries in the final PDF.

Example reporting matrix — actual notification timing must be defined in the RoE:

Interim reports are not the final penetration test report. They are short, factual alerts: what was found, on which asset, what you stopped doing, and what you need from the client to continue safely.

Authorization letter and tester risk

The authorization section is sometimes informally called a "get-out-of-jail letter" in practitioner slang, but authorization letter is the clearer professional term. It states that the signer permits the named tester to perform the described activities on the listed assets for the stated period.

Minimum authorization content:

• Legal name of client organization
• Name of penetration testing firm or individual testers
• Summary scope reference (attachment or SoW section)
• Effective dates
• Signature, title, and date from someone with authority over the assets

Tester-side risks when RoE is weak or missing:

• Criminal liability under computer misuse statutes
• Civil claims from downtime or data exposure
• Potential denial or limitation of insurance coverage if the activity falls outside the policy's covered work or agreed scope
• Reputational damage when blue team or law enforcement responds to an "unauthorized" test

Carry a PDF of the signed RoE and authorization during on-site work. For remote tests, keep an encrypted copy reachable offline if email fails mid-incident.

Cloud, third-party, and shared-responsibility notes

Modern RoE must mention environments where the client does not own the hypervisor. Client authorization covers assets the client owns or is contractually permitted to test; it does not override a cloud or SaaS provider's own testing restrictions.

The shared-responsibility model means the RoE should state which layer the client authorizes: identity configuration, application code, container images, or network controls. Testing only the app when the engagement sold "cloud pentest" creates a reporting gap and a legal gray area.

Apply RoE discipline to your home lab

You do not need a notarized document to attack your own Metasploitable VM. You still benefit from RoE habits:

• Document which VMs and subnets are in scope on the isolated bridge
• Keep lab traffic off vmbr0 or your home LAN unless the walkthrough requires it
• Snapshot targets before exploitation so you can restore clean state
• Never reuse lab exploit commands against work, school, or Internet hosts "just to see"

The VirtualBox pentest lab and Proxmox pentest lab setup guides describe the technical isolation. This article describes the documentation that makes the same boundaries clear when someone else owns the servers.

Sample RoE outline you can adapt

Use this skeleton in a document editor. Replace bracketed placeholders; have legal counsel review before client use.

PENETRATION TEST RULES OF ENGAGEMENT

1. Parties
   Client: [Legal name]
   Tester: [Firm or individual]
   Client technical contact: [Name, phone, email]
   Client authorization signatory: [Name, title]
   Tester engagement lead: [Name, phone, email]

2. Authorization
   The undersigned authorizes [Tester] to perform security testing
   described herein on in-scope assets from [start date] through
   [end date].

3. In-scope assets
   [IP ranges, hostnames, URLs, cloud subscriptions, applications]

4. Out-of-scope assets
   [Explicit exclusions, third parties, production data stores]

5. Permitted techniques
   [List allowed testing types]

6. Prohibited techniques
   [DoS, social engineering, destructive actions, etc.]

7. Testing schedule
   Time zone: [TZ]
   Allowed hours: [e.g., Mon–Fri 09:00–17:00]
   Blackout dates: [List]

8. Communication and reporting
   Status cadence: [e.g., weekly]
   Critical finding notification: [hours, channel]
   Secure evidence transfer: [method]

9. Data handling
   Retention: [days]
   Destruction: [procedure after report delivery]

10. Emergency stop
    Contact: [phone / email]
    Tester response: cease active testing within [N] minutes

11. Signatures
    Client: _________________________ Date: _______
    Tester: _________________________ Date: _______

Common RoE mistakes

References

• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
• PTES — Pre-engagement
• OWASP APTS — Rules of Engagement Template
• AWS penetration testing policy
• Microsoft MSRC — Penetration testing rules of engagement
• Google Cloud — Penetration testing FAQ

Summary

Rules of engagement turn a scope statement into something a tester can execute without guessing. They name the assets, the permitted and forbidden techniques, the hours, the contacts, the reporting thresholds, and how authorized testing is documented.

As a conservative testing practice, treat denial-of-service, phishing, or cloud control-plane testing as out of scope until the RoE or governing agreement clearly allows them. When you find something critical, follow the RoE escalation path before you chase the next shell.

In your own lab, you are both client and tester. The isolated network and snapshot discipline from the hardware guides play the same role the signed authorization package plays on a paid engagement. Carry that habit forward before you aim Nmap at an address you do not own.