Statement of Work (SOW) Template

A free statement of work template that attaches to a master service agreement and pins down the deliverables, milestones, acceptance criteria, and price for one specific project. Download in PDF or Word and fill in the bracketed fields.

Last updated: August 5, 2026

What Is a Statement of Work (SOW)?

A statement of work, usually shortened to SOW, is the document that describes exactly what is being built or delivered on a single engagement: the deliverables, the schedule, the assumptions, the acceptance criteria, and the price. It is almost always an attachment rather than a standalone contract. The master service agreement between the parties carries the legal terms that rarely change — confidentiality, liability, insurance, IP, governing law — and each SOW adds the project-specific detail on top of that foundation.

That split is what makes the model efficient. Once the MSA is negotiated, a new project needs only a short SOW rather than another full legal review, so work can start in days instead of weeks. The tradeoff is that a sloppy SOW inherits none of the protection people assume it has: if the deliverables are vague or the acceptance criteria are missing, the MSA cannot fix it. The precision has to live in this document.

When to Use This Template

  • You have a master service agreement in place and need to authorize a specific project under it
  • A project needs defined deliverables, milestones, and acceptance criteria before work starts
  • Multiple projects will run for the same client and each needs its own scope and budget
  • You need a change control process so scope additions are priced rather than absorbed
  • The client requires named resources, rates, or a not-to-exceed budget for approval
  • A previous project ended in a dispute about whether the work was actually finished

Received a contract like this to sign?

Don't guess what's in it. ScanContract's AI flags risky clauses in 60 seconds.

Analyze My Contract Free

Template Preview

Full text of the template. Fields in [BRACKETS] are placeholders you fill in.

