SaaS MSA Issue Checklist

This checklist drives Pass 2 of the review. Issues are organized into four tiers:

• Tier 1 — Always reviewed in detail. Covered in both comprehensive and quick_triage.
• Tier 2 — Reviewed in detail in comprehensive only. In quick_triage, surfaced only when materially deviant.
• Tier 3 — Reviewed in detail in comprehensive only. Drafting cleanliness; rarely material on their own.
• Tier 4 — SaaS-specific provisions; treated like Tier 2 (detailed in comprehensive, deviation-only in quick_triage).

For each item, classify: Present and standard / Present but unusual / Missing / N/A.

Items marked with † are particularly perspective-sensitive — the same clause language reads very differently depending on which side the user is on. See perspective_lens.md for how to flip the lens.

Tier 1 — Always reviewed in detail

1.1 Limitation of Liability †

What it is: the clause capping each party's aggregate liability arising under the agreement.

What "standard" looks like:

• Mutual cap, typically expressed as fees paid in the prior 12 months. Some enterprise deals run higher (24 months, 2x annual fees) or use multipliers.
• Carve-outs from the cap for: confidentiality breach, indemnification obligations, gross negligence, willful misconduct, infringement, and the customer's payment obligations.
• Many MSAs include a "super-cap" for specific high-stakes categories — security incidents involving customer data, breaches of data protection obligations — typically 2x or 3x the base cap.
• Mutual exclusion of indirect, incidental, consequential, special, exemplary, and punitive damages, with carve-outs that mirror the cap carve-outs.

What's unusual:

• Cap below 12 months of fees (favors vendor; problematic for customer).
• Cap above 24 months without an enterprise-grade context (favors customer; unusual but not problematic).
• Missing standard carve-outs (gross negligence, willful misconduct, IP indemnification, customer payment obligations) — flag whichever side is disadvantaged.
• Asymmetric caps in a "mutual" cap clause.
• No super-cap for security incidents in deals where customer data is sensitive (problematic for customer in security-sensitive deals).
• Caps that include or exclude "amounts paid" inconsistently between sections.
• Limitation of liability provisions that appear to cap the customer's payment obligations (always a drafting error; flag).
• Liquidated damages provisions in addition to the cap structure (uncommon; flag).

1.2 Indemnification †

What it is: mutual or one-sided obligations to defend and pay damages for specified third-party claims.

Standard SaaS MSAs typically have three indemnification components:

• Vendor's IP indemnity: vendor indemnifies customer against third-party IP infringement claims arising from the service. Standard exceptions: customer's modification of the service, combination with third-party products, customer's use in violation of agreement, customer-provided content.
• Customer's content/use indemnity: customer indemnifies vendor against third-party claims arising from customer's data, customer's use of the service in violation of laws, or customer's misuse.
• Mutual confidentiality indemnity: sometimes present, sometimes folded into general damages claims.

What "standard" looks like:

• Vendor IP indemnity covering claims that the service infringes third-party patents, copyrights, trademarks, or trade secrets.
• Standard exceptions to vendor IP indemnity (modification, combination, customer content, etc.).
• Vendor's right and obligation to: defend the claim, control settlement, and either replace the infringing component, modify it to be non-infringing, obtain a license, or refund.
• Customer indemnity scoped to customer's content, customer's misuse, and customer's violations.
• Procedural mechanics: prompt notice, control of defense, cooperation, no settlement without consent.

What's unusual:

• No vendor IP indemnity at all — flag as critical for customer; standard for some vendors but problematic.
• Vendor IP indemnity excludes patents (sometimes structured as "no patent indemnity" in cost-sensitive deals; flag for customer).
• "Sole and exclusive remedy" language for IP infringement that would limit customer's other recourse — increasingly viewed as overreach; flag for customer.
• Customer indemnity scope that extends beyond customer's actual conduct (e.g., "any claim arising out of customer's use of the service" without limitation) — favors vendor.
• Indemnity capped at the LoL cap (which would make the indemnity nearly worthless for high-value claims) — flag whichever side is disadvantaged.
• No procedural protections (no notice requirement, no cooperation, no consent for settlement) — favors the indemnified party in some respects but creates uncertainty.

