How to Negotiate a Master Services Agreement (2026)

A master services agreement (MSA) is the umbrella contract that governs an ongoing relationship between a customer and a service provider. It sets the legal terms once, so that individual pieces of work can be ordered quickly under separate statements of work (SOWs) without renegotiating the whole deal each time. Getting the MSA right pays off over years, because every SOW inherits its terms. This guide explains the structure, the clauses worth negotiating, and where each side usually lands. It is general information, not legal advice. ## How the MSA and SOW structure works The MSA holds the terms that rarely change: liability, indemnity, confidentiality, IP, payment mechanics, termination, dispute resolution and governing law. Each SOW holds the terms specific to a piece of work: the services, deliverables, timeline, acceptance criteria and price. One MSA can sit above many SOWs. The key drafting question is the order of precedence: if a SOW conflicts with the MSA, which wins? The usual answer is that the MSA governs except where a SOW expressly says it overrides a specific clause, which stops a stray SOW from quietly rewriting your core protections. Settle this precedence clause early, because it shapes everything else. ## The clauses worth your energy Scope and the SOW process. The MSA should define how SOWs are created, agreed and changed. Insist on a change-control process so neither side can expand or shrink the work informally. Define acceptance: how the customer confirms a deliverable meets the criteria, how long it has to review, and what happens if it rejects. Payment. Fix invoicing frequency, payment terms (net 30 is common), what expenses are reimbursable, and whether work is fixed-price, time-and-materials, or capped. Agree interest on genuine late payment and the right to dispute an invoice in good faith without triggering default. Liability. As in any commercial contract, the provider wants a cap at fees paid and a broad exclusion of consequential loss, while the customer wants carve-outs for data breach, confidentiality and IP. A wrinkle unique to the MSA structure: is the cap per SOW, or aggregate across all SOWs? A per-SOW cap protects the customer better because one SOW's cap is not exhausted by an unrelated SOW's problem. Settle this in the MSA. Indemnity. Negotiate the IP infringement indemnity (provider to customer) and any data or confidentiality indemnities, and decide whether each sits inside or outside the cap. Keep triggers fault-based and tied to third-party claims where you can. Intellectual property. Decide who owns the deliverables and what happens to the provider's pre-existing tools and know-how. The standard resolution: the provider keeps its background IP and licenses it within the deliverables, while the customer owns or gets a broad licence to the specific work product it paid for. If the customer provides materials, licence those back to the provider only for the project. Confidentiality and data protection. A mutual confidentiality clause, and, where personal data is involved, a data processing addendum with security commitments, breach-notice timelines and sub-processor controls. Personnel and subcontracting. Key-person provisions, the right to approve or object to subcontractors, and non-solicitation of each other's staff (kept reasonable in scope and duration). Term and termination. Separate the MSA's term from each SOW's term. A common structure: the MSA runs until terminated, each SOW runs for its own period, and termination of the MSA does not automatically kill SOWs in flight unless a party chooses. Define termination for cause, for convenience (with notice), and for insolvency, plus what happens to work in progress and payment on termination. Dispute resolution and governing law. Agree the governing law and whether disputes go to courts or arbitration, and where. For cross-border relationships this matters a great deal. ## A fallback ladder for the customer 1. Per-SOW liability cap at a multiple of that SOW's fees, with data breach, confidentiality and IP uncapped; MSA governs over SOWs; broad IP ownership of deliverables. 2. Per-SOW cap at 12 months' fees with a super cap for data breach; IP and data indemnities outside the cap. 3. Aggregate cap but set high enough to matter; strong acceptance and change-control rights. 4. Standard cap, but secure the exit: termination for convenience on notice, clean handover of work product and data. ## A fallback ladder for the provider 1. Single aggregate cap at fees paid, broad exclusion of consequential loss, narrow fault-based indemnities inside the cap, keep all background IP. 2. Accept a per-SOW cap but only at the fees for that SOW, and only carve out IP and law-required items. 3. Offer a super cap for data breach tied to insurance rather than uncapped exposure. 4. Accept broad deliverable ownership for the customer in exchange for a clear licence back of your background tools and reusable components. ## Common mistakes to avoid - Leaving the order of precedence between MSA and SOW unclear, so a SOW silently overrides core protections.

• Not deciding whether the liability cap is per-SOW or aggregate, which can leave the customer badly under-protected.
• Mixing commercial terms into the MSA that belong in a SOW, forcing a renegotiation of the master every time the work changes.
• Forgetting acceptance criteria, so there is no clear test for whether a deliverable is done.
• Letting MSA termination automatically kill active SOWs (or failing to, when you wanted it to).
• Ignoring IP ownership of deliverables until a dispute makes it urgent. ## Running many SOWs under one MSA without losing track The real test of an MSA is not the first negotiation; it is living with it. A single MSA can spawn dozens of SOWs over years, each with its own term, deliverables, acceptance dates and fees, all inheriting the master's terms. Keeping that straight in folders and spreadsheets is where things slip: an expired SOW still being billed, a deliverable never formally accepted, a cap everyone forgot was per-SOW. Keeping the MSA and every SOW in one connected workspace, linked, versioned and with key dates and obligations tracked, makes the relationship manageable rather than a pile of documents. Adira is built around that idea, on frontier AI, so the master agreement, its SOWs and their obligations sit together. If you cannot see at a glance which SOWs are live under which MSA, that is the gap worth closing. More at Adira. The negotiation points above work with any tool. ## Bottom line Negotiate the MSA as the foundation it is: settle the order of precedence, decide whether liability caps are per-SOW or aggregate, keep commercial terms in the SOW so the master stays stable, and nail acceptance, IP ownership and the exit. Do that once and every future SOW inherits a clean, balanced deal. For a material relationship, have a qualified lawyer review the MSA before you sign.