Penetration Testing Rules of Engagement: Template and Guide

Rules of engagement are the operating agreement for a single penetration test: what may be touched, when, how far a tester may go, and who is called when something breaks. They turn a signed-off scope into instructions a tester can act on at four in the afternoon without ringing anyone first.

This guide covers every clause a set of rules of engagement needs, why each one is there, and the handful that save an engagement when something goes wrong. There is a free Word template at the end, built for UK work and ready to adapt.

Rules of engagement, the statement of work and the authorisation letter

Three documents carry one engagement, and they are not interchangeable. The statement of work fixes the commercial terms: what is being tested, for how much, and what you deliver. The authorisation letter is the client’s written permission to test, signed by someone with authority over the systems. The rules of engagement sit between them and govern how the test actually runs, day to day.

Keep all three together and reference each from the others. The rules of engagement do not grant permission to test, so they never replace the authorisation letter, and they do not set the fee, so they never replace the statement of work. They decide behaviour.

Clauses every set of rules of engagement needs

A workable document answers a tester’s questions before they have to ask them. At a minimum it covers:

• Document control: the parties, a version number, the date agreed, and who owns the rules on each side. Version it, because the rules change and a tester must know which version is current.
• Targets in scope: every host, address, application or range, named precisely, with its environment and its owner.
• Out of scope: what must not be touched, including the obvious exclusions, so an accident is harder.
• Approach and intrusiveness: black box, grey box or white box, authenticated or not, production or a staging copy, and whether the tester works through a web application firewall or is allowlisted around it.
• Constraints and safeguards: the limits that keep a live system standing.
• Credentials and data: how accounts are supplied, held and revoked, and how evidence containing real data is handled.
• Third-party and cloud permissions: confirmation that the client can authorise what is in scope.
• Contacts and escalation: two names and two routes on each side.
• Stop conditions and out-of-band notification: when to pause, and what gets a phone call before the report.
• Change control: how the rules change once testing has started.

Testing windows and production safeguards

The window is more than a start and end date. It names the time zone, the permitted hours, and any blackout periods: the payroll run, a release freeze, the Saturday afternoon a retailer does not want touched. Testing a live system at the wrong hour is a business decision rather than a technical one, and it belongs to the client.

The safeguards are the clauses that keep a production system from becoming the incident you were hired to prevent. In practice they come down to a short list, and the detail is in the piece on testing in production without breaking it:

• No denial of service, and no technique that risks taking a service offline, including high-volume automated activity against endpoints that create records.
• No destructive proof. Where access could delete or alter data, the tester demonstrates it against a record they created themselves and describes the destructive step rather than performing it.
• Credential testing against live accounts is rate-limited so real users are not locked out.
• Any automated tool capable of generating load has that behaviour switched off before it is pointed at a client asset.
• Changes made to a live system are recorded as they happen and reversed before the engagement closes.

Contacts, escalation and the stop condition

Ask for two names and two routes on each side, with phone numbers. The single named contact will be on a plane on the day it matters, and an escalation that stalls because one person did not pick up is an escalation that failed.

The stop condition is a sentence most documents leave out and every difficult engagement needs: either side may call a stop, on the numbers given, with no argument about whether the tester was in the right. On a stop, the default is to pause, confirm, and agree in writing before resuming.

Separate from the stop condition is the out-of-band notification threshold: the findings serious enough to warrant a phone call before the report is written. Writing that threshold well is harder than it looks, and it is covered in depth in finding something critical mid-engagement. A threshold described as “critical findings will be reported immediately” is not a threshold at all, because critical is a label applied after a judgement. Describe situations instead:

The following are reported out of band, by phone first and a short written note immediately after:

  - unauthenticated access to data belonging to more than one customer;
  - any access that lets code run on a system holding production data;
  - credentials for a production system found where they should not be;
  - evidence that a weakness is already being exploited by someone who is not the tester;
  - anything on a life-safety or payment path.

The client may add to this list.

What a client adds is often revealing. An organisation that writes in “any finding affecting the pension calculation” is telling you something about its risk that no severity model would have produced.

Credentials and data during testing

Access granted for a test should stop working when the test stops. In practice it outlives the engagement by months, because revoking it is nobody’s task. The rules of engagement should list the accounts supplied, say how they were transferred, and commit the client to revoking every one when testing ends, with the testing firm confirming in writing that it no longer holds them.

Where testing touches real personal data, the document commits the tester to capturing the minimum evidence needed, redacting at the point of capture rather than at the point of writing, and recording what is held so the client can account for it in its own retention answer. A redacted screenshot in the report does not help if the unredacted original sits in a working folder for four years. Where that evidence is stored, and who can reach it, is the kind of assurance the security page sets out.

Third-party hosting and cloud permissions

A client can only authorise testing of what it owns or controls. For anything hosted by a third party, including cloud providers and software-as-a-service vendors, the client must hold the authority or the host’s permission, and the rules of engagement should record which assets those are and what permission is relied on.

Cloud assets are their own case. Each major provider publishes its own current testing policy, and they differ on whether prior approval or notification is required, which services are covered, and what is prohibited. Check the live policy for every provider in scope, carry its prohibitions into your out-of-scope and safeguards clauses, and keep a dated copy. The side-by-side detail is in the guide to cloud penetration testing rules.

Changing the rules once testing has started

Scope changes mid-engagement more often than anyone plans for: a target turns out to be larger than described, a new system appears, the client wants a window moved. Any change to scope, targets, window or constraints is agreed in writing by both rules owners, the version is raised, and the change is logged before testing continues under the new terms. A change that materially alters the size of the work is handled through the statement of work’s change process, not absorbed quietly.

The template

The Word template below is a complete set of rules of engagement with every clause above, placeholders in square brackets, and italic guidance notes you delete as you fill it in. It is written for UK commercial work and pairs with the authorisation letter and statement of work templates.

Download the template (Word, 43 KB)

This template is a starting point, not legal advice. Have your firm’s own terms reviewed by a solicitor before you rely on them.