Rules of Engagement: What Should Be in Every Offensive Security Contract

Four documents, four jobs

Security testing is authorized attack. The paperwork is what makes it authorized, and it only works when each document does its own job. Our approach page describes the same four documents in plain language; this article looks at what goes in them.

Providers package these differently, and the names vary. What matters is that each job is done in writing before anyone touches a system. An MSA without a SOW commits nobody to test anything; a SOW without authorization permits nothing.

What the rules of engagement should cover

The National Institute of Standards and Technology (NIST) defines rules of engagement (ROE) this way: "Detailed guidelines and constraints regarding the execution of information security testing." Its glossary adds that the document "is established before the start of a security test, and gives the test team authority to conduct defined activities without the need for additional permissions."

NIST Special Publication 800-115 includes a rules-of-engagement template in its Appendix B. The sections below follow the questions that template and the rest of the publication raise.

Targets and the exclude list

Name what may be tested and, just as importantly, what may not. The NIST template says: "It is also crucial to identify any system not authorized for testing—this is referred to as the “exclude list.”" Fragile systems, shared infrastructure and anything run by a third party who has not agreed belong on it.

Testing window

State the dates and the hours. The template notes that "it may be prudent to conduct technical testing of an operational site during evening hours rather than during peak business periods." Record the time zone, any change freezes, and whether testing may run outside the agreed hours if a finding needs following up.

Permitted techniques

The template says this section "should detail allowable and unallowable activities." Be specific. Is social engineering in scope, and against whom? May the tester exploit a finding, or only confirm it? May they create accounts, upload files or change data? Is anything that could affect availability allowed at all?

Intensity

Intensity is how hard the testing pushes: request rates, concurrent scans, the number of login attempts before an account might lock, and, for a red team engagement, how stealthy the operators should be and whether your defenders know testing is under way. Agree it in terms the system owners recognize.

Source addresses and identification

NIST recommends that the addresses testing will come from "should be identified in the assessment plan to enable administrators to differentiate assessment activities such as penetration testing attacks from actual malicious attacks." Put them in the rules of engagement, along with how your team can confirm that suspicious activity is the tester.

Escalation contacts

List named contacts on both sides, with how to reach them in and out of hours. The template calls for "a table with all points of contact for the test team, appropriate management personnel, and the incident response team." Agree how a critical finding is reported: NIST says that where testing gains administrator rights on a critical system, "assessors should immediately notify the person identified in the assessment plan or ROE."

Stop conditions

Write down when testing pauses. The template says: "Criteria for halting the information security testing should be provided," and adds that a process for reinstating the test team and resuming testing should also be provided. Common triggers include unexpected degradation of a system, evidence of a real intruder, or accidental access to data outside scope. NIST puts the question directly: "should testing stop? If so, when can testing recommence—and by whose authority?"

Data handling

Test results are a map of your weaknesses. The template notes that they "will identify vulnerabilities that an adversary can exploit, and should be considered sensitive." Agree how evidence is captured, stored and transferred, who can see it, when credentials issued for testing are revoked, and when material is deleted. NIST adds that where retention requirements are not already set, they "should be specified in the assessment plan or ROE." At Red Cell, the retention period and deletion point are set in the SOW for each engagement.

Changes during the engagement

NIST says the rules "should be followed unless specific permission to deviate has been obtained, normally in writing, from the original signatory or individual in command." Say who can approve a change and how it is recorded.

Authorization and third-party hosting

Authorization is the permission itself, so it has to come from someone who can actually grant it and name the specific systems. You can authorize testing of what you own and operate. You cannot, on your own, authorize testing of infrastructure someone else runs.

That matters most for systems hosted or operated by a third party: cloud platforms, managed hosting, software-as-a-service products and outsourced services. Check each provider's own requirements, confirm them before testing, and keep a record. Red Cell does not test a third party because a client asks; the party that operates the system authorizes the work, in writing, first.

Legal review

NIST notes that while involving legal advisors is at each organization's discretion, "it is recommended that they always be involved for intrusive tests such as penetration testing." It also mentions that legal departments may assist by "providing indemnity or limitation of liability clauses into contracts that govern security assessments." Those terms, and the authorization itself, are for your counsel.

Checklist before testing starts

If you are writing a request for proposal (RFP), our RFP guide covers how to ask providers about these documents up front. How to read a penetration testing report covers what should come out at the other end. If you would rather work through scope and constraints in conversation, start with scoping.

Sources

1. 01NIST, Glossary: rules of engagementAccessed 2026-09-26
2. 02NIST, Special Publication 800-115, Technical Guide to Information Security Testing and AssessmentAccessed 2026-09-26
3. 03NIST, SP 800-115 full text (sections 6.5, 6.6, 7.2 to 7.4 and Appendix B)Accessed 2026-09-26