msa-review-saas

Files (14)

• SKILL.md
• baseline-customer.md · acceptance/fixtures/
• data-handling-critical.md · acceptance/fixtures/
• vendor-perspective.md · acceptance/fixtures/
• baseline-customer.golden.json · acceptance/snapshots/
• data-handling-critical.golden.json · acceptance/snapshots/
• vendor-perspective.golden.json · acceptance/snapshots/
• example_customer_review.md · examples/
• example_vendor_review.md · examples/
• issue_checklist.md · reference/
• perspective_lens.md · reference/
• red_flags.md · reference/
• severity_rubric.md · reference/
• test-plan.md

SKILL.md (first lines)

# MSA Review — SaaS

Conduct a structured review of a SaaS Master Services Agreement from the user's stated perspective and produce a report that an in-house lawyer can act on without redoing the analysis. The output is a draft for human review, not a final word; treat it accordingly.

This skill is calibrated to commercial-grade SaaS MSAs. It is not designed for: enterprise software license agreements (perpetual licenses), professional services agreements without a software component, hosted-but-not-SaaS arrangements (managed hosting, IaaS), or government / public-sector SaaS contracts (which have additional FedRAMP, FAR, and procurement-specific overlays).

## When this skill applies

Apply when the user provides a SaaS MSA, Master Subscription Agreement, SaaS Agreement, Cloud Services Agreement, or substantively similar instrument and asks for review or redline guidance. The user's perspective — vendor or customer — fundamentally changes the analysis; require it before proceeding if not supplied.

Do not apply this skill to:

- **Non-SaaS software agreements.** Perpetual license agreements, on-premises software agreements, and managed-hosting agreements have different fundamental structures (license vs. subscription, on-premises vs. cloud, software-only vs. service). Tell the user this is the wrong skill.
- **Order Forms or SOWs alone.** Those documents reference an MSA; review them in conjunction with the MSA (use the optional `order_form` input) or via a dedicated Order Form Review skill (deferred — see DE-070).
- **DPAs / Privacy Addenda.** Use DPA Checklist Review for those.
- **NDAs accompanying the SaaS deal.** Use NDA Review for those.
- **Government / public-sector SaaS.** Federal and state procurement requirements layer additional terms (FedRAMP, FAR clauses, procurement statutes) that this skill does not cover.

## Inputs

The skill requires the document and perspective. If perspective is not provided:

> "Before I review, which side are you on? Vendor (you're providing the SaaS service) or customer (you're subscribing to it)?"

Optional inputs refine the analysis:

- **`review_depth`** controls thoroughness. Default is `comprehensive` (all issues with detailed findings); `quick_triage` covers core issues only.
- **`jurisdiction`** affects findings on enforceability-sensitive provisions (limitation of liability, non-competes if any, choice of forum).
- **`deal_context`** changes severity calibration. A small-dollar SMB deal warrants different scrutiny than a high-value enterprise deal; an existing-relationship renewal warrants different scrutiny than a first-time vendor evaluation.
- **`order_form`** triggers MSA-vs-Order-Form conflict analysis (Pass 6, below).
- **`prior_agreements`** triggers conflict-with-prior-agreement analysis.
- **`standard_positions`** replaces the skill's generic benchmarks with the user's own — when the user's organization has its own fallback positions, those are the operative standard.

When optional inputs are not provided, the skill makes default assumptions and notes them in the report.

## Workflow

Produce the review in six passes. Earlier passes inform later ones; do not collapse them.

### Pass 1: Document orientation

Before substantive review:

- Confirm the document is a SaaS MSA. If it is a different instrument (perpetual license, professional services without SaaS, managed-hosting), stop and tell the user.
- Identify the parties; confirm vendor and customer roles match the user's stated perspective.
- Note the document structure: does it have clean section/article numbering, defined-terms section, integration with referenced documents (Order Form, DPA, AUP)?
- Note governing law, jurisdiction/venue, and any specified dispute-resolution mechanism (court, arbitration, JAMS, AAA).
- Note the contract length and complexity. SaaS MSAs typically run 8–30 pages; over 35 pages typically signals enterprise-grade complexity that warrants extra attention.
- Identify any annexes, schedules, exhibits, or service-specific terms.

### Pass 2: Standard-issue check

Walk through the standard SaaS MSA issue checklist in `reference/issue_checklist.md`. The checklist groups issues into four tiers:

- **Tier 1 — Always reviewed in detail (covered in both `comprehensive` and `quick_triage`):** liability, indemnification, IP and data ownership, data protection (DPA reference), warranties and disclaimers, term and termination, payment, key SLAs.
- **Tier 2 — Reviewed in detail in `comprehensive` only:** confidentiality, assignment, governing law and venue, dispute resolution, force majeure, change-of-terms mechanics, suspension and acceleration rights, professional services scope, third-party components.
- **Tier 3 — Reviewed in detail in `comprehensive` only:** notice mechanics, integration / entire-agreement, amendment requirements, severability, waiver, counterparts, electronic signatures, definitions completeness, headings.
- **Tier 4 — SaaS-specific provisions:** acceptable use policy reference, customer data definition, data residency and localization, sub-processor management (typically by reference to DPA), audit rights, security incident response, business continuity / disaster recovery, support / maintenance windows, third-party authentication and SSO, API rate limits and overage handling.

