Penetration test scoping template

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

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

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

• 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.

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

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

• 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

• 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.