# Penetration testing rules of engagement: what to agree in writing

Source: https://penetrationtestservices.com/guides/penetration-testing-rules-of-engagement/
Publisher: Excession Labs (penetrationtestservices.com)
Last updated: 2026-11-09

Pentest rules of engagement: what to agree in writing (authorization, scope, test windows, off-limits actions, stop conditions, data) plus a template outline.

> **Short answer:** Rules of engagement are the written terms of a penetration test. They state who authorizes the test, what is in and out of scope, when testing happens, which actions are off limits, when the tester must stop, how data is handled, and who to call. Agree them before testing starts. This page is not legal advice.

Rules of engagement (RoE) are the written terms that govern a penetration test. They protect both sides: the owner knows what the tester will do, and the tester knows what they may do. Without them the tester has no permission, and the same actions look like an attack.

Excession Labs tests only with written authorization from the system owner. This page is not legal advice. Ask a lawyer to review your own documents.

## Why do rules of engagement matter?

They set permission, limits and a shared plan, and pentesting standards put this work first. NIST SP 800-115 treats planning as the first phase of a test. PTES, a community method last edited in 2014, opens with pre-engagement.

Good rules reduce three risks:

- Legal risk: testing without permission can break computer misuse laws.
- Operational risk: a careless test can take down a service or damage data.
- Scope drift: without a list, tests grow.

## What goes into an authorization letter?

An authorization letter is a signed statement that the owner permits the test. Keep it short and exact. It contains:

1. Name and role of the signer, and a statement that they have authority over the systems.
2. Name of the testing company and the testers' contact.
3. The systems in scope, by name and address.
4. The start and end dates.
5. A statement that testing is permitted within the rules document.
6. Signature and date.

If a third party hosts any in-scope system, check its policy. PTES warns that a client's permission may not cover its third-party providers. For large cloud platforms, the providers publish their own testing policies. Read the policy for each provider you use.

## How do you define scope?

Scope is the list of what may be tested. List each target by exact host name, URL, API base path, environment and version. Add the roles and tenants the tester may use.

State what is out of scope. Examples: production payment processors, third-party SaaS tools, other customers' systems, employees, office networks. The tester does not touch a target that is not listed. "Our website" is too vague for a scope; "app.example.com and api.example.com, staging, build 2026.11" works.

## What are the test windows?

State the dates and the hours when active testing may run. Add times when it may not: peak sales hours, batch jobs, release freezes.

Say whether you want the test during business hours or off-peak, and state the time zone. Say also if the tester may run heavy requests, such as a large number of login attempts, and when.

## What actions are off limits?

Write the forbidden actions out. Common items for web app, API and SaaS tests:

- Denial of service or load testing.
- Social engineering of your staff or customers, unless scoped.
- Attacks on third-party systems.
- Deleting or changing records that the tester did not create.
- Reading or copying real customer data beyond what proves a flaw.
- Sending bulk email or text messages.
- Persistent changes to production configuration.

Also set bounds. If a test sends email, uploads files, guesses passwords or calls paid third-party APIs, state the maximum and who pays. Excession Labs bounds these tests and states their cost in the report.

Destructive proofs use only test-owned accounts and records, marked as test data.

## What are stop conditions?

A stop condition is an event that makes the tester pause and call you. Agree them before the test. Typical ones:

- The service shows errors or slows down because of testing.
- The tester sees real customer data that should not be exposed.
- The tester finds a critical flaw that is easy to use and affects live users.
- The tester finds signs that someone else has already compromised the system.
- The tester is asked to go outside scope.
- Your contact asks the tester to stop.

For each one, write who is called, by what channel, and how quickly, with a time you define in your own document. A tester who finds a serious flaw should not wait for the final report.

## How is data handled?

State what data the tester may see, store and keep. Cover:

- Where test evidence is stored, and in what form (encrypted storage).
- Who can access it.
- How long it is kept, and how it is deleted.
- How credentials and tokens are handled, and when they are revoked.
- Whether real personal data may appear in evidence. If it does, the tester redacts it.
- How the final report is delivered and who may receive it.

If the tester gets source code, say how it is stored and when it is deleted. For personal data under a privacy law, ask your counsel which terms you need.

## Who are the contacts?

List names, roles, phone numbers and chat channels for both sides. On your side, name a technical contact, a backup, an escalation contact who can stop the test, and the security team contact who handles alerts, so they know the test is real. On the tester's side, name the lead.

## A template outline

Use these headings as a start and fill each with exact facts. The outline is not a legal document.

```text
RULES OF ENGAGEMENT: 

1. Parties and purpose
   1.1 System owner and signer
   1.2 Testing provider
   1.3 Goal of the test
2. Authorization
   2.1 Statement of permission
   2.2 Third-party systems and provider policies
   2.3 Signature and date
3. Scope
   3.1 In-scope assets (host, URL, environment, version)
   3.2 Out-of-scope assets
   3.3 Roles, tenants and accounts provided
   3.4 Test type (black, grey or white box)
   3.5 Known issues to skip
4. Schedule
   4.1 Start and end dates
   4.2 Allowed hours and time zone
   4.3 Blackout and freeze periods
5. Allowed methods
   5.1 Tools and request limits
   5.2 Bounded tests (uploads, email, password guessing, paid APIs)
6. Off-limits actions
7. Stop conditions and escalation
   7.1 Events that pause the test
   7.2 Who is called, how, and how soon
   7.3 Rule for critical findings found during the test
8. Data handling
   8.1 Test data and test-owned records
   8.2 Evidence storage, access and retention
   8.3 Credentials: issue, use, revoke
   8.4 Report delivery and recipients
9. Contacts
   9.1 Technical, backup, escalation (system owner)
   9.2 Lead and backup (testing provider)
   9.3 Security team and monitoring provider
10. Changes to the rules (written change process)
11. Reporting and retest
   11.1 Report format and severity scale
   11.2 Retest terms
12. Signatures
```

## How do the rules relate to the rest of the work?

After you sign, finish the steps in [how to prepare for a penetration test](/guides/how-to-prepare-for-a-penetration-test/). Then the test runs, and the report records what the tester did under these rules. The "safety constraints" section of an Excession Labs report restates the key limits, so you can check that the tester stayed inside them. See [our methodology](/methodology/).

The [free pentest pilot](/free-pentest/) follows the same rule: you give written authorization from the system owner before testing starts.

## Questions

### Are rules of engagement a contract?

They are often part of the contract or attached to it, but a lawyer should decide that for you. Some teams use a separate scope document and an authorization letter. This page is not legal advice.

### Who signs the authorization?

A person who has the authority to permit testing of the systems in scope. That is usually an executive or the system owner. If a third party hosts the system, you may also need their permission.

### Can the rules change during the test?

Yes, with a written change. If the tester finds something that needs a wider scope, they stop and ask. Both sides record the change before the tester acts on it.

### What is the difference between scope and rules of engagement?

Scope says what may be tested. Rules of engagement cover scope plus how, when and under what limits the test runs. Many teams keep scope inside the rules document.

## Sources

- [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment (planning and rules of engagement)](https://csrc.nist.gov/pubs/sp/800/115/final)
- [PTES Pre-engagement (Internet Archive capture, 2025-01-03)](https://web.archive.org/web/20250103002608/http://www.pentest-standard.org/index.php/Pre-engagement)
- [PCI SSC Information Supplement: Penetration Testing Guidance v1.1](https://listings.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf)