The Paperwork a Pentester Needs Before the First Packet Is Sent

Most pentest disasters are not technical. They happen because the person who said "yes, go ahead" could not actually say yes for the system you hit. A verbal go-ahead from a friendly IT manager is not a defence, and it is certainly not a scope.

This is the checklist I would want signed, in writing, before any scan, login attempt or phishing email leaves my machine. It is general information from a UK perspective, not legal advice, and the details depend on your contract and circumstances.

Why "in writing" matters in the UK

The Computer Misuse Act 1990 makes unauthorised access to a computer an offence (section 1), and also covers unauthorised acts that impair a system (section 3). The Act does not contain a pentester exemption. What separates your work from an offence is that the access is authorised, and that is something you will want to be able to prove.

The question of who can give that authorisation is covered separately in What 'Authorisation' Actually Means Under the Computer Misuse Act. Here the point is practical: the document is your evidence, so make it specific enough that a stranger could read it a year later and see exactly what you were allowed to do.

The things to get signed

A named signatory who has the authority to approve testing of these assets.
An exact scope: hostnames, IP ranges, applications, environments.
An explicit out-of-scope list.
Permitted techniques, and forbidden ones.
Test dates and hours, including time zone.
Source IPs you will test from.
Emergency contacts on both sides, reachable out of hours.
How data you encounter will be handled, stored and destroyed.
Reporting format, and who may see the report.

That is a long list, but each item exists because someone, somewhere, got burnt without it.

Scope: addresses, not adjectives

"The corporate network" is not a scope. "10.20.0.0/16 and the hostnames in appendix A" is. Vague scope invites the classic mistake: you find a forgotten box on a neighbouring subnet, it looks like theirs, and you go for it.

Write the rule for discovered assets into the document too. A sensible default is "stop, report, and wait for written confirmation before touching anything not listed". That one line saves a lot of awkward phone calls.

Does the client actually own the thing?

Quick detour, because this is where scopes quietly fall apart. Clients routinely list assets they do not control. A few common examples:

A SaaS product, where the vendor owns the infrastructure.
A managed service provider running the firewalls or hosting.
Cloud-hosted workloads, where the provider has its own testing policy.
A shared hosting platform with other tenants on the same machine.
Offices in a building where the landlord runs the network or doors.

The client can authorise testing of what they own. They cannot authorise you to hit their provider's shared platform. Get the third party's written permission, or have the scope carve those parts out. Check the provider's current testing policy rather than trusting memory; they change, and some require notification for certain activities.

Techniques: say what is off the table

Agree the risky stuff explicitly rather than assuming. The usual items worth naming:

Denial of service or load testing (most engagements exclude it; some need it).
Password guessing against live accounts, given lockout policies.
Social engineering, phishing, phone pretexts and which staff may be targeted.
Physical access and tailgating.
Exploits that can crash a production service.
Pivoting from a compromised host into other networks.
Writing to production data, versus read-only proof.

Social engineering and physical testing deserve special care. Staff are not the signatory, so make sure the client has thought about how they will be treated, and who stops the exercise if someone calls the police. For physical work, carry a signed authorisation letter with a contact number that is answered, and check that number works before you go.

Dates, hours and the 3am problem

State when you will test, and from where. If your source IPs are listed, the client's SOC can tell your traffic from a real attacker, or decide to deliberately not tell them, which is also a legitimate choice if agreed up front.

Agree a stop condition as well. If you cause an outage, or find evidence of an actual intruder already inside, what happens? A real compromise in progress changes the engagement from a test to an incident, and both sides should know that before it occurs.

Data you will see and what happens to it

You will probably see personal data, whether you meant to or not. Under UK GDPR, the client is typically the controller and you are likely a processor, which means a written contract with the required terms (Article 28) is normally needed. Whether that is the right characterisation for your engagement depends on the facts, so have it checked.

The practical rules are simple:

Take the minimum needed to prove a finding. A screenshot with values masked beats a database dump.
Store evidence encrypted, on a device you control, for a stated period.
Agree how and when it is deleted, and confirm that in writing.
Do not browse records out of curiosity. Misusing personal data you can reach is a separate problem from whether your access was authorised.

Also agree what happens if you find something awful, such as illegal material. Know in advance who you tell and what you do, because you will not want to work it out on the day.

Insurance and liability

Check that the contract sets out liability for accidental damage, and that you have professional indemnity cover that actually covers testing work. Clients sometimes want unlimited liability clauses; whether you accept that is a business decision, but make it a conscious one.

How to check you have enough

A quick test: hand the signed paperwork to someone who was not in any of the meetings. Can they tell which IP ranges you were allowed to touch, between which hours, using which techniques, with whose approval? If any of those needs a conversation to answer, the document is not finished.

The boring paperwork is the one part of the job that protects you after everything technical has gone fine. It is also the part nobody writes blog posts about, which is probably why so many people skip it.