Summary. The master services agreement and the statement of work do different jobs, and most disputes arise because one document did the other's work badly. This guide separates them: what belongs in the master agreement, negotiated once by lawyers, and what belongs in each SOW, written by the people performing the work. It then covers scope and acceptance, which determine when payment is owed; pricing and change control; service levels and remedies; IP ownership in services, where defaults surprise customers; the risk allocation architecture; data and security; personnel and subcontracting; termination and transition; and the order of precedence problem.

A healthcare company engages a systems integrator to implement a new scheduling platform. The master services agreement is thirty-one pages, negotiated over six weeks, with a mutual liability cap at twelve months of fees and a carefully drafted IP provision assigning deliverables to the customer.

The statement of work is four pages, written by the integrator's project manager and signed by the customer's director of operations. It describes the work as "implementation of the scheduling platform including configuration, data migration, integration with existing systems, training, and go-live support." It contains no acceptance criteria, no milestone definitions, and a sentence stating that "in the event of any conflict, the terms of this SOW shall control."

Fourteen months and $2.1 million later, the system is not live. The integrator says the scope grew; the customer says the work was never completed. There is no way to determine which is right, because nothing in the SOW defines what "integration with existing systems" meant or what would establish that it had been achieved.

And the precedence sentence, added without thought by a project manager, arguably subordinates the thirty-one negotiated pages to a four-page document that says almost nothing.

The master agreement was drafted well and did not matter. The statement of work decided the dispute, and nobody with the relevant expertise had read it.

The division of labor

The master services agreement (MSA) establishes the legal framework once, for all engagements. It is negotiated by counsel, it changes rarely, and it should contain nothing about the specific work.

The statement of work (SOW) defines a particular engagement: what will be done, by when, for how much, and how anyone will know it is finished. There will be many SOWs under one MSA, each written by the operating teams.

Why the split matters. It allows the parties to negotiate the hard legal terms once, then start subsequent projects in days rather than weeks. It also creates the failure mode described above, in which the operating teams draft the document that actually governs.

What belongs in the MSA:

  • Structure, term, and the relationship between the MSA and SOWs
  • Order of precedence
  • The change control process
  • Invoicing, payment, taxes, and expenses (rates in the SOW)
  • Warranties and disclaimers
  • Intellectual property architecture
  • Confidentiality
  • Data protection and security
  • Indemnification
  • Limitation of liability
  • Insurance
  • Personnel provisions and subcontracting
  • Independent contractor status
  • Termination and its consequences
  • Dispute resolution, governing law, notices, assignment, and the remaining boilerplate

What belongs in the SOW:

  • Description of services and deliverables
  • Acceptance criteria and the acceptance process
  • Assumptions and dependencies
  • Customer obligations
  • Schedule, milestones, and dependencies
  • Pricing, payment schedule, and expense policy
  • Key personnel and the staffing plan
  • Governance — meetings, reporting, and escalation
  • Any SOW-specific terms that vary from the MSA, identified as such

Order of precedence: the provision that undoes everything

This clause deserves its own section because it is short, it is usually drafted carelessly, and it can invert the entire negotiation.

The default that should almost always apply: the MSA governs, except where a SOW expressly identifies the MSA section it is modifying and states that it is doing so for that SOW only.

Why. A SOW is drafted by project personnel under time pressure, using a template, and reviewed by no lawyer. A precedence clause stating that "the SOW controls in the event of conflict" means a project manager can, inadvertently, override the liability cap, the IP assignment, the indemnity, or the warranty — none of which they know exist.

The full hierarchy in a typical engagement, from highest:

  1. The MSA
  2. Addenda to the MSA — a data processing addendum, a security addendum, a business associate agreement — each of which should state that it prevails over the MSA on its subject matter
  3. The SOW, for scope, schedule, price, and expressly identified modifications
  4. Change orders to the SOW
  5. Exhibits and specifications
  6. Purchase orders and invoices, which should be expressly limited to administrative and accounting purposes with all pre-printed terms rejected

State that last item explicitly. Otherwise a customer's purchase order terms and a vendor's invoice terms enter the relationship through UCC § 2-207 or its common law analogue, and the parties have a third and fourth set of terms nobody negotiated.

