If you've ever signed a big vendor deal, you've probably seen two documents instead of one — a Master Service Agreement and a Statement of Work — and wondered why the lawyers couldn't just combine them. They're kept separate on purpose, and understanding why saves you from renegotiating legal terms every time you start a new project. The MSA sets the rules of the relationship once; the SOW defines each specific job. Get the split right and you can launch projects fast while keeping your legal protections locked in. Here's how the two fit together.
Quick answer: A Master Service Agreement (MSA) is the umbrella contract setting the legal and commercial terms that govern an ongoing relationship — liability, IP, confidentiality, payment terms, dispute resolution. A Statement of Work (SOW) sits under the MSA and defines a specific project: scope, deliverables, timeline, and price. You sign the MSA once, then issue a new SOW for each engagement — so new projects don't require renegotiating the heavy legal terms.
What is a Master Service Agreement (MSA)?
An MSA is the foundational contract between two parties who expect to do business repeatedly. It nails down the terms that should stay constant across every project: payment and invoicing rules, intellectual property ownership, confidentiality, warranties, limitation of liability, indemnity, insurance, term and termination, and dispute resolution. Once signed, these terms apply to everything that follows — you negotiate them once, not every time.
What is a Statement of Work (SOW)?
An SOW is a project-specific document executed under an existing MSA. It covers the operational detail of a particular engagement: the scope of work and deliverables, the timeline and milestones, the acceptance criteria, the specific fees for that project, and any project-specific assumptions or dependencies. Each new project gets its own SOW, while inheriting all the legal protections of the MSA.
How they work together
Think of it as a hub and spokes. The MSA is the hub — signed once, carrying the legal terms. Each SOW is a spoke — a quick document defining one project, referencing the MSA and incorporating its terms. So when a client wants a second or third project, you don't reopen liability and IP negotiations; you just issue a new SOW. The MSA usually includes a clause stating that its terms govern, and that in any conflict, the MSA controls (or, sometimes, that the SOW controls for project-specific points) — define that order of precedence clearly.
What goes in which document
| In the MSA (once) | In each SOW (per project) |
|---|---|
| Payment and invoicing rules | Specific project fees and schedule |
| IP ownership framework | Project deliverables and ownership specifics |
| Confidentiality | Project assumptions and dependencies |
| Liability cap and indemnity | Scope of work |
| Warranties and insurance | Timeline and milestones |
| Term and termination | Acceptance criteria |
| Dispute resolution and governing law | Project personnel/contacts |
Why separate them at all?
Speed and consistency. Negotiating an MSA is slow because it's where the hard legal terms live. Once it's done, launching a new project is fast — a short SOW, signed in a day. It also keeps the relationship consistent: the same liability cap, IP rules, and dispute clause apply to every project, so nothing slips through when teams are moving quickly. For agencies, consultancies, and software vendors with repeat clients, the MSA-plus-SOW structure is the efficient standard.
Worked example
A software development firm signs an MSA with an enterprise client covering payment terms (net 30), IP (client owns custom code on payment; vendor keeps its libraries), a liability cap, confidentiality, and arbitration. Over the next year the client commissions three projects — a mobile app, an analytics dashboard, and an integration — each launched with a one-page SOW specifying that project's scope, milestones, and price, all referencing the MSA. Three projects, three quick SOWs, zero renegotiation of the legal terms. When a dispute arises on the dashboard project, the MSA's liability cap and arbitration clause apply automatically.
Common mistakes
- Putting project scope in the MSA, making it rigid and forcing renegotiation.
- Putting legal terms in the SOW, so they vary inconsistently per project.
- No order-of-precedence clause, creating conflicts between the two.
- An SOW that doesn't reference the MSA, leaving it without the legal terms.
- Vague SOW scope, the same trap as any service agreement.
Checklist
- Put durable legal terms (liability, IP, confidentiality, disputes) in the MSA.
- Put project-specific scope, timeline, and price in each SOW.
- Reference the MSA in every SOW and incorporate its terms.
- Add a clear order-of-precedence clause.
- Keep the SOW scope specific, with acceptance criteria.
- Sign the MSA once; issue a fresh SOW per project.
Frequently asked questions
What's the difference between an MSA and an SOW? An MSA sets the legal and commercial terms of an ongoing relationship; an SOW defines a specific project's scope, timeline, and price under that MSA.
Do I sign a new MSA for every project? No. You sign the MSA once and issue a new SOW for each project, which inherits the MSA's terms.
Which document controls if they conflict? Whatever the order-of-precedence clause says — commonly the MSA governs, with SOWs controlling only on defined project specifics.
Can I just use one combined contract? You can for a one-off engagement, but for repeat work the MSA-plus-SOW structure is faster and more consistent.
What must an SOW include? Scope, deliverables, timeline/milestones, acceptance criteria, and project-specific fees, while referencing the MSA.
This article is for legal awareness and education only and is not legal advice. Contract structures should fit the engagement; consult a qualified advocate before finalising an MSA or SOW.