Statement of Work (SOW)

  1. 1. 1. Statement of Work Identification

    This Statement of Work number [SOW NUMBER] (this "SOW") is entered into as of [SOW EFFECTIVE DATE] between [PROVIDER NAME] (the "Provider") and [CLIENT NAME] (the "Client"). This SOW is issued under and governed by the Master Service Agreement between the Parties dated [MSA DATE] (the "MSA"). All capitalized terms not defined in this SOW have the meanings given to them in the MSA. This SOW becomes effective only when signed by an authorized representative of both Parties, and it does not alter the MSA except as expressly stated in Section 13.

  2. 2. 2. Project Background and Objectives

    The Client has engaged the Provider to address the following business need: [BUSINESS BACKGROUND AND PROBLEM STATEMENT]. The objectives of this project are: [OBJECTIVE 1], [OBJECTIVE 2], and [OBJECTIVE 3]. Success will be evaluated against the acceptance criteria in Section 6 rather than against business results that depend on factors outside the control of the Provider. This section is included for context and does not expand the scope of work described in Section 3.

  3. 3. 3. Scope of Work

    The Provider will perform the following work: [DETAILED SCOPE OF WORK, described as discrete activities such as discovery, design, build, integration, testing, training, and handover]. The work will be performed at [WORK LOCATION, e.g., remotely, at Client facilities, or a combination] during [WORKING HOURS AND TIME ZONE]. The following items are expressly out of scope and are not included in the price in Section 8: [OUT OF SCOPE ITEMS, e.g., data migration from legacy systems, third-party license fees, ongoing support after handover, content creation, hardware procurement]. Any work not described in this section is additional work and requires a change order under Section 9 before it is performed.

  4. 4. 4. Deliverables

    The Provider will produce the following deliverables: [DELIVERABLE 1 — description, format, and quantity], [DELIVERABLE 2 — description, format, and quantity], and [DELIVERABLE 3 — description, format, and quantity]. Each deliverable will be provided in [FILE FORMATS AND MEDIA] and delivered through [DELIVERY METHOD, e.g., shared repository, secure file transfer, printed copies]. Documentation accompanying the deliverables will include [DOCUMENTATION SCOPE, e.g., technical specifications, admin guide, source files, credentials handover]. Anything not listed in this section is not a deliverable under this SOW.

  5. 5. 5. Milestones and Schedule

    The estimated project schedule is as follows: kickoff on [KICKOFF DATE]; [MILESTONE 1] due [DATE 1]; [MILESTONE 2] due [DATE 2]; [MILESTONE 3] due [DATE 3]; and final delivery by [FINAL DELIVERY DATE]. The schedule assumes that the Client meets the responsibilities in Section 7 and that no more than [ASSUMED REVISION ROUNDS] rounds of feedback are required at each review point. Delays caused by the Client, by third parties under the control of the Client, or by change orders extend the remaining schedule day for day at a minimum, and the Provider will provide a revised schedule in writing. Neither Party is responsible for schedule impacts caused by events outside its reasonable control as described in the MSA.

  6. 6. 6. Acceptance Criteria and Testing

    Each deliverable will be measured against the following acceptance criteria: [ACCEPTANCE CRITERIA, stated as objective, testable conditions such as functional requirements met, performance thresholds achieved, documents complete against an agreed outline]. The Client will review each deliverable and provide written acceptance or a written list of specific deficiencies within [ACCEPTANCE PERIOD, e.g., 10 business days] of delivery. If the Client does not respond within that period, the deliverable is deemed accepted. If deficiencies are identified, the Provider will correct those that fall within the agreed acceptance criteria at no additional charge within [CORRECTION PERIOD, e.g., 10 business days] and resubmit for a further review period of [RE-REVIEW PERIOD, e.g., five business days]. Requests that go beyond the acceptance criteria are handled as change orders rather than corrections, and deemed acceptance applies to any deliverable put into production use by the Client.

  7. 7. 7. Client Responsibilities and Dependencies

    The Client will provide the following in support of the project: [CLIENT DEPENDENCIES, e.g., system access and credentials, environment provisioning, subject matter experts, content and brand assets, test data, third-party vendor coordination]. The Client will designate [CLIENT PROJECT MANAGER] as the single point of contact with authority to approve deliverables and change orders, and will provide decisions and approvals within [CLIENT RESPONSE WINDOW, e.g., three business days] of request. The Client is responsible for the accuracy and legality of all materials, data, and instructions it supplies. Where a Client dependency is late, the Provider may reallocate assigned personnel and may charge documented standby time at [STANDBY RATE] after [STANDBY GRACE PERIOD].

  8. 8. 8. Pricing, Payment Schedule, and Not-to-Exceed Budget

    The price for the work in this SOW is [PRICING BASIS — FIXED FEE of AMOUNT / TIME AND MATERIALS at the rates in Section 10 with a not-to-exceed amount of AMOUNT / MILESTONE-BASED as set out below]. Payment is scheduled as follows: [PAYMENT 1 AMOUNT] on execution of this SOW, [PAYMENT 2 AMOUNT] on acceptance of [MILESTONE], and the balance of [FINAL PAYMENT AMOUNT] on final acceptance. Where the engagement is time and materials, the Provider will notify the Client in writing when incurred fees reach [BUDGET ALERT THRESHOLD, e.g., 80 percent] of the not-to-exceed amount and will not exceed that amount without a signed change order. Invoicing and payment terms, late charges, and dispute procedures are governed by the MSA. Reimbursable expenses are limited to [EXPENSE BUDGET] and require prior written approval.

  9. 9. 9. Change Control

    Either Party may request a change to the scope, deliverables, schedule, or price of this SOW by submitting a written change request describing the change and the reason for it. The Provider will respond within [CHANGE RESPONSE PERIOD, e.g., five business days] with an assessment of the impact on scope, schedule, price, and resources. No change is binding until a written change order is signed by an authorized representative of both Parties, and the Provider will continue performing the existing scope while a change request is pending. Verbal approvals, email requests, and instructions given directly to project personnel do not authorize additional work or additional cost. Each signed change order becomes part of this SOW.

  10. 10. 10. Project Team, Rates, and Key Personnel

    The Provider will staff the project with the following roles: [ROLE 1] at [RATE 1] per hour, [ROLE 2] at [RATE 2] per hour, and [ROLE 3] at [RATE 3] per hour. The following individuals are designated key personnel and will not be removed from the project without [KEY PERSONNEL NOTICE, e.g., 10 business days] written notice and a proposed replacement of comparable skill: [KEY PERSONNEL NAMES AND ROLES]. The Provider may use subcontractors consistent with the MSA and remains fully responsible for their work and their compliance with this SOW. Rates in this SOW are fixed for the duration of the project unless extended by change order beyond [RATE VALIDITY DATE].

  11. 11. 11. Assumptions and Constraints

    This SOW is based on the following assumptions: [ASSUMPTION 1, e.g., existing systems are documented and accessible]; [ASSUMPTION 2, e.g., a single production environment and one staging environment]; [ASSUMPTION 3, e.g., third-party APIs remain available and unchanged during the project]; and [ASSUMPTION 4, e.g., all content is provided by the Client in final form]. If any assumption proves incorrect, the affected work is subject to change control under Section 9. Known constraints include [CONSTRAINTS, e.g., regulatory review windows, freeze periods, hardware lead times]. The Provider is not responsible for delays or defects arising from third-party products, services, or infrastructure not supplied by the Provider.

  12. 12. 12. Project Completion and Warranty Period

    This SOW is complete when the final deliverable has been accepted under Section 6 and all amounts due have been paid. Following final acceptance, the Provider will correct defects in the delivered work that are reported in writing within [WARRANTY PERIOD, e.g., 30 days] and that cause the deliverable to fail the acceptance criteria, at no additional charge. The warranty does not cover issues caused by modification of the deliverable by the Client or a third party, use outside the documented purpose, changes in third-party systems, or normal maintenance and enhancement requests. Ongoing support, maintenance, or enhancements after the warranty period require a separate SOW or support agreement. Handover materials, credentials, and documentation listed in Section 4 will be transferred at completion.

  13. 13. 13. Relationship to the Master Service Agreement

    This SOW is subject in all respects to the terms of the MSA, including its provisions on confidentiality, intellectual property ownership, warranties, insurance, limitation of liability, indemnification, and governing law. In the event of a conflict, the MSA controls except where this SOW expressly states that a specific provision is being modified for this project only and identifies the MSA section being modified. Termination of the MSA terminates this SOW unless the Parties agree in writing to complete the project under the surviving terms. This SOW may be terminated on its own under the termination provisions of the MSA, in which case the Client will pay for all work performed and approved expenses incurred through the termination date.

  14. 14. 14. Signatures

    By signing below, the Parties authorize the work described in this Statement of Work under the terms of the Master Service Agreement identified in Section 1. PROVIDER: [PROVIDER NAME]. Signature: ______________________. Printed Name: [PROVIDER SIGNER NAME]. Title: [TITLE]. Date: [DATE]. CLIENT: [CLIENT NAME]. Signature: ______________________. Printed Name: [CLIENT SIGNER NAME]. Title: [TITLE]. Date: [DATE]. This SOW may be executed in counterparts, and electronic signatures have the same effect as original signatures.

  15. 15. Disclaimer

    This template is provided for general informational purposes only and is not legal advice. A statement of work depends on the master agreement it sits under, and using this document without a governing agreement leaves important terms such as liability, insurance, and intellectual property undefined. Review and adapt this language for your own project and contract structure, and consult a licensed attorney before relying on it for a significant engagement. Use of this template does not create an attorney-client relationship with ScanContract.