Scope, deliverables, and acceptance

The test for a well-written scope is whether a person who was not in the room could read it and determine whether the work was performed.

Describe deliverables specifically, and distinguish:

  • Deliverables — tangible outputs (a document, a configured environment, code, a report) that are delivered, tested, and accepted.
  • Services — activities performed over time (support, monitoring, staff augmentation) measured against service levels rather than accepted.

Most SOWs blur the two, which makes it impossible to determine when payment is earned.

Acceptance criteria are the single most important provision in a deliverables-based SOW. For each deliverable, specify:

  • The objective criteria it must satisfy — functional requirements, performance thresholds, test cases, or conformity to a specification attached as an exhibit.
  • The review period — a defined number of business days after delivery.
  • The process — the customer tests, and either accepts in writing or provides a written statement of the specific deficiencies.
  • Cure — the vendor's period to correct, and the number of cure cycles before the customer may reject.
  • Consequences of rejection — refund, termination of that deliverable, or termination of the SOW.
  • Deemed acceptance if the customer does not respond within the review period. Vendors want this; customers should accept it only with a reasonable period and a requirement of written notice reminding them the clock is running.
  • Acceptance of a deliverable does not waive later-discovered latent defects, which should be addressed by the warranty.

Assumptions and dependencies protect the vendor and discipline the customer. List them: the customer will provide data in a stated format by a stated date; a named customer resource will be available for a stated number of hours per week; third-party systems will be accessible; environments will be provisioned. Then state the consequence of a dependency failure — schedule relief, additional charges at stated rates, or both.

Customer obligations should be a separate, enumerated section. Most failed engagements involve a customer that did not do what it agreed to do, and a SOW that never said what that was.

Out of scope. State what is not included, explicitly. The exclusions do more work than the inclusions.

Pricing, invoicing, and change control

Pricing models:

  • Fixed fee. The vendor bears the risk of effort overruns. Requires a tightly defined scope and a working change control process, and vendors price a contingency into it.
  • Time and materials. The customer bears the effort risk. Requires rate cards, a not-to-exceed cap, and reporting. A T&M engagement without a cap is an open checkbook.
  • Capped time and materials — the practical compromise: T&M billing up to a ceiling, with the vendor absorbing the excess or the parties returning to change control.
  • Milestone-based. Payment on achievement of defined, objectively verifiable milestones. The best structure for a customer, because it aligns payment with progress, and it requires milestones defined well enough to be verifiable.
  • Retainer or subscription for ongoing services.
  • Outcome or value-based, which requires a measurable outcome and a baseline that both parties trust.

Payment terms. Net period, invoicing frequency, required invoice detail (which should be enough to verify the charges), a disputed invoice procedure requiring payment of undisputed amounts, late fees, and suspension rights on non-payment after notice.

Holdback. A customer may retain a percentage of each milestone payment until final acceptance — 10 to 15 percent is common. It is the most effective remedy a customer has, and it is worth more than most indemnities.

Expenses. Pre-approval above a threshold, a travel policy, and a prohibition on markups.

Taxes. Fees exclusive of taxes, with the customer responsible for sales and use tax and the vendor for taxes on its income. Note that services are taxable in a number of states and that a bundled fee can make an otherwise exempt component taxable — separately stating taxable and non-taxable components is worth doing at the SOW stage.

Rate increases. Whether rates are fixed for the SOW term, adjustable annually with notice, or indexed. Cap the increase.

Change control is what makes fixed-fee engagements survivable. The process:

  1. Either party proposes a change in writing.
  2. The vendor prepares an impact assessment — scope, schedule, and price.
  3. Both parties sign a change order.
  4. No work proceeds on a change until the change order is signed.

The fourth step is the one that fails. A vendor that performs changed work on a verbal instruction, expecting to paper it later, will be arguing about it in litigation. A customer that directs work outside scope and refuses to sign a change order is creating a constructive change claim against itself. Both parties should train their project teams that the rule is absolute, and both should have a defined escalation path for urgent changes that cannot wait for the paperwork — usually a written email confirmation from a named person with authority, followed by a formal change order within a defined period.

