What is a pen test scope document?

It is the written agreement that defines exactly what a penetration tester may and may not touch, when, and how. It protects both the client and the tester by removing ambiguity about authorization and boundaries.

Why list out-of-scope systems explicitly?

Naming systems that must not be tested — third-party hosted services, production databases, anything fragile — prevents accidental outages and legal exposure. An explicit exclusion list is clearer and safer than assuming testers will infer boundaries.

What are rules of engagement?

Rules of engagement are the operating constraints for the test: no real-data exfiltration, no destructive actions, identifiable testing traffic, and an immediate-stop rule if a live outage risk appears. They keep an aggressive test from causing real harm.

Why include an emergency contact and testing window?

A defined window tells operations and monitoring teams when alerts are expected from testing, and the emergency contact gives the tester someone to reach instantly if something goes wrong. Together they prevent a finding from becoming an incident.

Is the authorization block legally important?

Yes. Penetration testing without written authorization can constitute unauthorized access. The signed authorization block establishes that the client explicitly permitted the listed testing, which is the legal basis for the engagement.

Penetration Test Scope Document Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Authorize a pen test without ambiguity

A penetration test without a clear scope is a liability for everyone involved. This builder produces a complete scope and rules-of-engagement document — what’s in, what’s emphatically out, when, by whom, and what the report must contain — ending with a signature block that establishes written authorization.

How it works

You enter the client and vendor, then list in-scope targets and IP ranges one per line. You select which test types are permitted from a standard checklist (external network, web app, API, mobile, social engineering, and more), and you list out-of-scope systems explicitly so nothing fragile gets touched. You set the testing window, an emergency contact, and your reporting requirements. The builder assembles these into numbered sections plus a fixed rules-of-engagement block — no data exfiltration, no destructive actions, identifiable traffic, immediate-stop on outage risk — and a dual-signature authorization section. That signed authorization is what legally distinguishes a sanctioned test from unauthorized access.

Tips and example

Be specific in IP ranges — use CIDR like 203.0.113.0/24 or explicit start-end pairs so there’s no guesswork.
Put anything third-party hosted in the out-of-scope list; you usually can’t legally authorize testing on infrastructure you don’t control.
Schedule the window to overlap business hours only if your ops team is watching, so alerts from testing aren’t mistaken for a real attack.
State the report format you need (for example CVSS v3.1 scored findings) up front so deliverables match expectations.