Key Clauses Explained

What each important clause does — and what to watch out for before you sign.

Scope of Work and Out-of-Scope List

Describes the activities included in the project and names what is deliberately excluded.

The exclusion list does more work than the inclusion list. Providers should name the expensive assumptions people make by default — data migration, content creation, third-party licenses, post-launch support. Clients should read that list carefully, because anything on it will arrive later as a separate invoice rather than as part of the quoted price.

Acceptance Criteria

Defines objectively when a deliverable is finished and starts the review clock.

Criteria like "to the satisfaction of the Client" are unenforceable in practice and guarantee a fight. Both sides benefit from testable conditions. Clients should note the deemed-acceptance rule, since silence past the review window counts as approval, and providers should make sure putting a deliverable into production also counts as acceptance.

Milestones and Schedule Assumptions

Sets the dates and states what the timeline depends on from the client side.

A schedule without dependencies attached is a promise the provider cannot keep alone. Providers should tie every date to the client responsibilities section and preserve day-for-day extensions. Clients should confirm that a slipped date on their side extends the schedule rather than triggering standby charges immediately.

Change Control

Requires a signed change order before scope, price, or schedule can move.

The important sentence is the one saying verbal requests and messages to project staff do not authorize work. Without it, providers do unpaid work and clients receive surprise invoices. Clients should make sure change requests get a written impact assessment before approval, not a lump sum after the fact.