Service levels

For ongoing services, service levels convert an aspiration into an obligation.

Define each metric precisely: what is measured, how it is measured, over what period, by whom, and what is excluded (scheduled maintenance, customer-caused failures, force majeure, third-party outages). An availability commitment without an exclusion list is unenforceable; one with an unlimited exclusion list is meaningless.

Common metrics: availability or uptime; response time by severity; resolution time by severity; first-contact resolution; and delivery or throughput measures.

Severity definitions are where support agreements are won and lost. Define severity by business impact — a Severity 1 is a production outage or a critical function unavailable with no workaround — and specify who assigns severity and how a disagreement is escalated. A vendor that unilaterally classifies every issue as Severity 3 has defeated the entire service level structure.

Remedies:

  • Service credits, calculated as a percentage of fees, escalating with the severity or duration of the miss.
  • A chronic failure termination right after a defined number of misses in a period, which is more valuable than the credits.
  • Root cause analysis obligations for significant failures.
  • Earnback provisions, which vendors request and customers should resist unless the performance genuinely recovers.

The critical question: are service credits the sole and exclusive remedy for a service level failure? Vendors insist; customers should preserve at least the termination right and, for a catastrophic failure, the ability to claim damages. A sole-remedy credit provision means that a vendor whose failure costs the customer millions owes a few percent of a monthly fee.

Reporting. Monthly reports with the underlying data, and a customer audit right. A service level the customer cannot verify is not a commitment.

Intellectual property

This is where services agreements most often disappoint customers, because the default rules do not do what customers assume.

The default. A contractor who creates copyrightable work owns it, absent a written assignment. The work made for hire doctrine, 17 U.S.C. § 101, applies to an independent contractor only if the work falls within one of nine enumerated categories and there is a signed writing — and most software, most reports, and most designs do not fit the categories. Reciting "work made for hire" without an assignment leaves the vendor owning the deliverables.

The provision that works therefore has two parts: a work-made-for-hire recital and a present assignment — "to the extent any deliverable is not a work made for hire, Vendor hereby irrevocably assigns" — plus a further assurances covenant and a power of attorney to execute recordation documents.

The three-category framework:

  1. Vendor background IP — tools, methodologies, frameworks, libraries, and know-how the vendor brings. The vendor keeps it. The customer needs a perpetual, irrevocable, worldwide, non-exclusive, royalty-free license to use it to the extent embedded in or necessary to use the deliverables, including the right to modify and to have third parties do so. Without that license, the customer owns a deliverable it cannot lawfully operate.

  2. Customer background IP and data — the customer keeps it. The vendor gets a limited license to use it solely to perform the services.

  3. Foreground IP / deliverables — created for the customer. Two structures:

    • Customer owns, with a license back to the vendor for its general know-how and non-customer-specific improvements. The customer's preference.
    • Vendor owns, with a broad license to the customer. Common where the vendor is productizing, and acceptable to a customer only if the license is genuinely broad, perpetual, and irrevocable, and includes the right to modify and to engage other vendors.

Provisions to scrutinize:

  • Residuals clauses — permitting the vendor's personnel to use "general knowledge, skills, and experience" retained in unaided memory. Broadly drafted, a residuals clause can swallow the confidentiality obligation. Narrow it to genuinely general skills, and exclude the customer's confidential information, trade secrets, and any specifically identified material.
  • Open source. Require disclosure of every open source component in a deliverable, prohibit components under copyleft licenses that would require source disclosure of the customer's proprietary code, and require compliance with attribution and notice obligations.
  • AI-generated content. Require disclosure of whether generative tools were used, address ownership and copyrightability of AI-assisted output, allocate the risk of third-party claims arising from training data, and require license-filter settings for code generation.
  • Third-party materials embedded in deliverables — identified, with the license terms disclosed and the cost allocated.
  • Escrow of source code for critical custom software, with defined release conditions.

Risk allocation

Warranties the vendor should give:

  • Services performed in a professional and workmanlike manner by qualified personnel, consistent with industry standards.
  • Deliverables will conform to the specifications for a defined period after acceptance.
  • Non-infringement of third-party intellectual property.
  • Authority, and no conflicting obligations.
  • Compliance with law.
  • No harmful code.
  • Where relevant, no open source that would require disclosure of customer proprietary code.

