Penetration Testing SOW Template & Buyer Checklist

Important SOW and Legal-Safe Note

A penetration testing statement of work should be approved before testing begins. It is commonly used as part of the contractual work agreement for an authorized security assessment, but this article is a planning framework, not final legal language. A SOW should define the business objective, scope, assets, exclusions, assumptions, responsibilities, timeline, rules of engagement reference, deliverables, data handling, retesting, and acceptance criteria.

The SOW is related to, but not the same as, a technical scope document, rules of engagement, request for proposal, master services agreement, NDA, written authorization letter, or final penetration test report. Legal, procurement, security, operations, and compliance stakeholders should review the final SOW before signature. This article is educational and does not provide legal advice.

Executive Summary / TL;DR

A penetration testing SOW defines the agreed work plan: objective, scope, responsibilities, deliverables, timeline, assumptions, and acceptance criteria.
A safe SOW should not be vague about assets, exclusions, rules of engagement, written authorization, data handling, reporting, or retesting.
The SOW is broader than technical scope and different from the RFP, ROE, MSA, NDA, authorization letter, and final report.
Good SOW quality reduces misunderstandings between security, engineering, procurement, legal, finance, and compliance teams.
SOW details affect cost, timeline, testing depth, report usefulness, retesting expectations, and audit evidence.
Web, API, cloud, mobile, network, red team, and compliance engagements need different SOW inputs and safety boundaries.
Compliance SOWs should map systems and evidence to audit objectives without claiming that penetration testing alone guarantees compliance.
DeepStrike can support SOW discussions for authorized assessments, but the final SOW should be reviewed by the buyer’s legal, procurement, security, and compliance teams.

Quick Answer: What Is a Penetration Testing Statement of Work?

A penetration testing statement of work is a written planning and procurement document that defines the agreed work for an authorized security assessment. It explains the business objective, in-scope and out-of-scope assets, assumptions, constraints, buyer and provider responsibilities, testing windows, rules of engagement reference, written authorization requirement, deliverables, reporting format, data handling, retesting terms, timeline, and acceptance criteria. It should help all stakeholders understand what will be tested, what will not be tested, how testing will be controlled, what evidence will be delivered, and how the engagement will close. It is not a substitute for legal review or a permission-to-test letter.

Figure 1. Penetration testing SOW workflow from business objective through SOW approval, authorization, testing, reporting, retesting, and closure.

What Is a Penetration Testing Statement of Work?

A penetration testing statement of work is the agreed work plan for a security testing engagement. It connects the buyer’s business need with the provider’s testing activities and the final deliverables. In practice, it helps answer: what is being tested, why it is being tested, who is responsible for each dependency, when testing can occur, how results will be delivered, and what counts as completion.

The SOW is not the same as technical scope. Scope defines the authorized assets and boundaries. The SOW includes scope, but also covers responsibilities, deliverables, timeline, communication, data handling, retesting, and acceptance criteria. It is also not the same as an RFP, which is used before vendor selection, or the final report, which documents what was found after testing.

A strong SOW is especially important when production systems, regulated data, cloud accounts, third-party services, internal networks, identity systems, or social engineering are involved. It gives the buyer, provider, legal, procurement, and security teams a shared reference before any testing starts.

Why a Penetration Testing SOW Matters

A clear SOW reduces ambiguity. If the document only says “test our environment,” the provider may not know which assets are authorized, which systems are fragile, which credentials should be used, or how the final report will be judged. That creates cost, safety, and trust problems.

For buyers, the SOW supports procurement clarity, project governance, scope control, and audit evidence. For testing teams, it sets boundaries and dependencies so work can be performed safely and efficiently. For legal and compliance reviewers, it documents the intended work without turning the article itself into legal advice.

The value of a SOW is not paperwork. It is alignment. A good SOW helps prevent missed systems, unauthorized testing, unclear deliverables, open-ended retesting, unsafe production activity, weak evidence handling, and disputes over whether the engagement is complete.

SOW vs Scope vs RFP vs ROE vs MSA vs Authorization Letter vs Final Report

These documents often overlap, but they do different jobs. The SOW should reference related documents where needed instead of trying to replace them all.

