What is a statement of work?
A statement of work (SOW) is the document that defines one specific engagement between a customer and a provider: what will be done, what will be delivered, when, by whom, how the result will be accepted and what it will cost. It usually sits under a master service agreement and inherits that contract's legal terms, so the SOW can concentrate on the work itself. Some organizations call it a work order or a task order, and "scope of work" is often used for the scope section inside it.
What goes in a SOW
- Scope: what is included and, just as important, what is explicitly excluded
- Deliverables: the reports, systems, configurations or services the provider must hand over
- Schedule and milestones: start and end dates and the checkpoints between them
- Roles and staffing: who on each side is responsible, and any named key personnel
- Acceptance criteria: how the customer decides a deliverable is complete
- Assumptions and dependencies: what the customer must provide, such as access, test accounts or a maintenance window
- Price and payment: a fixed fee, time and materials, or payments tied to milestones
Example: a penetration test SOW
| Section | Entry |
|---|---|
| Scope | External network 198.51.100.0/26; customer web portal and its API |
| Exclusions | Social engineering, denial of service, the third-party hosted payroll system |
| Dates | Testing March 9 to March 20; draft report by March 27 |
| Deliverables | Executive summary; technical report with CVSS-rated findings and reproduction steps; one retest within 60 days |
| Acceptance | Customer approves the final report after a readout meeting |
| Price | Fixed fee, half at kickoff and half on acceptance |
| Testing conduct | Governed by the separately signed rules of engagement |
Why a precise SOW is a security control
Vague scope causes two kinds of security failure. Testers or administrators may touch systems nobody authorized, because the SOW said "the network" instead of listing address ranges and applications. Or a task falls between the parties: a migration SOW that never mentions decommissioning the old server leaves a forgotten, unpatched system online. Clear exclusions, named responsibilities and acceptance criteria that include security checks, such as a vulnerability scan before go-live, prevent both. Changes go through a written change order rather than an email, so the scope on file always matches the work being done.
SOW vs. MSA vs. rules of engagement
- SOW: one project's scope, deliverables, schedule and price.
- MSA: the standing legal terms, such as liability, confidentiality and governing law, that every SOW inherits.
- Rules of engagement: for a security test, the operational limits on how testers may work, including permitted techniques, testing windows, contacts and stop conditions. A penetration test SOW normally points to them.
Statement of work on the CompTIA Security+ exam
SY0-801 lists the SOW among the agreements in objective 5.3, which covers managing third-party risk. Scenario wording such as "define the scope, deliverables and timeline of this engagement" or "a specific project under an existing contract" points to a SOW. The MSA is the main distractor: it sets the terms for all work, while the SOW defines one job. Rules of engagement are the distractor in penetration testing questions; if the question is about how testers must behave during the test rather than what the customer is buying, choose the rules of engagement. An SLA fits only when the question is about ongoing service levels.