Rules of engagement (RoE)

What are rules of engagement in penetration testing?

Rules of engagement are the written permission and the operating limits for a test, agreed and signed before any traffic is sent. NIST's glossary puts it plainly: the RoE is established before the test starts and "gives the test team authority to conduct defined activities" without asking again for each one.

That authority is the point. Attacking a system without the owner's permission can be a crime under computer misuse laws such as the US Computer Fraud and Abuse Act, whatever the intent. The RoE is what makes a pentest legal, and what the tester points to when an on-call engineer asks why someone is logged in as their admin.

Where does the standard template come from?

The reference is Appendix B of NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, published in September 2008. Appendix B is titled "Rules of Engagement Template," and NIST describes it as illustrative: organizations may structure their own RoE however they choose. Its sections are introduction (purpose, scope, assumptions and limitations, risks), logistics (personnel, schedule, test site, equipment), communication strategy (including incident handling), target systems with an exclude list, testing execution (technical and nontechnical components, data handling), reporting, and a signature page.

Section 6.5 of the same publication notes that an RoE carries the same content as an assessment plan and also covers activities an organization's policies would normally prohibit, such as attacks that compromise systems. That is why the RoE, not the plan, is the authorizing document.

FedRAMP makes this formal. Its Penetration Test Guidance (version 3.0, 2022) says the RoE must be developed in accordance with SP 800-115 Appendix B, approved by the Authorizing Official before testing, and must include a clause requiring that critical high-impact vulnerabilities be reported to the AO, CIO, CISO and ISSO as soon as they are found.

What clauses does a real RoE contain?

The checklist below follows the NIST structure and adds the questions the PCI SSC's penetration testing guidance (section 4.1.3) suggests asking. Each item should end up as a concrete sentence in the signed document.

1. Parties and purpose. The client legal entity, the testing firm, and why the test is happening (annual PCI test, SOC 2 evidence, pre-launch review).
2. Authorizing signatories. Who has the authority to permit testing of these systems. NIST's template expects at least the test lead and senior management (CSO, CISO or CIO) to sign.
3. Targets. Hostnames, URLs, IP ranges, API base paths, cloud account IDs, each listed explicitly.
4. Exclude list. Systems that must not be touched, named as explicitly as the targets. Shared infrastructure, third-party SaaS, and the payment processor usually sit here.
5. Third-party permissions. Hosting and cloud provider rules. AWS, for example, permits testing of many listed services without prior approval but prohibits DoS, request flooding and DNS zone walking. The PCI guidance notes that where a hosting agreement requires approval, it must be obtained before testing.
6. Testing windows and time zone. Start and end dates, allowed hours, and blackout periods such as a release freeze or month-end close.
7. Source addresses. The IPs or egress ranges testing will come from, so the SOC can tell the test from an attack.
8. Permitted techniques. For example: authenticated testing, exploitation to proof of concept, file upload of benign markers.
9. Prohibited techniques. Typically denial of service, social engineering, physical access, and destructive actions unless separately agreed.
10. Accounts and access level. Which test accounts and roles the tester receives, whether source code or specs are provided (see black-box, gray-box and white-box testing).
11. Depth of exploitation and success criteria. How far the tester may go after the first foothold: stop at proof, pivot to adjacent systems, or pursue a named objective. The PCI guidance recommends agreeing success criteria in advance so the tester does not exceed expectations.
12. Data handling. Proof-of-concept access only, what may be retained, how evidence is stored and when it is destroyed. The PCI guidance says any cardholder data obtained must be secured under PCI DSS.
13. Communication and escalation. Named primary and backup contacts on both sides, the channel for routine updates, and a separate out-of-hours number.
14. Critical finding notification. How fast a critical issue is reported, and to whom, without waiting for the report.
15. Stop conditions. When testing halts: service degradation, evidence of a real prior compromise (both NIST and the PCI guidance address this), or a request from a named contact. Also who can authorize resuming.
16. Reporting and cleanup. Deliverables and their format, the retest arrangement, and removal of test accounts, uploaded files and tools after the engagement.

Which clauses keep a production test safe?

Clauses 5, 9, 11, 12 and 15 carry most of the production risk. The wording that tends to work in practice is specific:

Rate: automated requests will not exceed 10 per second per target host.
Writes: test accounts may create and modify only records they own.
  No bulk deletion, no changes to billing, no outbound email or SMS
  to real recipients.
Exploitation: stop at proof of impact. Read one record to prove access;
  do not enumerate a table.
Halt: if error rates or latency on any target visibly degrade, testing
  pauses and the client contact on the call sheet is phoned, not emailed.

The numbers are examples to adjust, not norms. What matters is that each line is testable after the fact: someone can read the request log and see whether it was followed.

How is an RoE different from scope and from a statement of work?

Scope is one section of the RoE; the statement of work is the commercial contract that sits above both.

Teams get into trouble when the SOW's scope and the RoE's target list drift apart after a late change, or when the RoE is folded into the SOW and never reaches the engineers on call.

Common mistakes

• An exclude list that says "production databases" with no hostnames.
• A single point of contact who is on vacation during the test window.
• No clause for what happens when the tester finds signs of a real attacker.
• Test accounts created for the RoE and never deleted afterward. See authenticated penetration testing for account hygiene.

Written by Parameter · Last reviewed September 27, 2026