Document	What It Defines	When It Is Used	Why It Matters
Statement of Work (SOW)	The agreed work plan: objective, scope summary, responsibilities, timeline, deliverables, retesting, acceptance criteria, and operational assumptions.	After vendor selection and before testing begins.	Turns the engagement into a clear buyer-provider work agreement.
Technical Scope	The exact assets, roles, environments, exclusions, and test boundaries.	During scoping and SOW preparation.	Prevents unauthorized testing and missed assets.
Request for Proposal (RFP)	The buyer’s requirements, evaluation criteria, and procurement questions.	Before vendor selection.	Helps compare providers and collect proposals.
Proposal / Quote	The provider’s response: approach, proposed scope, timeline, assumptions, and pricing basis.	During vendor evaluation.	Shows how the provider plans to meet the buyer’s need.
Master Services Agreement (MSA)	General commercial and legal terms between buyer and provider.	Before or alongside the SOW.	Keeps general legal terms separate from engagement-specific work.
NDA / Data Handling Agreement	Confidentiality and handling of sensitive information, evidence, credentials, source code, logs, and reports.	Before sensitive information is shared.	Protects data exchanged during scoping and testing.
Rules of Engagement (ROE)	Operational testing rules: allowed methods, prohibited actions, windows, escalation, rate limits, and stop conditions.	Before testing starts, often as SOW appendix.	Controls operational risk during authorized testing.
Authorization Letter	Written approval from the asset owner or authorized leadership to test defined assets under agreed boundaries.	Before any testing starts.	Helps establish that testing is authorized, scoped, and accountable.
Final Report	Findings, evidence, severity, impact, remediation guidance, and any agreed compliance mapping.	After testing.	Documents results and supports remediation decisions.
Retest Validation Summary	Whether agreed findings were remediated during the retest window.	After remediation, if retesting is included.	Supports closure without turning the retest into a new assessment.

Figure 2. Document comparison showing how RFP, proposal, SOW, ROE, authorization, and final report support different stages of a penetration testing engagement.

Pentest SOW Review Model

To make the article more useful than a generic template, review every penetration testing SOW across six layers: commercial agreement, authorized scope, operational safety, deliverables and evidence, retesting and closure, and compliance/procurement review. A SOW can look complete but still fail if one of these layers is vague.

Layer	What to Check	Common Failure
Commercial agreement	Objective, responsibilities, milestones, acceptance criteria, and change process.	The document lists services but does not define completion.
Authorized scope	Exact assets, exclusions, assumptions, environments, ownership, and third-party approvals.	“All systems” language creates overreach or gaps.
Operational safety	ROE reference, testing windows, blackout periods, rate limits, emergency stop, escalation contacts.	Testing is approved commercially but not safe operationally.
Deliverables and evidence	Report format, severity model, evidence rules, data handling, audience needs.	Buyer receives a generic report that does not support remediation or audit review.
Retesting and closure	Retest window, number of rounds, eligible findings, client evidence, closure criteria.	Retesting becomes open-ended or disputed.
Compliance and procurement review	Framework mapping, source verification, legal/procurement review, no guarantees.	SOW overclaims compliance or omits required evidence.

Figure 3. Pentest SOW Review Model: a six-layer framework for reviewing whether a penetration testing SOW is clear, safe, and procurement-ready.

What Should Be Included in a Penetration Testing SOW?

A comprehensive SOW should define the work in practical terms. The buyer should be able to read it and understand what systems are covered, what evidence will be delivered, what the provider needs from the client, and how scope changes will be handled.

SOW Section	What to Define	Why It Matters
Engagement objective	Business reason for the assessment: compliance evidence, product launch, breach-risk reduction, vendor assurance, M&A, cloud migration, or red team simulation.	Keeps the test aligned with business goals.
Scope summary	A plain-English summary of the in-scope test type and environment.	Frames detailed scope for non-technical stakeholders.
In-scope assets	Domains, URLs, IP ranges, API base URLs, cloud account IDs, mobile builds, internal ranges, AD domains, user roles, environments.	Prevents missed assets and unauthorized testing.
Out-of-scope assets	Excluded systems, third-party services, fragile infrastructure, customer tenants, production data, physical locations, or social engineering methods.	Protects systems that are not approved.
Assumptions	Conditions assumed true, such as working test accounts, asset ownership, environment stability, documentation availability, and whitelisting.	Identifies dependencies before delays occur.
Constraints	Rate limits, blackout windows, no DoS, no destructive changes, no real payment abuse, no unapproved phishing, no production data extraction.	Controls operational and legal risk.
Client responsibilities	Access provisioning, accounts, documentation, approvals, contacts, test data, infrastructure readiness.	Prevents project delays caused by missing inputs.
Provider responsibilities	Perform authorized testing, communicate issues, protect evidence, deliver agreed reports, follow ROE.	Clarifies expected professional conduct.
ROE reference	Where the operational testing rules are defined.	Connects the SOW to safe execution controls.
Written authorization	Testing should not begin without approval from the asset owner or authorized leadership.	Establishes authorized testing boundaries.
Deliverables	Executive summary, technical report, evidence, remediation guidance, compliance mapping, retest summary, closeout call if included.	Defines what the buyer receives.
Retesting	Included rounds, eligible findings, retest window, client evidence, output, expiry.	Prevents open-ended remediation disputes.
Data handling	How credentials, screenshots, logs, reports, source code, PII, PHI, cardholder data, secrets, and cloud exports are handled.	Protects sensitive evidence.
Timeline and milestones	Kickoff, access deadline, testing window, draft report, review, final report, retest, closeout.	Keeps expectations and dependencies visible.
Acceptance criteria	What must be delivered or accepted for project closure.	Defines completion without relying on vague expectations.
Change control	How new assets, additional testing, schedule changes, or retest extensions are approved.	Controls scope creep and budget impact.

