Penetration Testing Statement of Work Template (2026): Scope, Rules of Engagement, Deliverables and Acceptance Criteria

A penetration testing statement of work is the document an assessor reads when they ask what was tested and how. PCI DSS Requirement 11.4.1 requires that a penetration testing methodology is defined, documented and implemented by the entity, covering the entire cardholder data environment perimeter and critical systems, testing from both inside and outside the network, application-layer and network-layer testing, and retention of penetration testing results and remediation activities results for at least 12 months (PCI Security Standards Council). New York's cybersecurity regulation is equally specific: 23 NYCRR 500.5(a)(1) requires penetration testing of information systems from both inside and outside the information systems' boundaries by a qualified internal or external party at least annually (New York State Department of Financial Services). Neither obligation is discharged by an invoice. Both are discharged by a scope statement, a named methodology and a report, which is exactly what a statement of work locks down before testing starts.

Most disputes on a penetration test are scope disputes wearing another costume. The asset count moved, the third environment was assumed, the report arrived without reproduction steps, the retest was billed separately, or nobody agreed what "done" meant. Every one of those is a clause that was missing from the statement of work. The template below is written for the person who has to sign it: a security lead, a compliance owner, a procurement manager, or a founder buying a first test before an audit.

This post is a template, not legal advice. The clauses cover the technical and commercial substance of a penetration testing engagement. Confidentiality, limitation of liability, indemnification, insurance and governing-law provisions are flagged where they belong, but the wording of those provisions should come from your own counsel. Every regulatory citation below links to the publishing body so any requirement can be checked at source.

Quick answer: what does a penetration testing statement of work need to contain?

A penetration testing statement of work needs eleven things to be defensible in front of an auditor and enforceable in front of a vendor:

1. Named parties and the contract it operates under.

2. Objectives stated as outcomes, not activities.

3. In-scope assets with counts, environments, URLs, IP ranges, roles and credential tiers.

4. Explicit exclusions, including systems, techniques and third-party assets.

5. A named methodology: the Penetration Testing Execution Standard, the OWASP Web Security Testing Guide, and NIST SP 800-115.

6. A testing window with dates, time zone and any blackout periods.

7. Rules of engagement: authorization, testing sources, prohibited actions, escalation and a stop-test trigger.

8. Data handling: what data testers may access, where evidence is stored, and when it is destroyed.

9. Deliverables: report contents, severity scale, evidence standard and format.

10. Retest terms: what is included, the window it must be used in, and whether a clean-retest letter is issued.

11. Acceptance criteria: the objective test that says the engagement is complete.

Everything else in a statement of work is commercial packaging around those eleven.

Key takeaways

• The scope table is the whole document. A statement of work that says "the web application" instead of "one production web application at [URL], approximately [N] authenticated endpoints, three roles" will be re-scoped mid-engagement, and re-scoping mid-engagement is how a fixed price becomes a change order.

• Name the methodology, do not describe it. PTES defines seven phases from pre-engagement interactions through reporting (Penetration Testing Execution Standard), NIST SP 800-115 defines a four-stage methodology of planning, discovery, attack and reporting (NIST), and the OWASP Web Security Testing Guide provides the per-test-case coverage map (OWASP). Citing them by name is what turns "we tested it" into evidence.

• Acceptance criteria are the most commonly missing clause. Without them, the engagement ends when the vendor says it ends. With them, it ends when the deliverables meet a written standard.

• Retest terms decide whether your report closes findings or only lists them. Assessors under PCI DSS Requirement 11.4.4 expect exploitable vulnerabilities and security weaknesses found during penetration testing to be corrected and the testing repeated to verify the corrections.

• Evidence retention is a contract term, not an afterthought. PCI DSS Requirement 11.4.1 sets a 12-month floor for retaining penetration testing results and remediation activities. Your data-destruction clause has to be compatible with the retention your framework requires.

How this template was built

The clause set below was assembled from the requirements that assessors actually cite, read at source in September 2026:

• PCI DSS Requirement 11.4 sub-requirements 11.4.1 through 11.4.6, read from the PCI Security Standards Council's published Self-Assessment Questionnaire D for Service Providers, which reproduces the requirement text in full.

• 23 NYCRR Part 500 section 500.5, read from the New York State Department of Financial Services' published regulation text.

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, September 2008, for the four-stage penetration testing methodology and the planning-phase expectations around rules, management approval and goals.

• The OWASP Web Security Testing Guide, stable version 4.2 published 3 December 2020, for the per-test-case coverage identifiers.

