Questions to ask before you sign a penetration test SoW

A statement of work is the only part of a penetration test that exists before the test does. Everything that later goes wrong — the asset nobody was allowed to touch, the critical finding sent to the wrong inbox, the retest that turned out to be chargeable — was decided, or left undecided, in that document. None of what follows is adversarial: a good supplier will raise half of it unprompted, because ambiguity costs them time too.

Scope: what is in, what is explicitly out, how change is handled

Scope should read as an inventory, not a description. "The customer portal and supporting APIs" means almost nothing on the first morning: the portal shares a domain with a marketing site, two APIs went unmentioned, the mobile client talks to a third, and the admin interface sits on another hostname. Ask for scope a tester could work from without a phone call — hostnames, IP ranges, applications with their environment, API base paths with a specification attached, mobile package identifiers, cloud account identifiers.

Then ask for the exclusions, with the same precision. The out-of-scope list is the more useful of the two, because it records what a reasonable tester would otherwise treat as fair game: denial-of-service, social engineering unless separately commissioned, physical access, the shared identity provider, the payment processor's infrastructure, destructive action against production data. For each, establish whether it is your choice or a limitation on the provider's side — that distinction matters when someone later reads the report as evidence of coverage.

Finally, how change is handled, because scope always changes. Name who may authorise a change, in what form, and what happens to effort: swapped against something removed, added with a change note, or deferred. Without that clause the predictable outcome is a tester expanding scope out of goodwill and running short on the part you cared about.

• Is scope enumerable rather than descriptive — could a stranger build the target list from it?
• What is excluded, and is each exclusion your decision or a constraint?
• Who approves a change, through what channel, and how is effort adjusted?
• What happens to in-scope assets found during testing that nobody listed?

The testing window, and whether production is in it

Two dates are not a window. A window is a start date, an end date, the permitted hours within each day, and the time zone those hours are in — and it should distinguish active testing from the engagement period that includes reporting and retest. A one-week test delivered as a report in the same week is not a one-week test.

Ask explicitly whether production is included and what that constrains: no destructive payloads, no data modification beyond proving a finding, no mass automated activity against rate-limited endpoints. If the target is staging, ask for the material differences from production to be recorded — authentication provider, infrastructure, feature flags, integrations, data volume — because those differences become the later argument about whether a finding applies. Then settle the logistics that quietly consume days: when credentials arrive and who confirms they work at the stated privilege level before day one; who owns allow-listing for source addresses, WAF, bot protection and geo-blocking; whether a release is scheduled inside the window; and whether anyone has told operations, so the first hour does not end on an incident call.

Rules of engagement and the stop conditions

Rules of engagement turn "test our systems" into permitted behaviour. State which techniques are authorised and which are not. Credential attacks are the usual example: permitted at all, against which interfaces, at what rate, against real accounts or only test accounts? Lockout is a genuine operational risk and the answer should not be improvised at 10am on a Tuesday. Also decide: exploitation or demonstration only; whether privilege escalation and lateral movement are in bounds once a foothold exists; how much real data may be extracted as evidence; and whether activity may produce customer-visible effects such as email, SMS or webhooks.

Then the stop conditions — when testing halts immediately. Cheap to write, invaluable to hold: signs that testing is degrading a service; live customer data in a supposedly test environment; indication of an active compromise; evidence the tester has reached something out of scope; a request to stop from a named contact. Pair each with a notification path and a named recipient. A stop condition without a phone number is a sentence, not a control. Ask too for deconfliction, so your security team can ask "was that you?" and get an answer in minutes: a shared channel, tester source addresses, and a known header on tooling traffic.

Who is authorising this, and do third parties need to agree

Someone must be able to say "yes, test this" on behalf of the organisation that owns the systems — and be right about it. The SoW should name that person and their role, and a careful provider will insist on it rather than accept a signature from whoever raised the purchase order. Where scope includes assets owned by a group company, a joint venture or a client of yours, authorisation has to come from, or be delegated by, the actual owner.

Third-party systems are where this most often breaks. Check that your cloud platform's current testing terms permit the planned activity; most allow customer-initiated testing of your own workloads within limits, but the limits are specific and they change. Managed hosting, in-scope SaaS components, a payment provider, a shared identity service: each may need its own permission, and that paperwork sits with whoever holds the contract — usually you. Record which third parties are involved, who is obtaining permission, and by when. Testing a SaaS platform you merely subscribe to, without its consent, is not a scoping oversight; it is unauthorised access to someone else's system. Multi-tenant hosts, and ranges containing addresses that are not yours, need their own line: removal, confirmation of ownership, or a restriction on technique.

