Master Services Agreements and Statements of Work: How the Two-Document Structure Protects Both Sides

By Hank FasthoffJuly 6, 2026

A company that hires the same IT vendor for five separate projects over two years can negotiate five full contracts, each covering the same indemnification, limitation of liability, IP ownership, confidentiality, and dispute resolution provisions. Or it can negotiate one master services agreement (MSA) that establishes those terms once, and then sign five focused statements of work (SOWs) that cover only the scope, deliverables, timeline, and pricing for each project.

MSAs exist because most of a commercial contract's provisions don't change from project to project. Indemnification, liability caps, insurance requirements, governing law, confidentiality, and termination rights are negotiated based on the relationship between the parties, not the specifics of any individual engagement. Renegotiating those terms every time a new project starts wastes time and legal fees, introduces the risk of inconsistent provisions across contracts, and delays project kickoff while lawyers redline boilerplate.

Separating the relationship terms (the MSA) from the project terms (the SOW) lets the legal team negotiate once and the business team execute repeatedly. Each new SOW incorporates the MSA's terms by reference, so the SOW can remain short and focused on what's changing rather than restating what's already been agreed.

What Goes in the MSA

An MSA should contain every provision that applies across all engagements under the relationship, regardless of the specific work being performed. These are the terms the parties negotiate at the beginning of the relationship and expect to remain constant.

Scope of relationship defines the general categories of services the provider will offer. It doesn't describe any specific project (that's the SOW's job), but it establishes the boundaries of the relationship. "Provider will perform information technology consulting, software development, and related professional services for Client as described in individually executed Statements of Work."

Payment terms establish how invoices are submitted, when payment is due, how disputed invoices are handled, and what happens when payment is late. Standardizing payment terms in the MSA prevents each SOW from becoming a negotiation over billing mechanics. The SOW specifies the pricing and fee structure for each project. The MSA specifies how and when those fees are billed and collected.

Intellectual property ownership establishes the default rules for who owns work product created under the relationship. Most MSAs follow one of two models. In a client-owns model, all deliverables created under any SOW are assigned to the client, and the provider retains ownership only of its pre-existing tools, methodologies, and frameworks (with a license granted to the client to use them as part of the deliverables). In a provider-owns model, the provider retains ownership of all deliverables and grants the client a license to use them. The MSA sets the default. Individual SOWs can override the default for specific projects if the MSA's order-of-precedence clause permits it.

Confidentiality provisions define what constitutes confidential information, how it must be protected, what disclosures are permitted (to employees, advisors, subcontractors with a need to know), what exclusions apply (information that's publicly available, already known, independently developed, or received from a third party without restriction), and how long the obligation survives termination. Confidentiality terms don't change from project to project, so they belong in the MSA.

Indemnification establishes each party's obligation to defend and compensate the other for third-party claims. IP indemnification (the provider's obligation to defend the client against infringement claims), breach of confidentiality, and general third-party liability indemnification are relationship-level obligations that apply across all SOWs.

Limitation of liability establishes the liability cap, the consequential damages waiver, and any carve-outs. Because the MSA governs multiple SOWs, the liability cap formula needs to be drafted carefully. "Fees paid under this Agreement" is ambiguous when the agreement covers $50,000 in year one and $500,000 in year three. "Fees paid in the 12 months preceding the event giving rise to the claim" is more precise. Some MSAs tie the cap to the fees paid under the specific SOW that generated the claim, which isolates each project's risk.

Insurance requirements specify the types and levels of insurance each party must maintain, additional insured endorsements, and certificate requirements. These are relationship-level terms that don't change by project.

Governing law, jurisdiction, and venue establish where and under what law disputes will be resolved. These belong in the MSA because they apply to every SOW.

Dispute resolution specifies whether disputes are resolved through arbitration, litigation, or a multi-step process (negotiation, then mediation, then arbitration or litigation). Dispute resolution provisions belong in the MSA because the process should be consistent regardless of which SOW is at issue.

Termination provisions establish the grounds for terminating the MSA itself (which terminates all SOWs) and for terminating an individual SOW (which leaves the MSA and other SOWs intact). The MSA should address both scenarios separately.

What Goes in the SOW

A SOW should contain only the terms specific to the individual project. Everything that applies across the relationship is in the MSA. Everything that's unique to this engagement is in the SOW.

Scope of work describes what the provider will deliver. Functional specifications, technical requirements, and deliverables should be defined with enough specificity that both parties know what "done" looks like. Ambiguous scope is the most common source of disputes in services engagements, and it produces change order requests, delays, and disagreements about whether something is in scope or out of scope.

Deliverables identifies the tangible outputs of the project (software code, reports, designs, documentation, training materials) and defines what the provider is expected to produce, as distinguished from the services performed in producing them.

Timeline establishes the project schedule, including milestones, dependencies, and the expected completion date. Milestone-based timelines tied to deliverables are more effective than calendar-based timelines, because they connect payment to output rather than elapsed time.

