# Pentest scope template: what to agree before you test

Published: 2026-11-12 · By HackerGPT Team
Canonical: https://hackergpt.org/blog/pentest-scope-template/

> A fill-in pentest scope and rules of engagement template, built on NIST SP 800-115, with two filled-in examples: your own site, and a site you test with written permission. Plus five passive checks that show what a one-line scope leaves out.

**TL;DR:** A pentest scope is a written agreement, signed by someone entitled to give permission, that lists exactly what you may test, what you may not, how, when, who to call when something breaks, and what happens to the data and the findings. Anything it does not list is out of scope. Below is a fill-in template built on the rules of engagement outline in NIST SP 800-115, with one filled in for your own site and one for a site you test with written permission.

This is for learners moving from practice targets to a real site: your own app, a friend's shop, a first small client. You will get a template you can copy, two filled-in examples, and five passive checks that show how much a one-line scope leaves unsaid. The rule underneath all of it: **test only what you own or have written permission to test.** This article is general information, not legal advice; the law itself is on the [rules of legal hacking](https://hackergpt.org/legal-hacking/) page.

## What is a pentest scope, and how is it different from rules of engagement?

The scope says **what** you may test; the rules of engagement say **how**. In practice both go in one document, signed before the first request is sent. NIST defines the rules of engagement as "detailed guidelines and constraints regarding the execution of information security testing", established before the test starts, which give the test team "authority to conduct defined activities without the need for additional permissions" ([NIST SP 800-115, 2008, glossary](https://csrc.nist.gov/pubs/sp/800/115/final)).

That second half is the point. A signed scope is what lets you work without asking at every step, and it is also the line you must not cross. A finding outside it is not a bonus; it is a problem you have to report and stop at.

Three words get mixed up, so here is how this article uses them:

| Term | Answers | Example |
| --- | --- | --- |
| Authorisation | Who says you may test at all | "Jane Doe, director of Example Ltd, authorises Sam to test…" |
| Scope | Which targets | `shop.client.example`, staging only, not the payment page |
| Rules of engagement | How, when and what if | no load testing, weekdays 09:00–17:00 UTC, call this number if the site goes down |

## What should a pentest scope template include?

It should include the eleven parts below. They follow the structure of the rules of engagement template in [NIST SP 800-115, Appendix B](https://csrc.nist.gov/pubs/sp/800/115/final) (purpose and scope, personnel, schedule, communication and incident handling, the target list with an "exclude list", allowed and disallowed activities, data handling, reporting and a signature page), rearranged and cut down for a web app tested by one or two people. NIST itself says its structure is illustrative and organisations should adapt it.

1. **Parties and authority**: who owns the target, who grants permission and why they are entitled to, who tests.
2. **In scope**: exact hosts, URLs, IP addresses and environments, plus the test accounts you are given.
3. **Out of scope**: written out, not implied. NIST calls it the exclude list.
4. **Techniques**: what is allowed, what is not, whether scanners and agents may run, and at what request rate.
5. **Time window**: start and end with a time zone, and times to avoid.
6. **How your traffic can be recognised**: source IPs, a header or User-Agent, so the owner can tell your test from an attack.
7. **Data**: what you may look at, what you must not keep, and what to do when you reach personal data or a secret.
8. **Contacts and stop conditions**: who to call, and the conditions under which you stop.
9. **Rules on top**: the hosting provider's testing policy, and any vendor's.
10. **Reporting**: format, secure delivery, deadline, retest, and who may share the findings.
11. **Changes and sign-off**: every change in writing, signed by both sides.

Copy it from here, or [download the template as a Markdown file](https://hackergpt.org/blog/pentest-scope-template/pentest-scope-template.md):

```markdown
# Pentest scope and rules of engagement
Anything not listed under "In scope" is out of scope.

## 1. Parties and authority
- Owner of the target:
- Person granting permission (name, role):
- Why they can grant it:
- Tester(s):

## 2. In scope
| Target (exact host, URL, IP or app) | Environment | Notes |
|---|---|---|
- Test accounts provided (username, role):

## 3. Out of scope
- Third-party services the site loads or links to:
- Other hosts, subdomains and environments:

## 4. Techniques
- Allowed:
- Not allowed: denial of service and load testing; social engineering;
  changing other users' data; emailing real users.
- Scanners and agents allowed? Maximum request rate:
- Stop at proof: show a finding exists, do not use it to go further.

## 5. Time window
- Start / end (date, time, time zone):
- Times to avoid:

## 6. How the testing traffic can be recognised
- Source IP addresses:
- User-Agent or header added to requests:

## 7. Data
- May view: / Must not copy or keep:
- If personal data or a secret is reached: stop, record, report, delete.

## 8. Contacts and stop conditions
- Technical contact (name, phone, hours):
- Stop and call when: the site degrades; real users' data is reached;
  something outside scope is reached.

## 9. Rules on top
- Hosting provider and its testing policy:

## 10. Reporting
- Format and delivery: / Deadline: / Retest:
- Who may publish or share findings, and when:

## 11. Changes and sign-off
- Permission granted by (name, role, signature, date):
- Tester (name, signature, date):
```

## How do I check that a scope covers what the site really touches?

Write the one-line scope you would naturally write, then run passive checks against it and see what falls outside. We did this on 12 November 2026 against [CyberGym](https://cybergym.hackergpt.app), HackerGPT's deliberately vulnerable practice target, which is published to be tested. The one-line scope: "cybergym.hackergpt.app". Every check below only reads public records or fetches public pages; none of them tests anything.

**1\. What does the name resolve to, and who runs that address?**

```bash
dig +short cybergym.hackergpt.app
curl -s https://rdap.arin.net/registry/ip/34.231.169.117 | jq -r '.name, .entities[0].vcardArray[1][1][3]'
```

```text
34.231.169.117
AT-88-Z
Amazon Technologies Inc.
```

One address, in an Amazon range according to its RDAP record. So the host's own policy applies on top of any permission the site owner gives. [AWS lets customers test their own resources on a list of services without prior approval](https://aws.amazon.com/security/penetration-testing/), and prohibits, among other things, denial of service, simulated DoS, and request flooding, including login and API request flooding. That goes in part 9 of the template, and it is why part 4 needs a request rate.

**2\. Does the certificate cover other names?**

```bash
echo | openssl s_client -connect cybergym.hackergpt.app:443 -servername cybergym.hackergpt.app 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName
```

```text
X509v3 Subject Alternative Name:
    DNS:cybergym.hackergpt.app
```

Only this one name. A certificate listing several names, or a wildcard, is a prompt to ask which of those hosts are meant, not a permission to test them all. Other `*.hackergpt.app` names exist and are public; they are not in this scope because they are not on the line.

**3\. What does the page load from somewhere else?**

```bash
curl -s https://cybergym.hackergpt.app/ | grep -oE '(src|href)="//[^/"]+' | sort -u
curl -s https://cybergym.hackergpt.app/main.js | grep -oE 'https://[a-z0-9.-]+' | sort -u
```

The HTML loads jQuery and a cookie-consent script from `cdnjs.cloudflare.com`. The application bundle names sixteen more `https` origins, among them `accounts.google.com` and `www.googleapis.com` (the "Log in with Google" flow) and links to `twitter.com`, `github.com`, `etherscan.io` and `opensea.io`. None of these belong to CyberGym. You may test how CyberGym handles the Google login it receives; you may not test Google. A link on an in-scope page is not a permission to test where it points.

**4\. What do `robots.txt` and `security.txt` say?**

```bash
curl -s https://cybergym.hackergpt.app/robots.txt
curl -s https://cybergym.hackergpt.app/.well-known/security.txt | grep -E '^(Contact|Expires)'
```

```text
User-agent: *
Disallow: /ftp
Contact: https://github.com/hacker-gpt/cybergym/security
Expires: Fri, 12 Nov 2027 19:26:37 GMT
```

`robots.txt` is a request to crawlers, not a scope document: `/ftp` is in scope on CyberGym (it is part of a challenge), and on someone else's site a disallowed path is not out of bounds either, unless the scope says so. `security.txt`, defined in [RFC 9116 (2022)](https://www.rfc-editor.org/rfc/rfc9116), gives you a contact for reporting; it is a good default for part 8 when the owner has not named one. It does not grant permission to test.

**5\. What names does the app itself mention?**

CyberGym's public configuration endpoint, `/rest/admin/application-configuration`, gives `http://localhost:3000` as its base URL and `juice-sh.op` as its domain. Names you discover while testing go in the "ask first" pile: they are not in scope because the target mentions them.

![Scope diagram: one in-scope CyberGym host, third-party and linked hosts out, discovered names ask-first, AWS rules on top](https://hackergpt.org/blog/pentest-scope-template/scope-boundary.webp)

*What five passive checks turned up around a one-line scope for CyberGym, sorted into in scope, out, ask first, and rules on top.*

Run the same five checks on your own target before you sign. They take a few minutes, and every name they print is a question for part 2 or part 3. On a larger app, a crawl that lists every page and API endpoint, such as [AppMap](https://hackergpt.org/features/appmap/), shows what sits behind the host once the scope is agreed; mapping is itself testing, so it comes after the signature. How to read that map is in [how to map a web app's attack surface](https://hackergpt.org/blog/map-web-app-attack-surface/).

## Example 1: what does a scope look like for testing my own site?

It looks shorter, but you still write it, because "my site" is rarely only yours. Your hosting, login provider, payment provider and email service are someone else's, and their terms apply. Say you run a small SaaS at `app.your-app.example`:

```markdown
## 1. Parties and authority
- Owner: Your App Ltd. Permission: you, as its director. Tester: you.

## 2. In scope
| Target                               | Environment | Notes                   |
|--------------------------------------|-------------|-------------------------|
| https://staging.your-app.example     | staging     | copy of prod, fake data |
| https://api.staging.your-app.example | staging     | /v1/* only              |
- Test accounts: test-user@your-app.example (user), test-admin@your-app.example (admin)

## 3. Out of scope
- Production (app.your-app.example) until staging is done
- The payment provider's hosted checkout; the login provider's pages
- Marketing site and blog (separate host, separate vendor)

## 4. Techniques
- Allowed: manual testing, an AI agent run at no more than 5 requests/second
- Not allowed: load testing, emails to real users, password spraying on prod

## 8. Contacts and stop conditions
- Stop if staging slows down for everyone, or real customer data shows up in staging

## 9. Rules on top
- Hosting provider's testing policy: linked here, read on the day you sign
```

The rate of 5 requests per second is an example, not a recommendation: pick what your staging server is sized for. The two decisions that matter are testing staging before production, and leaving the payment and login pages to their vendors. Testing your own site is legal; testing your vendor's is not covered by owning the site that uses it. The rest of the run, from recon to findings, is in [how to pentest your own website](https://hackergpt.org/blog/how-to-pentest-your-own-website/).

## Example 2: what goes in the scope when I test someone else's site with permission?

Everything in Example 1, plus proof of who gave you permission and why they could. The person who says yes must be entitled to: the business owner or a director, not the developer who built the site, and not an employee who "is fine with it". Say a friend runs `shop.client.example` and asks you to look at it:

```markdown
## 1. Parties and authority
- Owner: Client Shop Ltd. Permission: Jane Doe, director (owns the business and the domain)
- Tester: Sam Smith, sam@tester.example

## 2. In scope
| Target                          | Environment | Notes                         |
|---------------------------------|-------------|-------------------------------|
| https://shop.client.example     | production  | storefront and customer area  |
- Test accounts: two customer accounts created by Jane for the test

## 3. Out of scope
- Admin panel; checkout and payment pages; the shop platform's own servers
- Any other domain or subdomain, including ones found during the test

## 5. Time window
- 18-20 November 2026, 20:00-23:00 UTC (low traffic)

## 6. How the testing traffic can be recognised
- From 203.0.113.10; header X-Pentest: sam-smith-2026-11

## 7. Data
- Real customers' data must not be opened, copied or kept. If reached: stop, note the URL, call Jane

## 10. Reporting
- PDF report by 27 November, sent as an encrypted file; Jane decides who else sees it

## 11. Sign-off
- Jane Doe, director, signed 15 November 2026 / Sam Smith, signed 15 November 2026
```

`203.0.113.10` is from a range reserved for documentation; use your real source address. Three choices there are deliberate. Production is in scope because there is no staging, so the window is at night and nothing writes to other customers. The admin panel is out until a second agreement, since a mistake there hurts more. And if the shop runs on a hosted platform, the platform's own terms decide what testing is allowed on its servers; check them, and if they do not allow it, narrow the scope rather than assume. What goes in the report you deliver is in [this pentest report example](https://hackergpt.org/blog/pentest-report-example/).

## What happens if I find something outside the scope?

You stop, write down what you saw, and tell your contact; you do not explore it. That holds for a subdomain that looks related, a third-party service with an obvious bug, and personal data you were not supposed to reach. If the owner wants it tested, they extend the scope in writing and you test it afterwards. NIST's template asks for exactly this: criteria for halting the test and a process for resuming it are part of the rules of engagement ([NIST SP 800-115, Appendix B, 3.2](https://csrc.nist.gov/pubs/sp/800/115/final)). Cloud providers say the same for their platforms: [Microsoft's rules of engagement](https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement) limit testing to "your own tenant or assets for which you have explicit authorization".

## Key takeaways

- Get permission in writing from someone entitled to give it, and write the exact hosts on the page: anything not listed is out of scope.
- Write an exclude list, and put every third-party service the site loads (payments, login, CDN, analytics) on it.
- Run DNS, RDAP, certificate, page-source and `security.txt` checks before signing, and turn every unexpected name into a question for the owner.
- Add the hosting provider's testing policy and a request rate; most of them forbid denial of service and flooding whatever the site owner says.
- When you reach anything outside the scope, stop and report it; test it only after a written change.

## FAQ

### Is a verbal OK enough to start a pentest?

It is far weaker than a written one. A verbal yes rarely says which hosts are covered, cannot be shown to anyone later, and is easy to remember differently. Get the scope in writing and signed by someone entitled to authorise the test before you send the first request. This is general information, not legal advice.

### Do I need a scope to test my own website?

Yes, a short one. Your site depends on services you do not own, such as hosting, a login provider and a payment provider, and their terms apply even when the site is yours. Writing down which hosts you will test, and which vendor pages you will leave alone, keeps your test on your own systems.

### Do I need to tell AWS, Google Cloud or Azure before testing my site?

Not usually for your own resources, but their rules still apply. AWS lets customers test a list of services without prior approval and prohibits denial of service and request flooding. Google Cloud says customers are not required to contact it but must follow its Acceptable Use Policy and Terms of Service. Microsoft limits testing to your own tenant or assets you are authorised for and prohibits denial-of-service testing.

### Is a bug bounty programme's scope the same as a pentest scope?

It does the same job, but the programme writes it and you accept it as published. Each programme lists its targets, its exclusions and its rules, and safe-harbour terms typically cover only testing that stays inside them. Read the policy before every session, because programmes change their scope.

### Can I practise writing a scope without a client?

Yes. Write one for CyberGym at cybergym.hackergpt.app, which is published as a legal practice target, then run the five passive checks from this article against it and see what your one-line scope missed. Then write one for your own site before you test it.

## Sources

- [NIST SP 800-115, Technical Guide to Information Security Testing and Assessment (September 2008)](https://csrc.nist.gov/pubs/sp/800/115/final): Appendix B, Rules of Engagement Template; glossary definition of rules of engagement
- [AWS: Penetration Testing](https://aws.amazon.com/security/penetration-testing/): permitted services and prohibited activities
- [Google Cloud security FAQ](https://support.google.com/cloud/answer/6262505): penetration testing of your own projects
- [Microsoft Security Testing Rules of Engagement](https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement)
- [RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (April 2022)](https://www.rfc-editor.org/rfc/rfc9116)
- [ARIN RDAP](https://rdap.arin.net/registry/ip/34.231.169.117): registration record for CyberGym's address, read 12 November 2026

Practise on [CyberGym](https://cybergym.hackergpt.app) first, or run HackerGPT on your own site at [hackergpt.app](https://hackergpt.app) once your scope is signed.