Penetration testing rules of engagement: template, example and what to check before you sign

By The PenTest Index · Sources checked October 10, 2026

Penetration testing rules of engagement are the written rules for how an agreed test will run: which targets, during which hours, which techniques are off-limits, who to call, and when testing must stop. A signed copy only gives permission for testing the signer is authorized to approve. Before you sign one, check the twelve clauses below.

Don't sign yet if any of these is true:

The targets are described with open-ended words like "and related systems."
Permission is missing from someone with authority over a system on the list.
Nobody can be reached to stop the test during the hours it runs.

Penetration testing rules of engagement template: the 12 clauses

Use these twelve clauses to write rules of engagement, or to read the ones your provider sent. Each row says what to write down and the warning sign that means "hold."

Three terms first. A penetration test (pentest) is an agreed attempt to break into a system the way an attacker would, so the weaknesses get found and fixed. Rules of engagement (often shortened to ROE) are the rules for how that test runs. Scope is the list of what gets tested.

Think of a contractor working in your house. The scope is the list of rooms. The rules of engagement are the house rules while they're there: working hours, what not to touch, and who to call if a pipe bursts.

Draft for planning. This template does not give anyone permission to test. Never put passwords, keys or customer data in it.

Table columns: #; Clause; What to write down; Hold if.
#	Clause	What to write down	Hold if
1	Parties, purpose and dates	Who is testing whom, why, the document version, and the date this permission ends.	There is no end date.
2	Exact targets and environment	Each hostname, URL, address range, cloud account and workspace. Say whether it is production or staging.	You see "and related systems" or other open-ended wording.
3	Off-limits systems and techniques	Systems that must not be touched. Techniques you have not agreed to, such as overload tests, tricking staff, entering buildings, or deleting data.	Nothing at all is listed as off-limits.
4	Owners and permission	Who owns or runs each target, and who has said yes in writing. Include your hosting, sign-in, payment and email companies.	A target is run by another company and nobody has checked its rules.
5	Testing window	Dates, hours, time zone, and blackout periods such as release days.	It says "during the engagement" with no hours.
6	Test accounts and where testing comes from	The roles and test accounts testers will use, who creates and removes them, and the addresses test traffic will come from.	Your team could not tell test traffic from a real attack.
7	Traffic limits and fragile systems	How hard automated tools may push, and any old or unstable system that needs gentle handling.	You have a system known to fall over under scanning and it is not named.
8	Side effects	What testing may create, change or send: records, emails, payments, messages to other systems. Where each one goes during the test, and who cleans up.	Your test environment can still send real emails or charge real cards.
9	Defenses and who is told	Whether blocking tools stay on, whether tester addresses are let through, and whether your monitoring team or provider knows about the test.	Your monitoring provider has not been told and is not meant to be part of the test.
10	How far testers go	Whether testers only prove a weakness exists or keep going, and the point where the goal is met.	There is no limit on what happens after the first break-in.
11	Sensitive data, evidence and cleanup	What testers may view, copy and keep. How they prove access without taking data. Where evidence is stored and the date it is destroyed. Which accounts and tools get removed.	There is no destruction date.
12	Contacts, stop rules and changes	Named people on both sides with numbers that work during testing hours. How fast a serious finding is reported. What triggers a stop, who can call it, who can restart. Who approves a change.	Nobody is named who can stop the test.
	Signatures	Name, title and date for each side.	Permission is missing for a listed target.

Fill it in in your own document. Nothing you copy is sent to us.

Rules of engagement template. Draft for planning.

This template does not give anyone permission to test.

Never put passwords, keys or customer data in it.