Pricing specifies the fee structure for this project. Fixed fee, time-and-materials (hourly rates with a not-to-exceed cap), milestone-based payments, or some combination. The MSA establishes the billing mechanics. The SOW establishes the price.

Acceptance criteria define the standards the deliverables must meet and the process for the client to accept or reject them. A well-drafted acceptance provision includes a testing period (typically 10 to 30 days after delivery), specific criteria against which the deliverables are evaluated, a rejection procedure (written notice identifying the deficiencies), a cure period for the provider to correct rejected deliverables, and a deemed-acceptance provision (if the client doesn't test within the window, the deliverables are deemed accepted).

Project-specific IP terms override the MSA's default IP ownership rules when a particular project requires different treatment. If the MSA defaults to client-owns but a particular SOW involves the provider building on its own proprietary platform, the SOW might specify that the provider retains ownership of the platform enhancements and grants the client a license.

Key personnel identifies the individuals who will perform the work, if the client's selection of the provider was based on specific people's expertise. Key personnel provisions may restrict the provider from reassigning named individuals without the client's consent.

Order of Precedence

When the MSA and a SOW address the same subject and state different terms, one of them has to control. An order-of-precedence clause resolves the conflict by establishing a hierarchy among the contract documents.

A common approach provides the MSA priority over the SOW for all legal and commercial terms, on the theory that the MSA was negotiated as the comprehensive framework and shouldn't be overridden by project-level shortcuts. Under this approach, if the SOW includes a liability cap that differs from the MSA's cap, the MSA's cap controls.

An alternative approach provides the SOW priority over the MSA for project-specific terms, on the theory that a more specific, later-negotiated document better reflects the parties' intent for that engagement. Under this approach, if the SOW specifies different IP ownership terms for a particular project, the SOW controls.

Neither approach is inherently better. What's important is that the contract specifies which document wins, and that both parties' legal and business teams know the answer. Without an order-of-precedence clause, a court or arbitrator interprets the conflict using general contract construction principles, and the outcome is unpredictable.

A typical precedence clause reads something like this. "In the event of any conflict between this MSA and any SOW, the terms of this MSA shall control, except that the SOW shall control with respect to the scope of work, deliverables, timeline, pricing, and acceptance criteria for the applicable project."

When MSAs Make Sense

An MSA is worth the upfront negotiation time when you expect two or more engagements with the same counterparty. If you're hiring a vendor for a single project with no anticipated follow-on work, a standalone services agreement is simpler and faster. If you're entering a relationship that will produce multiple projects over months or years, the MSA pays for itself in reduced negotiation time on every subsequent SOW.

Industries where MSAs are standard include IT services and consulting, software development and implementation, marketing and creative services, staffing and professional services, managed services and outsourcing, and manufacturing and supply chain relationships.

Common Mistakes

Treating the MSA as permanent. An MSA negotiated three years ago may not reflect current business practices, regulatory requirements, or risk tolerances. Review and update the MSA periodically, particularly when the scope or scale of the relationship changes.

Leaving IP ownership to the default without evaluating each project. If the MSA defaults to client-owns but a project involves the provider's proprietary technology, the default may transfer ownership of something the provider didn't intend to give up. Evaluate IP ownership on each SOW and override the default when the project requires it.

Defining scope ambiguously. "Provider will develop a website" doesn't define scope. "Provider will develop a 10-page responsive website conforming to the wireframes in Exhibit A, including CMS integration, contact form functionality, and cross-browser testing on Chrome, Safari, Firefox, and Edge" defines scope. Every word you don't include in the scope definition is a potential dispute about whether it was included in the price.

Omitting the order-of-precedence clause. Without it, every conflict between the MSA and a SOW becomes a contract interpretation question that may need to be resolved by a court.

Failing to document scope changes. When a project's scope, pricing, or timeline changes mid-engagement, amend the SOW in writing. Informal agreements to adjust terms are one of the most common causes of disputes in services relationships. If it's not in a signed amendment to the SOW, it's a handshake that won't survive in litigation.

Practical Recommendations

Negotiate the MSA with the understanding that it will govern multiple projects over an extended period. Invest the time to get indemnification, liability, IP, and confidentiality right in the MSA, because those terms will apply to every SOW you sign under it.

Keep SOWs focused on the five project-level terms that change with each engagement. Scope, deliverables, timeline, pricing, and acceptance criteria. Everything else should be in the MSA.

Include an order-of-precedence clause that both parties understand and that their respective business teams know how to apply. If the SOW can override the MSA's IP terms for a specific project, make sure the project managers know that and draft the SOW accordingly.

Require written SOW amendments for every scope change. Don't allow scope creep to accumulate informally and then produce a payment dispute at the end of the project.

Review the MSA at least annually and amend it when the relationship evolves, the legal environment changes, or the risk profile of the work shifts. A three-year-old MSA that doesn't address data security, AI-generated deliverables, or current regulatory requirements needs updating.