Rules of Engagement for Pentest Contracts

The Rules of Engagement, usually shortened to ROE, is the single document that turns a penetration test from an unauthorized attack into a legitimate service. It deserves more care than most contracts get.

A weak ROE does not just create legal exposure. It creates ambiguity at the exact moment ambiguity is most dangerous, mid-engagement, when a tester finds something interesting just outside what they thought was authorized.

What a solid ROE actually specifies

• Named scope. Specific IP ranges, domains, or wildcard subdomains, listed explicitly rather than described in prose.
• Named exclusions. Anything inside that range the client cannot authorize, commonly a third-party-hosted subdomain or a shared piece of infrastructure. Exclusions should always override inclusions, never the other way around.
• A testing window. Exact start and end dates, and ideally hours, so nothing runs before authorization begins or after it lapses.
• Permitted techniques. Whether exploitation is in scope at all, and if so, whether it is limited to confirmation (proving a flaw is real) or extends to deeper post-exploitation activity.
• An emergency contact. A real person who can be reached if something unexpected happens, on both sides.

Scope is not just a list, it is a boundary that has to be enforced

Writing a scope down is the easy part. The harder part is making sure every single action taken during the engagement is actually checked against it, not assumed to be within it because it seemed close enough. We wrote a full piece on why scope enforcement has to be a technical control, not just a policy, because the gap between "we agreed on scope" and "every tool respected it in real time" is where most real incidents come from.

Time windows matter as much as target lists

It is common for engagements to sit approved but not yet started, or to run past their original end date because a retest got scheduled late. A tool or a team that only checks scope once, at kickoff, will happily keep running against a target whose authorization already expired. Every action should re-check both scope and the time window at the moment it actually runs, not just when it was first proposed.

Put it in the report too

A good final report references the ROE directly, usually by a document number or reference code, so a client's auditor can trace every finding back to a specific authorization. For more on what belongs in that final document, see how to read a penetration test report.