What happens when something serious is found

Two separate questions, and most documents answer neither. The first is critical-finding escalation. If a tester gains administrative control, reaches customer data, or finds an unauthenticated path to something severe, you want to know that day. Agree the threshold in plain terms, the maximum time to notification, the channel, and named recipients with a fallback. Agree what the tester does next: stop and await instruction, move on elsewhere, or continue proving impact. All three are defensible; only one should be a surprise. Agree also that a same-day escalation carries enough written detail for your team to start work before the formal report.

The second is evidence of prior compromise — web shells, unfamiliar scheduled tasks, modified binaries, credentials in use from odd places, log gaps. Different situation, different handling: testing pauses on the affected system, notification goes immediately to a named incident contact, the tester preserves rather than disturbs what they found, and the engagement may be suspended while you invoke incident response. State who may authorise resumption. Penetration testers are not your incident responders, and that handover should be pre-agreed rather than negotiated during a bad afternoon.

Deliverables, and what they contain

"A report" is not a specification. A workable list: a management summary written for a non-technical reader; technical findings giving, for each issue, the affected asset, a severity rating with the scoring method named, the underlying cause, reproduction steps sufficient for your own engineer to reproduce it unaided, evidence, and specific remediation advice; a coverage statement recording anything in scope that was not reached and why; a methodology reference; and a retest section once retesting has happened.

Be explicit about formats. The PDF is the record; machine-readable output is what engineers work from. Ask whether raw evidence — request and response pairs, screenshots, tool output — is supplied or merely referenced, and whether severity is CVSS, an internal rating, or both. Ask for a sample report before signing; it is the most informative thing you can read about a supplier, and worth reading beside their stated methodology to see what that methodology commits to in practice. One further clause saves many arguments: who the report may be shared with. Most buyers eventually hand a report, or a summary, to a customer, an auditor or an insurer — agree that now, along with whether an attestation letter or redacted version exists.

Retest terms and timing

A test that finds problems and never confirms their resolution has done half a job. Pin down: all findings or only those above a severity threshold; one pass or several, since remediation rarely lands first time; the window length, and whether extensions are available and at what cost; whether retest verifies the fix only or also probes for the bypasses and variants a patch often introduces; whether the output is an updated report, a retest letter, or both; and whether the original tester, who already holds the context, performs it.

Retest being excluded or chargeable is not automatically a red flag. If the engagement was objective-driven, or remediation will take a year, a separately scoped revisit can be the honest structure. What matters is that the position appears in the SoW rather than surfacing when you ask for it.

Data handling, retention and confidentiality

During the engagement the provider holds credentials to your systems, data extracted as evidence, architecture detail, perhaps source code — and a document describing exactly how to compromise you. That document is the most dangerous thing anyone writes about your organisation all year.

Ask where engagement data is stored, in which jurisdictions, and whether it is encrypted at rest; who internally can access it and whether access is logged; how the report is delivered, which should mean authenticated download or encrypted mail, never an unprotected attachment to a distribution list; how long data is retained, distinguishing the report from the raw evidence; and what is destroyed, when, with written confirmation. If personal data is in scope, ask for processing terms and sub-processors, and what happens to your data if the provider is acquired or ceases trading. Confidentiality should run both ways: check whether the provider may name you as a client or use anonymised findings in research — both reasonable to request, neither to be assumed. Comparing the SoW against what a provider publishes about its own controls and data handling is a quick sanity check.

Who performs the work, and may it be subcontracted

You are buying people, so the SoW should say which people: the seniority of those assigned, relevant experience for your technology, a commitment that the named or equivalently qualified individuals do the work, and a named lead accountable for quality who attends the readout. Ask whether any part may be subcontracted, which part, and to whom. Subcontracting is not inherently a problem — hardware, embedded systems or an unusual platform are often best handled by a specialist, and a reputable provider will say so plainly. The problem is learning afterwards that your data went somewhere you never vetted. Require prior written consent, flow the confidentiality and data-handling terms down, and keep the prime provider liable for the subcontractor's work.

Insurance and liability, in plain terms

Testing carries a small but real chance of breaking something, and the contract should allocate that risk visibly. In plain language: does the provider carry professional indemnity and public liability cover, at what level, and will they evidence it; is there cyber liability cover, which is a different thing; is the cap a multiple of fees or a fixed sum; and what is excluded? Most agreements exclude consequential loss, lost profit and business interruption. That is normal, but worth knowing, since an outage caused during testing may fall squarely into an excluded category.