Penetration Testing SOW Template

Use this SOW template as a planning framework, not as final legal language. Legal and procurement teams should adapt the final contract language to the organization’s policies and risk tolerance.

SOW Section	Example Language Direction	Notes
Project title	Name the engagement clearly, such as “External Web and API Penetration Test for ExampleCorp.”	Keep it short and specific.
Objective	State the business goal: pre-launch validation, compliance evidence, vendor assurance, cloud review, breach-risk reduction.	Avoid vague “test security” wording.
Background	Briefly describe relevant changes: new application, cloud migration, prior incident, audit cycle, acquisition, or architecture change.	Adds context without replacing methodology.
Scope summary	Summarize the test type and environment in one short paragraph.	Detailed assets should follow.
In-scope assets	List exact domains, IP ranges, apps, APIs, cloud accounts, mobile builds, roles, and environments.	Use asset IDs where possible.
Out-of-scope assets	List excluded systems and activities, including third-party services, DoS, social engineering, physical access, or production data extraction if not approved.	Do not rely on assumptions.
Assumptions	State buyer-provided inputs: accounts, MFA support, diagrams, API docs, test data, VPN access, whitelisting, cloud roles.	Assumptions should be testable.
Dependencies	Define what must be ready before testing begins.	Missing dependencies can pause the schedule.
Testing approach	Describe high-level authorized approach and references, such as NIST, OWASP, PTES, or cloud-provider policies where relevant.	Do not include exploit steps in the public article.
ROE reference	Reference an attached ROE or appendix covering allowed methods, prohibited actions, windows, contacts, stop conditions, and escalation.	ROE controls how testing occurs.
Written authorization	State that testing should not start until written authorization is approved by the asset owner or authorized leadership.	The SOW should not replace authorization.
Roles and responsibilities	Separate buyer duties from provider duties.	Prevents access and approval delays.
Testing windows	Define allowed dates, hours, blackout periods, and maintenance conflicts.	Protects production operations.
Data handling	Define evidence minimization, redaction, encrypted transfer, access controls, retention, and deletion.	Align with NDA and privacy requirements.
Deliverables	List executive summary, technical report, remediation guidance, compliance mapping, retest output, and presentation if included.	Do not promise unverified DeepStrike deliverables.
Reporting	Define format, severity model, review cycle, and delivery method.	Controls report quality expectations.
Retesting	Define included rounds, eligible findings, retest window, evidence needed, and output.	Avoid “retest if needed” ambiguity.
Timeline	List kickoff, access, test period, draft report, final report, retest, and closeout dates.	Tie milestones to dependencies.
Acceptance criteria	Define project completion: deliverables submitted, review completed, retesting delivered if included, or client acceptance.	Prevents open-ended closure.
Change management	Define written approval for new assets, schedule changes, or additional services.	Controls scope creep.
Compliance mapping	Define whether findings will be mapped to PCI DSS, SOC 2, ISO 27001, HIPAA, FedRAMP, GDPR, or cyber insurance evidence needs.	Use cautious wording and verify sources.

Scope, Assets, Exclusions, and Assumptions

The SOW should list assets with enough precision that the provider does not need to guess. Every unclear asset becomes a possible gap, delay, or authorization problem. The table below keeps the original article’s useful comparison structure while replacing vague examples with safer, publish-ready wording.

