How to Create a Penetration Testing Statement of Work (SoW) for a Contractor

A strong Penetration Testing Statement of Work (SoW) protects you from surprises: missed assets, unclear rules of engagement, weak deliverables, and disputes about what “testing” actually meant. It also helps the contractor run a safer, faster, and more useful engagement, especially when production systems, customer data, or compliance timelines are involved.

In this article, ESKA Security explains how to write a penetration testing SoW that contractors can execute confidently and your stakeholders can approve without friction.

What is a Penetration Testing Statement of Work (SoW)?

A Statement of Work (SoW) is a dedicated document that outlines the scope, approach, timeline, rules, responsibilities, and deliverables of a penetration test. It is specifically created to ensure both parties are aligned on how the work will be performed and what will be delivered. It should not be confused with other documents such as an MSA/NDA, which governs legal relationships and confidentiality, a contract or purchase order that addresses commercial terms, or the Rules of Engagement (RoE), which may be included in the SoW or provided as a separate appendix to address operational safety and boundaries.

A Statement of Work (SoW) answers several critical questions that define the scope and execution of a penetration test. These include:

• What will be tested? (assets, environments, roles, integrations)

• How will it be tested? (approach, methodology, validation depth)

• When will it be tested? (schedule, milestones, reporting cadence)

• How will risk be controlled? (rules of engagement, safety boundaries, escalation procedures)

• What will be delivered? (report structure, severity model, evidence quality, retest terms)

• Who is responsible for what? (access, accounts, allowlisting, points of contact)

If your SoW is strong, the engagement is predictable. If it’s vague, you will almost always face one of these outcomes: scope arguments, missed systems, incomplete testing due to lack of access, risky testing behavior, or a final report that is too generic to be useful.

What a SoW is NOT (and why this distinction matters)

Many organizations mix SoW language with legal and commercial documents. That often leads to confusion, because each document serves a different purpose.

SoW vs MSA / NDA

• MSA (Master Services Agreement) defines the overall legal relationship, liability, indemnities, governing law, and general terms of service.

• NDA (Non-Disclosure Agreement) defines confidentiality obligations and protected information.

The SoW is different. It is not the place to negotiate broad legal clauses. Instead, it should reference the MSA/NDA and focus on execution: scope, access, rules, deliverables, timelines, acceptance.

Example of correct SoW language:“This engagement is governed by the existing MSA and NDA between the parties. Any confidential information accessed during testing must be handled according to those agreements and the data handling requirements in Section X of this SoW.”

SoW vs Contract / Purchase Order

A purchase order or contract usually covers pricing, invoicing, and payment milestones. It can reference the SoW as the description of work being purchased.

The SoW should not be a pricing document. You can include commercial boundaries (e.g., what triggers a change request), but keep the SoW focused on what will be done and what “done” means.

SoW vs Rules of Engagement (RoE)

Rules of Engagement can exist as a separate appendix, but they are usually part of the SoW because they directly impact safety and scope control.

• RoE defines safety boundaries, timing constraints, escalation paths, and what is explicitly forbidden (DoS, brute-force, destructive actions).

• SoW is broader: it includes RoE, but also includes deliverables, responsibilities, methodology, and acceptance criteria.

Good practice: include RoE as its own section inside the SoW so stakeholders can review and approve it without hunting through other documents.

How to write a Penetration Testing SoW for a contractor

1) Engagement overview and objectives

Keep this section short and measurable.

Include:

• Business context (launch, due diligence, incident follow-up, customer requirement)

• Primary security objectives (validate controls, identify exploitable paths, test detection)

• Engagement type (external/internal, web/API/mobile/cloud, black/grey/white box)

Example objective statement

“The objective of this engagement is to identify exploitable security weaknesses across the in-scope systems, validate impact with safe proof-of-concept, and deliver remediation guidance that engineering can implement and leadership can track.”

2) Scope definition (the most important section)

Define scope with precision. “Our web app” is not scope. “https://app.example.com in production with authenticated roles” is scope.

Include:

• URLs, domains, IP ranges, cloud accounts/subscriptions

• Environments: production, staging, development

• Applications: web, API, mobile (build identifiers), admin panels

• Authentication: user roles, permissions, expected flows

• Third parties: explicitly in-scope or explicitly excluded

Always write an “Out of scope” list

Examples:

• Denial-of-service (DoS) or stress testing

• Social engineering / phishing (unless explicitly authorized)

• Physical testing

• Third-party providers not under your control

