Penetration testing contract: scope, rules of engagement, and acceptance

A penetration testing contract should answer a practical question before anyone sends the first packet: who may do exactly what, to which version of which asset, during which window, and what evidence will count as completed work? A master services agreement alone rarely answers that question. A useful procurement package combines legal terms with a statement of work (SOW), signed authorization, and operational rules of engagement (ROE).

This guide is a buyer-side operating checklist, not a jurisdiction-specific legal form. Counsel should settle enforceability, liability, confidentiality, intellectual property, privacy, employment, sector rules, and local authorization requirements. The security and product owners should make the technical boundaries executable. Both jobs matter, but they are different jobs.

Sign a document stack, not one vague order form

The commercial agreement usually carries the durable legal terms: parties, fees, payment, warranties, liability allocation, confidentiality, governing law, subcontracting, and termination. The SOW turns the purchase into a defined project: objectives, named services, schedule, dependencies, deliverables, acceptance process, retest entitlement, and change-control mechanism. A data-processing addendum or equivalent may be needed when evidence can contain personal data. The ROE is the live operating envelope used by testers and incident responders.

The ROE should be signed or expressly incorporated into the contract before testing starts. It identifies the authorizing organization, the testing team, accountable contacts, in-scope and excluded systems, source infrastructure, dates and hours, allowed and forbidden actions, production safeguards, stop and restart rules, evidence handling, and reporting. NIST SP 800-115 (2008), Appendix B, provides an ROE checklist. Adapt it to current platform rules and the project; it is not a complete modern testing catalogue.

Do not hide operational authority inside a general phrase such as “test the application.” A tester may need a copy of the authorization and contact details during the engagement. Conversely, an ROE should not be used to improvise waivers of liability or rights to customer data. Keep each decision in the document where its owner can review it.

Make scope executable: asset, environment, version, identity

A hostname by itself is not a complete target. For every asset, record its owner, environment, stable identifier, network boundary, application or API version, relevant build or commit identifier, tenant or cloud account/project, region where relevant, and authentication roles supplied for testing. Add source IP addresses or other markers that let defenders distinguish authorized traffic. Record dependencies that may receive traffic even if they are not direct targets.

The scope should say whether testing is black-, gray-, or white-box; whether source or architecture material is provided; which user roles and tenants exist; and whether social engineering, password attacks, persistence, file upload, data modification, lateral movement, or destructive techniques are permitted. An explicit exclude list is as important as the include list. “All company infrastructure” is unsafe when the company uses third-party SaaS, shared hosting, managed services, partner APIs, or acquired subsidiaries.

Freeze a test baseline at kickoff. If production deploys continuously, the SOW can define a release cutoff or a named build and require the buyer to disclose deployments during the window. A change is not automatically absorbed because it looks small. The agreed change process should state who may request and approve it, what impact analysis is required, whether the ROE and authorization must be reissued, and how schedule and fee changes are recorded. New domains, tenants, APIs, source locations, test techniques, or material versions should trigger that process.

The Pentest.red scope planner can help turn an initial inventory into a discussion document. It still needs named owners and approval. If the buyer is also choosing among providers, use a separate evidence-led vendor comparison rather than trying to encode supplier selection criteria inside the ROE.

Check cloud and third-party permission separately

The customer cannot grant more permission than it possesses. Ownership of an application does not automatically authorize testing the cloud provider’s control plane, a payment processor, a CDN tenant belonging to another party, an upstream identity service, or another customer’s data. Make a permission matrix with one row per owner or provider, the controlling policy, the approved resources and techniques, any notice or approval evidence, and the date on which the policy was checked.

Current primary provider rules illustrate why a generic “cloud testing permitted” clause is inadequate. Under its standard penetration-testing policy, AWS allows assessments without prior approval only for listed customer services, bars testing AWS infrastructure or AWS services themselves, requires prior approval for Command and Control testing, and prohibits DoS techniques; simulations are governed by separate provider rules. Microsoft says Azure customer resources can be tested without pre-approval, while third-party testers need explicit written authorization from the resource owner and all testing remains subject to Microsoft’s ROE; testing must stop when it crosses into Microsoft service vulnerabilities or unauthorized data. Google Cloud says no notice is required for testing a customer’s own project, but the test must obey its Acceptable Use Policy and Terms and affect only that customer’s projects, not other customers’ applications.

