SOW checklist: what belongs in the Statement of Work vs the MSA

The most common mistake in a statement of work isn't what it contains. It's what it duplicates. A SOW drafted by someone who has never read the governing MSA tends to grow over time — picking up confidentiality language, liability carve-outs, and payment terms that already exist one layer up. The result is a document that is both longer than it needs to be and in constant tension with the MSA sitting above it.

A clean statement of work checklist starts from the opposite assumption: the MSA handles the legal chassis, the SOW handles the engagement. Anything in the MSA that applies to this engagement should stay in the MSA. Anything specific to this engagement — scope, deliverables, price, timeline, acceptance — belongs in the SOW and nowhere else. The test for every paragraph in a draft SOW is the same: would this sentence apply to every future engagement with this vendor, or only to this one? If the former, it probably belongs in the MSA. If the latter, the SOW is the right home.

This is a practical statement of work checklist covering what to include, what to leave upstream in the MSA, and the handful of places where the two documents genuinely need to coordinate. The framing assumes a standard US-market MSA/SOW pair, but the principles apply regardless of jurisdiction.

What belongs in the SOW

The SOW is the engagement-specific document. A well-drafted SOW answers six questions and stops:

1. What is being delivered

A specific, testable description of the work product. Not "a website redesign" — that's a brochure. "A redesigned marketing website with thirty content pages, two interactive tools, a CMS migration from WordPress to Contentful, and updated SEO metadata on all migrated URLs" is closer to a deliverable definition.

The statement of work checklist item here is: can a third party read the description and determine whether the vendor has done what they promised? If the answer is no, the deliverable is too vague, and disputes at acceptance become inevitable.

2. How it will be delivered

The approach, methodology, and working assumptions. This is where the SOW describes sprints or phases, weekly check-ins, status reporting cadence, and which team members will do the work. It is also where the assumptions live — the things the vendor is assuming about the customer's environment, availability, and contributions.

Assumptions matter because they define the boundary of "in scope." An assumption like "Customer will provide access to the production database within 5 business days of kickoff" isn't a polite aside — it's the trigger for a scope change or timeline adjustment if the access doesn't arrive.

3. When it will be delivered

The timeline, milestones, and any dependencies between them. A good SOW distinguishes between hard dates (tied to a customer event, regulatory deadline, or external trigger) and soft dates (best estimates that can slip without consequence). Milestone language should make clear whether a slip on one milestone pushes subsequent ones, and whether missed milestones trigger anything — credits, re-plans, or termination rights.

4. What it will cost

Fees, payment schedule, and how overages are handled. The three common structures:

• Fixed fee. A single number for the entire SOW, usually paid in milestones. Appropriate when scope is well-defined.
• Time and materials. Hourly or daily rates with a not-to-exceed cap. Appropriate when scope is exploratory.
• Hybrid. Fixed fee for defined deliverables plus T&M for additional work above a threshold.

Payment schedule detail matters: what triggers each payment (delivery, acceptance, calendar date), what the invoice cadence is, and whether there is a deposit or retainer. The MSA usually sets default payment terms (net-30 is typical); the SOW can override them but only if it does so explicitly by citing the MSA clause being modified.

5. How it will be accepted

Acceptance criteria are often the weakest part of a weak SOW. Good acceptance language specifies:

• Who has authority to accept (named role or individual).
• When acceptance is deemed complete (on written sign-off, after a review period, after a defined test).
• What happens if rejection occurs (cure period, revised delivery, escalation path).
• Timeout behavior — if the customer doesn't respond within some number of days, is the deliverable deemed accepted?

A statement of work checklist without explicit acceptance criteria usually ends in an argument. The question "did the vendor do what they promised" needs a process-based answer, not a subjective one.

6. What happens if things change

Change control procedures. Who can request a change, who must approve it, and in what form. Most MSAs already contain a change order requirement; the SOW reiterates it with engagement-specific detail — for example, naming the specific individuals on each side who can sign change orders.