• The Penetration Testing Execution Standard, for the seven-section engagement structure.

Sections that could not be traced to a published requirement are presented as commercial good practice rather than as compliance obligations, and are labelled as such. Nothing in this template is drafted as, or substitutes for, legal advice.

The template

Copy the sections below into your own document. Replace every bracketed field. Delete any section that does not apply and renumber, rather than leaving an empty heading, because an empty heading in a signed statement of work invites the argument that the topic was considered and waived.

1. Parties and precedence

This Statement of Work ("SOW") is entered into by [CLIENT LEGAL NAME], a [JURISDICTION] company with its principal place of business at [CLIENT ADDRESS] ("Client"), and [VENDOR LEGAL NAME], a [JURISDICTION] company with its principal place of business at [VENDOR ADDRESS] ("Vendor"), effective [EFFECTIVE DATE].

This SOW is governed by and incorporates the [MASTER SERVICES AGREEMENT / PROFESSIONAL SERVICES AGREEMENT] dated [DATE] between the parties (the "Agreement"). Where this SOW conflicts with the Agreement, [the Agreement / this SOW] controls, except with respect to [SCOPE, SCHEDULE AND FEES], where this SOW controls.

SOW reference: [SOW-YYYY-NNN]. Version: [1.0]. Supersedes: [NONE / SOW-YYYY-NNN].

2. Background and objectives

Client operates [SHORT DESCRIPTION OF THE SYSTEM OR BUSINESS]. Client requires an independent penetration test to [SELECT ALL THAT APPLY]:

• Identify and demonstrate exploitable security weaknesses in the in-scope assets before an adversary does.

• Produce penetration testing evidence in support of Client's [SOC 2 / ISO 27001 / PCI DSS / HIPAA / NYDFS 23 NYCRR 500 / CMMC] programme.

• Validate remediation of findings from the prior assessment dated [DATE].

• Assess the effectiveness of [SPECIFIC CONTROL, for example multi-tenant isolation, segmentation, or the authorization model].

Objectives are stated as outcomes. The following are not objectives of this engagement and will not be used to measure it: number of findings, number of hours logged, or tool output volume.

3. Scope of work

Vendor will perform the following services against the assets listed in the scope table.

Scope table. Complete one row per in-scope asset. Counts, not adjectives, are what price and schedule are built on.

Scope tolerance. Vendor has priced this engagement on the asset counts above. Variance of up to [10%] in endpoint or host count will be absorbed without change order. Variance above that threshold is handled under Section 16 (Change control).

Environment. Testing will be performed against [PRODUCTION / A PRODUCTION-EQUIVALENT STAGING ENVIRONMENT]. Where a staging environment is used, Client confirms it is functionally equivalent to production in code version, configuration and data model, and that material differences are documented in Appendix [X].

Credentials. Client will provide [N] sets of credentials per role, no later than [N] business days before the testing window opens, along with any MFA bypass mechanism, test accounts, and API keys required. Delay in credential provision moves the testing window under Section 13.

4. Out of scope

The following are expressly excluded from this engagement:

• Any asset not listed in the scope table in Section 3.

• Denial-of-service and volumetric stress testing, including resource exhaustion and application-layer flooding.

• Physical intrusion, lock bypass and facility access testing. [Include only if not purchased.]

• Social engineering of Client personnel. [Include only if not purchased.]

• Testing of third-party or subprocessor infrastructure that Client does not own or control, absent written authorization from that third party supplied to Vendor before testing begins.

• Modification, deletion or exfiltration of production data beyond the minimum required to demonstrate impact, as defined in Section 8.

• Source code review, threat modelling and architecture review. [Include only if not purchased.]

• Remediation of findings. Vendor advises on remediation; Client implements it.

• Any statement, certificate or attestation of compliance with a regulatory framework. Vendor produces penetration testing evidence; the attestation is a separate engagement performed by a qualified assessor.

5. Methodology and standards

Vendor will conduct testing in accordance with the following published methodologies, and will name them in the report:

• Penetration Testing Execution Standard (PTES), covering pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post exploitation and reporting.

• OWASP Web Security Testing Guide, stable version [4.2], for web application and API test-case coverage. Findings will reference WSTG identifiers where applicable.

• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment, for the planning, discovery, attack and reporting phases.

• OWASP API Security Top 10 for API-specific coverage. [Include where APIs are in scope.]

• [MITRE ATT&CK] for technique mapping in the report. [Include where adversary emulation or internal network testing is in scope.]