Those distinctions can change. The SOW should require a dated preflight check immediately before execution, not permanently paste today’s service list into a multi-year contract. Where the target involves SaaS, a managed service, a reseller, a partner integration, or infrastructure owned by another group company, obtain the relevant owner’s permission or remove the target. Record who is responsible for provider notifications and who holds the response.

Run production testing with a real stop and resume path

“Stop if there is an incident” is not a procedure. Define observable halt triggers: elevated error rate or latency, unexpected data access, unstable service, alarm from the buyer’s incident commander, suspected activity outside scope, evidence of an unrelated attacker, or contact from a provider. Name the people who may order an immediate stop, the always-available channels, acknowledgement expectations, and what the tester must do after stopping. A technical lead should be able to halt first and document later when continued activity may cause harm.

Resume should require an affirmative decision by a named buyer role. The decision records the incident or symptom, affected assets, last test action, evidence preserved, mitigation applied, revised method or window, and the person authorizing restart. Silence, an expired pause, or a new shift must not count as permission. If the test changes from staging to production, from manual validation to high-volume automation, or from proof to lateral movement, use change approval as well as resume approval.

1. SignExecute the agreement, SOW, owner authorization and ROE; confirm third-party and provider constraints.
2. Freeze scopeRecord assets, versions, identities, exclusions, source systems, methods, window and named contacts.
3. OperateMonitor production, preserve a rapid stop path, and approve changes or resumption explicitly.
4. AcceptReview coverage, evidence, limitations and deliverable quality; log corrections without counting vulnerabilities.
5. RetestValidate agreed findings against a named fixed build and issue a condition-bound result.

The buyer’s security operations team should know the source addresses and window unless detection is itself an agreed objective. The ROE must say whether testers will be allowlisted and how authorized activity will be distinguished from a real intrusion. These are operating controls, not decorative contract language.

Control evidence from capture through deletion

Pentest evidence can contain credentials, personal data, session tokens, configuration, source fragments, customer records, and a map of exploitable weaknesses. The ROE and data terms should define what may be captured, minimization and redaction rules, approved storage and transfer channels, encryption expectations, access roles, locations, retention periods, legal-hold exceptions, backup treatment, and the deletion or return event. “Securely delete later” leaves too much unresolved.

Require an evidence manifest or equivalent record that links each finding to the affected asset and test condition without reproducing unnecessary sensitive content. Decide whether raw tool output, screenshots, proof-of-concept code, request/response pairs, logs, and test accounts are deliverables or retained work papers. If the provider uses subcontractors or hosted collaboration systems, name those paths in the legal and data documents. At closure, revoke credentials, remove test accounts and files, clean customer-side artifacts, and obtain the agreed destruction confirmation.

Delivery should use a controlled channel rather than ordinary email attachments. The buyer should designate report recipients and an owner for the canonical copy. For a concrete preview of useful report structure, inspect a sample penetration test report and the guide to what a useful pentest report contains before finalizing the SOW.

Accept the work by quality and coverage, not by vulnerability count

The number of findings is not a safe acceptance criterion. A capable test can legitimately produce few findings; a weak test can inflate counts with duplicates and informational noise. Never make payment depend on a minimum vulnerability quota, a promised critical issue, or a “clean” result. Acceptance should assess whether the provider performed the agreed work and delivered usable, traceable evidence. A report with no findings can satisfy those criteria without proving the system is free of vulnerabilities.

Define a review period and one consolidated comment cycle. Acceptance can require: the correct assets and frozen versions; a coverage record showing tested, not applicable, blocked, and untested areas; dates and tester identities; methods and material limitations; an executive explanation; deduplicated findings with affected asset, prerequisites, evidence, impact reasoning, severity rationale, reproduction and remediation guidance; urgent notification records; and an evidence/artifact disposition statement. OWASP reporting guidance supports this division between executive summary, test parameters, limitations, findings, and remediation details.

