Skip to content

Rules of engagement letter builder

Fill in the scope, the testing window and the permitted techniques. The authorization document writes itself beside the form, ready to copy, download or print.

A starting template, not legal advice: have both sides and counsel review it before anyone signs. What you type stays in this browser tab. Nothing is sent or stored, and a reload clears it.

One per line: hosts, address ranges, applications, accounts.

One per line: anything that must not be touched.

Testing window

Techniques

Ticked is permitted. Unticked is listed as prohibited.

One per line, for both sides: name, role, phone, email.

Signatories

Rules of Engagement and Testing Authorization

Authorization

[Client organization] ("the Client") authorizes [Tester or testing firm] ("the Tester") to perform security testing of the systems listed as in scope below, under the conditions in this document. Testing outside these conditions is not authorized.

The Client confirms that it owns the in-scope systems or holds written permission from their owner to authorize this testing, and that it has given any notice its hosting, cloud or service providers require.

In scope

  • [In-scope targets, one per line]

Any system not listed here is out of scope.

Out of scope

  • [Out-of-scope targets, one per line]

Testing window

Testing may take place from [start date] to [end date], [permitted hours], time zone UTC.

Testing outside this window needs written approval from the Client contact named below.

Permitted techniques

  • Network discovery and port scanning
  • Automated vulnerability scanning
  • Web application and API testing
  • Exploitation of identified vulnerabilities
  • Privilege escalation and lateral movement inside scope
  • AI-assisted analysis of findings and tool output

Prohibited techniques

  • Password guessing against in-scope accounts
  • Social engineering of staff (email, phone, in person)
  • Physical access testing
  • Wireless network testing
  • Denial-of-service or load testing
  • Changing or deleting production data

A technique listed in neither section needs written approval from the Client before it is used.

Data handling

Findings and evidence are stored encrypted, shared only with the contacts named in this document, and deleted within 30 days of the final report. Credentials and personal data met during testing are reported to the Client and not retained.

Incidents and emergency contacts

If testing causes or reveals a service disruption, or the Tester finds signs of an earlier compromise, the Tester stops testing and tells the contacts below at once.

  • [Emergency contacts for the Client and the Tester: name, role, phone, email]

Signatures

For the Client: [Name], [Title], [Client organization]

Client signature: ______________________ Date: ______________

For the Tester: [Name], [Title], [Tester or testing firm]

Tester signature: ______________________ Date: ______________

What rules of engagement are

Rules of engagement are the document a client and a tester agree before a penetration test starts. They say what may be tested, when, by which methods, and who to call when something goes wrong. Together with a signed authorization letter, they are what separates a security test from an intrusion: the tester holds written permission from someone entitled to give it, and the client’s operations team knows what activity to expect and from whom.

What a pentest scope template should cover

  • Scope: the hosts, address ranges, applications and accounts that are in scope, and the ones that are explicitly out. Anything unlisted is out.
  • The testing window: dates, permitted hours and the time zone they are stated in, so a night-time scan is not a surprise.
  • Techniques: what is permitted and what is prohibited. Social engineering, physical access and anything that can degrade a service deserve an explicit yes or no.
  • Data handling: where findings and evidence are kept, who sees them, and when they are deleted.
  • Emergency contacts and stop conditions: who is called, on which number, if a system goes down or the tester finds signs of an earlier compromise.
  • Signatures from people with the authority to grant and to accept the permission.

How to use the document

Fill in the form with the client, not for them: the scope list is only as good as the client’s knowledge of what it owns. Read the result together, edit the wording to fit the engagement, and have counsel review it. Once it is signed, the tester keeps a copy within reach for the whole testing window, and the client shares the window and the source addresses with whoever watches its alerts.

Systems run by someone else need more than the client’s signature. Cloud platforms, hosting companies and software-as-a-service vendors each publish their own testing policy, and some require notice or forbid certain techniques outright. Check those policies before a target goes on the in-scope list, and keep the tool’s output as a draft until every owner has agreed.

Questions

Is this a legal document?

It is a starting template, not legal advice. It gives both sides a complete first draft to edit. Have your own counsel review the final text, because the law on computer access and on contracts differs by country and by state.

Who should sign a penetration testing authorization letter?

Someone with authority over every in-scope system, usually an owner or an executive of the client, and the person responsible for the engagement at the testing firm. Where a system is hosted or operated by a third party, check whether that party’s terms require its permission or notice as well.

How do rules of engagement differ from a statement of work?

A statement of work is the commercial agreement: deliverables, price and dates. Rules of engagement are the operating rules for the test itself: targets, hours, techniques, data handling and who to call. The authorization letter is the signed permission. This template combines the last two in one document.

Is what I type stored or sent anywhere?

No. The form and the document exist only in this browser tab. Nothing is sent to a server, nothing is saved in the browser, and reloading the page clears it. Copy, download or print the document before you leave.

Do I need this for a bug bounty program or a CTF?

Usually not. A bug bounty program’s published policy and a CTF’s rules are the authorization, and their scope sections do the job of this document. Stay inside them, and ask the organizer in writing when something is unclear.

More tools, prices and docs