# Penetration test scoping template

Fill this in before you ask for quotes. Firms price the scope you give them, so a clear scope gets you prices you can compare and a test that covers what matters. Leave out the sections that do not apply.

Online version: https://pentesting.org/toolkit/pentest-scoping-template

## About your organisation

**Organisation name**:

> 

**Main contact** (name, role, email, phone):

> 

**Technical contact during testing** (someone who can answer questions and fix access problems quickly):

> 

**Sector** (helps the firm think about the threats you face):

> 

**Where your systems run** (your own premises, a cloud provider, a hosting company, a software supplier):

> 

## Why you are testing

**Reason for the test** (a customer or contract, PCI DSS, ISO 27001, SOC 2, Cyber Essentials Plus, cyber insurance, a new release, a routine check):

> 

**Who will read the report** (board, auditor, customer, insurer, engineers):

> 

**Date you need the final report by**:

> 

**Previous tests** (when, by whom, and whether the findings were fixed):

> 

## What is in scope

Complete the parts that apply. Give numbers where you can: they drive the number of testing days.

**Web applications** (URLs; what each one does; number of user roles to test; whether you will provide test accounts for each role; production or a test copy):

> 

**APIs** (base URLs; documentation you can share, such as an OpenAPI file or a Postman collection; rough number of endpoints; how clients authenticate):

> 

**External network** (public IP addresses or ranges and domain names; which are hosted by a third party):

> 

**Internal network** (number of sites; rough number of hosts or subnets; whether Active Directory is in scope; how the tester gets access, such as on site, VPN or a device you ship):

> 

**Cloud** (provider or providers; number of accounts, subscriptions or projects; the main services you use; the access you will grant, such as a read-only role):

> 

**Mobile apps** (iOS, Android or both; how you will supply the build; whether the app back end is in scope):

> 

**Staff and phishing** (email phishing, phone pretexting or physical entry; number of staff in scope; who has approved it):

> 

## What is out of scope

- Systems, addresses or functions that must not be touched.
- Services run by third parties that you have no permission to test.
- Types of testing you do not want, such as denial of service or tests that change live data.

## Rules of engagement

**Testing window** (dates, days of the week, hours and time zone):

> 

**Blackout periods** (releases, peak trading, month end):

> 

**Production testing allowed?** (and any limits on it):

> 

**Emergency contact and stop procedure** (who the tester calls if something breaks, and how testing is paused):

> 

**Tester source IP addresses** (ask the firm, so your team can recognise the traffic):

> 

**Who in your organisation will be told** (for example your security operations team or managed service provider):

> 

**Handling of serious findings** (tell us straight away by phone, or keep for the report):

> 

**Data handling** (what the tester may view or copy, and when they must delete it):

> 

## Approach

**Perspective** (an outside attacker with no access, a logged-in user, or both):

> 

**What you will share** (nothing (black box), accounts and documentation (grey box), or source code and architecture (white box)):

> 

**Standards you want followed** (for example the OWASP Web Security Testing Guide or a requirement from your auditor):

> 

**Accreditation required** (CREST, NCSC CHECK, or none):

> 

## What you want delivered

- [ ] A written report with an executive summary and full technical findings
- [ ] A severity rating for each finding, with the rating method stated
- [ ] A debrief call to walk through the findings
- [ ] A retest after you fix the findings, and the window for it
- [ ] A letter of attestation or summary you can share with customers
- [ ] Findings in a format your team can import, such as a spreadsheet

## Permissions

- Written authorisation from the owner of every system in scope.
- Permission from any hosting company or software supplier whose systems are in scope, and a check of your cloud provider’s testing policy.
- A signed contract and, where needed, a non-disclosure agreement before testing starts.