Acceptance does not mean the buyer agrees with every risk score or promises to fix every issue. Accepting the report, verifying remediation, and accepting residual business risk are separate decisions. The contract can separate documentary defects, which the provider must correct, from good-faith technical disagreements, which should be logged with both rationales. If the parties negotiate deemed acceptance, its clock should start only after the buyer has received all required files through an accessible channel.

Define the retest as a conditional verification

A retest is not an unlimited second engagement. The SOW should say whether one or more rounds are included, the booking notice, the window after final report delivery, eligible findings, maximum effort if applicable, required evidence that fixes are deployed, and what happens when the buyer misses the window. It should also state whether related variants are tested and how new weaknesses discovered during validation are handled.

Freeze the retest baseline: finding identifier, fixed build or commit, environment, configuration, account role, and date. Results should be condition-bound, such as “remediated under tested conditions,” “not remediated,” “partially remediated,” “cannot verify because prerequisites were unavailable,” or “not tested.” Avoid an unqualified “fixed.” A changed architecture, newly added endpoint, migration to another cloud, or expansion to sibling systems is usually a change request, not free retest scope. The practical guide to remediation validation explains how to preserve that evidence chain.

Worked example: Northstar Tickets procurement

The following scenario is fictional and illustrative. Northstar Tickets is procuring a test before a release. Its buyer package includes an existing master agreement and data terms, a project SOW, an authorization signed by the owner of the named resources, and an attached ROE. Scope is the production portal.example.invalid release 2026.10-rc3, the production api.example.invalid API schema 3.14.2, and an Android candidate in staging identified by its package name and build hash. The register also names two test tenants, buyer-supplied customer and support roles, the provider’s source addresses, and the specific AWS accounts containing the application resources. The corporate website, payment processor, customer support SaaS, AWS service infrastructure, employee phishing, DoS, and every other tenant are excluded.

Manual web and API testing, limited automated discovery at agreed rates, role-bound authorization testing, file upload validation, a non-destructive proof of impact, and manual testing of the named Android build’s local storage, deep links, and interaction with the in-scope API are permitted. Persistence, extraction of real customer records, password spraying, changes to real customer production data, lateral movement outside the named application accounts, and service disruption are prohibited. Upload checks use synthetic files only in the two approved test tenants, with cleanup agreed in advance. The buyer’s incident commander and the provider lead can halt work immediately; only the incident commander or delegate can authorize resume in writing after the restart record is complete.

During kickoff, the product team proposes adding beta-api.example.invalid. It is absent from the authorization and uses a different deployment. The provider does not “take a quick look.” The buyer raises a change request containing the asset owner, build, data classification, AWS resource boundary, methods, rate limit, incremental effort, and revised schedule. Testing begins only after the authorized approver updates the scope and ROE.

The deliverables are a scope and coverage register, urgent notices for material findings, a draft report, a readout, a final report, an evidence inventory, and one retest memo. Northstar has five business days in this fictional example to send consolidated comments. It accepts the report when required assets and versions match, blocked or untested areas are visible, each finding is reproducible from redacted evidence, severity reasoning is stated, and agreed files are usable. There is no minimum finding count. Documentary gaps are corrected; a disagreement about business impact is recorded without holding the entire report hostage.

One retest may be booked within thirty calendar days of the final report, provided Northstar supplies the deployed build identifiers and working accounts. The retest covers the reported findings and agreed variants through the same control path. A new mobile release or unrelated endpoint needs a change request. The memo reports the exact build and conditions and does not turn a narrow validation into a guarantee that the product has no vulnerabilities.

Put the acceptance conversation before the test

The best time to negotiate report quality, evidence handling, retest conditions, and change approval is before testers gain access. Walk the draft package through procurement, the resource owner, security operations, incident response, product engineering, privacy, and counsel. Ask each person to make the decision they would face during the engagement. If the answer still depends on a phone call to someone who is not on the contact sheet, the ROE is not ready.

Pentest.red can review a proposed scope and discuss a penetration testing service when an independent assessment fits the buyer’s need. Before scheduling, agree the assets, versions, operational boundaries, deliverables, acceptance checks, and retest conditions in writing. The result should be a controlled project and usable evidence, not a promise that any finite test will find every vulnerability.