For each item, classify:

- **Present and standard:** the document addresses this issue and the addressing falls within the normal range for SaaS MSAs.
- **Present but unusual:** the document addresses this issue with non-standard scope, severity, or carve-outs.
- **Missing:** the document does not address this issue.
- **N/A:** this issue does not apply given the document type or specific facts.

### Pass 3: Perspective and asymmetry analysis

Read every Tier 1 finding through the user's perspective lens (`reference/perspective_lens.md`). The same provision reads very differently from each side:

- **Vendor perspective:** wants broad limitations of liability, narrow warranties, broad disclaimers, limited service commitments, customer-friendly payment obligations (auto-renewal, billing in advance, late fees, suspension rights), broad data-use rights for service operation, broad acceptable-use restrictions on customers, narrow customer indemnities, and operational flexibility (right to modify service, sub-processor changes, terms amendments).
- **Customer perspective:** wants strong service commitments backed by SLA credits, narrow disclaimers and reasonable warranties, controllable termination rights (especially for cause), reasonable liability allocation (super-caps for security and IP issues), strong data protection and ownership of customer data, customer-friendly IP indemnities, predictable pricing and renewal terms, and stability (limits on vendor's right to unilaterally change service or terms).

For each Tier 1 finding, identify which side the provision favors and by how much. For "present but unusual" findings, characterize the deviation: favorable / unfavorable / extreme.

### Pass 4: Operational and red-flag check

Beyond standard issues, look for provisions that create operational risk regardless of perspective. The full list is in `reference/red_flags.md`; key categories:

- **Unilateral amendment rights** that allow vendor to change terms without customer consent.
- **Acceleration clauses** that allow vendor to demand all remaining contract value on breach (especially when paired with broad breach definitions).
- **Suspension rights** that allow vendor to suspend service for non-payment without notice or cure.
- **IP assignments hidden in feedback or improvements clauses.**
- **Customer-data uses for vendor's own purposes** (model training, benchmarking, anonymized resale) without explicit customer consent.
- **Auto-renewal with long opt-out windows** (60+ days) and price-increase rights at renewal.
- **One-sided audit rights** (vendor's right to audit customer's usage but not customer's right to audit vendor's compliance).
- **Forum selection that creates significant disadvantage** to one side (especially Delaware Chancery or vendor's home court).
- **Mass arbitration provisions** that prohibit class actions and limit consolidation.
- **Termination for convenience without proportionate refund mechanics.**
- **Most-favored-nation clauses** on pricing or terms (uncommon but flag whenever present).
- **Source code escrow** absent or inadequate for the deal size.
- **Force majeure clauses** that excuse vendor's service failure but not customer's payment obligation.
- **Material conflicts with industry-standard SLAs** (e.g., 95% uptime in an enterprise contract).

### Pass 5: Conflicts with prior agreements

If `prior_agreements` was provided, examine the document for:

- Express references to the named prior agreements; confirm references are accurate.
- Integration / entire-agreement clauses that would extinguish prior agreement protections.
- Provisions that conflict with terms in the prior agreements.
- Term provisions that don't account for existing relationships (e.g., MSA term running concurrently with an existing services engagement).

If `prior_agreements` was not provided, this pass is skipped.

### Pass 6: MSA-vs-Order-Form conflict analysis

If `order_form` was provided, examine the Order Form against the MSA. Common conflicts:

- **Term length conflicts:** Order Form specifies a different subscription term than the MSA framework contemplates.
- **Pricing inconsistencies:** Order Form pricing references rates not in the MSA, or contradicts MSA pricing terms.
- **Service-level conflicts:** Order Form's stated SLA differs from the MSA's referenced SLA.
- **Data-protection conflicts:** Order Form references different data categories or data-residency commitments than the MSA's DPA contemplates.
- **Termination-right conflicts:** Order Form's termination provisions modify or contradict MSA termination provisions.
- **Indemnification or warranty mods:** Order Form modifies MSA indemnification or warranty terms (typically vendor-favorable; sometimes substantial).
- **Governing-law conflicts:** Order Form specifies different governing law or venue (occasionally happens with multi-jurisdictional vendors).

The general interpretive rule (in most SaaS MSAs) is that Order Form-specific terms override MSA framework terms for that order; verify the MSA's "order of precedence" or "conflict" provision and apply it. If no conflict provision exists, flag — that itself is a deficiency.

From LegalQuants/lq-ai, Apache-2.0.

More from LegalQuants/lq-ai