Testing will be manual-led. Automated tooling is used for coverage and enumeration; every reported finding will have been manually verified and reproduced by a named tester. Vendor will not report unvalidated scanner output.

Severity. Findings will be rated using [CVSS v3.1 / CVSS v4.0] base scores with the full vector string published per finding, alongside a business-impact rating assigned by the tester. Where the two diverge, the report will explain why.

Tester qualifications. Vendor confirms that testing will be performed by personnel holding [OSCP / OSWE / CREST CRT / GIAC / EQUIVALENT] certifications, and will supply named tester biographies in the report. Testers will be organizationally independent of the personnel who built or administer the in-scope systems.

6. Testing window and schedule

Permitted testing hours. [24 hours per day for the duration of the window] or [BUSINESS HOURS ONLY, HH:MM to HH:MM, TIME ZONE, excluding weekends].

Blackout periods. No testing will occur during [DATES], covering [REASON, for example a release freeze, month-end close, or a clinical or trading peak].

Notice of start. Vendor will notify [CLIENT CONTACT] by [EMAIL / SLACK CHANNEL] at the start and end of each testing day.

7. Rules of engagement

Authorization. Client represents that it owns or is authorized to permit testing of every asset in Section 3, and that it has obtained any required authorization from hosting providers, cloud providers and third parties. Client will execute the authorization letter at Appendix [A] before the window opens. Vendor will not begin testing without it.

Testing sources. Vendor will test from the following source addresses, which Client will allowlist where required: [IP ADDRESSES]. Vendor will notify Client of any change to source addresses at least [24] hours in advance.

Defensive controls. In-scope defensive controls will be [LEFT IN ENFORCING MODE / SET TO MONITOR MODE / ALLOWLISTED FOR VENDOR SOURCE IPS] for the duration of the window. Where controls are left enforcing, both parties accept that coverage may be reduced and the report will state where testing was blocked.

Prohibited actions. Vendor will not:

• Execute denial-of-service, volumetric or resource-exhaustion attacks.

• Modify or delete production data, except as required to demonstrate impact and only with prior written approval per finding.

• Exfiltrate production personal data, cardholder data, protected health information or credentials beyond the minimum sample required as evidence, as defined in Section 8.

• Pivot to, or test, any asset outside Section 3, including assets discovered during testing. Discovered out-of-scope assets will be reported, not tested.

• Install persistence mechanisms that survive the engagement, or leave any implant, account or configuration change in place at window close.

Discovered credentials. Where Vendor recovers valid credentials, Vendor will use them only against in-scope assets, will report them immediately, and will not use them after the window closes.

Stop-test trigger. Either party may suspend testing immediately by notifying the other party's escalation contact. Testing will be suspended automatically if Vendor observes [EVIDENCE OF A PRIOR OR CONCURRENT THIRD-PARTY COMPROMISE / MATERIAL SERVICE DEGRADATION ATTRIBUTABLE TO TESTING / EXPOSURE OF REGULATED DATA OUTSIDE THE AGREED HANDLING TERMS]. Suspended time is added to the window under Section 16.

Deconfliction. Client will inform its managed detection provider and internal security operations team of the window and of Vendor's source addresses, or will explicitly elect not to, in order to run the test as a detection exercise. Client's election: [INFORMED / NOT INFORMED].

Emergency contacts.

8. Data handling and evidence

Data minimisation. Vendor will access the minimum data required to demonstrate impact. Where a finding is proven by retrieving a record, Vendor will retrieve [ONE] record, will redact identifying fields in the report, and will not retrieve the underlying dataset.

Regulated data. Where in-scope systems process [cardholder data / protected health information / personal data subject to GDPR or provincial privacy law], Vendor will [NOT EXTRACT SUCH DATA AT ALL / EXTRACT ONLY REDACTED SAMPLES] and will record the fact of access rather than the content.

