SaaS Terms of Service — What Actually Matters

Most founders treat their Terms of Service like a checkbox. Grab a template, swap in your company name, ship it. I get it — you're busy building product, not reading legalese.

But your ToS is a contract. Every customer you sign is bound by it. And when something goes wrong — a data breach, a billing dispute, a customer claiming your platform cost them millions — those terms are the only thing standing between you and a very expensive problem.

I've reviewed hundreds of SaaS agreements. Here's what actually matters, what's mostly boilerplate, and where founders consistently get burned.

The Provisions That Can Hurt You

Liability Caps

This is the single most important clause in your entire agreement. A liability cap limits the maximum amount a customer can recover from you in a lawsuit. Without one, a $99/month customer could theoretically sue you for millions.

The standard approach: cap your total liability at the fees paid by that customer in the prior 12 months. This is market. Enterprise customers will negotiate it, but it's a reasonable starting point.

Common mistake: No cap at all. I've seen founders ship terms with zero liability limitation. That's writing a blank check to every customer you onboard.

Approach	Risk Level	Notes
No cap	🔴 Critical	You're exposed to unlimited claims
12-month fees paid	🟢 Standard	Market norm for SaaS
Fixed dollar amount	🟡 Situational	Works for freemium/low-price tiers
Greater of fees paid or $X	🟢 Good	Gives a floor for low-spend customers

Limitation of Liability

Related but distinct from the cap: your limitation of liability clause excludes certain types of damages entirely. The big ones to exclude:

• Consequential damages (lost profits, lost revenue, business interruption)
• Incidental damages
• Punitive damages

This is the clause that prevents a customer from saying "your 2-hour outage cost us $5M in lost sales." Without it, you're on the hook for downstream impacts you can't predict or control.

Pro tip: Carve out mutual exceptions for confidentiality breaches, IP infringement, and indemnification obligations. Investors and enterprise buyers expect these carve-outs, and they're reasonable.

Indemnification

Indemnification means one party agrees to defend and cover the other if a third party brings a claim. In SaaS agreements, this typically flows two ways:

• You indemnify the customer against IP infringement claims (someone sues them claiming your software violates a patent or copyright)
• The customer indemnifies you against claims arising from their use of the platform, their data, or their end users

What matters: Keep your indemnification obligation narrow. You should indemnify for IP infringement of your core platform — not for how customers configure it, what data they upload, or what their users do with it.

Common mistake: One-sided indemnification where only you indemnify. If a customer uploads infringing content to your platform and you get sued, you want them covering that.

Data Ownership and Portability

This one trips up more founders than almost anything else. Be crystal clear about three things:

1. Customer data belongs to the customer. Always. Say it explicitly.
2. You get a license to use their data to provide the service (and to generate aggregated, anonymized analytics if you want that option).
3. What happens to data on termination? Spell out the export window and deletion timeline.

Common mistake: No data portability provision. If a customer can't get their data out, you'll face pushback from every serious buyer — and potential regulatory issues under GDPR and state privacy laws.

Common mistake #2: Claiming ownership of customer data or "insights derived from" customer data without clear anonymization/aggregation language. This is a red flag for any savvy buyer and can tank enterprise deals.

IP Ownership

Two clean rules:

• You own the platform, all improvements, and all IP in the service. Full stop.
• The customer owns their data and any content they create.

Where this gets messy: custom development. If you're building features for a specific customer, your ToS (or your Order Form / SOW) needs to clarify who owns what. Default position: you own all platform IP, including features inspired by customer requests. If a customer wants to own custom code, that's a separate negotiation with a different price tag.

Auto-Renewal and Termination

SaaS is a recurring revenue business. Your terms should reflect that:

• Auto-renewal is standard (monthly or annual, depending on your billing model)
• Require written notice to cancel, with a defined notice period (30 days is typical)
• Specify what happens on termination: data export period, deletion timeline, survival of key clauses (liability, IP, confidentiality)

