SaaS Agreements: What Belongs in the Subscription Contract Your Customers Click Through

By Hank FasthoffJuly 6, 2026

A SaaS agreement governs access to software delivered over the Internet rather than installed on the customer's hardware. Unlike a traditional software license (where the customer receives a copy of the code and runs it locally), a SaaS relationship means the provider controls the infrastructure, the customer's data lives on the provider's servers, and the service can be modified, interrupted, or terminated by the provider at any time unless the contract provides otherwise.

That structural dependency is why SaaS agreements contain provisions that don't appear in traditional product sales contracts. Service availability, data ownership, breach notification, and termination rights carry more weight in a SaaS context because the customer can't run the software without the provider's ongoing cooperation. A product sale is a completed transaction. A SaaS subscription is an ongoing relationship, and the agreement must govern every aspect of how that relationship operates.

This article is written for the SaaS company drafting its customer agreement, not for the customer reviewing one. Every provision is addressed from the provider's perspective: what to include, how to structure it, and where the negotiation pressure comes from.

Service Level Agreement

An SLA defines what level of performance the provider commits to deliver and what happens when it falls short. Without a defined SLA, "we'll keep the service running" is an unenforceable aspiration. With a defined SLA, it's a contractual obligation backed by measurable standards and specified remedies.

Uptime commitment should be expressed as a percentage of total available time in a given measurement period (typically monthly). Enterprise-grade SaaS products commonly commit to 99.9 percent uptime, which allows approximately 43 minutes of unplanned downtime per month. A 99.99 percent commitment allows approximately 4.3 minutes per month. The commitment the provider makes should reflect what its infrastructure can reliably deliver, because committing to 99.99 percent and delivering 99.5 percent produces service credit obligations and reputational damage.

Measurement methodology should specify how uptime is calculated (total minutes in the month minus unplanned downtime, divided by total minutes), what counts as downtime (the service is unavailable to users, excluding scheduled maintenance and force majeure events), and who measures it (the provider's monitoring system, with the customer having the right to dispute measurements using independent monitoring data).

Service credits are the standard remedy for SLA failures. A typical structure provides a 10 percent credit against the monthly fee for uptime between 99.0 and 99.9 percent, 25 percent for uptime between 95.0 and 99.0 percent, and 50 percent for uptime below 95.0 percent. Service credits are applied against future invoices, not paid as cash, and are typically the customer's sole and exclusive remedy for SLA failures (which means the customer can't sue for damages based on downtime alone, only claim credits).

Chronic SLA failures should trigger a termination right. If the provider misses the uptime commitment for three consecutive months or four months in any 12-month period, the customer should have the right to terminate for cause without paying an early termination fee.

Data Ownership and Portability

Data ownership is the provision customers negotiate most aggressively, and it should be drafted with precision from the provider's side.

Customer data belongs to the customer. State this unambiguously: "As between Provider and Customer, Customer retains all right, title, and interest in and to Customer Data." The provider receives a limited license to process, store, and transmit the data solely to provide the service and as otherwise permitted by the agreement.