Storage. Engagement data, including credentials, evidence, screenshots and raw tool output, will be stored [ENCRYPTED AT REST IN VENDOR'S [REGION] ENVIRONMENT], accessible only to personnel assigned to this engagement.

Transfer. Reports and evidence will be delivered by [ENCRYPTED PORTAL / PGP-ENCRYPTED EMAIL TO KEY ID [KEYID]]. Credentials will never be transmitted in plaintext by email or chat.

Retention and destruction. Vendor will retain engagement data for [12] months from final report delivery, then securely destroy it and confirm destruction in writing within [10] business days. Client acknowledges that a shorter retention period may conflict with the 12-month retention of penetration testing results and remediation activities expected under PCI DSS Requirement 11.4.1, where that requirement applies.

Subprocessors. Vendor will not disclose engagement data to any subprocessor not listed at Appendix [B] without Client's prior written consent.

Personnel. All Vendor personnel assigned to this engagement are subject to [BACKGROUND CHECKS / CONFIDENTIALITY AGREEMENTS] and are located in [COUNTRIES]. Client restriction on tester nationality or residency: [NONE / SPECIFY].

9. Communication and critical-finding notification

Standing channel. A shared [SLACK CONNECT CHANNEL / MICROSOFT TEAMS CHANNEL] will be opened at kickoff and closed [30] days after final report delivery.

Cadence. Vendor will provide a written progress update [DAILY / EVERY SECOND BUSINESS DAY] during the testing window, covering coverage completed, blockers, and findings confirmed to date.

Critical-finding notification. Vendor will notify Client's engagement owner within [4] hours of confirmation of any finding rated Critical, and within [24] hours of any finding rated High. Notification will include a plain-language description, the affected asset, the immediate containment step Vendor recommends, and reproduction steps. Notification is by [PHONE THEN EMAIL], not by the shared channel alone.

Evidence of prior compromise. If Vendor identifies indicators that the in-scope environment is already compromised, Vendor will stop testing that asset, preserve evidence, and notify Client's escalation contact immediately. Incident response is outside this SOW.

Blocked coverage. Vendor will notify Client within [8] hours where access, credentials, or a defensive control prevent planned coverage, so that the blocker can be cleared inside the window rather than reported as a gap afterwards.

10. Deliverables

Vendor will deliver the following:

Report contents. The technical report will contain, at minimum:

1. Cover page with Client name, assessment window, report version and named testing team.

2. Executive summary with severity distribution and a plain-language narrative of business risk.

3. Scope statement reproducing the asset table from Section 3, with any deviation explained.

4. Methodology section naming PTES, the OWASP Web Security Testing Guide and NIST SP 800-115, and describing what was and was not covered.

5. Severity rating scale with the definitions used for Critical, High, Medium, Low and Informational.

6. Findings table indexed by identifier, severity, affected asset and status.

7. Per-finding detail containing: title, severity, CVSS base score and full vector, business impact, technical description, affected systems, external references such as CWE and OWASP identifiers, step-by-step reproduction instructions with evidence, and a specific remediation recommendation.

8. Root-cause analysis grouping findings by structural cause.

9. Retest results, where a retest has been performed.

10. Appendices listing tools used, testers and their certifications, and out-of-scope assets discovered.

A worked example of this structure, page by page, is in the penetration testing report sample.

Evidence standard. Every finding rated Medium or above will include reproduction steps sufficient for a Client engineer to reproduce the issue without contacting Vendor, plus supporting evidence. Findings that cannot meet this standard will be reported as Informational and labelled as unconfirmed.

11. Retest terms

Vendor will perform [ONE] retest of remediated findings at no additional charge, subject to the following:

• Eligible findings. All findings rated [MEDIUM AND ABOVE / ALL SEVERITIES] reported in the final report.

• Retest window. The retest must be requested within [90] days of final report delivery. Requests after that date are quoted separately.

• Scope of retest. Retesting verifies the specific reported issue and the immediate attack path around it. It is not a re-run of the full engagement and does not cover new functionality shipped since the original test.

• Regression. Where a fix introduces a new issue on the same code path, that issue is treated as part of the retest, not as a new engagement.

• Outcome. Vendor will issue a retest report stating, per finding, whether it is Resolved, Partially Resolved or Not Resolved, with evidence.

• Clean-retest letter. Where all eligible findings are Resolved, Vendor will issue a letter suitable for supply to Client's auditor or customer. [Confirm whether the letter names individual findings or states aggregate closure.]

Retesting is what turns a findings list into closed risk, and it is the clause most often quietly billed as an extra. Confirm at contract stage whether it is included and how long the window runs.

12. Acceptance criteria

The engagement is complete when all of the following are true. Client will confirm acceptance in writing within [10] business days of final report delivery, or provide a written list of deficiencies against these criteria.

1. Coverage. Every asset in the Section 3 scope table has been tested, or any untested asset is listed in the report with the reason it was not tested.

2. Methodology. The report names the methodologies in Section 5 and maps coverage to them.

3. Reproducibility. Every finding rated Medium or above includes reproduction steps and evidence meeting the standard in Section 10.

4. Severity discipline. Every finding carries a CVSS base score with its full vector string and a business-impact rating.

5. Manual validation. No finding in the report is unvalidated automated output. Vendor confirms manual verification in writing.

6. Deliverables. Every deliverable listed in Section 10 has been received in the stated format.

7. Notification compliance. Any Critical or High finding was notified within the timelines in Section 9.

8. Retest. Where a retest was performed inside the window, the retest report states a status per finding.

9. Data destruction. Vendor has confirmed destruction of engagement data per Section 8, or the retention period is still running.

Deficiencies raised under this section will be remedied by Vendor within [10] business days at no additional charge. Acceptance is not withheld on the basis of the number or severity of findings discovered, which are an outcome of testing rather than a defect in it.

13. Schedule dependencies and Client responsibilities

Client will:

• Provide credentials, test accounts, API specifications and any VPN or bastion access by the date in Section 6.

• Nominate an engagement owner with authority to approve scope questions inside [4] business hours.

• Allowlist Vendor source addresses where required, and confirm in writing that they are in place before the window opens.

• Notify its hosting and cloud providers where their terms require it.

• Ensure the test environment is stable and populated with representative data.

• Return comments on the draft report by the date in Section 6.

Where a Client dependency slips, the testing window and all downstream dates move by the same number of business days, and Vendor is not in breach of the schedule. Slippage beyond [10] business days is handled under Section 16.

14. Pricing and payment

Basis. Fees are [FIXED FEE FOR THE SCOPE IN SECTION 3 / TIME AND MATERIALS AT [RATE] PER DAY, CAPPED AT [AMOUNT]]. Fixed fee is the norm for a defined scope; time and materials belongs to open-ended research work, not to a scoped penetration test.

Expenses. [NONE / PRE-APPROVED TRAVEL AT COST].

Invoicing. [50% on signature, 50% on final report delivery] or [100% on final report delivery]. Payment terms [NET 30].

Taxes. Amounts are exclusive of applicable sales tax, VAT or GST.

For market-rate context before you fill this section in, see the 2026 penetration testing cost guide and the penetration testing cost calculator.

15. Assumptions

This SOW is priced and scheduled on the following assumptions. If any proves false, Section 16 applies.

• Asset counts in Section 3 are accurate within the tolerance stated.

• Credentials and access will be available on the date stated and will remain valid for the window.

• The test environment will be available for the full window, subject only to declared blackout periods.

• No material change to the in-scope application or infrastructure will be deployed during the window. Where a deploy is unavoidable, Client will notify Vendor before it lands.

• Client will supply an API specification where APIs are in scope.

• Client holds all necessary authorizations for testing, including from third-party providers.

16. Change control

Any change to scope, schedule or fees is effective only when recorded in a written change order signed by both parties. A change order will state: the change requested, the reason, the impact on scope, the impact on schedule, and the impact on fees.

Changes that trigger a change order include: asset count variance beyond the Section 3 tolerance, addition of an environment or application, a request for out-of-hours testing not priced in Section 14, a Client dependency slipping more than [10] business days, and any suspension under the stop-test trigger that consumes more than [1] business day of the window.

No verbal instruction, chat message or email from either party's staff varies this SOW.

17. Confidentiality, liability and legal terms

The parties' obligations on confidentiality, limitation of liability, indemnification, insurance, intellectual property in the report and deliverables, data processing terms, and governing law and jurisdiction are set out in the Agreement referenced in Section 1 and are not restated here. Where no Agreement exists, those provisions must be drafted before this SOW is signed.

Consult counsel. Penetration testing involves authorized access to computer systems. The authorization letter at Appendix [A], the scope boundary in Sections 3 and 4, and the liability allocation in the Agreement are the documents that make that access lawful and bounded. Have your own legal counsel review them. This template is a starting point for a commercial and technical discussion, not legal advice, and nothing in it should be treated as a legal opinion on your jurisdiction.

Points to raise with counsel: whether the liability cap is expressed as a multiple of fees and whether it carves out data breach caused by Vendor; whether report intellectual property is assigned to Client or licensed; whether Client may share the report with customers, auditors and regulators without further consent; whether a data processing agreement is required; and whether any regulator notification obligation is triggered by findings.

18. Signatures

Appendix A: Authorization to test letter. Appendix B: Approved subprocessors. Appendix C: Asset inventory, if too large for Section 3. Appendix D: Prior report, where this engagement validates remediation.

Clauses buyers forget

These are the clauses whose absence causes the most friction after signature. Check each one before you sign.

1. Acceptance criteria. Without a written standard for "complete", the vendor decides when the engagement ends.

2. Retest window length. "Retest included" with no window means the retest expires whenever the vendor says it does. Ninety days is a workable floor for an application team on a normal release cadence.

3. Regression handling on retest. If a fix introduces a new issue on the same code path, is that inside the retest or a new engagement?

4. Evidence standard per finding. A report full of findings that your engineers cannot reproduce is a report you will pay twice for.

5. Blocked-coverage notification. If a WAF blocks the tester on day two and you hear about it in the report on day fifteen, you bought less coverage than you paid for.

6. Named testers and certifications. Ask for named biographies in the deliverables list, not just a firm-level claim.

7. Tester independence. Assessors under PCI DSS Requirement 11.4.3 expect organizational independence of the tester. Put it in writing.

8. Data destruction confirmation in writing. Not just "we will delete it", but a written confirmation with a deadline.

9. Report sharing rights. Can you send the report to a customer under NDA, to an auditor, to a regulator? Silence here becomes a problem the first time a prospect asks for it.

10. Scope tolerance. A stated percentage tolerance on asset counts prevents a change order over a handful of endpoints.

11. Deconfliction election. Recording whether your detection team was told turns a penetration test into a detection exercise, or keeps it a pure coverage exercise. Either is valid. Undeclared is not.

12. Machine-readable export. A CSV or JSON export of findings is what lets you load results into your tracker without retyping them.

13. Attestation letter of testing performed. Distinct from the report, and often what a customer's vendor-risk questionnaire actually wants.

14. Discovered out-of-scope asset handling. Testers will find assets you forgot. Agree in advance that they are reported and not tested.

15. Stop-test trigger and who can pull it. Both parties, in writing, with a defined contact.

A scoreable version of the vendor-side questions behind these clauses is in the pentest and red team RFP question bank, and a structured request-for-proposal starting point is at the penetration testing RFP template.

Mapping SOW clauses to what assessors ask for

Auditors do not read your statement of work looking for elegance. They read it looking for four things: what was in scope, who tested it, against what methodology, and what happened to the findings. The table below maps the template's clauses to the requirement each framework's assessor cites.

Framework citations above are to the requirement text published by the PCI Security Standards Council and the New York State Department of Financial Services. SOC 2 and ISO 27001 do not publish a penetration testing cadence of their own; their assessors evaluate whether the organisation's own stated process was followed and evidenced. A deeper treatment of what auditors accept is in pentest evidence auditors accept.

Red flags in a vendor's proposed statement of work

If the vendor sends their paper first, these are the clauses to negotiate before signature.

• Scope described in adjectives. "The main application and supporting infrastructure" is not a scope. Ask for the table.

• Methodology described but not named. A paragraph of prose about "industry best practice" without naming PTES, the OWASP Web Security Testing Guide or NIST SP 800-115 is a paragraph an assessor cannot use.

• Retest priced as a separate engagement. Legitimate for a scope expansion. Not legitimate for verifying the findings you just paid to discover.

• Time and materials on a defined scope. Open-ended billing on a bounded application is a pricing model mismatch.

• No critical-finding notification timeline. If a Critical is found on day one, you need to know on day one.

• Deliverables listed as "a report". Ask for the section list in the SOW itself, not in a sales deck.

• Automated-scan output presented as penetration testing. Ask directly what proportion of reported findings will be manually verified, and put the answer in Section 5.

• A liability cap below the fee. Uncommon, and worth escalating to counsel when you see it.

• Silence on report sharing. Ask for explicit permission to share with auditors, regulators and customers under NDA.

What this means for buyers

A statement of work is the cheapest control in a penetration testing programme. It costs an afternoon of drafting and it removes almost every category of dispute that shows up later: scope creep, missing evidence, a retest that expired, an audit finding because nobody wrote down which methodology was used.

Three practical moves. First, insist on the asset table with counts, because everything downstream is priced and scheduled off it. Second, write acceptance criteria, because they are the only clause that defines "done" in a way that is not the vendor's opinion. Third, put the retest window and the regression rule in writing, because closing findings is the point of the exercise and the clause most often left vague.

Stingrai's engagements are scoped against exactly this structure. Findings are manually verified before they reach a report, and remediation retests are included. Across the engagements analysed in the 2026 state of penetration testing report, 1,206 verified findings across 55 tests carried a 0.74% false-positive rate, 92.7% of tests surfaced at least one High or Critical issue, and the median time to fix a Critical was 10.5 days. Those are the numbers an acceptance-criteria clause is designed to protect.

Frequently Asked Questions

What is a penetration testing statement of work?

A penetration testing statement of work is the contract document that defines what will be tested, how, when, by whom, what will be delivered, and how the engagement is judged complete. It sits under a master services agreement and controls scope, schedule and fees. At minimum it contains parties, objectives, an in-scope asset table with counts, exclusions, a named methodology, a testing window, rules of engagement, data handling terms, deliverables, retest terms and acceptance criteria. It is also the document your assessor reads when they need to establish what was covered, which is why PCI DSS Requirement 11.4.1 requires a defined and documented penetration testing methodology.

What should be in the scope section of a pentest SOW?

The scope section should list every in-scope asset as a row in a table with an identifier, environment, authentication requirement, role count and an approximate size measure such as endpoint or host count. Adjectives do not scope an engagement; counts do. Include a scope tolerance clause, typically around 10%, so a handful of extra endpoints does not trigger a change order. State whether testing runs against production or a production-equivalent staging environment, and record any material differences. Anything not in the table belongs in the out-of-scope section, including discovered assets, which should be reported rather than tested.

What are rules of engagement in a penetration test?

Rules of engagement are the operating constraints on the testing team. They cover written authorization for every asset, the source addresses testing will originate from, whether defensive controls are enforcing or in monitor mode, prohibited actions such as denial-of-service and production data modification, how discovered credentials may be used, a stop-test trigger either party can pull, deconfliction with the detection team, and named emergency contacts available outside business hours. NIST SP 800-115 places this work in the planning phase, where rules are identified, management approval is finalised and documented, and testing goals are set.

How do I write acceptance criteria for a penetration test?

Write acceptance criteria as objective, checkable statements rather than as a satisfaction standard. Useful criteria include: every asset in the scope table was tested or its exclusion explained; the report names the methodologies used; every finding at Medium or above includes reproduction steps and evidence sufficient for an engineer to reproduce it unaided; every finding carries a CVSS base score with the full vector; no finding is unvalidated automated output; every listed deliverable arrived in the stated format; and Critical and High findings were notified inside the agreed timelines. Give yourself a defined review period, typically 10 business days, and require the vendor to remedy deficiencies at no charge. Acceptance is never withheld because the test found too many issues.

Does a penetration testing SOW need to specify a methodology?

Yes, and it should name the methodology rather than describe it. Name the Penetration Testing Execution Standard, which structures an engagement across pre-engagement interactions, intelligence gathering, threat modelling, vulnerability analysis, exploitation, post exploitation and reporting. Name the OWASP Web Security Testing Guide, stable version 4.2, for web and API test-case coverage. Name NIST SP 800-115 for the planning, discovery, attack and reporting phases. PCI DSS Requirement 11.4.1 explicitly requires industry-accepted penetration testing approaches in a documented methodology, so a named standard is the difference between evidence an assessor accepts and prose they do not.

How often does a penetration test need to be performed?

It depends on the framework you answer to. PCI DSS Requirement 11.4.2 and 11.4.3 require internal and external penetration testing at least once every 12 months and after any significant infrastructure or application upgrade or change, with segmentation testing at least every 12 months and at least every six months for service providers under Requirement 11.4.6. New York's 23 NYCRR 500.5(a)(1) requires testing from inside and outside the information systems' boundaries at least annually. SOC 2 and ISO 27001 publish no cadence of their own; their assessors check that you followed the cadence you documented. Teams shipping code weekly typically pair an annual full-scope engagement with continuous coverage between releases.

What should the deliverables section of a pentest SOW include?

List each deliverable, its format and its due date, then specify the report's contents in the SOW itself. A defensible report contains a cover page with the assessment window and named testers, an executive summary, a scope statement, a methodology section naming the standards used, a severity scale with definitions, a findings index, per-finding detail with CVSS score and vector, business impact, affected systems, external references, reproduction steps with evidence and a specific remediation recommendation, root-cause analysis, and appendices covering tools and tester certifications. Also ask for a machine-readable findings export and an attestation letter of testing performed, which is often what a customer's vendor-risk questionnaire is actually requesting.

Should retesting be included in a penetration testing SOW?

Yes, and it should be specified rather than implied. State how many retests are included, which severities are eligible, how long the retest window runs, whether a regression introduced by a fix on the same code path is covered, what the retest report states per finding, and whether a clean-retest letter is issued for supply to auditors and customers. PCI DSS Requirement 11.4.4 expects exploitable vulnerabilities found during penetration testing to be corrected and the testing repeated to verify the corrections, so a vague retest clause creates an audit gap as well as a commercial one. Stingrai includes remediation retests in its engagements.

Is a penetration testing SOW a legal contract?

A statement of work is a contract document, but it normally operates under a master services agreement that carries the confidentiality, liability, indemnity, insurance, intellectual property and governing-law provisions. The SOW controls scope, schedule and fees. The authorization to test letter is the document that makes otherwise unauthorized access to computer systems lawful, so it should be executed before testing begins and should be signed by someone with authority over the assets. This template covers technical and commercial substance only. Have your own legal counsel review the authorization letter, the liability allocation and the report-sharing rights before signature.

How much does a penetration test cost, and how should the SOW price it?

Price a defined scope as a fixed fee, not as time and materials, because the asset table in the scope section already bounds the work. Time and materials belongs to open-ended research engagements. Include any out-of-hours premium as a separate line so it is visible, state whether retesting is included at zero cost, and set invoicing terms explicitly. Stingrai publishes package pricing openly: a one-time Autonomous Pentest with Snipe from US$3,000 and a one-time Hybrid Pentest with certified penetration testers at US$6,800, both covering exactly one web application and its APIs, and both available as subscriptions from US$450 per month and US$1,275 per month on a 12-month engagement. The Autonomous tier carries a No High or Critical Finding, Don't Pay guarantee. Other scopes are quoted individually. Current figures are on the pricing page.

Related reading

• Penetration Testing RFP Template

• Penetration Testing Cost Calculator

• Penetration Testing Report Sample (2026)

• How to Scope a Penetration Test (2026)

• Red Team Rules of Engagement: Buyer Checklist

• Pentest Evidence Auditors Accept: SOC 2, ISO 27001, PCI and CMMC

• Pentest and Red Team RFP Question Bank (2026)

• Penetration Testing Cost Guide 2026

• Right to Test Clause for SaaS Vendor Pentests

• Stingrai Pricing

References

1. PCI Security Standards Council. _PCI DSS Requirement 11.4, as published in the Self-Assessment Questionnaire D for Service Providers._ https://www.pcisecuritystandards.org/document_library/. Reproduces the full text of Requirements 11.4.1 through 11.4.6, covering methodology, internal and external testing cadence, remediation and retest, and segmentation testing frequency.

2. New York State Department of Financial Services. _Cybersecurity Requirements for Financial Services Companies, 23 NYCRR Part 500, section 500.5 Vulnerability management._ https://www.dfs.ny.gov/system/files/documents/2026/07/NYCRR-part-500-Cybersecurity-Regulation.pdf. Requires annual penetration testing from inside and outside system boundaries by a qualified internal or external party, plus automated scans and manual review at a risk-based frequency.

3. National Institute of Standards and Technology. _SP 800-115, Technical Guide to Information Security Testing and Assessment._ September 2008. https://csrc.nist.gov/pubs/sp/800/115/final. Defines the four-stage penetration testing methodology of planning, discovery, attack and reporting, and the planning-phase expectations for rules, management approval and goals.

4. OWASP Foundation. _Web Security Testing Guide, stable version 4.2._ 3 December 2020. https://owasp.org/www-project-web-security-testing-guide/. Provides the WSTG test-case identifiers used for web application and API coverage mapping.

5. Penetration Testing Execution Standard. _PTES main page._ http://www.pentest-standard.org/index.php/Main_Page. Defines the seven engagement sections from pre-engagement interactions through reporting.

6. OWASP Foundation. _API Security Project._ https://owasp.org/www-project-api-security/. Reference set for API-specific test coverage where APIs are in scope.

7. Stingrai. _Pricing._ https://www.stingrai.io/pricing. Published package pricing for autonomous and hybrid penetration testing engagements.

Ready to put this SOW to work?

Stingrai scopes engagements against exactly this structure: an asset table with counts, a named methodology, written rules of engagement, manually verified findings with reproduction steps, and a remediation retest included. Snipe, Stingrai's autonomous AI agent for web application penetration testing, works concurrently with certified penetration testers on every engagement, hunting IDOR, broken authorization and business-logic flaws, reviewing source code, and gating pull requests. Book a free scoping call, get a quote, or see published pricing.