Common mistake: No survival clause. If your limitation of liability doesn't survive termination, a churned customer could sue you with no cap in place. The clauses that matter most need to outlive the agreement.

Clause	Should Survive Termination?
Liability cap / LoL	✅ Yes
Confidentiality	✅ Yes
IP ownership	✅ Yes
Indemnification	✅ Yes
Payment obligations	✅ Yes (for accrued fees)
SLA commitments	❌ No
Support obligations	❌ No

SLA Commitments

If you're offering an uptime SLA (e.g., 99.9% availability), put it in a separate SLA document, not in the core ToS. This lets you update SLA terms without re-versioning your entire agreement.

More importantly: don't over-promise.

• 99.9% uptime = ~8.7 hours of allowed downtime per year. That's tight but achievable for most well-run platforms.
• 99.99% uptime = ~52 minutes per year. Unless you're running multi-region redundancy with automatic failover, don't promise this.
• "100% uptime" = you're lying. Don't.

The remedy matters too. Standard SLA remedy is service credits — not refunds, not liability. Credits against future invoices. Cap your total credits at something reasonable (e.g., 30 days of fees in a given month). Never let SLA failures trigger your general indemnification obligations.

Common mistake: Promising an SLA with no exclusions for scheduled maintenance, force majeure, or issues caused by the customer's own infrastructure.

Acceptable Use Policy

Your AUP protects you from customers who abuse your platform. It should prohibit:

• Illegal activity
• IP infringement
• Reverse engineering or scraping
• Interfering with other customers' use
• Exceeding usage limits or rate limits

Why it matters: Without an AUP, terminating a bad actor becomes a breach of contract on your part. With one, you have clear grounds to suspend or terminate.

Keep it in a separate policy document (like the SLA) so you can update it without amending the core agreement. Reference it in the ToS.

Governing Law and Venue

Pick your home jurisdiction. If you're a Delaware C-Corp (and most venture-backed startups are), your ToS should specify:

• Governing law: State of Delaware (or wherever you're incorporated/headquartered)
• Venue: Courts in your chosen jurisdiction
• Consider adding: Mandatory arbitration with a class action waiver (this is increasingly standard and gives you more predictable dispute resolution)

Common mistake: Not specifying anything, which means a customer in Germany could theoretically drag you into a German court under German law.

What's Mostly Boilerplate (But Still Needs to Be There)

Not everything in a ToS requires deep strategic thinking. These provisions are important but largely standardized:

• Entire agreement / merger clause — the ToS supersedes prior discussions
• Severability — if one clause is invalid, the rest survives
• Assignment — you can assign the agreement (important for M&A); they can't without consent
• Notices — how formal communications work
• Force majeure — neither party liable for events beyond control
• Waiver — not enforcing a right once doesn't mean waiving it forever

These are "set it and forget it" provisions. Use standard language, don't overthink them — but don't skip them either.

The Priority List

If you're building or cleaning up your SaaS ToS, here's where to spend your time:

Priority	Provision	Why
🔴 Critical	Liability cap + LoL	Existential risk without it
🔴 Critical	Data ownership	Blocks enterprise deals if wrong
🔴 Critical	IP ownership	Protects your core asset
🟠 High	Indemnification	Defines who pays when things break
🟠 High	Termination + survival	Protects you post-churn
🟡 Medium	SLA commitments	Only if you offer one — get it right
🟡 Medium	AUP	Gives you termination rights
🟢 Standard	Governing law	Pick your state, move on
🟢 Standard	Boilerplate	Use templates, don't reinvent

Final Thought

Your SaaS ToS isn't a formality — it's the legal architecture of your customer relationships. Get the critical pieces right and you'll close enterprise deals faster, raise money with fewer diligence flags, and sleep better knowing a single customer dispute can't sink your company.

Get them wrong, and you're carrying risk you don't even know about.

---

Building or updating your SaaS terms? Book a free call — we draft and negotiate SaaS agreements every week.