Item	Good SOW Example	Weak SOW Example	Risk
Web domains	app.example.com and admin.example.com in production; staging excluded unless separately approved.	Company web app	Missed apps or accidental testing of unrelated domains.
IP ranges	203.0.113.0/27 public perimeter range owned by the client.	External network	Scanning non-owned IPs or skipping real exposure.
API endpoints	api.example.com/v1 with OpenAPI specification and provided test tokens.	APIs	Hidden endpoints or authorization paths may be missed.
Cloud accounts	AWS account 123456789012 and Azure subscription ABC, regions listed in appendix.	Cloud resources	Unclear tenant boundaries and provider-policy risk.
Mobile apps	Android build 2.3 and iOS TestFlight build 5.1 with test accounts.	Mobile app	Wrong build, platform, or backend may be tested.
Environments	Production web app and staging API; development tenant excluded.	All environments	Testing unstable or unauthorized systems.
Active Directory	EXAMPLE.LOCAL domain with approved test account and listed domain controllers.	Domain controllers	Unsafe AD activity or incomplete identity coverage.
Third-party systems	Payment gateway sandbox approved; live gateway excluded.	Not mentioned	Vendor policy violations or accidental third-party testing.
Test accounts	Buyer provides standard user, admin, support, and API service-role accounts before kickoff.	Provider will create accounts	Delays or inaccurate business-logic testing.
Assumptions	Environment remains stable during the test; release freeze during active testing window.	No assumptions	Findings may be invalidated by unplanned changes.
Dependencies	Buyer provides VPN, allowlisting, architecture diagram, API docs, and test data by kickoff.	Access will be provided	Schedule slips and incomplete coverage.

Rules of Engagement and Written Authorization

Rules of engagement define how the approved testing can occur. The SOW may summarize or reference the ROE, but it should not replace a detailed ROE when operational risk is significant. Written authorization should be approved before testing starts and should align with the approved scope and ROE.

Written authorization helps establish that testing is approved by the asset owner and bounded by the agreed scope and rules of engagement. Avoid casual legal phrases. For a B2B cybersecurity article, use precise language: testing should be authorized, documented, time-bounded, and controlled.

ROE / Authorization Item	Should the SOW Mention It?	Why
Authorized targets	Yes	The SOW should list or reference exact assets approved for testing.
Allowed methods	Yes	Clarifies high-level testing categories without publishing operational exploit detail.
Prohibited actions	Yes	DoS, destructive changes, unapproved phishing, production data extraction, physical access, or password spraying may be excluded.
Testing windows	Yes	Keeps testing aligned with operational risk and business blackout periods.
Emergency stop	Yes	Defines who can pause testing and how escalation occurs.
Critical finding escalation	Yes	Prevents critical findings from waiting until final report delivery.
Data handling	Yes	Protects evidence such as screenshots, credentials, logs, and sensitive records.
Cloud and third-party approvals	Yes	Buyer approval may not authorize testing against vendor or cloud-provider systems.
Out-of-scope discovery	Yes	Defines what testers do if they discover an unlisted asset or dependency.
Authorization letter	Yes	Confirms that testing should not begin without written approval from the appropriate asset owner or authorized leadership.

Deliverables, Reporting, and Evidence

Deliverables should be defined before testing begins. A buyer should not accept a vague line item that says only “penetration test report.” The SOW should describe the audience, format, evidence expectations, severity model, remediation guidance, and any compliance mapping required.

Deliverable	Audience	SOW Detail to Define
Executive summary	Leadership, board, security management	Risk themes, business impact, top findings, remediation priorities, scope caveats.
Technical report	Security, engineering, DevOps, AppSec	Affected assets, evidence, impact, reproduction context, remediation guidance, severity.
Compliance mapping	Compliance, audit, GRC	Framework or control mapping where relevant, without implying full compliance.
Severity model	All stakeholders	CVSS or internal risk model, business impact adjustment, severity definitions.
Evidence package	Security and engineering	Screenshots, logs, request/response excerpts, configuration evidence, redaction rules.
Remediation tracker	Engineering, project owners	Finding ID, severity, owner, remediation status, due date, retest status.
Retest validation summary	Security, compliance, engineering	Which original findings were retested, result, date, evidence, unresolved items.
Closeout call	Mixed stakeholder group	Review scope, key findings, remediation priorities, and next steps if included.

Retesting and Remediation Validation

Retesting should be explicit. Buyers often assume remediation validation is included, while providers may treat it as a separate service. The SOW should define retesting before the report is delivered.

Retesting Term	Clear SOW Wording Direction	Common Risk
Included or separate	State whether retesting is included and under what conditions.	Buyer expects free validation that provider did not price.
Number of rounds	Define one or more agreed retest cycles, or state that retesting is separate.	Open-ended retesting creates disputes.
Eligible findings	Define whether all findings or only critical/high findings are included.	Low-risk issues consume retest time without agreement.
Retest window	Define the time period after final report or fix submission.	Fixes arrive months later and require a new assessment.
Client evidence	State what proof the client must provide before retesting begins.	Provider spends time validating unready fixes.
Retest boundary	Clarify that retesting validates original findings, not a full new penetration test.	Retest becomes uncontrolled new testing.
Output	Define whether the provider delivers an updated report, validation summary, or closure note.	Buyer lacks audit-ready evidence.
Failed fixes	State how unresolved findings are documented.	No shared understanding of closure.

