Penetration Testing Rules of Engagement: 7 Things to Agree

Penetration testing rules of engagement (ROE) are the written terms that set how a test runs: who authorizes it, when it happens, which techniques are allowed, who hears about urgent findings, when testing stops and what happens to data. NIST calls them “detailed guidelines and constraints regarding the execution of information security testing.”

Your penetration test scope says what gets tested; the penetration test rules of engagement specify how.

Core components of an ROE

• Formal authorization: Written, signed approval from an authorized person on your side before testing starts. Without it, testing is unauthorized. Per PCI SSC guidance, documenting the agreed conditions “authorizes the tester to test the environment”. NIST adds that the ROE “gives the test team authority to conduct defined activities without the need for additional permissions.” We sign an NDA before testing.
• Testing scope (in-scope vs out-of-scope):
  • In-scope: External network ranges, internal network segments, web applications, APIs, cloud accounts or physical locations.
  • Out-of-scope: Systems you exclude, plus third-party hosted or cloud services until the provider approves testing (PCI SSC section 4.1.4).
• Testing windows and schedule: Dates, hours, time zone, production or staging. PCI SSC’s examples include “During what time window will testing need to be performed?”
• Methodologies and permitted techniques: Choose black, grey or white box, set what PCI SSC calls “the degree of exploitation, if any, that is permitted,” and decide whether social engineering is included. Physical entry is tested only if written into the rules. Denial-of-service and load testing aren’t part of our penetration tests. On AWS, C2 testing, simulated phishing and malware tests need a Simulated Events form filed “at least two (2) weeks in advance of the start date.”
• Communication and escalation protocols: Name technical and emergency contacts and a secure channel on both sides. We report critical vulnerabilities to that contact during the test.
• Emergency stop procedure: Agree on who can halt testing, what triggers a stop and when the test is complete. If a tester finds a previous or ongoing compromise, PCI SSC’s example is to “activate incident response procedures and stop penetration test until resolution of the compromise situation.” PCI SSC says completion criteria “should be documented in the rules of engagement.”
• Data handling and privacy: Decide whether testers disclose captured passwords and what data they may keep. For cardholder data, PCI SSC says “Only a proof-of-concept test should be performed,” and the tester should notify you immediately if it’s accessed. Our penetration testing checklist covers cleanup afterward.

In one internal test, we found an old configuration file with service credentials on a share open to employees. The tester used them only to confirm how far that access reached, a limit worth writing into the rules. The client deleted the file and rotated the credentials.

Key industry standards and frameworks

These frameworks shape rules of engagement and scoping:

• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment. Appendix B “provides a template for creating Rules of Engagement (ROE).”
• PTES (Penetration Testing Execution Standard): Our testing is aligned with PTES.
• OWASP: Our web and API tests are aligned with the OWASP Top 10 and the OWASP Web Security Testing Guide.
• PCI SSC and compliance: Section 4.1.3 of Penetration Testing Guidance v1.1 supplies the examples behind most points above. Under PCI DSS, HIPAA or SOC 2, a pentest is assessment evidence, not a compliance certificate; see penetration testing requirements.

(Note: Baseline terms are in the NIST CSRC Glossary. Microsoft’s rules of engagement for testing in its cloud say testers who accidentally access data they lack rights to must “stop immediately.”)

Sources: NIST CSRC Glossary: Rules of Engagement; NIST SP 800-115; PCI SSC Penetration Testing Guidance v1.1; AWS Penetration Testing policy; Microsoft Security Testing Rules of Engagement; OWASP Web Security Testing Guide.