Penetration Testing Statement of Work: Template and Clauses

A statement of work is where a penetration test stops being a conversation and becomes an agreement. It names what is being tested, for how much, what you deliver, and the terms that apply when something is disputed. Get the scope wording and the assumptions right and most arguments never happen. Get them wrong and you spend the margin on email.

This guide covers the clauses a penetration testing statement of work needs, the wording that keeps scope from being read two ways, and the commercial and legal terms that protect both sides. There is a UK-ready Word template at the end. This is not legal advice, and a firm should have its own terms reviewed by a solicitor.

Statement of work, rules of engagement and authorisation

One engagement is carried by three documents, and keeping them separate keeps each one clean. The statement of work is the commercial and delivery agreement. The rules of engagement govern how the test runs day to day. The authorisation letter is the client’s permission to test. The statement of work references the other two and does not try to do their jobs.

Some firms fold everything into one engagement letter, and that works for small jobs. As soon as the work is large enough to involve a window, a retest and a liability cap, three documents are easier to agree, easier to change, and easier to point a client at when a question comes up.

Sections a penetration testing statement of work needs

A complete statement of work covers, in roughly this order:

• Parties and document control: legal names, company numbers, a version and date, and references to the related rules of engagement and authorisation letter.
• Background and objectives: what the client wants and why, in plain terms.
• Scope of work: the targets, test types and counts, written so they cannot be read two ways.
• Approach and methodology: the standard followed and the severity scale used.
• Assumptions and dependencies: what the engagement relies on, and what pauses the clock.
• Testing window and location: dates, working pattern and rescheduling notice.
• Deliverables: the report, the debrief, any attestation letter, and the delivery date.
• Retests and acceptance: whether a retest is included, and how the report is accepted.
• Charges and payment: the basis, the day rate for change, and payment terms.
• Liability, insurance, data handling and retention: the terms that matter when something goes wrong.
• Change control, term and termination, and governing law.

Scope wording that cannot be read two ways

Scope is the clause that costs real money when it is loose. The fix is precision and restraint.

• Name each target exactly, and give a count where a count exists: this application, these roles, this many external hosts, this API with this many endpoints. A number is a boundary; an adjective is an argument.
• Say what a test type includes and excludes. “Test the API” should become “test the documented REST endpoints listed, authenticated as the two supplied roles”, so the interface in front of it, or an undocumented endpoint, is a change rather than an assumption.
• Avoid words that promise more than any time-boxed test delivers. “Full”, “comprehensive” and “complete” invite a client to expect coverage no fixed-day engagement provides. State what is covered and let the absence of a claim speak for the rest.
• Put the out-of-scope list in writing. Denial of service, physical access, social engineering and remediation are the usual exclusions, and naming them prevents the expectation forming.

Assumptions and what pauses the clock

The most common overrun in this work is access, and it is almost always the client side: accounts promised for Monday that do not work, allowlisting still in a queue, a second factor going to someone on leave. The assumptions section is where a firm protects its timeline against that, by stating what the client must provide and what happens if it is late.

List the dependencies, then say plainly that where one is late or incomplete, the clock pauses, the window may be rescheduled, and resulting standing time is chargeable at the day rate. Typical dependencies:

• Working accounts, one per role and two per role where authorisation is tested, confirmed from outside the client’s network the week before.
• A named technical contact available throughout the window.
• A signed authorisation letter, and any third-party or cloud permissions, held before testing begins.
• Access (allowlisting, a VPN or a supplied device) in place and tested, not merely requested.
• A stable target: a mid-test change that materially alters the work is handled through change control, not absorbed.

Deliverables, retests and acceptance

Say what the client gets, who writes it, and when. A report written by the person who did the test is worth more than one assembled from tool output, and buyers increasingly ask, so if it is true, say so. The usual deliverables are a written report with an executive summary, scope, method, findings with severity and remediation, and a retest record; a debrief to walk the client through it; and, on request once the engagement is delivered, an attestation letter.

Acceptance needs a clock of its own. Give the client a fixed number of working days from delivery to confirm the report meets the statement of work or to raise, in writing, what does not. If nothing is raised in that time, the report is accepted. A dispute about a single finding is handled on its technical merits and does not hold up acceptance of the rest, a point covered in when a client disputes a finding.

Decide the retest terms explicitly: whether one is included, and for how long after delivery it can be used. An open-ended retest promise is a liability a firm carries indefinitely; a fixed window, say 90 days, is fair to both sides. The retest confirms whether each finding has been remediated and updates its status, and work beyond that is a new engagement.

Liability, insurance and data handling

This is the part most worth a solicitor’s eye. The notes below are a neutral starting point, not legal advice.

• Liability. Under the Unfair Contract Terms Act 1977, a term cannot exclude liability for death or personal injury caused by negligence, and can limit other loss only so far as the term is reasonable. So a statement of work keeps liability for death or personal injury and for fraud uncapped, then caps the rest at a figure that reflects the value of the work and the insurance held, usually a multiple of the charges or a stated sum, and excludes indirect and consequential loss.
• Limitation period. The Limitation Act 1980 gives six years for a claim founded on simple contract and six years in tort, running from when the cause of action accrued. A statement of work can acknowledge this rather than leave it unsaid.
• Insurance. Name the cover carried, because clients ask for evidence of it. Professional indemnity is the one buyers check. Employers’ liability of at least five million pounds is a legal requirement for most UK employers with staff, with narrow exemptions, so a firm with employees names it; a sole trader with none may not need it.
• Data handling. Where the firm processes personal data on the client’s behalf, it does so as a processor under UK GDPR. Article 28 requires the contract to commit the firm to acting on documented instructions, keeping the data confidential, securing it, allowing audits, and deleting or returning it at the end of the services.

Retention sits here too. Decide how long findings and evidence are kept, write it down, and make deletion something that happens rather than something that is intended. The trade-offs are in how long a testing firm should keep client findings. Where a retention preference and the contract disagree, the contract wins.

Changes once testing starts

Scope changes mid-engagement more often than anyone plans for. The statement of work needs a change clause that both sides can invoke: a change to scope, targets, window or deliverables is agreed in writing, with its effect on charges and timeline, before work continues under it. A discovery that materially changes the shape of the work, a target far larger than described, for instance, is handled this way rather than quietly absorbed, which protects the firm’s margin and the client’s trust at once.

The template

The Word template below is a full UK statement of work with every section above: parties, scope, assumptions, deliverables, retests and acceptance, charges, liability, insurance, data handling, change control, termination and governing law. Placeholders are in square brackets and the italic guidance notes are there to be deleted. It references the rules of engagement and authorisation letter templates so the three fit together, and you can run the engagement it describes in Pental.

Download the template (Word, 42 KB)

This template is not legal advice. The liability, insurance and data clauses in particular should be reviewed by a solicitor against your firm’s own position before you rely on them.