#	Clause	What to write down	Hold if
1	Parties, purpose and dates	Who is testing whom, why, the document version, and the date this permission ends.	There is no end date.
2	Exact targets and environment	Each hostname, URL, address range, cloud account and workspace. Say whether it is production or staging.	You see "and related systems" or other open-ended wording.
3	Off-limits systems and techniques	Systems that must not be touched. Techniques you have not agreed to, such as overload tests, tricking staff, entering buildings, or deleting data.	Nothing at all is listed as off-limits.
4	Owners and permission	Who owns or runs each target, and who has said yes in writing. Include your hosting, sign-in, payment and email companies.	A target is run by another company and nobody has checked its rules.
5	Testing window	Dates, hours, time zone, and blackout periods such as release days.	It says "during the engagement" with no hours.
6	Test accounts and where testing comes from	The roles and test accounts testers will use, who creates and removes them, and the addresses test traffic will come from.	Your team could not tell test traffic from a real attack.
7	Traffic limits and fragile systems	How hard automated tools may push, and any old or unstable system that needs gentle handling.	You have a system known to fall over under scanning and it is not named.
8	Side effects	What testing may create, change or send: records, emails, payments, messages to other systems. Where each one goes during the test, and who cleans up.	Your test environment can still send real emails or charge real cards.
9	Defenses and who is told	Whether blocking tools stay on, whether tester addresses are let through, and whether your monitoring team or provider knows about the test.	Your monitoring provider has not been told and is not meant to be part of the test.
10	How far testers go	Whether testers only prove a weakness exists or keep going, and the point where the goal is met.	There is no limit on what happens after the first break-in.
11	Sensitive data, evidence and cleanup	What testers may view, copy and keep. How they prove access without taking data. Where evidence is stored and the date it is destroyed. Which accounts and tools get removed.	There is no destruction date.
12	Contacts, stop rules and changes	Named people on both sides with numbers that work during testing hours. How fast a serious finding is reported. What triggers a stop, who can call it, who can restart. Who approves a change.	Nobody is named who can stop the test.
	Signatures	Name, title and date for each side.	Permission is missing for a listed target.

Prepared with The PenTest Index:

https://thepentestindex.com/penetration-testing-rules-of-engagement/

Which five to settle first

If time is short, settle clauses 2, 4, 5, 11 and 12 before anything else. That choice is our judgment, and here is the reasoning. NIST's testing guide says a test plan should answer five basic questions: what is the scope, who is authorized, what are the logistics, how is sensitive data handled, and what happens in an incident. It adds that rules of engagement contain the same information (NIST SP 800-115, section 6.5). Our five clauses line up with those five questions.

Where the rest comes from: we wrote the template ourselves after reading NIST's sample rules of engagement outline (Appendix B of the same guide), the PCI Security Standards Council's list of points to agree before testing (Penetration Testing Guidance v1.1, section 4.1.3), and the Penetration Testing Execution Standard (PTES) pre-engagement page. Clause 8 on side effects is our own addition for teams testing web apps. NIST calls its outline "a starting point," and so is this one.

What does a filled-in rules of engagement look like?

Here is one for a made-up company, so you can see how specific each line should be.

Fictional example. Larkfield is not a real company. The provider, the people, the dates and every limit below are invented. The numbers are examples, not safe values for your systems.