Data Handling, Confidentiality, and Retention

A penetration testing SOW should address evidence handling because testing may expose credentials, PII, PHI, cardholder data, source code, internal architecture, cloud configuration exports, logs, and vulnerability details. The article should remain educational; exact retention and contractual language should be reviewed by legal and procurement.

Data Type	SOW / Data Handling Requirement	Risk if Missing
Credentials and test accounts	Secure transfer, restricted access, rotation or revocation after testing.	Stale accounts or leaked credentials remain usable.
PII, PHI, or cardholder data	Minimize collection, use test data where possible, redact evidence, encrypt reports.	Privacy, compliance, and trust risk.
Source code	Limit access, prevent unnecessary downloads, encrypt storage, define retention and deletion.	Intellectual property exposure.
Screenshots and logs	Mark as sensitive, redact secrets, control distribution.	Accidental disclosure of systems or data.
Cloud exports and secrets	Treat as sensitive credentials; encrypt, restrict, and delete according to agreement.	Cloud account compromise risk.
Reports	Deliver via secure channel or portal, restrict recipients, define retention.	Vulnerability details could be exposed.
Raw data	Only include if necessary and approved; define secure deletion.	Unnecessary storage of sensitive artifacts.

Roles, Responsibilities, and Communication

The SOW should make responsibilities visible. Many engagement delays come from missing accounts, unclear approvers, unavailable owners, or confusion between security, cloud, application, and procurement teams.

Role	Responsibility	Why It Matters
Client project owner	Owns schedule, approvals, access coordination, and sign-off.	Creates a single decision path.
Security owner	Defines objective, scope, severity expectations, escalation, and report needs.	Keeps testing tied to risk priorities.
Application owner	Provides app details, accounts, test data, business workflow context.	Improves authenticated and business-logic coverage.
Cloud / infrastructure owner	Provides account boundaries, access, network diagrams, provider-policy constraints.	Prevents cloud and network ambiguity.
SOC / incident contact	Knows testing window, handles alerts, receives urgent notifications.	Avoids confusing test activity with incidents.
Legal / procurement	Reviews contract terms, data handling, purchasing, and approval workflow.	Ensures the SOW fits policy and risk tolerance.
Provider lead	Coordinates testing team, communication, reporting, and escalation.	Creates accountability on delivery.
Communication channel	Shared channel, email thread, status call cadence, critical escalation path.	Reduces surprises during live testing.

Timeline, Milestones, and Acceptance Criteria

A SOW should tie schedule to dependencies. If access is late, test accounts fail, or the environment changes during testing, the timeline may need formal adjustment. This avoids turning delivery dates into unrealistic commitments.

Milestone	Dependency	Acceptance Criteria
Kickoff	SOW, stakeholders, and initial scope confirmed.	Project plan, communication path, and schedule agreed.
Access provisioning	Accounts, VPN, allowlisting, API docs, cloud roles, test data delivered.	Provider confirms access to in-scope assets.
Testing window	ROE and authorization approved.	Testing completed within approved windows and constraints.
Critical finding escalation	Emergency contacts and escalation rules available.	Urgent findings communicated according to SOW/ROE.
Draft report	Active testing complete.	Draft contains findings, evidence, severity, and remediation guidance.
Report review	Buyer reviews draft and submits corrections or context.	Agreed changes incorporated where appropriate.
Final report	Draft review complete.	Final deliverable matches SOW reporting expectations.
Retesting	Fixes submitted within agreed window.	Eligible original findings verified and documented.
Closeout	Deliverables complete.	Project accepted under agreed criteria.

How SOW Details Affect Cost, Timeline, and Quality

A SOW should explain cost drivers qualitatively without inventing prices. Scope size, technical complexity, role coverage, cloud boundaries, reporting depth, retesting, compliance mapping, data sensitivity, and time constraints all affect effort.