Provider-generated data (aggregated, anonymized usage data, performance analytics, metadata derived from the customer's use of the platform) belongs to the provider, provided it doesn't identify the customer or any individual. This distinction should be stated in the agreement, because providers rely on aggregated usage data for product improvement, benchmarking, and analytics, and customers who don't understand the distinction may object.

Data portability requires the provider to allow the customer to export its data in a standard, machine-readable format (CSV, JSON, XML, or an industry-standard format appropriate to the data type) at any time during the subscription and for a defined period after termination (typically 30 to 90 days). If the provider doesn't offer data export, the customer is locked in, and sophisticated customers won't accept that.

Data deletion after the post-termination export period should be specified. The provider should commit to deleting all customer data within a defined timeframe (typically 30 days after the export period expires) and providing written confirmation of deletion upon request.

Data Security and Breach Notification

Security obligations should be documented in the agreement, not left to the provider's general security page (which the provider can update unilaterally). Minimum security commitments include encryption of data in transit and at rest, access controls limiting provider personnel access to customer data on a need-to-know basis, regular security assessments (SOC 2 Type II audit, ISO 27001 certification, or equivalent), and incident response procedures.

Breach notification timelines should be specific. "Provider will notify Customer of any confirmed data breach affecting Customer Data within 72 hours of Provider's discovery of the breach." This timeline allows the customer to meet its own notification obligations under state breach notification laws (Texas requires notification "as quickly as possible" and in no event later than 60 days after discovery under Texas Business and Commerce Code § 521.053) and federal regulations (HIPAA requires notification within 60 days for covered entities).

Audit rights give the customer the ability to verify compliance. At minimum, the provider should commit to making its SOC 2 or equivalent audit report available to the customer annually. For enterprise customers, the agreement may include the right to conduct or commission an independent security audit of the provider's systems, typically limited to once per year with reasonable advance notice.

Subscription Term and Auto-Renewal

SaaS agreements are subscription-based, and the term structure determines when and how the customer can exit.

Annual terms are most common for B2B SaaS. Multi-year commitments (two or three years) are used for enterprise deals and typically include pricing discounts in exchange for the longer commitment. Monthly terms are common for self-service products and lower price points.

Auto-renewal provisions should specify whether the subscription renews automatically at the end of the term (and for what period: month-to-month, or another full annual term), how much notice the customer must give to prevent renewal (30 to 90 days before the renewal date), and whether the provider can increase pricing at renewal (and if so, how much notice is required and whether there's a cap on the increase).

Auto-renewal is heavily regulated. The FTC's Negative Option Rule (finalized in 2024) requires that cancellation be as easy as sign-up, that the provider obtain affirmative consent before charging, and that pre-renewal reminders be sent before annual renewals. California's Automatic Renewal Law (Cal. Bus. & Prof. Code §§ 17600-17606) imposes additional requirements, including conspicuous disclosure of auto-renewal terms before the customer subscribes and a post-transaction acknowledgment. If your SaaS product has subscribers in California (and most do), the California ARL applies regardless of where the provider is located.

Limitation of Liability

Standard SaaS limitation of liability caps the provider's total liability at the fees paid by the customer in the 12 months preceding the claim. This is the industry baseline. Caps of one to three months' fees are vendor-aggressive and may not survive negotiation with sophisticated customers. Caps above 12 months are customer-aggressive and create more exposure than most providers should accept.

Consequential damages waivers exclude both parties from liability for indirect, incidental, special, consequential, or punitive damages, including lost profits, lost revenue, lost data, and business interruption. This waiver is mutual (it protects both sides) and is standard in SaaS agreements.

Carve-outs from the cap and the consequential damages waiver should be negotiated. Customers push for carve-outs (higher or uncapped liability) for data breaches caused by the provider's failure to comply with its security obligations, the provider's indemnification obligations for IP infringement, and the provider's gross negligence or willful misconduct. Providers should accept carve-outs for these categories but negotiate a "super-cap" (typically two to five times the general cap) rather than uncapped liability.

Indemnification

SaaS indemnification is typically structured as a mutual obligation, with each side indemnifying the other for specified categories of claims.

Provider indemnifies the customer for third-party claims alleging that the service infringes a patent, copyright, trademark, or trade secret. This is the provider's most important indemnification obligation, because the customer has no control over the service's technology and can't evaluate whether the platform infringes someone else's IP. Provider indemnification should include the obligation to defend (not just indemnify), sole control over the defense and settlement, and the right to modify the service or obtain a license to cure the infringement.

Customer indemnifies the provider for claims arising from the customer's content (data the customer uploads or processes through the service), the customer's violation of the acceptable use policy, and the customer's breach of applicable law.

Termination and Data Return

Termination provisions should specify termination for cause (material breach that isn't cured within a defined period, typically 30 days after written notice), termination for chronic SLA failure (linked to the SLA provision), termination for convenience (if included, typically on 30 to 60 days' notice, sometimes with an early termination fee for annual or multi-year commitments), and termination on insolvency or change of control.

After termination, the provider must make the customer's data available for export in a standard format for a defined period (30 to 90 days), continue providing access to the service during the transition period (if a transition assistance clause is included), and delete all customer data after the export period expires, with written confirmation.

Practical Recommendations

Draft the SLA with numbers, not aspirations. Uptime percentage, measurement methodology, service credit structure, and chronic failure termination triggers should all be defined. "99.9% monthly uptime measured from Provider's monitoring system, with service credits and termination rights for repeated failure" is an SLA. "We strive to provide reliable service" is an aspiration.

State data ownership in one sentence: customer owns its data, provider has a limited license to process it. Everything else in the data section flows from that sentence.

Comply with auto-renewal laws before you launch the subscription. Build the FTC Negative Option Rule requirements and the California ARL requirements into your sign-up flow, your renewal process, and your cancellation mechanism. Retrofitting compliance after a regulatory inquiry or a class action is far more expensive than building it in from the start.

Set the liability cap at 12 months of fees and accept carve-outs for data breach, IP indemnification, and gross negligence at a super-cap of two to five times the general cap. This structure is market-standard, defensible in negotiation, and manageable from a risk perspective.

Include a post-termination data export period and a deletion commitment. A customer who can't get its data out of your platform after termination will pursue every available legal remedy to force the issue, and "we deleted it" without a contractual basis is a liability, not a defense.