• Attempting to bypass MFA with account takeover techniques (unless explicitly authorized)

3) Methodology and testing approach

Contractors should know what standards and depth you expect.

Common methodology references:

• OWASP Web Security Testing Guide (WSTG)

• OWASP API Security Top 10 and testing guidance

• PTES (Penetration Testing Execution Standard)

Define:

• Whether exploitation is required for validation

• How far they may go (e.g., privilege escalation allowed, but no persistence)

• Tooling constraints (optional) if your environment has strict policies

It is important to note that simply running a scan and generating a report does not constitute a comprehensive penetration test. If you want the test to include exploitation-based validation of vulnerabilities, this should be explicitly stated in the Statement of Work. This ensures that the contractor understands the depth of testing required and that the engagement goes beyond just identifying vulnerabilities to actively testing their exploitability.

4) Rules of Engagement (RoE) and safety boundaries

RoE prevents outages and escalates risk correctly.

Include:

• Testing hours and change freeze windows

• Request rate limits, brute-force restrictions, lockout avoidance rules

• “No destructive actions” and clear definitions (e.g., no data modification, no mass deletion)

• What constitutes acceptable proof (minimal PoC)

• What happens when critical findings are discovered (notify within X hours)

Example RoE language

• “No DoS, volumetric scanning, or resource exhaustion testing.”

• “If a critical vulnerability is identified, contractor must notify the customer within 24 hours via the defined escalation channel.”

• “Evidence collection must use synthetic data where possible and must not exfiltrate customer data.”

5) Access, prerequisites, and shared responsibilities

Split responsibilities between Customer and Contractor. This avoids delays.

Customer provides

• Test accounts (roles, privileges, MFA approach)

• Network access (VPN, allowlisting, jump host)

• Technical contacts (DevOps/SRE, app owner)

• High-level architecture notes (optional but helpful)

• Test data approach (synthetic data, masked data, or a sandbox)

Contractor provides

• Named testers and contact points

• Planned testing schedule

• Communication cadence (daily/weekly standups or written updates)

• Immediate notification process for critical issues

6) Deliverables (make them measurable)

Define deliverables with acceptance criteria. If you don’t define “good,” you might receive “something.”

Minimum deliverables typically include:

1. Executive summary (risk, business impact, key themes)

2. Technical report with:

   • Finding title + severity

   • Impact and affected assets

   • Reproduction steps (clear and repeatable)

   • Evidence (screenshots, requests, logs)

   • Remediation guidance (practical, prioritized)

3. Risk scoring model (CVSS + business context)

4. Debrief session (walkthrough with engineering + stakeholders)

5. Retest / verification (optional but recommended)

Acceptance criteria examples

• “Each finding must include affected asset, reproduction steps, and remediation guidance.”

• “Critical/High findings must be validated with safe proof-of-concept.”

• “Final report delivered within X business days after testing ends.”

7) Severity definitions and reporting SLAs

Define notification windows for critical findings and the timeline for the final report.

Example:

• Critical: notify within 24 hours

• High: notify within 72 hours

• Final report: within 5–10 business days after the last testing day

• Retest report: within 5 business days after remediation is confirmed ready

8) Timeline, milestones, and change control

Specify phases:

• Kickoff and access validation

• Active testing window

• Reporting and review

• Debrief

• Retest (if included)

Add change control rules:

• Scope changes require written approval

• New assets discovered mid-test are handled via a change request

• Major environment changes can pause the engagement

9) Data handling and confidentiality requirements

This section is essential if production or regulated data is in play.

Include:

• Storage: encryption, access control, geographic constraints (if needed)

• Retention period: 30/60/90 days, and deletion confirmation

• Restrictions: no customer PII exfiltration; use synthetic samples

• Incident handling: what the contractor must do if they see evidence of compromise

Сreating a Penetration Testing Statement of Work (SoW) is an essential step in ensuring that your testing engagement is clear, well-structured, and runs smoothly. By addressing key aspects such as scope, methodology, rules of engagement, deliverables, and responsibilities, you set clear expectations for both the contractor and your internal stakeholders. This minimizes risks, avoids confusion, and ensures that the final report is actionable and aligns with your security goals.

With a detailed SoW in hand, you can confidently proceed with the engagement, knowing that the scope of work is well-defined, the boundaries are respected, and the results will be valuable to your business. Whether you're testing a web app, an API, or a cloud environment, a solid SoW lays the foundation for a successful penetration test that helps you identify and address critical vulnerabilities before they can be exploited.