Not-to-Exceed Budget

Caps time-and-materials spend and requires an alert as the cap approaches.

Clients should treat the not-to-exceed number as a hard ceiling and check that the eighty percent alert is a contractual obligation rather than a courtesy. Providers should make sure hitting the cap stops work rather than forcing them to finish the scope for free, which is exactly how a not-to-exceed clause turns into a fixed price by accident.

Key Personnel

Names the individuals the client is relying on and controls how they can be replaced.

Clients buying a specific team should name them here, since otherwise the senior people who ran the pitch can be swapped for juniors on day one. Providers should keep replacement flexibility for illness, resignation, and reassignment, and make sure the obligation is comparable skill rather than an identical person.

Assumptions

Lists the conditions the price and schedule were built on and routes exceptions to change control.

This is the provider main defense against a project that turns out to be twice the job it looked like. Write the assumptions that would actually break the estimate, not generic filler. Clients should challenge assumptions that are obviously wrong at signing rather than discovering them in a change order later.

Relationship to the MSA

Confirms the SOW inherits the legal terms of the master agreement and sets the conflict order.

If a SOW silently changes a liability cap or IP term, it can be unenforceable or ignored depending on how the MSA is drafted. Any intended override should name the exact MSA section being modified and say it applies to this project only. Never sign a SOW that references an MSA nobody can locate.

Frequently Asked Questions

What is the difference between a statement of work and a master service agreement?
The master service agreement carries the legal terms that stay the same across every project — confidentiality, IP ownership, liability caps, insurance, indemnification, governing law. The statement of work carries the project-specific detail — deliverables, milestones, acceptance criteria, price, and assumptions. The MSA is signed once, and each new project gets its own SOW attached to it.
Can a statement of work stand on its own without an MSA?
It can, but then it has to carry the full legal terms itself, which makes it a services agreement rather than a true SOW. If you use this template without a master agreement in place, add the missing provisions on confidentiality, IP ownership, warranties, liability limits, and governing law, or use a consulting or independent contractor agreement instead. Signing a SOW that references an MSA nobody can produce is the worst of both options.
What makes acceptance criteria good?
They have to be objective enough that a third party could apply them without asking either side what they meant. Functional requirements met, a performance threshold hit, a document complete against an agreed outline. Vague language like satisfactory quality shifts the decision to whoever is more stubborn. Pair the criteria with a review window and a deemed-acceptance rule so a project cannot stall in permanent review.
How do change orders work under a SOW?
Either party submits a written change request, the provider assesses the impact on scope, schedule, and price, and nothing changes until both sides sign a change order. Work continues on the existing scope while the request is pending. The clause that matters most is the one stating that verbal approvals and messages to project staff do not authorize extra work, because that is where unbilled scope creep usually begins.
Should a SOW be fixed price or time and materials?
Fixed price suits well-defined work where the deliverables and assumptions are clear, and it puts estimation risk on the provider. Time and materials suits discovery, research, and evolving scope, and it puts budget risk on the client, which is why a not-to-exceed cap with an alert threshold is standard. Many SOWs mix the two, fixing the price for defined phases and running exploratory work on a capped hourly basis.

Related Templates

Downloaded a template? Analyze the final contract.

Before you sign, let ScanContract's AI check for risky clauses and missing protections.

Scan My Contract