How to write a master service agreement for selling software
Draft your MSA as the legal framework for every deal, then push pricing, scope, and duration into Order Forms or SOWs. That structure protects your core legal terms across every transaction without reopening negotiations from scratch each time. Before you write a single clause, confirm you have addressed these six items:
- Order of precedence: state which document controls when terms conflict
- IP and license approach: vendor retains background IP; customer receives a limited license
- Liability cap: tie it to fees paid in the prior year
- Indemnities: mutual, fault-based, with IP carve-outs
- DPA and security obligations: include a Data Processing Agreement as an exhibit and reference SOC 2 or ISO 27001 where applicable
- Amendment and change control: require written, signed changes by authorized representatives
The rest of this guide walks through every clause in that framework, flags the traps that appear most often in customer-paper MSAs, and gives you copy-ready language to drop into your first draft.
Table of Contents
- What is an MSA and when should you use one?
- Core clause checklist for a software MSA
- SaaS-specific traps and common MSA drafting mistakes
- Negotiation playbook: what to protect and what to concede
- Copy-ready sample clauses for your first draft
- How to execute, amend, and manage your MSA over time
- How Formable supports MSA drafting, negotiation, and management
- Key takeaways
- The clause that most legal teams underestimate
- Close deals faster with Formable's MSA workflow
- Useful sources
- FAQ
What is an MSA and when should you use one?
A master service agreement (MSA) is a framework contract that sets the legal terms governing every transaction between two parties. It does not describe what you will deliver or what the customer will pay. Those details live in Order Forms or Statements of Work that attach to the MSA and incorporate it by reference. The two-tier structure means you negotiate the hard legal questions once, then close individual deals by signing a one-page Order Form.
Use an MSA when you expect to run multiple projects or subscription renewals with the same customer. A standalone SOW works for a one-time engagement with no expectation of repeat business. A subscription agreement (your standard SaaS terms of service) works when customers self-serve and you cannot negotiate terms individually. The MSA sits between those two: it is the right instrument when an enterprise procurement team insists on negotiated terms before they will sign any Order Form.
Three procurement reasons enterprises ask for an MSA: they want a single legal document their legal team has approved rather than reviewing new terms on every order; they need consistent data protection and security language across all vendors; and they want a dispute resolution mechanism that does not require re-litigating jurisdiction every time a project goes sideways.
Core clause checklist for a software MSA
Every clause below belongs in a software MSA. The drafting notes tell you what to watch for in each one.
| Clause | What to include | Key drafting note |
|---|---|---|
| Recitals | Brief description of each party and the purpose of the agreement | Keep short; recitals are not operative terms |
| Definitions | Defined terms for "Services," "Deliverables," "Confidential Information," "Personal Data," "Background IP," "Foreground IP" | Define "Background IP" explicitly to protect your platform |
| Scope of services | Reference to Order Forms and SOWs for specifics | Do not describe services in the MSA body |
| License grant | Limited, non-exclusive, non-transferable license to use the software | Never grant ownership; grant access only |
| Background IP | Vendor retains all pre-existing IP and IP developed independently | Explicitly exclude platform code from any assignment |
| Deliverable ownership | Custom deliverables may be assigned to client; background IP is licensed, not assigned | Tie assignment to full payment |
| Payment and invoicing | Net 30 or Net 15 payment terms, late fees, suspension rights for non-payment | Include a right to suspend access after 30 days past due |
| Taxes | Customer responsible for taxes other than vendor's income taxes | Reference applicable US sales tax treatment |
| Change orders | Written change order required for any scope change | Reference the SOW change order procedure |
| Confidentiality | Mutual NDA obligations, carve-outs for public information and legal disclosure | 3-to-5-year post-termination survival period |
| Data Processing Agreement | GDPR/CCPA-compliant DPA as an exhibit | Required if you process personal data |
| Security | Reference to vendor's security program; SOC 2 or ISO 27001 where applicable | Avoid committing to certifications you do not currently hold |
| Warranties and disclaimers | Limited warranty that services conform to documentation; disclaimer of implied warranties | Include "AS IS" language for everything beyond the limited warranty |
| SLA | Uptime commitment, credit mechanism, measurement methodology | Define "downtime" precisely to avoid disputes |
| Acceptance | Specific acceptance window (e.g., 10 business days) with deemed acceptance if no written objection | Avoid open-ended acceptance that lets customers withhold payment indefinitely |
| Audit rights | Limited audit rights with advance notice, scope restrictions, and cost allocation | Cap audit frequency at once per year |
| Indemnities | Mutual indemnities for third-party IP claims; vendor indemnity for data breach caused by vendor negligence | Fault-based, not strict liability |
| Limitation of liability | Cap at prior 12 months of fees; mutual cap; carve-outs for fraud and willful misconduct only | Keep carve-outs narrow |
| Insurance | Minimum coverage requirements for each party | Specify commercial general liability and cyber liability minimums |
| Term and termination | Initial term, auto-renewal, termination for cause (30-day cure), termination for convenience | Include data return/deletion obligations on termination |
| Survival | List surviving clauses explicitly: confidentiality, IP, limitation of liability, payment obligations | Survival provisions must be explicit to avoid post-termination exposure |
| Assignment | Neither party may assign without consent; carve-out for change of control | Vendor carve-out for M&A is standard |
| Amendment | Written, signed by authorized representatives | No email amendments |
| Notices | Email acceptable for operational notices; certified mail for legal notices | Specify notice addresses |
| Governing law | Choose your state; include venue selection | Delaware or your state of incorporation is typical |
| Dispute resolution | Negotiation, then mediation, then arbitration or litigation | AAA or JAMS arbitration is common for enterprise deals |
| Order of precedence | MSA controls legal terms; Order Form controls commercial terms | See sample language above |
Liability caps tied to fees paid in the prior year are the standard vendor-protective approach. Resist customer pressure to carve out broad categories like "breach of confidentiality" or "data breach" from the cap entirely. A mutual cap with narrow carve-outs for fraud and willful misconduct is a defensible position.
Pro Tip: Security frameworks commonly referenced in MSAs include SOC 2, ISO 27001, and NIST CSF. If you reference a certification in your MSA, include language that permits you to substitute an equivalent framework over time. Committing to a specific certification you do not yet hold creates immediate breach exposure.
SaaS-specific traps and common MSA drafting mistakes
Customer-drafted MSAs are written for professional services vendors, not SaaS companies. The language that works for a consulting firm can be catastrophic for a software vendor. These are the provisions that cause the most damage.
Work-for-hire and IP assignment traps
Customer MSAs frequently include language stating that all deliverables are "works made for hire" or that the customer owns all IP created under the agreement. For a SaaS vendor, that language can unintentionally assign ownership of your core platform if a court finds it was "created under" the agreement. Customer-drafted MSAs frequently assume deliverables-based ownership and can unintentionally assign platform IP if not revised. The fix is a clear carve-out: "Notwithstanding any other provision, Vendor's Background IP, including all pre-existing software, algorithms, and platform components, is not a deliverable and is not assigned to Customer under this Agreement."
Data and AI-specific risks
- Breach notification windows: Enterprise customers typically require security breach notification within a few days of discovery. Commit to a window you can operationally meet; 72 hours is more realistic than 24.
- AI model training rights: — If your product uses customer data to train or improve AI models, you must address this explicitly. Silence on model training is increasingly treated by enterprise legal teams as a red flag. State clearly whether customer data is used for training and under what conditions.
Negotiation playbook: what to protect and what to concede
Enterprise MSA negotiations typically run 4–8 weeks from first draft to signature, depending on the customer's legal team size and internal approval process. Budget for two to three rounds of redlines on the core risk allocation clauses.
Six priorities for a software vendor
- SOW control: — Accept that the customer may want to control commercial terms in the Order Form. That is a reasonable concession that does not affect your legal risk position.
- Amendment procedure: Require all amendments to be written and signed by authorized representatives to prevent informal, binding changes to prevent informal, binding changes by email or verbal agreement.
Practical tradeoffs
A practical vendor tactic is to accept SOW-level control for commercial terms while keeping MSA-level control for legal risk allocation. That preserves pricing flexibility per project without reopening core legal terms. Customers often push hard on payment terms and SLA credits. Both are acceptable concession areas. Payment terms moving from Net 15 to Net 30 and SLA credits increasing from 5% to 10% per incident are reasonable trades that do not affect your liability exposure.
Governing law is worth a fight if the customer insists on a jurisdiction with unfavorable case law for software vendors. Delaware, New York, and California are all defensible choices for a US software company. Avoid agreeing to a customer's home state if it is a jurisdiction where you have no presence and no counsel.
Sample negotiation timeline
- Week 2–3: — Customer legal team returns first redline
Copy-ready sample clauses for your first draft
These snippets are vendor-favorable starting points. Adapt them to your specific business model and have qualified US counsel review before use.
License grant
"Subject to the terms of this Agreement and Customer's payment of applicable fees, Vendor grants Customer a limited, non-exclusive, non-transferable, non-sublicensable license to access and use the Software solely for Customer's internal business purposes during the applicable Order Form term."
Background IP retention
"As between the parties, Vendor retains all right, title, and interest in and to the Software, platform, algorithms, tools, templates, and all other Background IP. No rights in Background IP are transferred to Customer under this Agreement. Customer receives only the license rights expressly stated herein."
Liability cap
"Except for each party's indemnification obligations and liability for fraud or willful misconduct, each party's total cumulative liability to the other arising out of or related to this Agreement shall not exceed the total fees paid by Customer to Vendor in the twelve (12) months immediately preceding the event giving rise to the claim."
Mutual indemnity with IP carve-out
"Vendor shall defend, indemnify, and hold harmless Customer from any third-party claim alleging that the Software, as delivered by Vendor and used in accordance with this Agreement, infringes any US patent, copyright, or trademark. Customer shall defend, indemnify, and hold harmless Vendor from any third-party claim arising out of Customer's use of the Software in violation of this Agreement or applicable law. Each party's indemnification obligation is conditioned on the indemnified party: (a) promptly notifying the indemnifying party in writing; (b) granting the indemnifying party sole control of the defense; and (c) cooperating reasonably at the indemnifying party's expense."
DPA stub language
"To the extent Vendor processes Personal Data on behalf of Customer in connection with the Services, the parties agree to the Data Processing Agreement attached as Exhibit D, which is incorporated by reference. Vendor shall notify Customer of a confirmed security breach affecting Customer Personal Data within seventy-two (72) hours of Vendor's discovery of such breach. Vendor shall not use Customer Personal Data to train, fine-tune, or improve any AI or machine learning model without Customer's prior written consent."
SLA sample
"Vendor shall use commercially reasonable efforts to make the Software available 99.9% of the time in any calendar month, excluding Scheduled Maintenance and Force Majeure Events ('Uptime Commitment'). 'Downtime' means the total accumulated minutes in a calendar month during which the Software is unavailable, excluding Scheduled Maintenance windows communicated at least 48 hours in advance. If Vendor fails to meet the Uptime Commitment in any calendar month, Customer shall be eligible for a service credit equal to 10% of the monthly subscription fee for that month, applied to the next invoice. Service credits are Customer's sole and exclusive remedy for SLA failures."
Acceptance language
"Customer shall have ten (10) business days following delivery of each Deliverable to provide written notice of any material non-conformance with the applicable SOW specifications. If Customer does not provide written notice within that period, the Deliverable shall be deemed accepted. Acceptance shall not be unreasonably withheld, conditioned, or delayed."
How to execute, amend, and manage your MSA over time
Execution options
Mutual wet or electronic signature is the most common execution method and creates the clearest record of mutual assent. Electronic acceptance (a click-through or checkbox) works for lower-risk Order Forms but is harder to enforce for the MSA itself in a dispute. Commencement by performance, where both parties begin performing before signing, creates an implied contract but leaves terms ambiguous. For an MSA, always use mutual signature.
Electronic signatures under the federal E-SIGN Act and the Uniform Electronic Transactions Act (UETA) are legally binding for commercial contracts in all 50 US states. Use a platform that creates an immutable audit trail with timestamps for each signature event.
Pro Tip: Version your MSA documents with a date stamp in the footer (e.g., "MSA v2.1 — March 2025"). When you send a redline, include the version number in the file name. This prevents confusion about which version is current during multi-round negotiations. Formable's contract workflow management tools handle versioning automatically.
Amendment procedure
Every change to the MSA after execution requires a written amendment signed by authorized representatives of both parties. That rule applies to email confirmations, Slack messages, and verbal agreements. Courts have found informal email exchanges to constitute binding amendments when the MSA did not explicitly require written, signed changes. The fix is a single sentence: "This Agreement may not be amended except by a written instrument signed by authorized representatives of both parties."
For Order Forms and SOWs, use a change order procedure that requires the same written sign-off. A change order template attached as an exhibit to the SOW is the cleanest approach.
Lifecycle management
After execution, the MSA needs periodic maintenance. Review it annually or when your product materially changes. Common triggers for a formal amendment include adding new product lines not covered by the original scope, changes to your sub-processor list that require DPA updates, and new state privacy laws that affect your data handling obligations. A contract platform with template and playbook storage makes it straightforward to track which version of your MSA is in use with each customer and flag agreements that are due for review.
How Formable supports MSA drafting, negotiation, and management
Contract platforms built for legal and GTM teams reduce the time from first draft to signature by giving you templates, clause libraries, and automated risk detection in one place. Formable is designed specifically for this workflow.
- Template library: Start from a vendor-favorable MSA template with pre-built clauses for license grants, IP retention, liability caps, DPAs, and SLAs. Adapt the template to your product without starting from a blank document.
- Contract creation with AI: Formable's contract creation tool combines templates with generative AI so you can produce a first draft in minutes and iterate on clause language without switching between tools.
- AI contract review: — Upload a customer-paper MSA and Formable flags work-for-hire language, missing liability caps, overly broad IP assignments, and absent DPA provisions automatically. Playbooks let you define your negotiation positions once and apply them consistently across every deal.
- AI addendum support: For AI-enabled software, Formable provides an AI addendum template that covers model training rights, data residency, and breach notification language, the provisions enterprise customers are most likely to scrutinize.
For legal teams managing AI contract review across a high volume of enterprise deals, the combination of playbook enforcement and automated risk scanning reduces the time spent on routine clause review and keeps negotiation positions consistent.
Key takeaways
A well-drafted software MSA keeps your IP, caps your liability, and gives you a repeatable framework for every enterprise deal that follows.
| Point | Details |
|---|---|
| Two-tier document structure | Keep legal terms in the MSA; push pricing, scope, and duration to Order Forms and SOWs. |
| IP retention is non-negotiable | Vendor retains background IP; customer receives a limited license, never ownership of platform code. |
| Liability cap standard | Tie the cap to fees paid in the prior year; keep carve-outs narrow (fraud and willful misconduct only). |
| DPA and breach notification | Include a DPA exhibit and commit to breach notification within 72 hours; address AI model training rights explicitly. |
| Formable accelerates the workflow | Use Formable's MSA templates, AI risk scanning, and redlining tools to produce a first draft and close deals faster. |
The clause that most legal teams underestimate
Most in-house counsel moving from a professional services background to a SaaS context focus their energy on the liability cap and the indemnity. Those are important. But the clause that causes the most long-term damage is the one that gets the least attention: the acceptance clause.
In a professional services MSA, acceptance is tied to a deliverable. A customer reviews a document, a design, or a piece of code and either accepts or rejects it. That model maps cleanly onto project work. In a SaaS MSA, there are no discrete deliverables in the traditional sense. The software is always running, always being updated, and always subject to the customer's evolving expectations. An acceptance clause drafted for professional services, dropped into a SaaS MSA without modification, creates a permanent right for the customer to reject the software at any point by claiming it does not conform to undocumented specifications.
The practical consequence is that customers use open-ended acceptance language as leverage during billing disputes. They have not "accepted" the software, so they argue payment is not yet due. The fix is simple: define acceptance as the earlier of written approval or the expiration of a 10-business-day review window, and tie it to written specifications in the SOW, not to the customer's subjective satisfaction.
The same blind spot appears in the survival clause. Legal teams often list confidentiality and IP as surviving termination but forget to include the limitation of liability. If the limitation of liability does not survive, a customer can bring a claim after the agreement ends and argue the cap no longer applies. Explicitly list every clause that should survive, including limitation of liability, payment obligations, and governing law.
Close deals faster with Formable's MSA workflow
Drafting a software MSA from scratch takes time, and every round of redlines with a customer's legal team adds weeks to your sales cycle. Formable cuts that cycle by giving your team a vendor-favorable MSA template, an AI review engine that flags risky clauses at intake, and a collaborative redlining tool that keeps both parties aligned before signature.
Upload a customer-paper MSA and Formable's playbook engine identifies work-for-hire language, missing liability caps, and absent DPA provisions in minutes. Your team negotiates from a consistent position on every deal, not just the ones where senior counsel has time to review. When terms are agreed, e-signing is built in, with a full audit trail and timestamp for every signature event. For teams building on top of Formable's API, e-signing and redlining can be embedded directly into your own platform.
Start with a free MSA template or upload your current agreement for an AI risk scan at formabledocs.com.
Useful sources
The sources below provide deeper clause language, regulatory guidance, and security framework references for US software MSAs.
- Master Service Agreement for SaaS: How It Works and What to Watch in Customer MSAs | Terms of Service Lawyer — Expert Terms and Conditions Lawyer
- SaaS MSA for AI Companies: What Founders Must Know | Andrew S. Bosin LLC
- Master Service Agreement Guide: Clauses, Red Flags & Negotiation (2026) | ReviewMyContract
- Master Service Agreement Template: How to Write an MSA | Contractable
- Master service agreement: Templates and resources for ... | Thomson Reuters
- Master service agreement law | Daeryun Law
| Resource | Best used for |
|---|---|
| Terms of Service Lawyer (toslawyer.com) | SaaS IP and work-for-hire clause review |
| Andrew S. Bosin LLC (njbusiness-attorney.com) | AI product DPA and breach notification drafting |
| ReviewMyContract (reviewmycontract.ai) | Order of precedence and survival clause guidance |
| Thomson Reuters Legal Blog | Security framework references (SOC 2, ISO 27001, NIST) |
| Daeryun Law | Amendment procedure and post-termination obligations |
| AETHER Pulse | GDPR/CCPA compliance for AI-enabled software |
| Formable (formabledocs.com) | MSA templates, AI risk scanning, redlining, and e-signing |
FAQ
What should be included in a master service agreement?
A software MSA should include a license grant, IP ownership and background IP retention, payment terms, confidentiality, a Data Processing Agreement exhibit, security obligations, warranties and disclaimers, an SLA, indemnities, a liability cap tied to prior 12 months of fees, term and termination, survival clauses, amendment procedure, and governing law.
What is a master software as a service agreement?
A SaaS MSA is a framework contract between a software vendor and a customer that governs the legal terms for all subscription orders. Unlike a professional services MSA, it grants a license to access software rather than assigning deliverables, and it must address data processing, AI model training rights, and uptime obligations specific to hosted software.
What are common MSA drafting mistakes?
The most common mistakes are: including work-for-hire or blanket IP assignment language that exposes platform IP, omitting a DPA exhibit when the software processes personal data, using open-ended acceptance windows that allow customers to withhold payment indefinitely, and failing to list which clauses survive termination.
What is an MSA in software sales?
In software sales, an MSA is the master legal agreement that a vendor and an enterprise customer sign before any Order Form or SOW. It sets the terms that apply to every transaction, so neither party needs to renegotiate liability, IP, or data protection each time a new order is placed.
How long does it take to negotiate a software MSA?
Enterprise MSA negotiations typically run 4–8 weeks from first draft to signature, depending on the customer's legal team and internal approval process. Budget for two to three rounds of redlines on the core risk allocation clauses, with the longest delays usually occurring on IP, liability caps, and DPA terms.
