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.

What is the Penetration Test Scope Document Builder?

Builds a penetration test scope and rules-of-engagement document with in-scope targets, IP ranges, permitted test types, explicit out-of-scope systems, a testing window, emergency contacts, reporting requirements, and an authorization sign-off block. It runs free in your browser on Gera Tools, with nothing uploaded.

Penetration Test Scope Document Builder

Name: Penetration Test Scope Document Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

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.

The legal importance of written authorization

Penetration testing involves deliberately probing systems for vulnerabilities — activities that would constitute unauthorized access under the Computer Fraud and Abuse Act (in the US), the Computer Misuse Act (in the UK), and equivalent legislation in most jurisdictions. Written, signed authorization is the legal safe harbor that distinguishes a sanctioned security test from criminal activity.

This matters not just for the testing vendor but for the client’s security team. Internal employees are also protected (and potentially implicated) by the scope document. If testing traffic triggers a third-party SOC alert or a cloud provider’s abuse team, presenting the signed scope document and authorization is how you demonstrate that the activity was intentional and permitted.

What goes in the out-of-scope list

The out-of-scope exclusion list is as important as the in-scope list. Systems that should almost always be excluded:

Third-party SaaS providers and cloud platforms you do not own. You cannot legally authorize testing of AWS, Google Cloud, or Salesforce infrastructure without their explicit penetration testing approval process.
Production databases holding real customer data, unless you have specifically accepted the risk and have rollback procedures.
Life-safety systems — any OT/ICS equipment, medical devices, building management systems.
Systems belonging to other clients in a shared hosting environment.
Any system not explicitly in scope — the default assumption should always be out-of-scope, not in-scope.

Defining the testing window

A testing window is more than a courtesy notice. It tells your monitoring team when to expect the unusual traffic so they do not escalate a genuine alert to an incident. It also provides a time-boxed stop condition: if something goes wrong outside that window, the tester knows they are operating outside the agreed terms.

Best practice is to define both a start date/time and an end date/time in the local timezone of the client’s operations team, and to include an explicit statement about what happens if the test needs to be paused or extended — requires a written amendment to the scope, not a verbal approval.

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.
Include a clause specifying what the tester must do if they discover an active compromise by a third party during the test — a not uncommon finding that the scope document should address in advance.