What the document has to name
Every item below exists because its absence has caused a problem on someone's engagement.
- Targets: the exact hosts, domains, applications and ranges in scope
- Exclusions: what is explicitly out of scope, including anything shared or third-party hosted
- Window: the dates and hours during which testing may happen
- Permitted techniques, and the prohibited ones
- Accounts and credentials provided, and the data the tester may create
- Contacts: who to reach immediately, and how, if something behaves unexpectedly
- Handling: how findings and any data encountered are stored and transmitted
Exclusions protect you more than inclusions
A target list says what may be tested. The exclusion list says what must not be, and that is the part that prevents accidents.
Shared hosting is the common trap. Your application may sit on infrastructure you do not own, in which case your signature does not authorize testing it. Third-party infrastructure stays out of scope until that provider has authorized testing in writing too.
Why the contact line matters
Testing touches live systems. Occasionally something behaves unexpectedly, and the value of the engagement at that moment depends entirely on whether a named person can be reached in minutes.
A rules of engagement document with a generic support address is a document that has not been thought about. It needs a person, a phone number, and a backup.
Exploitation stops at proof of impact
This clause is worth stating explicitly, because it is what stops a test from becoming the incident it was hired to prevent.
Once a tester has shown they can reach something, they document it and stop. They do not extract the data, pivot further than needed, or keep the access. The report proves the exposure; it does not create a second one.