Disclaimers of implied warranties must be conspicuous and, for merchantability, must mention it.

Indemnification.

  • Vendor indemnifies for third-party IP infringement claims arising from deliverables (with the standard carve-outs for customer-supplied materials, unauthorized modification, and combination with items not supplied by the vendor); for bodily injury and property damage caused by its personnel; for breach of confidentiality; for its violation of law; and for its employment-related claims.
  • Customer indemnifies for claims arising from customer-supplied materials and from its use of deliverables outside the agreed purpose.
  • Mechanics: prompt notice, control of the defense, cooperation, consent to settlement, and whether defense costs are advanced or reimbursed. The duty to defend is materially more valuable than a duty to indemnify.
  • IP infringement remedies: the vendor's obligation to procure the right to continue using, modify to be non-infringing, or replace — and, only as a last resort, refund. A refund-only remedy leaves the customer without the system.

Limitation of liability. The architecture matters more than the number.

  • A mutual cap, commonly 12 months of fees paid under the affected SOW, or a multiple for higher-risk engagements.
  • Exclusions from the cap — this is the negotiation: indemnity obligations, breach of confidentiality, gross negligence and willful misconduct, death and bodily injury, damage to tangible property, breach of data protection or security obligations, and a party's payment obligations. Data breach exposure in particular should sit outside the general cap or under a separately negotiated supercap.
  • Consequential damages exclusion, mutual — drafted as a separate clause with express language that it survives any failure of a limited remedy's essential purpose, and with attention to whether lost profits are direct or consequential in the transaction.
  • Consider the interaction with service credits, which should not be the sole remedy for everything.

Insurance. Commercial general liability; professional liability (errors and omissions) at a limit proportionate to the engagement; cyber liability where data is involved; workers' compensation and employer's liability; automobile; and umbrella. Require additional insured status by endorsement for CGL, a waiver of subrogation, primary and non-contributory language, notice of cancellation, and certificates annually. Note that professional liability is claims-made, so require a tail after termination.

Data, privacy, and security

Where the vendor will access, process, or store customer data, the MSA needs an addendum rather than a paragraph.

Data ownership. Customer data remains the customer's. Specify what the vendor may do with it — solely to perform the services — and expressly address aggregated and de-identified use, benchmarking, and model training, each of which vendors want and customers frequently grant without noticing.

Data processing addendum where personal data is involved: roles (controller and processor, or business and service provider), processing instructions, purpose limitation, confidentiality of personnel, security measures, subprocessor approval and flow-down, assistance with data subject requests, breach notification with a defined timeline, deletion or return on termination, audit rights, and the transfer mechanism for cross-border processing.

Security addendum, with specifics rather than a promise of "industry standard": access controls and multi-factor authentication, encryption in transit and at rest, vulnerability management and patching timelines, logging and monitoring, background checks on personnel, secure development practices, penetration testing with results shared, incident response commitments, and an attestation — SOC 2 Type II or ISO 27001 — delivered annually.

Incident notification. A defined period — 24 to 72 hours is typical — from discovery, with the content specified, an obligation to cooperate in the investigation and in any required notifications, and allocation of the cost of notification, credit monitoring, and forensics. This is the exposure that most often justifies a supercap.

Sector overlays: a business associate agreement for protected health information, GLBA obligations for financial data, and FERPA for education records, each of which prevails on its subject matter.

Personnel, subcontracting, and independent contractor status

Key personnel. Name the individuals the customer is relying on, prohibit their removal without consent except for cause or resignation, require a qualified replacement approved by the customer, and — for critical roles — require a transition period of overlap. A key personnel provision without a consequence is a preference; attach a service credit or a termination right.

Staffing. Whether personnel are dedicated or shared, minimum experience requirements, and the customer's right to require removal of an individual for cause.

Subcontracting. Prohibited without consent, or permitted with notice for defined categories. Whichever, the vendor remains fully responsible for subcontractor performance and must flow down confidentiality, IP assignment, data protection, and security obligations.

