Saas contract review

SaaS Contract Review

Author: Audrent Version: 1.0.0 Last reviewed: 2026-05-01 License: MIT

What this skill does

Reviews a software-as-a-service contract — typically a Master Services Agreement (MSA), order form, Data Processing Addendum (DPA), or end-user license agreement — against a configurable set of standard market terms. For each clause that deviates materially from market norms, produces a finding with: the offending language quoted, the specific risk it creates, a suggested redline, and a fallback position if the counterparty rejects the primary redline.

The skill is vertical-specific to SaaS (covering the contract patterns common to subscription software, including data processing, uptime commitments, and auto-renewal mechanics). Use a different tool for non-SaaS contracts (employment, M&A, real estate, etc.) where the standard markups are different.

What this skill does NOT do

Critical for honest customer expectations:

• This skill is not legal advice and does not create an attorney-client relationship. Software-assisted contract review is a productivity tool for in-house teams, business owners, and procurement staff — it complements but does not replace qualified legal counsel for any contract that materially impacts your business.
• It does not understand your specific business context. The right markups for a 10-person startup negotiating with an enterprise vendor differ from the right markups for an enterprise vendor negotiating with a 10-person startup. The skill flags general patterns; you decide which apply.
• It does not catch novel terms. The skill is grounded in market-standard SaaS contract patterns. Unusual provisions, novel terms specific to a single counterparty, or industry-specific compliance requirements (HIPAA BAAs, financial-services-specific terms) may pass through unflagged.
• It does not handle contract drafting from scratch. The skill reviews an existing draft. To draft a contract, start from a template (Bonterms, Common Paper, your law firm's templates) and use this skill to check the resulting draft.
• It does not validate execution mechanics. Counterparty signature authority, electronic signature compliance, contract storage and retention — all out of scope. Use Ironclad, DocuSign CLM, LinkSquares, or similar for contract operations.

When to invoke this skill

Use this skill when:

• A vendor sends a contract for your signature and you need to evaluate it before sending to legal counsel (or for low-risk contracts, instead of sending to legal).
• A customer redlines your standard contract and you need to assess which redlines to accept, push back on, or compromise on.
• You're auditing your existing contract stack to identify high-risk obligations or non-standard terms.
• You're scoping the legal-review effort on an inbound contract — the skill produces a triage that helps your lawyer focus on the real issues.

Do not invoke this skill for:

• Contracts where significant financial obligation, IP transfer, or liability exposure exists. Use a lawyer.
• Litigation-related agreements (settlements, releases, NDA disputes). Use a lawyer.
• Specific regulatory compliance (HIPAA BAAs, GDPR-specific provisions, financial-services contracts). Use a domain-specialized lawyer.
• Contract negotiations involving the company's existential interests (acquisitions, major partnerships, credit facilities). Definitely use a lawyer.

Configuration: who is reviewing for whom

Before reviewing, identify the perspective:

1. You as the customer reviewing a vendor's SaaS contract. Default position: you want stronger liability caps protecting you from vendor failures, broader vendor warranties, more termination flexibility, and stronger data protections.
2. You as the vendor reviewing customer redlines on your standard MSA. Default position: you want to limit your liability, push back on unbounded indemnity, hold the line on auto-renewal terms, and protect your IP.
3. You as the customer reviewing a vendor's order form (already-negotiated MSA exists). Order form review is more limited — focus on pricing, term, scope, and any newly-introduced terms.
4. You as the buyer in a procurement/centralized review process. Review through both lenses — your business interests and the company's standard contract policy.

The same clause can be acceptable from one perspective and unacceptable from the other. The output format below indicates which perspective the recommendation reflects.

Review methodology

Walk through the contract in this order. For each section, run the relevant checks. If a section isn't present in the contract, note "section absent" and assess whether that's acceptable (some terms can be omitted; others should always be present).

1. Contract structure and parties

Check:

• Parties correctly named and identified (legal entity names, not DBAs).
• Effective date specified.
• Recitals (whereas clauses) accurate and not creating obligations they shouldn't.
• Order of precedence specified if multiple documents (MSA, order form, DPA, EULA).
• Signatures from authorized parties (GC or VP-level commonly, depends on contract value).

Common gaps:

• Wrong legal entity (parent vs. subsidiary, DBA vs. legal name) — Critical to fix before signing.
• No order of precedence with multiple documents — High; specify that order forms govern over MSA on conflicts (or vice versa, depending on intent).

2. Definitions

Check:

• Key terms defined: "Services," "Customer Data," "Confidential Information," "Term," "Effective Date," "Authorized Users."
• Definitions of "Customer Data" broad enough to include all data the vendor processes on your behalf (not just data you "submit").
• "Affiliates" defined (if either party has affiliates that may receive services or use the contract).

Common gaps:

• "Customer Data" defined narrowly (only "data uploaded by Customer"), excluding logs, analytics, derived data → broaden to include all data processed on customer's behalf.
• "Authorized Users" undefined while contract limits use to authorized users → define explicitly with criteria.

3. Services description and scope

Check:

• What is being purchased is clearly described — features, modules, user counts, usage limits.
• Service level commitments referenced (or stated as not provided).
• Beta or experimental features flagged (and typically excluded from warranties).
• Vendor's right to modify services bounded (unilateral feature removal during term should be limited).

Common gaps (customer perspective):

• Vendor reserves unrestricted right to modify services → push back to "material adverse modifications require notice and right to terminate."
• Beta features included with no warranty disclaimer carve-out → fine if you're aware; problematic if you're relying on beta features for production.

4. Term, renewal, and termination

Check:

• Initial term length stated.
• Renewal mechanism: auto-renew or affirmative renewal? If auto-renew, what notice period to terminate?
• Termination for cause: what counts as cause, notice period, cure period.
• Termination for convenience: who has it, notice period, refund mechanics.
• Effect of termination: data return, license wind-down, surviving obligations.

Common issues:

Pattern	Issue	Customer redline	Vendor pushback
Auto-renew with 60+ day cancellation window	Customer may miss cancellation window, locked in another year	Tighten to 30 days OR require affirmative renewal	Vendor may agree to 30 days; affirmative renewal is harder
No termination for convenience by customer	Customer locked in even if dissatisfied	Add 30-day termination for convenience after first 6 months	Vendor will resist; common compromise is "early termination fee equal to remaining annual fees"
Termination for cause with no cure period	Either party can terminate immediately on any breach	Add 30-day cure period for non-payment, 60-day for material breach	Vendor typically agrees
No data return obligation	Customer's data held hostage post-termination	Add 30-day post-termination data export period, then deletion	Standard request; vendor should agree

5. Pricing and payment

Check:

• Fees clearly stated with no ambiguity.
• Payment terms (Net 30, Net 60, etc.).
• Late payment penalties.
• Price increase mechanism for renewal terms.
• Tax responsibility (typically on customer, but check for VAT scope).
• Refund mechanics (rare in SaaS but worth checking).

Common issues:

• Renewal price increase unbounded ("at vendor's then-current prices") → cap to CPI + N% or X% per year, whichever is lower.
• Overage charges not explicit → ensure usage thresholds and overage rates clearly defined.
• Late payment penalty 1.5% per month is standard; higher rates pushable down.

6. License grant and IP ownership

Check:

• License scope: what can the customer do with the services?
• IP ownership: vendor retains its IP, customer retains its data and any customer-developed integrations.
• Feedback license: vendors often want a license to use customer feedback. Acceptable if non-exclusive and non-personally-identifying; not acceptable if it creates broad IP transfer.
• Open source components: are they listed and is their licensing compatible with customer's use?

Common issues (customer perspective):

• Feedback license too broad (claims ownership of any improvements customer suggests) → narrow to non-exclusive license to use feedback for product improvement.
• Customer "data" includes ML training rights for the vendor → push back hard, especially on confidential data; specifically prohibit using customer data for model training without explicit additional consent.

7. Warranties and disclaimers

Check:

• Vendor warranties: what does vendor promise (services performance, IP non-infringement, security)?
• Disclaimer of implied warranties (typically merchantability, fitness for purpose) — present in nearly every contract, market standard.
• Beta-feature disclaimer (if any beta features are in scope).
• Customer warranties: what is customer warranting (right to provide data, no malware, etc.)?

Common issues:

• No vendor warranty of any kind on service performance → push for at least an SLA-tied warranty.
• IP non-infringement warranty heavily disclaimed → push back; vendor should warrant their services don't infringe third-party IP.

8. Limitation of liability

This is one of the most-negotiated sections. Pay close attention.

Check:

• Cap amount (12 months of fees paid is most common; some vendors push for lower).
• Carve-outs from cap (typical: gross negligence, willful misconduct, IP indemnity, breach of confidentiality, breach of data protection).
• Direct vs. consequential damages (most contracts disclaim consequential damages — market standard).
• Mutual or one-sided cap (mutual is standard; one-sided in vendor's favor is a flag).

Common issues:

Pattern	Customer concern	Vendor concern
Cap of $X (small fixed amount)	Inadequate for real damages	Acceptable for vendor
Cap of fees paid in last 6 months	Light cap	Vendor preferred
Cap of fees paid in last 12 months	Standard	Standard
Cap of 2x fees paid	Customer-favorable	Pushback warranted
No carve-outs for IP indemnity / data breach	Bad for customer	Vendor preferred
Carve-outs for IP indemnity, data breach, gross negligence, confidentiality	Customer standard	Pushback by vendor common
Both parties' liability uncapped	Generally avoided	Vendors strongly resist

Customer redline (typical): cap = 12 months fees; carve out IP indemnity, data breach (or unlimited liability for data breach where vendor's negligence caused), gross negligence, willful misconduct, breach of confidentiality.

9. Indemnification

Check:

• IP infringement indemnity from vendor (defending and indemnifying customer if vendor's services infringe third-party IP).
• Customer indemnity for misuse / customer-content-related claims.
• Procedure: notice of claim, control of defense, settlement consent.
• Mutuality on indemnity scope.

Common issues:

• Vendor indemnity scope narrow (only "patents") → expand to "intellectual property" generally.
• Customer indemnity overbroad → narrow to claims arising from customer's actual misuse, not just any third-party claim involving customer use.
• No procedure for indemnity claims → add: prompt notice required, indemnitor controls defense, settlements requiring admission of liability or non-monetary obligations need indemnitee's consent.

10. Data protection and privacy

Check:

• DPA included or referenced (if applicable — required for any vendor processing personal data of EU/UK/California residents).
• Specific subprocessor list and notice of changes.
• Security commitments (encryption, access controls, security certifications).
• Data location commitments (where is data stored / processed?).
• Breach notification timeline (most regulations require 72 hours from discovery; aim for 24-48 hours from vendor).
• Data deletion on termination.
• Audit rights (typically: customer can audit vendor's compliance, but limited to once per year, with notice, at customer's expense).

Common issues (customer perspective):

• No DPA → require one if processing personal data.
• Subprocessor list undisclosed → require disclosure and notice of changes.
• Breach notification timeline weak ("reasonable promptness") → tighten to specific hours.
• No deletion obligation → add 30-day post-termination deletion confirmation.

11. Service Level Agreement (SLA)

Check:

• Uptime commitment (99.5%, 99.9%, 99.95%, 99.99% are typical tiers).
• Measurement methodology (when is downtime "downtime"? Are scheduled maintenance windows excluded?).
• Remedies for SLA breach (service credits, termination right after sustained breach).
• Excluded events (force majeure, scheduled maintenance, customer-caused issues).

Common issues:

• SLA committed but no remedy → SLA without remedy is just marketing; insist on at least service credits.
• Service credits as sole remedy for any sustained breach → acceptable for most cases, but for repeat or material breaches, customer should have termination right.

12. Confidentiality

Check:

• Definition of Confidential Information (typically: marked or reasonably understood as confidential).
• Term of confidentiality (often perpetual for trade secrets, 3-5 years for general confidential info).
• Permitted disclosures (legal compulsion, advisors, regulators).
• Return/destruction on termination.
• Carve-outs for residual knowledge / employees' general skills.

Common issues:

• No carve-out for legally compelled disclosure → add (all serious contracts have this).
• Confidentiality term too short (1 year for trade secrets is inadequate) → extend or specify perpetual for trade secrets.

13. General provisions

Check:

• Governing law and venue (typically vendor's state for vendor-paper contracts, customer's state for customer-paper).
• Dispute resolution (litigation, arbitration, mediation-first).
• Assignment (can either party assign? Typically: not without consent, but allowed for change of control).
• Force majeure scope.
• Entire agreement clause.
• Modification only in writing.
• Notice provisions (where to send legal notices, by what means).

Common issues:

• Assignment to competitors not restricted → add "not to direct competitors of the other party without consent."
• Notice provisions only by mail → add email-acceptable notice for routine matters.

Output format

For each finding, produce an entry in this structure:

## Finding [N]: [Brief title]

- **Severity:** Critical | High | Medium | Low | Informational
- **Section:** [contract section reference]
- **Perspective:** Customer | Vendor | Mutual concern
- **Risk type:** [Liability | Termination | IP | Data | Pricing | Other]

### Clause as written

> [Quoted text from the contract, exactly as drafted.]

### Issue

[2-4 sentences explaining the specific problem with this clause.]

### Suggested redline

[Specific replacement language, in markup format showing additions/deletions where helpful]

### Fallback position

[If counterparty rejects the primary redline, what's an acceptable compromise?]

### Why this matters

[1-2 sentences on the practical risk if left unchanged.]

After individual findings, produce:

## Review Summary

- Contract type: [MSA | Order form | DPA | combination]
- Counterparty: [name]
- Total findings: [count]
- By severity: Critical: [N] | High: [N] | Medium: [N] | Low: [N]

## Critical issues — must resolve before signing

[List of Critical findings.]

## High-priority issues — strongly recommend resolving

[List of High findings.]

## Suggested negotiation order

[Sequence the redlines so the most important ones go first; concede on lower-priority items if needed to get the higher-priority ones.]

## Sections that look acceptable as drafted

[Document what was reviewed and passed — auditor of the audit can see scope.]

## Items requiring counsel review

[Specific findings that warrant lawyer input rather than self-redline. Examples: novel IP terms, regulatory compliance specifics, contracts above company's risk threshold.]

Operating principles for this skill

1. Pick the right perspective. Always confirm whose perspective the review is from. Same clause may be a red flag from one side and acceptable from the other.

2. Show the actual clause text. Quote the contract language; don't just describe the issue abstractly. The customer needs to see what's flagged.

3. Provide specific drafting language. "Push back on auto-renewal" is not actionable; "Replace 'unless terminated by Customer with at least sixty (60) days' notice' with 'unless terminated by Customer with at least thirty (30) days' notice'" is.

4. Always provide a fallback. Most negotiations involve trade-offs. Suggest a reasonable middle ground for each redline so the customer has a path to compromise rather than a yes/no fight.

5. Triage to legal counsel for novel or high-stakes items. Don't pretend the skill can handle every issue. When something is genuinely complex or material, say "engage counsel" explicitly.

6. Honest about what's market-standard. Many contracts will have many clauses that are imperfect-but-standard. Don't flag every minor issue as a critical concern; reserve Critical/High for things that genuinely warrant push-back.

Standard legal disclaimer

This skill provides software-assisted analysis of contract language based on publicly known SaaS contract patterns. It does not constitute legal advice and does not create an attorney-client relationship between the user and Audrent or any party affiliated with this skill. Use of this skill does not substitute for review by qualified legal counsel licensed in the relevant jurisdiction. The skill's findings are informational; final negotiation and signing decisions are the user's responsibility.

Skill metadata

• Author: Audrent
• Version: 1.0.0
• License: MIT
• Source of truth: audrent.com/skills/saas-contract-review (when published)
• Provenance: Authored by the Head of Agent Commerce at Audrent. Grounded in standard SaaS contract patterns (Bonterms, Common Paper, market-typical MSA / DPA / order form structures). No third-party code, no external dependencies, no network calls. Complete contents are in this single SKILL.md file.
• Reporting issues / suggested improvements: [email protected]