1.3 Intellectual Property and Customer Data Ownership †

What it is: allocation of IP rights between vendor's service IP and customer's data and content.

What "standard" looks like:

• Vendor owns all IP in the service, including the platform, software, documentation, and any improvements vendor makes (whether based on customer feedback or otherwise).
• Customer owns all IP in customer data — the data customer uploads to or generates within the service.
• Customer grants vendor a license to use customer data solely for purposes of providing the service (and, sometimes, narrow ancillary purposes — service improvement, anonymized analytics).
• Feedback provided by customer becomes vendor's property or licensable to vendor (depending on the drafting).
• Customer retains all rights not expressly granted.

What's unusual:

• Customer data licensed to vendor for vendor's "internal business purposes" beyond service operation — flag as material for customer.
• Customer data licensed to vendor for "service improvement" without customer opt-out — increasingly contested; flag as material for customer.
• Customer data licensed for "training of machine learning models" or "training of AI/ML systems" — flag as critical for customer in deals where customer data is sensitive or proprietary; this is the dominant new issue in 2025-2026 SaaS deals.
• "Aggregated and anonymized" data carve-outs that effectively allow vendor to monetize customer data — flag for customer; the anonymization standard is often weaker than the GDPR's.
• Feedback provisions that assign all customer feedback to vendor without limitation — flag as material for customer.
• Vendor IP grant to customer that is narrower than necessary to use the service (e.g., excludes customer's own service users in a multi-tier resale model) — flag for customer.
• Vendor's IP grants tied to specific deployment models that don't match the actual deployment — flag.

1.4 Data Protection (DPA Reference)

What it is: the MSA's incorporation of and reference to a Data Processing Agreement.

What "standard" looks like:

• Express incorporation of a DPA (either appended to the MSA as an exhibit or executed separately).
• Statement that the DPA controls data protection terms; the MSA does not duplicate substantive DPA terms.
• Reference to the applicable regulatory regimes (GDPR, US state privacy, HIPAA where applicable, etc.).
• The DPA itself is then reviewed by the DPA Checklist Review skill, not by this MSA review.

What's unusual:

• No DPA at all — flag as critical for customer if any personal data is being processed; flag as material for vendor (regulatory exposure).
• DPA "available on request" but not attached or pre-executed — flag as material; the operative DPA terms should be locked at MSA signing.
• DPA terms scattered through MSA without a structured DPA document — flag as material; the unbundled approach makes compliance assessment difficult.
• Reference to a DPA that is dated (e.g., "the parties' 2020 DPA") in a regime that has materially changed (CCPA→CPRA, GDPR transfer mechanism updates) — flag as material; DPA may be stale.

1.5 Warranties and Disclaimers †

What it is: vendor's affirmative warranties about the service and the disclaimer of other warranties.

What "standard" looks like:

• Express warranties (vendor): service will perform substantially in accordance with documentation; service will be provided in a workmanlike manner; vendor has the right to provide the service; service will not introduce malicious code; vendor maintains a security program (often by reference to a Trust Center or security exhibit).
• Disclaimer: of all other warranties, express or implied, including merchantability, fitness for a particular purpose, non-infringement (typically already covered by IP indemnity), accuracy, and uninterrupted operation.
• Customer warranties: customer has the right to provide its data; customer's data does not violate third-party rights; customer's use complies with applicable laws.

What's unusual:

• Missing the basic vendor express warranties (workmanlike performance, right to provide service) — flag as critical for customer.
• Disclaimer of warranties that haven't been disclaimed in the express warranties — internal inconsistency, flag.
• Disclaimer of vendor's data protection or security commitments — flag as critical for customer.
• "AS IS" service warranty without any express warranty — vendor-aggressive; flag as critical for customer.
• Customer warranty extending beyond customer's actual control (e.g., "customer warrants that customer's users will not violate AUP") — flag for customer; customer should warrant only its own conduct.

1.6 Term and Termination †

What it is: how long the agreement lasts, how it renews, and how it can be terminated.

What "standard" looks like:

• Term: initial term of one to three years, with auto-renewal unless either party gives notice of non-renewal (typically 30–90 days before end of term).
• Termination for cause: either party can terminate for material breach by the other, with notice and cure period (typically 30 days).
• Termination for convenience: sometimes — if present, typically allows the customer to terminate with refund of unused fees, often with a cap on refund or a notice period.
• Termination for insolvency: either party can terminate on the other party's bankruptcy, insolvency, or assignment for benefit of creditors.
• Effect of termination: customer pays all amounts owed; vendor stops providing service; data return/deletion per DPA; survival of confidentiality, indemnification, payment, limitation of liability, and other relevant provisions.

What's unusual:

• Vendor-favorable patterns to flag:
  • Long auto-renewal opt-out windows (60+ days) — favors vendor.
  • Unilateral price increases at renewal beyond a stated cap — flag for customer.
  • No customer termination for convenience — typical but worth noting in long-term deals.
  • Termination-for-cause notice/cure that effectively prevents customer's exit (excessively long cure periods, ambiguous breach definitions).
• Customer-favorable patterns to flag:
  • Customer termination for convenience without proportionate refund cap — favors customer.
  • Aggressive vendor termination liability (e.g., forfeiture of all prepaid amounts on vendor's termination for cause) — flag for vendor.
• Both-side issues:
  • No termination-for-insolvency provision — both parties should want this.
  • Auto-renewal mechanics with no notice obligation from vendor (customer must remember the deadline unilaterally) — flag for customer.
  • "Termination for change of control" provisions that aren't symmetric (e.g., vendor can terminate on customer's change of control but not vice versa) — flag.

1.7 Payment, Pricing, and Renewal Pricing †

What it is: the financial terms — what the customer pays, when, how, and how prices change at renewal.

What "standard" looks like:

• Pricing: specified in Order Form; MSA reserves Order Form precedence on pricing.
• Invoicing: typically annual in advance for SaaS subscriptions; payment net 30 from invoice.
• Late fees: typically 1.5% per month on overdue amounts (or the maximum permitted by law).
• Suspension/acceleration: vendor may suspend service for non-payment after notice and cure period (typically 10–15 days); some MSAs include acceleration of all remaining contract value on uncured breach.
• Renewal pricing: either fixed (uncommon) or capped (e.g., "no more than CPI + X%" or "no more than 5% per year"). Sometimes uncapped (vendor-favorable).
• Tax: customer pays applicable taxes; vendor responsible for its own income tax.

What's unusual:

• No cap on renewal price increases — flag as material for customer; multi-year renewals can balloon unpredictably.
• Suspension rights without notice or cure period — flag as critical for customer; vendor can take service offline without warning.
• Acceleration clauses that demand all remaining contract value on minor breach — flag as material; converts ordinary breach disputes into existential financial events.
• Late fees beyond statutory maximum — flag as minor (state usury law may make excess unenforceable).
• Right to charge for usage above committed levels without notice or cap — flag for customer.
• Payment of "fees and any other charges as billed" without itemization — flag for customer; transparency issue.

1.8 Service Level Agreement (SLA)

What it is: vendor's commitments on service availability, performance, and the customer's remedies for SLA breach.

What "standard" looks like:

• Uptime commitment: typically 99.5% to 99.99% for enterprise-grade SaaS.
• Calculation methodology: monthly basis; excluded periods (scheduled maintenance, force majeure, customer-caused issues).
• Remedies: SLA credits typically 5–10% of monthly fees per percentage point below commitment, with a cap (typically 25–50% of monthly fees).
• Remedy as exclusive: SLA credits typically stated as customer's "sole and exclusive remedy" for SLA misses; carve-outs sometimes for material/repeated breaches.
• Reporting: vendor provides uptime reports; customer must request credits within a stated period.

What's unusual:

• No SLA at all — flag as material for customer in any non-trivial deal; flag for vendor as missing customer expectation.
• Uptime commitment below 99.5% in an enterprise context — flag for customer.
• Excessive exclusion list that effectively eliminates the SLA (e.g., "scheduled maintenance" with no time bound or "force majeure" defined to include vendor's own infrastructure failures) — flag for customer.
• SLA credits as truly exclusive remedy even for repeated material failures — flag for customer; customers typically want exit rights for chronic SLA breach.
• No customer right to terminate for chronic SLA breach — flag for customer.
• Asymmetric SLA reporting (customer must report incidents within 24 hours but vendor reports monthly) — flag for customer.

Tier 2 — Reviewed in detail in comprehensive only

2.1 Confidentiality

What it is: mutual confidentiality obligations covering information shared between the parties (distinct from customer data and DPA terms).

Standard pattern: mutual confidentiality with carve-outs (publicly available, prior knowledge, independent development, third-party receipt, compelled disclosure with notice). Term typically 3–5 years post-termination.

Unusual: missing entirely; one-sided when both parties share confidential information; perpetual obligations on broad categories.

2.2 Assignment

Standard pattern: mutual restriction with consent; carve-outs for change of control, M&A, internal reorganization. Either party retains right to assign to successor.

Unusual: unilateral right by one party; broad consent rights that block legitimate M&A; assignment to direct competitor of the other party (sometimes flagged in customer-favorable templates).

2.3 Governing Law and Venue

Standard pattern: specified state's law and forum (state or federal court in that state) or arbitration with specified rules. Delaware, New York, and California are the most common state choices.

Unusual: no governing law specified; vendor's home jurisdiction in a jurisdiction with no nexus to the deal; non-US jurisdiction in an otherwise-US deal; mandatory arbitration in a venue inconvenient to customer.

2.4 Dispute Resolution

Standard pattern: specifies how disputes are resolved — court litigation, arbitration (JAMS, AAA, ICC, CPR), or tiered (negotiation → mediation → arbitration). Arbitration choices specify the rules, the seat, and the language.

Unusual: mass arbitration prohibitions that block class actions; mandatory pre-suit mediation that delays equitable relief; arbitration with class waiver in jurisdictions where consumer-protection rules invalidate.

2.5 Force Majeure †

Standard pattern: mutual carve-out for events beyond reasonable control. Typically excuses non-performance other than payment obligations. Includes notice, mitigation, and termination right if FM continues beyond X days.

Unusual:

• FM defined to include vendor's own infrastructure failures or cloud-provider outages — flag for customer; this swallows the SLA.
• Asymmetric — excuses vendor's service failure but not customer's payment obligation (typical and acceptable; flag if extreme).
• No termination right after extended FM — flag.

2.6 Change-of-Terms Mechanics †

What it is: vendor's right to modify the MSA, AUP, or service over time.

Standard pattern: vendor may modify the AUP and operational policies on notice; material changes to MSA terms require customer consent or trigger customer's right to terminate without penalty.

Unusual:

• Unilateral right to modify all MSA terms on notice — flag as critical for customer.
• "Continued use constitutes acceptance" of modified terms without customer's express opt-in or termination right — flag as critical for customer.
• AUP modifications without notice — flag as material.

2.7 Suspension and Acceleration

Already covered in §1.7 above.

2.8 Professional Services Scope

If the MSA includes professional services (implementation, configuration, integration, training):

Standard pattern: PS scope governed by SOW; deliverables specified in SOW; PS-specific warranties (workmanlike performance, IP rights in deliverables); customer ownership of PS deliverables (with vendor retaining IP in pre-existing tools).

Unusual: PS terms scattered without clear SOW reference; vendor IP ownership of PS deliverables (typical for vendor-favorable templates; flag for customer); broad customer indemnity for PS-related claims; PS warranty disclaimers that swallow the warranty.

2.9 Third-Party Components

What it is: disclosure of and terms for third-party components or sub-services included in the SaaS offering.

Standard pattern: vendor identifies third-party components (typically in a schedule or by reference to a website); pass-through of third-party terms where applicable; vendor remains responsible for third-party performance under the MSA.

Unusual: broad disclaimers of vendor responsibility for third-party components — flag as critical for customer if third-party components are material to service delivery; missing identification of third-party components when service obviously depends on them; pass-through of third-party terms that conflict with the MSA.

Tier 3 — Reviewed in detail in comprehensive only

3.1 Notice mechanics

Email + physical mail typically; specified addresses; deemed delivered timing.

3.2 Integration / Entire Agreement

Standard integration clause; amendments in writing.

3.3 Amendment Requirements

Already covered in §2.6 (change-of-terms mechanics) where unilateral modification is contemplated.

3.4 Severability

Standard severability clause.

3.5 Waiver

Standard non-waiver clause.

3.6 Counterparts and Electronic Signatures

Standard.

3.7 Definitions Completeness

Verify that defined terms are actually defined; flag undefined uses or used terms that aren't defined.

3.8 Headings

Standard "headings are for convenience only" clause.

Tier 4 — SaaS-specific provisions

4.1 Acceptable Use Policy (AUP)

Standard pattern: AUP referenced or attached; restrictions on customer use (no malicious code, no service abuse, no resale or unauthorized access, no scraping); vendor's right to enforce AUP via suspension or termination.

Unusual: AUP terms that effectively block legitimate use; vendor's right to unilaterally modify AUP without notice; AUP enforcement without notice or cure.

4.2 Customer Data Definition

Standard pattern: "Customer Data" defined as data submitted by or for customer; customer retains ownership; clear distinction from "Vendor Data" (operational telemetry, anonymized usage data).

Unusual: narrow Customer Data definition that excludes data customer expects to be customer's; vendor data definition that includes customer-identifying data.

4.3 Data Residency and Localization

Standard pattern: vendor specifies data center locations; data residency commitments where customer requires; sub-processor disclosure (typically by reference to DPA).

Unusual: no commitment on data location; right to move data without notice; data residency commitments that don't match vendor's actual infrastructure.

4.4 Sub-processor Management

Typically covered by DPA. MSA-level reference should track DPA.

4.5 Audit Rights †

Standard pattern: customer's audit rights typically routed through SOC 2 Type II reports plus on-site audit on cause; vendor's audit rights typically of customer's compliance with AUP and license metrics.

Unusual: asymmetric audit rights (vendor audits customer but not vice versa); vendor's broad audit rights with substantial fees; no customer audit rights even via report review.

4.6 Security Incident Response

Standard pattern: typically covered by DPA; MSA-level reference should track. Where MSA contains independent security incident provisions, check timeline (24-72 hours typical), required content, cooperation obligations.

4.7 Business Continuity / Disaster Recovery

Standard pattern: stated RTO and RPO commitments; reference to BC/DR plan; testing cadence.

Unusual: missing entirely in enterprise contracts (flag); vague commitments without specific RTO/RPO.

4.8 Support and Maintenance Windows

Standard pattern: support hours specified; response time commitments by severity tier; planned maintenance windows.

Unusual: unspecified maintenance windows; response time commitments that don't match SLA exclusions.

4.9 Third-Party Authentication and SSO

Standard pattern: support for SAML 2.0, OIDC, SCIM (where applicable); customer's responsibility for IdP configuration; vendor's responsibility for federation reliability.

Unusual: SSO available only on premium tier (flag for enterprise customer); vendor's right to charge for SSO (becoming less common but historically present).

4.10 API Rate Limits and Overage Handling

Standard pattern: rate limits specified in documentation; overage handling specified (throttling, blocking, billing for additional capacity); customer notification before service-affecting limits.

Unusual: rate limits not documented; overage handling that allows vendor to suspend service without notice; overage billing without cap.