What Should Be in Every SaaS Master Services Agreement

A SaaS master services agreement (MSA) should cover nine core areas: scope of services and order forms, service levels, data handling and security, intellectual property, limitation of liability, indemnification, term and termination, confidentiality, and governing law. The MSA sets the standing legal terms of the customer relationship; individual order forms then plug into it with pricing and specifics. Get those nine sections right and you have a framework for handling most disputes before they escalate.

The MSA is the backbone of every SaaS vendor-customer relationship. It sets the rules of engagement before any order form gets signed, any data gets transferred, or any integration goes live. Yet many SaaS companies — especially early-stage ones — either cobble together a template from the internet or accept whatever their first enterprise customer sends over without negotiation. Consider working with a SaaS contract attorney to protect your interests.

Both approaches are dangerous. A poorly drafted MSA can expose you to unlimited liability, lock you into unfavorable terms for years, or create ambiguity that turns a minor disagreement into full-blown litigation.

Here is what every SaaS master services agreement should include — and why each clause matters.

What Should the Scope of Services Section Cover?

The MSA should establish the framework. The specific services, pricing, and term lengths belong in separate order forms (sometimes called statements of work or subscription agreements) that reference the MSA.

This two-layer structure gives you flexibility. You can add new products, adjust pricing, or modify terms for specific customers without renegotiating the entire agreement. The MSA governs the relationship; the order forms govern individual transactions. (If the split between the two documents is new to you, we wrote a plain-English breakdown: MSA vs SOW: What's the Difference?)

Key elements to include:

• A clear statement that the MSA governs all order forms unless an order form explicitly overrides a specific provision
• A hierarchy of documents clause (what controls if there is a conflict between the MSA, order form, and any attachments)
• Definitions for key terms like "Services," "Customer Data," and "Authorized Users"

What Service Level Terms Belong in an MSA?

Your SLA section defines what "working" means. Without it, every customer has their own interpretation of acceptable performance, and you will lose every argument.

A strong SLA section should cover:

• Uptime commitment — 99.9% is industry standard for most SaaS products. Define how uptime is measured (monthly, quarterly) and what counts as "downtime" (hint: scheduled maintenance should not)
• Response times — Categorize issues by severity and commit to specific response (not resolution) times for each tier
• Service credits — The remedy for missing your uptime target. Credits against future invoices are standard; avoid agreeing to refunds or the right to terminate for a single SLA miss
• Exclusions — Force majeure events, customer-caused issues, and third-party service outages should be carved out

How Should the MSA Handle Data and Security?

This is where most SaaS MSAs either shine or catastrophically fail. Your customers are trusting you with their data, and the agreement needs to reflect that responsibility.

Data ownership: State clearly that the customer owns their data. You have a limited license to process it solely to provide the services. This seems obvious, but many template agreements are ambiguous on this point.

Security obligations: Commit to reasonable security measures consistent with industry standards. Reference specific frameworks (SOC 2 Type II, ISO 27001) if you hold those certifications, but be careful about committing to certifications you do not yet have.

Data processing addendum: If you process personal data subject to GDPR, CCPA, or other privacy laws, attach a DPA. Do not try to bury data processing terms in the body of the MSA — regulators and sophisticated customers expect a standalone DPA.

Breach notification: Commit to notifying the customer within a specific timeframe (72 hours is common) after discovering a data breach affecting their data. Define what qualifies as a breach and what information the notification must contain.

Who Owns the Intellectual Property?

The IP section needs to answer three questions clearly:

1. Who owns what? You own the platform, the underlying technology, and any improvements. The customer owns their data and any custom configurations they build.
2. What licenses are granted? The customer gets a limited, non-exclusive license to use the services during the term. You get a limited license to use their data to provide the services.
3. What about feedback? If a customer suggests a feature and you build it, who owns it? Most SaaS agreements include a feedback clause granting the vendor ownership of any suggestions or ideas. This is standard and reasonable, but it should be explicit.

What Should the Limitation of Liability Clause Say?

This is the clause that matters most when things go wrong. Without a well-drafted limitation of liability, a single customer dispute could threaten your entire company.

Standard structure:

• Cap on direct damages — Typically limited to the fees paid in the 12 months preceding the claim. Some customers will push for 24 months or a multiple of annual fees
• Exclusion of indirect damages — Both parties waive consequential, incidental, and special damages (lost profits, lost data, business interruption)
• Carve-outs — Certain obligations should sit outside the liability cap: indemnification for IP infringement, breach of confidentiality, willful misconduct, and payment obligations

Do not agree to unlimited liability for data breaches. This is a common ask from enterprise customers, and it is one you should resist. Instead, negotiate a separate, higher sub-cap for data breach claims — perhaps two or three times the general liability cap.

How Does Indemnification Work in a SaaS MSA?

Indemnification allocates the risk of third-party claims. In a SaaS context, the typical structure is:

• Vendor indemnifies customer for claims that the services infringe a third party's intellectual property rights
• Customer indemnifies vendor for claims arising from the customer's data, their use of the services in violation of the agreement, or their violation of applicable law

The indemnification process matters as much as the obligation itself. Include clear procedures: prompt notice of claims, the indemnifying party's right to control the defense, and the indemnified party's obligation to cooperate.

How Should Term, Renewal, and Termination Work?

Ambiguity in termination provisions creates the most disputes I see in SaaS contracts. Be explicit about:

• Initial term and renewal — Auto-renewal is standard, but specify the renewal period and the notice window for non-renewal (30 to 90 days before the end of the current term)
• Termination for cause — Either party should be able to terminate if the other materially breaches and fails to cure within a specified period (usually 30 days after written notice)
• Termination for convenience — Customers will often request this. If you agree, require a minimum notice period and make clear that prepaid fees are non-refundable
• Effect of termination — What happens to the customer's data? Best practice is to provide a data export period (30 to 60 days) after termination, then delete the data

What Does the Confidentiality Clause Need to Cover?

A mutual confidentiality provision protects both parties. Cover:

• What qualifies as confidential information (broad definition with specific exclusions for publicly available information, independently developed information, etc.)
• The standard of care (at least the same care the receiving party uses for its own confidential information, but no less than reasonable care)
• Duration of the obligation (typically survives for two to three years after disclosure, or indefinitely for trade secrets)

Which Governing Law and Dispute Resolution Terms Should You Choose?

Choose your governing law deliberately. If you are a Connecticut-based SaaS company, Connecticut law is a reasonable choice. Avoid agreeing to govern under the law of your customer's state unless you understand the implications.

For dispute resolution, you have two main options:

• Litigation with an exclusive venue clause (courts in your home jurisdiction)
• Arbitration (faster and more private, but can be more expensive for smaller disputes)

Many SaaS companies use a tiered approach: mandatory negotiation first, then mediation, then arbitration or litigation. This structure resolves most disputes before they escalate.

The Takeaway

A strong MSA is not a formality — it is a strategic asset. It sets expectations, allocates risk, and gives you a framework for handling problems before they become crises. Each clause discussed above shows up in real disputes, and the companies with clear, well-drafted language come out better than those without it.

If you are building or revising your SaaS MSA, run it against the nine sections above and fix the weakest one first — for most companies that is the limitation of liability or the data terms. If you want a lawyer's eyes on it, we offer a $50 consultation. Book a consultation here.

Disclaimer: This blog post is intended for informational purposes only and does not constitute legal advice. Every contract and business situation is different. Please consult a qualified attorney for advice specific to your situation.