What does not belong in the SOW

Everything that applies to the relationship rather than this specific engagement should stay in the MSA. A statement of work checklist that keeps growing is usually growing in the wrong direction.

Confidentiality language

The MSA almost certainly has a confidentiality section. Duplicating it in the SOW — especially with slightly different wording — creates interpretive ambiguity. If the engagement genuinely requires different confidentiality treatment (heightened obligations for sensitive data, for example), the SOW should reference the MSA's confidentiality clause by number and modify it explicitly, not restate it.

Liability caps and carve-outs

The MSA sets the liability cap. A SOW that tries to lower the cap on the customer's side or carve out certain obligations is attempting something that may or may not work depending on MSA language. Some MSAs explicitly allow SOW-level liability modifications; many prohibit them. Writing a liability clause into a SOW without checking the MSA is how contradictions happen.

IP assignment language

IP ownership is set at the MSA level. The SOW can describe what specific work product is being created, but the assignment mechanics — who owns what, which licenses are granted, what exceptions apply for pre-existing IP — should already be handled upstream. Restating IP language in the SOW creates the same ambiguity problem as restating confidentiality language.

Warranties

Standard service warranties (workmanlike performance, non-infringement) live in the MSA. Engagement-specific warranties — for example, that a delivered software module will perform a specific function — can live in the SOW, but should be framed as specifications or acceptance criteria rather than standalone warranty language.

Indemnification

Indemnification obligations are mutual and apply across all engagements. They belong in the MSA. SOW-level indemnification is almost always either duplicative or contradictory.

Insurance requirements

The MSA typically specifies the insurance the vendor must carry. If a particular engagement requires additional coverage (for example, higher cyber liability limits for a data-sensitive project), the SOW can require a rider, but the base obligation lives in the MSA.

Termination rights

Termination of the MSA and termination of a specific SOW are different events. The MSA handles MSA-level termination. Whether a specific SOW can be terminated early — and on what terms — is engagement-specific and belongs in the SOW, but the default termination rights should live upstream.

Where the two documents need to coordinate

A few places require explicit coordination between the MSA and the SOW, and a good statement of work checklist makes sure none of them are silent:

• SOW references the MSA by version and date. If the MSA is amended later, it should be clear which version governs any SOW in flight.
• Payment term overrides are explicit. If the SOW sets a different payment cadence than the MSA, the SOW should name the MSA section being modified.
• Acceptance criteria reference the MSA's deemed-acceptance rule. Most MSAs have a default rule — often "deemed accepted 15 days after delivery absent written rejection." The SOW should either adopt the default or explicitly replace it.
• Change order process points back to the MSA. Rather than creating a new change order mechanism, the SOW should reference the MSA's existing process.

A few practical drafting patterns

• Use a consistent SOW template. Drift between SOWs is how inconsistency accumulates. A single template, reviewed against the MSA periodically, catches problems before they spread.
• Keep the SOW short. Most well-drafted SOWs fit on three to six pages for modest engagements. Anything longer usually contains material that belongs in the MSA.
• Number paragraphs. When a conflict arises, referencing "Section 3.2 of the SOW dated March 14" is materially easier than pointing at the third paragraph on page two.
• Attach exhibits for detail. Long lists of deliverables, technical specifications, or acceptance test plans should be exhibits to the SOW, not embedded in the main body. This keeps the SOW itself readable and makes updates easier.
• Do a read-together review. Before signing, read the MSA and the SOW in sequence, looking specifically for duplicated or contradicting language. This takes under an hour and catches most issues.

The bottom line

A statement of work checklist is really a checklist of what to leave out. The MSA already handles confidentiality, IP, liability, indemnification, and termination. The SOW's job is to describe this specific engagement — what, how, when, for how much, and under what acceptance criteria — and to stay out of the upstream legal architecture. SOWs that drift tend to grow. SOWs that stay clean tend to stay short, which also tends to make them easier to negotiate, easier to sign, and easier to enforce.