SOW Detail	Impact on Cost / Timeline	Quality Consideration
Asset count	More applications, APIs, hosts, and cloud resources require more tester time.	Too broad a scope can reduce depth.
User roles	Each role adds authentication, authorization, and workflow testing.	Role coverage is essential for access-control findings.
API complexity	Endpoint count, tenants, tokens, schemas, and abuse cases add effort.	Good documentation improves test quality.
Cloud complexity	Multiple accounts, IAM paths, containers, serverless, and CI/CD expand scope.	Cloud scope must respect provider and tenant boundaries.
Reporting depth	Executive, technical, compliance, and retest outputs require different work.	Good reporting improves remediation.
Retesting	Included retest rounds require reserved time after fixes.	Retesting improves closure confidence.
Testing windows	Narrow windows can extend the calendar.	Safety may require slower testing.
Compliance mapping	Framework mapping adds review and documentation effort.	Audit value improves when scope maps to evidence needs.
Red team / social engineering	Planning, approvals, HR/legal coordination, and stop rules add time.	Controls are necessary to avoid unsafe testing.

SOW Differences by Test Type

Test Type	SOW Details to Add	Common Mistake
Web application	URLs, domains, auth flows, user roles, admin areas, file uploads, payment flows, linked APIs, test data, rate limits.	Only listing the homepage or marketing domain.
API	Base URLs, endpoints, methods, OpenAPI/Postman docs, tokens, tenants, roles, schemas, rate limits, third-party integrations.	Saying “test the API” without endpoint inventory.
Cloud	AWS/Azure/GCP account IDs, subscriptions, projects, regions, IAM roles, services, provider-policy constraints, logging, storage, CI/CD.	Using “all cloud” without account boundaries.
External network	Public IP ranges, domains, exposed services, scan windows, fragile hosts, third-party hosting boundaries.	Unowned IPs or hosted systems are not verified.
Internal network / AD	Subnets, VPN access, AD domains, test accounts, domain controllers, segmentation, sensitive systems, credential handling.	Assuming all internal systems are safe to test.
Mobile	iOS/Android builds, devices, OS versions, accounts, backend APIs, local storage, rooted/jailbroken device policy.	Testing the wrong build or ignoring backend APIs.
Wireless	SSIDs, locations, APs, bands, encryption, time windows, physical boundaries.	Testing nearby networks or causing interference.
Red team	Objectives, allowed paths, target groups, duration, detection coordination, stop conditions, data handling.	Writing a vague “red team” SOW without success criteria.
Social engineering	Approved methods, target groups, volume, pretext review, HR/legal approvals, stop conditions.	Running social testing without explicit approval.
Compliance pentest	Audit boundary, control mapping, evidence requirements, retesting, report format.	Treating compliance testing like a generic pentest.
Continuous testing	Asset change triggers, cadence, retesting model, notification path, reporting periods.	New assets are added without scope governance.

Web Application Penetration Testing SOW

A web application SOW should list exact domains, URLs, authentication flows, user roles, admin areas, upload functions, payment paths, staging or production environment, linked APIs, test data, allowed methods, rate limits, and exclusions. It may reference OWASP WSTG or ASVS for coverage expectations, but the written scope still needs exact assets and roles. Avoid wording such as “test our website” because risk often lives behind login, in admin workflows, in file upload logic, or in API calls behind the user interface.

API Penetration Testing SOW

An API SOW should identify base URLs, endpoint inventory, HTTP methods, OpenAPI or Postman documentation, authentication mechanisms, tokens, roles, tenants, rate limits, schemas, abuse cases, and third-party integrations. REST, GraphQL, gRPC, and WebSocket APIs may require different inputs. The SOW should define test data and prohibit destructive production actions unless explicitly approved. OWASP API Top 10 can guide risk coverage, but it does not replace endpoint-level scope.

Cloud Penetration Testing SOW

A cloud SOW should define exact AWS accounts, Azure subscriptions, GCP projects, regions, IAM roles, storage, databases, serverless functions, containers, Kubernetes clusters, logging, key management, secrets, and CI/CD boundaries. It should state that testing must respect cloud-provider policies and tenant boundaries. Avoid claims about current cloud-provider rules unless verified immediately before publication because provider testing policies can change.

Network and Internal Penetration Testing SOW

Network SOWs should identify public IP ranges, internal subnets, VPN or onsite access, Active Directory domains, test accounts, segmentation boundaries, domain controllers, fragile systems, and prohibited actions. Internal testing can affect authentication, endpoints, file servers, and productivity, so the SOW should define credential handling, lockout safety, service scan limits, and emergency contacts.

Mobile Application Penetration Testing SOW

A mobile SOW should identify the exact iOS and Android builds, devices, OS versions, backend APIs, authentication flows, test accounts, local storage review, rooted or jailbroken device policy, third-party SDKs, and payment flows. If the mobile app relies on APIs, the SOW should align mobile and API scope so the assessment does not miss server-side authorization and data exposure paths.

Red Team and Social Engineering SOW

