September 24, 2026
The Reflected XSS Methodology: 11 Labs Behind $5,000+ in Bounties and 80+ Pentests
The Reflected XSS Methodology: 11 Labs Behind $5,000+ in Bounties and 80+ Pentests
Salman Khan
New Update: Our new blog is updated.
Free download
Fiza Nadeem is an SEO content writer at ioSENTRIX with 2.5+ years of experience in content writing, copywriting, and SEO.
Penetration testing rules of engagement (ROE) are the written terms that say what a tester may attack, when, how, and with whose permission. The document protects both sides: the client from an outage or data exposure they did not sign up for, and the testing team from doing something that is a crime without authorization. In cyber security, rules of engagement are the line between a penetration test and an intrusion.
This guide covers what a rules of engagement template should include, how to create the document, what NIST SP 800-115, PTES, OWASP and CISA say about authorization, and how ROE differs from a penetration test policy. ioSENTRIX signs an ROE before every engagement; what follows is what ours contains.
Rules of engagement in penetration testing are a signed document that defines the scope, boundaries, schedule, methods, communication channels and legal authorization for a security test. NIST's glossary, drawing on SP 800-115, defines ROE as detailed guidelines and constraints regarding the execution of information security testing, established before the test starts, that give the test team authority to conduct defined activities without the need for additional permissions.
That last clause is the point. Penetration testing involves actions that an organization's own policies normally prohibit, such as exploiting a vulnerability or pulling data from a compromised host. The ROE authorizes those actions for named people, against named systems, in a named window. Everything outside it stays prohibited. See our rules of engagement glossary entry and the guide to stages of penetration testing for where the ROE sits.
A penetration testing rules of engagement template should include eight sections: purpose and parties, scope with an explicit exclude list, schedule and testing windows, methodology and permitted techniques, risk controls and data handling, communication and escalation, reporting and retest, and written authorization with signatures. NIST SP 800-115 Appendix B publishes a template with a similar structure; the version below is the one we use.
State who is being tested, who is doing the testing, and why. Name primary and backup contacts on both sides with availability and a secure channel. SP 800-115 asks for a table of every point of contact, including the incident response team, so a SOC analyst who sees unusual traffic at 2 a.m. can identify it in one call.
List every asset authorized for testing: IP ranges, domains, cloud accounts, web and mobile applications, APIs, and the credentials the tester starts with. Then list what is excluded. SP 800-115 calls this the exclude list and describes it as crucial: production systems with strict uptime requirements, third-party platforms you do not own, employee devices, legacy systems that may fail when probed. An asset on neither list is not in scope.
Set start and end dates, the hours testing may run, and blackout periods around releases or maintenance. Business-hours testing suits internal systems where the team coordinates in real time; after-hours windows suit external infrastructure where load matters. A fixed window also lets the SOC tell the test from an attack.
Say whether the test is black box (no prior knowledge), gray box (limited credentials) or white box (full access, source code, architecture), and which standard the methodology follows, such as PTES, NIST SP 800-115 or the OWASP Web Security Testing Guide. Then state what is allowed. Denial-of-service testing, social engineering, physical entry, exploitation of production data stores and post-exploitation actions such as lateral movement each need an explicit yes or no. Silence is not consent.
Define how sensitive data is handled when the tester reaches it: whether personal, health or payment data may be viewed, copied or only demonstrated by screenshot, and how test artifacts are stored, transmitted and destroyed. SP 800-115 recommends that the ROE state halting criteria, the course of action if a test harms the network, and what to do if the tester finds a real intruder already inside.
Set the cadence and channel for status updates and the rule for critical findings. At ioSENTRIX a confirmed remote code execution or exposed credential store is reported the same day, not held for the final report. Write down who can pause the test and who can authorize resuming it.
Describe the deliverables: an executive summary, technical findings with severity ratings, evidence and reproduction steps, remediation guidance, and a tracker for open items. Say what will be retested after fixes. Our glossary covers what a penetration testing report should contain.
This section makes the rest enforceable. It records that a person with authority over the in-scope systems grants permission to test them as described, signed by that person and by the test lead. SP 800-115 specifies, at minimum, the test team leader and the organization's senior management, such as the CSO, CISO or CIO.
You create a rules of engagement document by working through six steps with the testing provider before testing begins: define objectives, inventory assets, agree on methodology and constraints, agree on risk controls and communication, confirm third-party and cloud provider permissions, and obtain signatures. It usually takes one or two scoping calls plus legal review.
A vendor willing to start without an ROE is itself a finding; our guide to choosing a penetration testing services provider lists the other signals.
All four agree on the principle: no testing without documented authorization and an agreed scope. They differ in how much structure they give you; NIST SP 800-115 gives the most.
NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment, treats the ROE as the document that authorizes assessors to perform activities the organization's policies normally prohibit. It recommends involving legal counsel for intrusive tests such as penetration testing, addressing indemnity and limitation-of-liability clauses in the contract, and resolving privacy concerns before the assessment begins. Appendix B is a full ROE template with a signature page. Federal agencies are its audience, but nothing in it is federal-specific; see our guide to NIST-aligned penetration testing.
The Penetration Testing Execution Standard puts rules of engagement inside its first phase, pre-engagement interactions. It separates scope (what is tested) from rules of engagement (how testing occurs), and it is blunt about authorization: the permission to test document is one of the most important documents to obtain, and testing cannot begin without the customer's signature on it.
OWASP's Web Security Testing Guide is a technical methodology for web applications, not a contracting guide. It points readers to PTES and SP 800-115 for the engagement framework and notes that internal testing, third-party testing and bug bounties differ in authorization and rules of engagement. OWASP tells you what to test; the ROE tells you whether you may.
CISA's own penetration testing service states that a rules of engagement document is drafted and signed by both parties describing the scope, that tests occur only at agreed times on predetermined systems, and that the tester stays in constant communication with the technical point of contact.
Underneath all of it sits the law. In the United States, 18 U.S.C. 1030 makes it an offense to access a computer without authorization or in excess of authorized access. The ROE is the record that access was authorized, and where the authorization stopped.
Rules of engagement, a penetration test policy and an authorization letter are three different documents. The policy is yours and lasts; the ROE is shared and lasts one engagement; the authorization letter is the page a tester carries.
A penetration test policy is an internal document that states how often your organization tests, which systems must be tested, who may authorize a test, which standards apply and how findings are tracked. It is what an auditor asks for when checking that testing is a governed process; our guides to SOC 2 penetration testing requirements and penetration testing for compliance cover what auditors expect.
Rules of engagement implement the policy for one test. The policy says "we test all internet-facing applications annually"; the ROE says "these seven applications, from these IP addresses, between these dates, with these constraints."
An authorization letter, or permission-to-test letter, is the signed consent that sits inside or alongside the ROE, the page a tester shows a hosting provider, a security guard or a lawyer. PTES treats it as the document that gates the start of testing; SP 800-115 folds it into the ROE signature page.
Yes. The major cloud providers publish their own rules for customers who test cloud resources, and your ROE must comply with them. AWS permits testing of a published list of services, including EC2, RDS, Lambda and API Gateway, without prior approval, prohibits denial-of-service and DNS-hijacking tests, and requires a form at least two weeks ahead for simulated events such as red team exercises. Microsoft's penetration testing rules of engagement for Azure permit fuzzing, port scanning and vulnerability assessment against your own resources, and prohibit denial-of-service testing, accessing data that is not yours, and post-exploitation actions. Google Cloud states that customers testing their own projects need not contact Google, provided they follow its acceptable use policy and terms.
Provider permission is not a substitute for your own ROE; it permits you to test your resources, while the ROE authorizes a specific tester to do so on your behalf. If a third-party SaaS platform is in scope, its consent is a separate item, and many refuse testing outright; our guide to third-party risk assessment covers vendors inside your attack surface but outside your authority.
Rules of engagement for security testing are the agreed, written constraints on a test: which systems may be tested, when, using which techniques, who must be told, what stops the test, and who authorized it. They apply to penetration tests, red team exercises and vulnerability assessments alike, and are signed by management and the test lead before work begins.
Someone with authority over the in-scope systems, and the test lead. NIST SP 800-115 specifies at minimum the test team leader and the organization's senior management, such as the CSO, CISO or CIO. If systems are owned or hosted by a third party, that party's consent is also required, and legal counsel should review the document first.
The purpose is to make the test safe, legal and useful at the same time: safe because the document names the systems that must not be touched and the conditions that halt testing; legal because it records written authorization from someone entitled to give it; useful because a test with no agreed scope produces findings nobody asked for and misses the systems that mattered. It is also the reference point for every judgment call a tester makes mid-engagement.
The ROE should say. The usual rule is that the tester stops, documents what was observed without exploiting it, and reports it to the named contact, who can extend the scope in writing or decline. Exploiting an out-of-scope system is unauthorized access, however vulnerable it looks.
ioSENTRIX is a CREST-accredited penetration testing firm, ISO/IEC 27001 certified and SOC 2 Type 2 attested. Every penetration testing engagement we run starts with a rules of engagement document built on the structure above: precise scope, an explicit exclude list, agreed windows, named techniques, data handling rules, same-day reporting of critical findings, and a signature page legal has seen. We bring the draft to the first scoping call. The ROE is how a test proves what holds without becoming an incident of its own.
If you are scoping a test and want a rules of engagement draft to start from, talk to us.