Non-solicitation. Mutual, limited to personnel who worked on the engagement, for a defined period (commonly 12 months), with a carve-out for general advertising and for individuals who apply unsolicited. Draft it with the antitrust framework in mind — an unlimited no-hire between businesses is a different and far riskier thing than a narrow, ancillary non-solicit.

Independent contractor status. State it, and then behave consistently. The classification risk is real: a customer that supervises the vendor's personnel, dictates their hours, provides their equipment, and integrates them into its teams may be a joint employer for wage and hour, discrimination, benefits, and workers' compensation purposes. The agreement should require the vendor to be solely responsible for its personnel's wages, taxes, and benefits, to indemnify for classification claims, and to confirm that its personnel are not eligible for the customer's benefit plans — and the customer's operating teams should be told to route direction through the vendor's manager rather than supervising individuals directly.

Term, termination, and transition

Term. The MSA's term, and the SOW's term, which should be independent — the MSA continuing until terminated, with SOWs running their own course and surviving MSA expiration to the extent the parties intend.

Termination rights:

  • For cause, on material breach with notice and a cure period.
  • For convenience by the customer, on notice, with payment for services performed and, for a fixed-fee engagement, a defined wind-down or cancellation charge. Customers should insist on this; vendors should price it.
  • For convenience by the vendor — rarely appropriate mid-engagement, and if granted, with a long notice period and transition obligations.
  • For insolvency, subject to bankruptcy limits.
  • For chronic service level failure.
  • On a change of control of the vendor, particularly to a competitor of the customer.

On termination:

  • Payment for services performed and non-cancellable commitments.
  • Delivery of work in progress, in a usable form, including source materials and documentation — this is frequently omitted, and a customer that terminates receives nothing it can use.
  • Return or deletion of confidential information and data, with a certificate.
  • Data export in an agreed format, within a defined period, at defined rates.
  • Transition services — the vendor's obligation to assist the customer or a successor vendor for a defined period (60 to 180 days) at agreed rates, including knowledge transfer, documentation, and cooperation. This is the most valuable termination provision a customer can have, and vendors resist it precisely because it removes their leverage.
  • Survival of confidentiality, IP, indemnity, limitation of liability, and dispute resolution.

A worked example

Return to the healthcare implementation, redone.

The MSA is unchanged, with three additions: an order of precedence clause providing that the MSA controls except where a SOW expressly identifies the MSA section it modifies; a data processing and security addendum with a 48-hour breach notification and a liability supercap for data incidents at three times the general cap; and a transition services obligation of up to 120 days at agreed rates.

The SOW is twenty-two pages instead of four, and includes:

  • Deliverables enumerated in a table: eleven items, each with a description, a specification reference, a milestone, and a payment amount.
  • Acceptance criteria for each deliverable, expressed as test cases in an exhibit, with a ten-business-day review period, a written deficiency requirement, two cure cycles, and deemed acceptance only after a written reminder.
  • Assumptions and dependencies: the customer will provide extracted data in a defined schema by a stated date; three named customer subject matter experts will be available eight hours per week; the legacy vendor will provide API access. Each with a stated consequence — day-for-day schedule relief and T&M charges at listed rates for standby time.
  • Customer obligations in a separate enumerated section.
  • Pricing: milestone-based, with a 12 percent holdback released on final acceptance, and a not-to-exceed cap on the T&M portion for data cleansing.
  • Key personnel: the solution architect and the integration lead named, with no removal without consent and a two-week overlap on any replacement.
  • Governance: weekly status with a defined report format, a monthly steering committee, and a three-tier escalation path with named individuals and response times.
  • Change control restated in the SOW with the rule that no work proceeds without a signed change order, and an emergency mechanism requiring written confirmation from one of two named authorized individuals.

What changes in the dispute. There is no dispute, because "integration with existing systems" is now eleven deliverables with test cases, the data dependency has a date and a consequence, and the holdback gives the customer leverage that the general liability cap never would have.

Frequently asked questions

Do we need both an MSA and a SOW? For a single small engagement, one document is fine. For an ongoing relationship, the split saves substantial time on every subsequent project — provided the precedence clause protects the MSA.