The reciprocal clause matters as much. You are granting explicit authorisation to perform the described activity against the described systems, which is what protects the tester from computer-misuse exposure for doing the job you asked for. A provider who does not ask for it is not being accommodating; they are being careless, and carelessness is what you are trying not to buy.

What "done" means

Define completion, or the engagement ends by running out of calendar. "Done" is a short list, all of which must be true: scope tested to the agreed depth or gaps documented with reasons; deliverables received in the specified formats; a readout held with your technical team, so findings are understood rather than merely delivered; questions answered within a stated period; retest performed or formally scheduled; data destruction confirmed in writing.

Add an acceptance mechanism — a fortnight is common — in which you may raise factual corrections or challenge a severity rating, with a committed response time. Challenges happen in good engagements: a severity that looks wrong is usually a context gap, where the tester did not know a compensating control existed or you did not know it was bypassable. Both conversations improve the report. Where a provider publishes a service description, cross-check it against the SoW; a mismatch is worth raising before signature.

The checklist

Copy this into your document review. "Not applicable" is a fine answer; a blank is not.

PENETRATION TEST SoW — PRE-SIGNATURE CHECKLIST

SCOPE
  [ ] Assets enumerated (hosts, ranges, apps + environment,
      API paths, package IDs, cloud account IDs)
  [ ] Out-of-scope list, with reason for each exclusion
  [ ] Change process: approver, channel, effort treatment
  [ ] Treatment of in-scope assets discovered during testing

WINDOW AND ENVIRONMENT
  [ ] Testing dates, permitted hours, time zone
  [ ] Engagement window (reporting + retest) stated separately
  [ ] Production included? limits on destructive activity
  [ ] If staging: differences from production documented
  [ ] Credentials verified working, per role, before day one
  [ ] Allow-listing owner (source IPs, WAF, bot, geo)
  [ ] Releases during window; operations and service desk told

RULES OF ENGAGEMENT
  [ ] Permitted / prohibited techniques
  [ ] Credential attacks: targets, rate, lockout risk
  [ ] Exploitation vs demonstration only
  [ ] Lateral movement and privilege escalation authorised?
  [ ] Evidence-extraction limits on real data
  [ ] Customer-visible side effects (mail, SMS, webhooks)
  [ ] Stop conditions, each with named recipient and channel
  [ ] Deconfliction: channel, source IPs, traffic marker

AUTHORISATION
  [ ] Named authoriser with authority over the assets
  [ ] Signed authorisation scoped to assets and window
  [ ] Cloud / hosting testing terms checked
  [ ] Third-party permissions: owner and deadline assigned
  [ ] Multi-tenant or shared assets resolved

SERIOUS DISCOVERIES
  [ ] Critical threshold, notification time, channel, recipients
  [ ] Tester's next action: stop / move on / prove impact
  [ ] Prior compromise: pause, preserve, notify incident contact
  [ ] Who authorises resumption

DELIVERABLES
  [ ] Itemised list with formats (PDF + machine-readable)
  [ ] Per finding: asset, severity + method, cause,
      reproduction steps, evidence, specific remediation
  [ ] Coverage statement: what was not reached, and why
  [ ] Readout included; sample report seen before signature
  [ ] External sharing rights; attestation / redacted version

RETEST
  [ ] Included or chargeable — stated either way
  [ ] All findings or severity threshold; passes; window; extensions
  [ ] Fix verification only, or bypasses and variants too
  [ ] Output, and whether the original tester performs it

DATA HANDLING
  [ ] Storage location, jurisdiction, encryption at rest
  [ ] Internal access control and logging
  [ ] Secure report delivery method
  [ ] Retention: report vs raw evidence; destruction confirmed
  [ ] Personal-data terms; sub-processors named
  [ ] Client-reference and research-use permissions

PEOPLE AND LIABILITY
  [ ] Seniority and relevant experience of assigned testers
  [ ] Named lead accountable for quality, present at readout
  [ ] Subcontracting: consent required, terms flowed down
  [ ] Professional indemnity, public and cyber liability, evidenced
  [ ] Cap and exclusions understood in plain terms
  [ ] Client authorisation clause present, correctly signed

DEFINITION OF DONE
  [ ] Scope tested to agreed depth, or gaps documented
  [ ] Deliverables received in specified formats
  [ ] Readout held; questions answered within stated period
  [ ] Retest performed or scheduled; data destruction confirmed
  [ ] Acceptance period for corrections and severity challenges

Working through this with a willing supplier takes about an hour, and it is the cheapest hour of the engagement. The clauses that look like bureaucracy — stop conditions, escalation paths, retest windows, a definition of done — are the ones that decide whether you end up with fixed systems or a filed document.