Say you run Larkfield, a 30-person software company with one web app and a public API. A large customer wants proof both were tested. You have chosen a provider and agreed the scope. (See Larkfield's scope.) Now the provider needs to know how to run the test without waking anyone up.

Table columns: #; Clause; Larkfield's entry.
#	Clause	Larkfield's entry
1	Parties, purpose and dates	Larkfield and its chosen provider. A customer asked for proof of testing. Version 1.0. Permission ends Friday, November 20, 2026, at 5 a.m. Eastern.
2	Targets and environment	app.staging.larkfield.example and api.staging.larkfield.example, both staging. Two test workspaces, A and B. Nothing else.
3	Off-limits	Production. The office network. Any real customer workspace. No overload tests, no tricking staff, no deleting records outside workspaces A and B.
4	Owners and permission	Larkfield owns both targets. Staging runs in Larkfield's own AWS account. The payment and sign-in companies' systems are not targets. Larkfield's engineering lead has read AWS's testing policy for the services staging uses.
5	Testing window	Monday, November 16, 2026, at 7 p.m. to Friday, November 20, 2026, at 5 a.m. Eastern. 7 p.m. to 5 a.m. Eastern only. No testing during the Wednesday release, 9 p.m. to 11 p.m.
6	Accounts and source	Six test accounts: a Viewer, an Editor and an Admin in each workspace. Larkfield creates them and removes them by November 27. The provider sends its source addresses before kickoff.
7	Traffic limits	Automated tools stay at or under 5 requests per second. The export feature is slow, so it is tested by hand only.
8	Side effects	Invitation emails go to a test inbox only. Payments use the payment company's sandbox. Outgoing webhooks point to a capture address Larkfield controls. No more than one invitation per minute. The provider lists every record it created; Larkfield deletes them.
9	Defenses and who is told	Blocking tools stay on. Larkfield tells its on-call engineer the dates and source addresses.
10	How far testers go	Prove the weakness, then stop. If a tester can reach workspace B from workspace A, one screenshot of a made-up record is enough. No going further into AWS.
11	Data, evidence and cleanup	Made-up records only. Screenshots are redacted. Evidence sits in the provider's encrypted project store and is destroyed 30 days after the final report, with written confirmation.
12	Contacts, stop rules, changes	Jo, engineering lead, and Lee, backup, both with mobile numbers that work overnight. Serious findings by phone within one hour. Testing stops on any real customer data, any email to a real person, any slowdown, or any doubt about scope. Only Jo or Lee can restart it, in writing. Any new target needs Jo's written yes first.
	Signatures	Larkfield's chief technology officer, who controls both targets and the AWS account. The provider's test lead.

Notice what makes these lines useful. They name things. They have numbers. And a stranger reading them at 2 a.m. would know what to do.

Is the rules of engagement my provider sent safe to sign?

Read it against the twelve clauses and mark each one. If a must-settle clause is wrong or vague, hold and send questions. Here is that check run on a made-up draft.

Say Larkfield's provider had sent this instead of the version above. We checked six clauses and assumed the other six were fine.

Table columns: Clause; Larkfield needs; The draft says; Finding; Who answers; Question to send.
Clause	Larkfield needs	The draft says	Finding	Who answers	Question to send
2 Targets	The two staging hostnames only	"app.staging.larkfield.example and associated infrastructure"	Unresolved	Provider	"Please replace 'associated infrastructure' with the exact hostnames and address ranges you will test."
4 Owners and permission	Payment and sign-in companies untouched	Nothing	Unresolved	Provider and Larkfield	"Please state that our payment and sign-in providers' systems are out of bounds, and how you will stay clear of them."
5 Window	Nights only, 7 p.m. to 5 a.m. Eastern	"Testing will occur during business hours"	Mismatch	Provider	"Our window runs from November 16, 2026, at 7 p.m. to November 20, 2026, at 5 a.m. Eastern, nights only. Can you test then? Does it change the price or the report date?"
8 Side effects	No email to real people, no real charges	Nothing	Unresolved	Larkfield engineering, then provider	"What could your testing create or send in our systems, and how will each be kept inside the test?"
11 Data and evidence	Evidence destroyed on a set date	"Tester may retain evidence"	Unresolved	Provider	"What do you keep, where is it stored, and on what date is it destroyed?"
12 Contacts and stop rules	A named person reachable overnight	Names a contact with a mobile number and a stop rule	Unresolved	Provider	"Will this contact be reachable throughout our overnight testing window, and who is the backup?"

Result: hold. One must-settle clause needs changing (the window). Four must-settle clauses need an answer. One smaller item needs an answer. That is six questions to send, and the provider can probably answer all of them in one email.

A note on the labels. "Supported" means the words in the document cover that one clause. It says nothing about how good the testing will be. "Mismatch" means the document says something you can't accept. "Unresolved" means it is vague or silent, and unknown never counts as fine.

Here is how two of those lines could read after the provider replies:

Table columns: Before; After.
Before	After
"…and associated infrastructure"	"app.staging.larkfield.example and api.staging.larkfield.example. No other host, address or account."
"Tester may retain evidence"	"Redacted screenshots and request logs only, kept in the provider's encrypted project store, destroyed 30 days after the final report, with written confirmation to Larkfield."

A tighter document is still not permission. The right people still have to sign it.

Check your own document

Mark each clause below. You don't type anything, so there is nowhere to paste a target or a password. Nothing you choose is saved or sent to us.

Rules of Engagement Check

Read your document clause by clause and choose the line that matches. Must-settle clauses are marked.

Result

Hold. Don't sign yet. Must-settle clauses that need changing: 0. Must-settle clauses that need an answer: 5. Smaller items: 7.

Questions to send back

Clause 1: Parties, purpose and dates (Not checked yet)Please add the document version, both parties' names and the date this permission ends.
Clause 2: Exact targets and environment (Not checked yet)Please replace any open-ended wording with the exact hostnames, URLs, address ranges and accounts you will test, and say which environment each one is in.
Clause 3: Off-limits systems and techniques (Not checked yet)Please list the systems and techniques that are off-limits, including overload tests, tricking staff, and changing or deleting data.
Clause 4: Owners and permission (Not checked yet)Which of the listed targets are run by another company, and whose rules or written permission cover testing each one?
Clause 5: Testing window (Not checked yet)Please state the testing dates, hours and time zone, and any blackout periods. Does our window change your price or report date?
Clause 6: Test accounts and where testing comes from (Not checked yet)Which test accounts and roles will you use, who removes them afterward, and which addresses will your traffic come from?
Clause 7: Traffic limits and fragile systems (Not checked yet)What request limit will you work to, how will you treat the fragile systems we named, and who on our side agreed to those limits?
Clause 8: Side effects (Not checked yet)What could your testing create, change or send in our systems, including emails, payments and messages to other systems, and how will each be kept inside the test?
Clause 9: Defenses and who is told (Not checked yet)Will our blocking tools stay on, do you need your addresses let through, and who tells our monitoring team?
Clause 10: How far testers go (Not checked yet)After you first get in, how far will you go, and at what point do you stop and report?
Clause 11: Sensitive data, evidence and cleanup (Not checked yet)What data may you view, copy and keep, where is evidence stored, on what date is it destroyed, and which accounts and tools do you remove?
Clause 12: Contacts, stop rules and changes (Not checked yet)Who are the named contacts on both sides during testing hours, what makes you stop, who can restart testing, and who approves a change?

This check reads the words in a document. It does not give anyone permission to test, and it is not legal advice.

Prepared with The PenTest Index: https://thepentestindex.com/penetration-testing-rules-of-engagement/

No text entry. Choices are held in the page only, not saved, not sent, and cleared on reload or "Clear".

If every applicable clause is covered and your provider suits you, you don't need anything else from us. Sign with your provider and keep a copy.

Rules of engagement vs scope vs statement of work: which document does what?

Scope says what gets tested. The statement of work says what you are buying. The rules of engagement say how the test runs. Authorization is the permission itself. They can be four documents or four parts of one signed agreement.

PTES puts the first split in one line: "While the scope defines what will be tested, the rules of engagement defines how that testing is to occur."

Table columns: Document; Question it answers; What goes wrong without it.
Document	Question it answers	What goes wrong without it
Scope	What is tested, and what is left out?	Two providers quote for two different jobs.
Statement of work	What work, what report, what dates, what price?	Arguments about what was paid for.
Rules of engagement	How may the test run? Hours, limits, contacts, stop rules.	An outage at 2 p.m. and nobody knows who can stop it.
Authorization	Who gave permission, for which targets and dates?	A tester touches a system nobody with authority approved.
Master agreement or NDA	Liability, confidentiality, payment terms	A legal question, not a testing one. Ask a lawyer.

Do you need a separate authorization letter? Not always. NIST's glossary says rules of engagement give "the test team authority to conduct defined activities without the need for additional permissions." So a signed rules of engagement can be the permission, if it names the targets and the right person signs. PTES describes a separate "Permission to Test" document instead. Either works. Missing authorization for a target does not.

No scope written yet? You can't finish the rules until the scope exists, because clause 2 has nothing to point at. If the test is for a web app or an API, Find My PenTest Match asks a few quick questions, shows which of the offers we compare fit, and gives you a brief to send the providers you choose. It is free, needs no email or sign-up, and sends nothing to providers.

Find My PenTest Match

Or copy the scope brief and fill it in yourself.

Who signs the rules of engagement, and who else has to say yes?

Someone authorized to approve the testing signs for your side, and the test lead signs for the provider. Any additional approvals required from other asset owners must also be in place.

NIST's sample outline says: "At a minimum, the test team leader and the organization's senior management (CSO, CISO, CIO, etc.) should sign the ROE stating that they understand the test's scope and boundaries" (Appendix B, section 7). At a small company that usually means whoever runs engineering or IT. A job title is not the test. Authority to approve the testing is.

Then check who else is involved. NIST again: if part of your systems sits on another party's network, "the owner of the other network usually must also consent in writing" (section 6.5). PTES says it more bluntly. Your permission covers your systems, and you "do not speak for" your outside providers.

The big cloud companies have already published their answer. Here is what their own pages said on October 10, 2026.

Table columns: What is being tested; What the official page says; Lead time.
What is being tested	What the official page says	Lead time
Your own resources on AWS	No prior approval for the services on AWS's permitted list. Other services go through AWS Support. Testing that uses command-and-control (remote control of a compromised machine) needs prior approval. Simulated phishing, malware testing and covert red team exercises need a Simulated Events form. Denial-of-service and flooding are prohibited under this policy. You may not test AWS's own infrastructure.	Simulated Events requests: at least two weeks before the start date.
Your own resources on Microsoft Azure	No pre-approval or notice needed. An outside tester needs explicit written authorization from the resource owner, and Microsoft says it does not grant that for you. Microsoft's rules of engagement prohibit denial-of-service testing, traffic-heavy automated testing and phishing or social engineering targeting Microsoft staff or using Microsoft services against others, and say Microsoft may interrupt a test in progress.	None stated
Your own projects on Google Cloud	"You are not required to contact us." You must follow Google's acceptable use policy and terms, and your tests may affect only your own projects.	None stated
A software product you subscribe to	We have not checked any one product's policy here. Look for its published testing rules or ask for written permission. The PCI guidance says that if a service agreement requires approval, you get it before testing (section 4.1.4).	Varies
A monitoring or managed security provider	PTES: tell them when their own devices or services are tested, unless measuring their response is the point of the test.	Varies
A building you lease or share	For physical testing, NIST suggests a signed form with contact details that testers can show to police or on-site security (Appendix B, section 5.1).	Varies

These are summaries. Read the page for the services and activities in your own test, and write what you found into clause 4.

Lead times bite. Say your test starts Monday, November 16, 2026, and includes simulated phishing sent from AWS. AWS wants the request at least two weeks ahead, so the form is due by Monday, November 2.

Why the fuss over who says yes? In September 2019, two testers hired by Iowa's State Court Administration were arrested at the Dallas County courthouse during a physical test. According to Krebs on Security's account, they showed deputies an authorization letter listing state employees who could vouch for them. One contact did not answer. Another said he did not believe they had permission for physical entry. All charges were dropped on January 30, 2020. Two lessons for your own document: the people named in it must agree on what was approved, and they must pick up the phone during testing hours.

NIST recommends that legal advisors "always be involved for intrusive tests such as penetration testing" (section 6.6). If any target is hosted or run by another company, have a lawyer read the authorization before testing starts. If you are testing cloud systems, see our guide to cloud penetration testing services.

How do you stop a test from sending real emails or charging real cards?

Agree two things: what testers may do, and where the results of those actions go. A staging label alone doesn't prove that email, payments or outgoing messages are cut off from the real world.

One r/cybersecurity thread asks it outright: "How do orgs run pen tests without accidentally causing real side effects?"

A tester filling in your contact form 400 times is doing their job. If each submission emails your sales team, that is 400 emails. Settle these before the test, and write the answers into clause 8.

Table columns: Feature; Question to settle; What to write down.
Feature	Question to settle	What to write down
Forms and email	Where do messages go? Can repeated actions reach real people?	The test inbox, and a limit on repeats.
Payments and refunds	Is it the payment company's sandbox? Could any action move real money?	Sandbox only, or the feature is out of bounds.
Webhooks and background jobs	A webhook is a message your app sends to another system when something happens. Which ones can fire?	The capture address, or which ones are switched off.
Checks between customers	Which workspaces and accounts are yours to test with?	The named test workspaces. No real customer workspace.
Automated requests	Who agrees the limit, and who watches for trouble?	A number both sides accept, and who can call a stop.

There is a trade-off, and it belongs in the document. Switching a feature off keeps things quiet. It also means that feature was not tested. Ask for the report to say so.

We don't give a "safe" request rate here because there isn't one. The right number depends on your system, and your engineers and the provider have to agree it.

What should be off-limits in a penetration test?

Put off-limits anything you aren't authorized to test, anything you can't afford to have disrupted, and any technique you haven't agreed to. Then write down what each exclusion leaves untested.

An exclusion and a limit are different. "Do not test the payment company's systems" is an exclusion. "Test our checkout in the sandbox after 7 p.m." is in-scope work with limits. Limits usually serve you better, because the feature still gets tested.

Common entries, and where they come from:

Overload tests. AWS and Microsoft both prohibit denial-of-service testing under their testing policies. PTES suggests that if availability worries you, stress testing belongs in a copy of production, not production itself.
Tricking staff by email or phone. PTES says any pretexts should be approved in writing first.
Copying real customer or card data. The PCI guidance says a tester who reaches cardholder data should tell you immediately and keep what they hold to a minimum (sections 4.2.4 and 5.3.1). Proof of access rarely needs the data itself.
Going deeper after the first break-in. The PCI guidance suggests agreeing "success criteria," the point where the test has shown enough (section 4.1.5).

Every exclusion is something the report can't speak to. The PCI guidance's report outline includes a "Statement of Limitations" for exactly this (section 5.2.1). Ask your provider to list every restriction in the final report, so your customer or auditor sees the same boundaries you agreed.

What happens if a tester goes outside the rules, or finds a real attacker?

Testing on the affected systems stops, your named contact is told, and nothing restarts until your side says so. That is what the rules should say, and it matches NIST's advice.

NIST covers both cases:

Something breaks or an incident starts. Activities should "cease until the incident is addressed and the assessors are given approval to resume." NIST adds that in many cases only the systems directly involved need to pause (section 7.1).
Signs of a real attacker. It "should immediately be reported to the appropriate individual," and testers should stop work on the systems involved while you respond (section 7.2).
The tester wants to do something not in the rules. They follow the rules "unless specific permission to deviate has been obtained, normally in writing, from the original signatory or individual in command" (section 7.2).

The PCI guidance shows the last one in practice. During a test of an online shop, the tester found a backup site nobody had listed. The client checked it and confirmed it, and only then was it added to the test (section 6.1). Found, reported, approved, then tested.

So clause 12 needs four things in plain words: what triggers a stop, who can call it, how the tester reaches that person at 2 a.m., and who can say "go again."

One limit on this section. It describes a test your team knows about. If the point is to see whether your defenders notice, that is a different exercise with its own rules about who is told. See red teaming vs pentesting.

Do rules of engagement still apply to an automated or AI-led test?

Yes. The rules are the same. The question is how the software is made to follow them.

A person can read "don't touch the payment system." Software needs it entered as a setting. OWASP's APTS material for autonomous penetration testing includes an illustrative rules of engagement template written for machines to read. It is marked non-normative, meaning it is an example and not a required format. Its fields are a useful shopping list: exact targets, a hard deny list, rate limits, actions that need a person's approval, and contacts who can stop a run.

Five questions to ask any provider selling an automated or AI-led test:

How do I enter the exact target list, and can the tool go beyond it?
Can I enter a list of systems it must never touch?
What is the traffic limit, and can I lower it?
Which actions wait for a person to approve them?
Who can stop a run, and how fast does it stop?

If you never received rules of engagement because you bought a subscription, the rules still need to be agreed. Settings do not replace written authorization. Go through the twelve clauses and find where each one lives in the settings or engagement documents. More on these offers in our guide to automated penetration testing.

Does PCI DSS or SOC 2 require rules of engagement?

The PCI Security Standards Council's guidance says to agree them before any testing. For SOC 2 and other audits, ask the person who will read your report what they want to see.

PCI. The Council's Penetration Testing Guidance says: "All penetration testing should only be conducted as defined by the rules of engagement agreed upon by both parties" (section 2.2). It also says it is important to "document and agree upon the conditions in which testing is to be performed and the degree of exploitation, if any, that is permitted" (section 4.1.3). Two cautions. This is version 1.1 from September 2017, written against an earlier version of the standard. And it is supplemental: the document says it "does not replace or supersede requirements in any PCI SSC Standard." Confirm what the current standard asks for with your assessor. Our PCI penetration testing page covers the test itself.

SOC 2, ISO 27001, customer questionnaires. We have not read a clause we can quote that names this document, so we won't guess. Ask the reader directly: "Do you need to see how the test was authorized and controlled? If so, which document do you want?"

NIST SP 800-115. It is guidance written for US federal agencies, dated September 2008. Everyone else may use it voluntarily. It is a good outline and not a rule you must meet.

Whoever reads your report decides what they accept. No template settles that for them.

What to do next

You have a provider and a draft. Run the check, send the questions, sign when all applicable clauses are covered. You're done here.
You have a provider and no draft. Ask whether they have their own version. If not, send them the template.
You have no scope yet. Start with the scope brief. The rules come after.
You have a scope and no provider. Compare published offers, then send the unresolved questions to the ones you shortlist. If a quote is already in hand, check the quote first.

Questions before you sign

Who writes the rules of engagement, me or the provider?

Usually the provider drafts them and you fill in the limits, the contacts and the hours. NIST says developing the plan "should be a collaborative process" between the testers and your security people (section 6.5). You know what must not break. They know what the testing involves.

Can we reuse last year's rules of engagement?

Reuse the structure, not the signatures. Check the targets, owners, people, phone numbers, hours and cloud policies again, then sign a new version. Last year's approval does not automatically cover this year's systems.

Does the same document cover the retest?

Only if its end date, targets and activities cover the retest. A retest is a second look to confirm your fixes worked. If it happens after the date in clause 1, or the environment has changed, you need an updated version. How many retests you get and what they cost belongs in your quote or contract, not here.

Do we need separate rules of engagement for every tool?

No. Write one document for the engagement. If one system or one kind of testing needs different limits, add a short annex for it. That is our suggestion for keeping things readable, not a rule from any standard.

Is a rules of engagement document a contract?

It sits beside the contract and is often attached to it. Whether it binds anyone, and how it ranks against your other agreements, is a legal question for a lawyer. This page is not legal advice.

How long should it be?

Long enough that each of the twelve clauses is specific. In our view that is often two to four pages. A one-paragraph version is too short. A forty-page version nobody reads at 2 a.m. is too long.

Sources

All checked October 10, 2026. We read these documents and policy pages and wrote the template and examples ourselves. We have not run a test, bought a service or reviewed any real provider's rules of engagement.

NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, September 2008: sections 6.5, 6.6, 7.1 and 7.2, Appendix B (sample rules of engagement outline) and Appendix F (glossary)
PCI Security Standards Council, Penetration Testing Guidance v1.1, September 2017: sections 2.2, 4.1.3, 4.1.4, 4.1.5, 4.2.4, 5.2.1, 5.3.1 and 6.1. Supplemental guidance, not the standard itself.
Penetration Testing Execution Standard, Pre-engagement: rules of engagement, permission to test, third parties. The page was last edited in 2014, so we used it for planning ideas and not for current cloud rules.
AWS Customer Support Policy for Penetration Testing
Microsoft Security Testing Rules of Engagement and Penetration testing in Azure
Google Cloud Security FAQ
OWASP APTS, Rules of Engagement Template appendix: illustrative and non-normative
Krebs on Security, "Iowa Prosecutors Drop Charges Against Men Hired to Test Their Security", January 31, 2020

The findings in the example use our Purchase Check: one condition, one document, one finding. None of these organizations endorses this site. The PenTest Index does not perform, authorize or certify penetration testing.