Red team SOWs should be objective-based and tightly governed. They should define goals, target groups, allowed techniques, prohibited techniques, HR/legal approvals, detection coordination, payload safety, data handling, stop conditions, and escalation. Do not include phishing templates, evasion steps, payloads, or operational abuse instructions in public content. Social engineering should never be treated as a casual add-on.

Compliance Penetration Testing SOW

Compliance-driven SOWs should map tested systems to audit boundaries and evidence needs. The wording should remain cautious: penetration testing can support security validation and audit evidence, but it does not automatically satisfy an entire framework, guarantee certification, or replace policy, governance, risk analysis, or remediation work.

Compliance Context	SOW Details to Define	Evidence to Preserve	Caveat
PCI DSS	Cardholder data environment, connected systems, segmentation where used, internal and external testing boundaries.	Asset list, network diagrams, report, segmentation evidence, retest evidence.	Verify current PCI DSS wording from PCI SSC. In PCI DSS v4.0, penetration testing is primarily associated with Requirement 11.4.
SOC 2	Systems supporting relevant Trust Services Criteria and customer-data environment.	Scope list, report date, tested systems, findings, remediation evidence.	SOC 2 does not impose one universal pentest requirement. Testing can support control evidence depending on control design and auditor expectations.
ISO 27001	Systems inside the ISMS scope and technical security review processes.	Risk treatment links, technical test evidence, remediation tracking.	Control references differ by ISO version. Avoid old control numbering unless the version is stated.
HIPAA	Systems that process or support ePHI, access controls, audit controls, transmission security, backup and incident workflows.	Risk analysis support, testing evidence, remediation records, safeguard review.	HIPAA does not universally name a penetration test cadence. Frame testing as support for risk analysis and security evaluation.
FedRAMP	Cloud service authorization boundary, testing rules, evidence needs, reporting expectations.	ROE, authorization boundary, final report, POA&M updates where applicable.	Verify current FedRAMP penetration test guidance and agency-specific requirements before publication.
GDPR Article 32	Systems processing EU personal data and technical controls for confidentiality, integrity, availability, and resilience.	Evidence of security testing, remediation, and technical control review.	Testing can support security diligence but does not guarantee GDPR compliance.
Cyber insurance	Externally exposed systems, identity controls, ransomware resilience, backup and incident response evidence.	Test report, remediation evidence, asset coverage, insurer-requested artifacts.	Policy wording varies. Do not claim testing guarantees coverage or approval.

Buyer Checklist: How to Review a Penetration Testing SOW

Review Question	Why It Matters	Owner
Is the business objective clear?	Aligns the assessment to risk, audit, launch, or procurement needs.	Security / procurement
Are assets listed exactly?	Prevents missed systems and unauthorized testing.	Security / engineering
Are exclusions explicit?	Protects third-party, fragile, or unapproved systems.	Security / legal
Are assumptions realistic?	Avoids hidden dependencies that delay testing.	Project owner
Are buyer responsibilities clear?	Ensures accounts, docs, access, and approvals are available.	Security / IT
Are provider responsibilities clear?	Defines expected work and communication.	Procurement / security
Is written authorization referenced?	Testing should not start without approved authorization.	Legal / security
Is ROE included or referenced?	Operational safety rules should be clear before testing.	Security operations
Are testing windows and blackout periods defined?	Protects production operations.	Operations
Are data handling rules clear?	Protects sensitive evidence.	Privacy / legal
Are deliverables defined?	Prevents generic or incomplete reporting.	Security / compliance
Is retesting defined?	Clarifies validation, rounds, windows, and closure.	Engineering / security
Are acceptance criteria included?	Defines project completion.	Procurement
Are third-party approvals identified?	Avoids vendor or cloud-provider policy issues.	Vendor management
Are compliance evidence needs mapped?	Supports audit review without overclaiming compliance.	GRC / audit
Is there a change process?	Controls added assets, dates, or deliverables.	Procurement
Has legal/procurement reviewed it?	Ensures final terms fit the organization’s policies.	Legal / procurement

Common SOW Mistakes

Mistake	Why It Hurts	Better Approach
Vague scope language	Creates gaps, overreach, and pricing disputes.	List exact assets, roles, environments, and exclusions.
“All systems” without asset list	Sounds broad but is not actionable.	Use a risk-based asset inventory.
No exclusions	Unsafe activities may be assumed allowed.	List prohibited actions clearly.
No written authorization reference	Testing may be commercially agreed but not formally approved by the asset owner.	Require written authorization before testing.
No ROE reference	Operational safety rules are unclear.	Attach or summarize ROE.
No data handling rules	Sensitive evidence may be mishandled.	Define minimization, redaction, retention, and deletion.
Unclear deliverables	Buyer may receive an unusable report.	Define report format, severity model, evidence, and remediation guidance.
No retesting terms	Fix validation becomes disputed.	Define rounds, window, eligible findings, and output.
Compliance overclaiming	Creates trust and legal risk.	Say testing supports evidence, not certification.
Using vendor boilerplate only	Misses company-specific risk, data, and procurement needs.	Review with security, legal, procurement, and compliance.
Under-scoping to reduce cost	Critical systems may be excluded.	Prioritize high-risk systems rather than arbitrary cuts.
Over-scoping without enough time	Coverage becomes shallow.	Phase the work or increase depth where risk is highest.