Who should draft the SOW? The people who will do the work, reviewed by someone who has read the MSA. The most common failure is a SOW drafted by people who do not know what the MSA says.

What is the most important SOW provision? Acceptance criteria. Without them, there is no objective way to determine whether the vendor performed.

Should we agree that the SOW controls over the MSA? No. Provide that the MSA controls except where the SOW expressly identifies the section it is modifying.

Do we own what the vendor creates? Only if the agreement assigns it. Work made for hire does not apply to most contractor deliverables, and a recital without an assignment leaves ownership with the vendor.

Are service credits enough of a remedy? Rarely. Preserve a chronic-failure termination right and, for catastrophic failures, the ability to claim damages.

Should the liability cap cover a data breach? Not within the general cap. Negotiate a supercap or an exclusion for data protection and security breaches, sized against the realistic notification and remediation cost.

What happens if we terminate mid-project? Whatever the agreement says — which for most customers should include delivery of work in progress in usable form, data export, and a transition services obligation at agreed rates.

Conclusion

Services engagements fail in two ways, and each maps to one document.

They fail legally when the master agreement allocated risk badly — no IP assignment, no license to background IP, a cap that swallows the data breach exposure, no transition obligation. Those failures are visible in the document and are fixed by negotiating it once, carefully.

They fail practically when the statement of work did not define what "done" means. No acceptance criteria, no enumerated dependencies, no change control discipline, and a scope description written in a paragraph that meant something different to each side. Those failures are invisible at signing and are the cause of nearly every disputed engagement.

The lesson is that the SOW deserves the same attention as the MSA, and it almost never gets it — because by the time the SOW is drafted, the lawyers have moved on and the deal feels done.

Governing the engagement after signature

A well-drafted agreement is worth very little if nobody administers it, and services engagements are administered by project teams who have never read it.

Distribute an abstract, not the agreement. A one-page summary for the project team: the scope boundary, the change control rule, the acceptance process and review periods, the key personnel commitments, the escalation path with names and response times, the invoicing requirements, and the notice provision. Project managers do not read thirty-one pages; they will read one.

Hold the change control line. The single most consequential operational discipline. Every scope conversation ends with either "that's in scope" or "that requires a change order." A project manager who says "we'll figure it out later" has created a dispute. Train both sides, and give each a named person with authority to approve an emergency change in writing.

Run acceptance on the calendar. Deliverables arrive and sit. The review period runs, deemed acceptance operates, and the customer has accepted something it never tested. Calendar each review period on delivery, assign a named reviewer, and require a written response — acceptance or specific deficiencies — before the period expires.

Document dependencies in real time. When the customer misses a dependency, the vendor should note it in the weekly status report that week, not in a claim eight months later. A contemporaneous status report showing a missed dependency is worth more than any argument reconstructed afterward; a claim first raised at the end looks manufactured, whether or not it is.

Keep the status reports substantive. "On track" for eleven weeks followed by "three months late" is the documentary pattern behind most services litigation. A status report that identifies risks, dependencies, and decisions needed is a project management tool and, later, the best evidence either side will have.

Escalate early. Governance structures exist to surface problems while they are still cheap. A steering committee that meets monthly and hears only good news is not governance. Both parties should treat the first missed milestone as the escalation trigger rather than the fourth.

Track the commercial mechanics. Holdback balances, milestone payments earned, change order values against the original fee, T&M spend against the not-to-exceed cap, service credit accruals, and key personnel changes. These are the facts that determine leverage in any renegotiation, and neither party usually has them at hand.

Diary the dates. SOW expiration, renewal and non-renewal windows, insurance certificate renewals, annual attestation delivery, rate adjustment dates, and the tail on claims-made professional liability coverage. Missing a non-renewal window renews an engagement nobody wanted; missing an insurance renewal leaves an uninsured vendor working on a critical system.

Related articles

This guide is provided for general informational purposes and does not constitute legal advice. Contract law, the enforceability of liability limitations, and data protection obligations vary by jurisdiction and by the nature of the engagement. Consult qualified counsel before executing a master services agreement or a significant statement of work.