FAQs

What is a penetration testing statement of work?

A penetration testing statement of work is a written planning and procurement document for an authorized security assessment. It defines the business objective, scope, exclusions, responsibilities, deliverables, testing windows, data handling, retesting, and acceptance criteria before testing begins.

What does SOW mean in penetration testing?

SOW means Statement of Work. In penetration testing, it describes the agreed work for the engagement. It is broader than a technical scope because it also covers responsibilities, timeline, deliverables, assumptions, retesting, and completion criteria.

What should be included in a penetration testing SOW?

A SOW should include the objective, scope summary, in-scope assets, exclusions, assumptions, constraints, roles, testing windows, ROE reference, authorization requirement, deliverables, data handling, retesting, timeline, acceptance criteria, and change control process.

What is the difference between a SOW and penetration testing scope?

Scope defines the assets and boundaries that may be tested. The SOW includes scope, but also covers responsibilities, deliverables, schedule, assumptions, data handling, retesting, and acceptance criteria. Scope says what can be tested; the SOW defines the agreed work.

What is the difference between a SOW and rules of engagement?

Rules of engagement define how testing may occur, including allowed methods, prohibited actions, windows, escalation, and stop conditions. The SOW may reference the ROE, but also covers commercial and project delivery terms.

Is a penetration testing SOW the same as an RFP?

No. An RFP is a buyer document used to collect proposals before selecting a provider. A SOW is the work plan used after the provider and scope are agreed. The RFP can inform the SOW, but it is not the same document.

Does a SOW replace written authorization for penetration testing?

No. A SOW should reference written authorization, but testing should not begin until the asset owner or authorized leadership approves testing under the agreed scope and rules of engagement.

What deliverables should a penetration testing SOW define?

The SOW should define the executive summary, technical report, evidence expectations, severity model, remediation guidance, compliance mapping if needed, retest validation output, delivery format, and any closeout presentation or review call.

How should retesting be included in a SOW?

Retesting should define whether it is included, how many rounds are covered, which findings are eligible, the retest window, what evidence the client must provide, and whether the output is an updated report or validation summary.

How does a SOW affect penetration testing cost?

The SOW drives effort through asset count, complexity, user roles, API endpoints, cloud boundaries, reporting depth, compliance mapping, testing windows, and retesting. Clear scope helps prevent hidden assumptions and change orders.

What should a compliance penetration testing SOW include?

It should identify the relevant audit boundary, systems in scope, evidence needs, framework mapping, retesting expectations, and limitations. It should not say that a pentest alone guarantees compliance, certification, or audit approval.

Who should review a penetration testing SOW before signing?

Security, engineering, cloud or infrastructure owners, legal, procurement, finance, and compliance stakeholders should review the SOW. The final contract language should be approved by qualified legal and procurement teams.

Conclusion

A clear penetration testing statement of work helps security, engineering, procurement, legal, finance, and compliance teams agree on the work before testing begins. It defines the objective, authorized scope, exclusions, assumptions, rules of engagement reference, written authorization requirement, deliverables, data handling, retesting, timeline, and acceptance criteria.

The strongest SOWs are specific enough to guide real work but cautious enough to avoid unsafe or unsupported claims. Web applications, APIs, cloud environments, mobile apps, networks, internal identity systems, red team scenarios, and compliance-driven engagements each need different SOW details. A vague SOW can create missed risk, uncontrolled scope, unsafe production testing, weak reports, and procurement disputes.

DeepStrike can support authorized SOW discussions for web application, API, cloud, mobile, network, internal, red team, and compliance-supportive penetration testing. The final SOW should be reviewed by the organization’s legal, procurement, security, operations, and compliance stakeholders before signature and before any testing begins.

About the Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led red team and application security engagements across technology, finance, healthcare, cloud, and regulated environments. His work focuses on real-world attack path validation, application vulnerabilities, API security, cloud security, identity exposure, breach-risk reduction, and adversary emulation.

Penetration Testing SOW: Template, Checklist & Retesting Guide