SaaS and Software Contracts: Data, Security, Service Levels, and Liability

When a company buys software as a service, it is not really buying software. It is renting access to someone else's system and — more importantly — placing its data, its operations, and sometimes its customers' personal information inside that system. The contract is the only tool that controls what happens to all three.

Most SaaS disputes trace back to four clusters of terms: data (who owns it, who may use it, what happens to it at exit), security (what is actually promised versus described), service levels (what "99.9% uptime" really pays when missed), and liability (who absorbs losses when something goes wrong). This guide takes each in turn, from the perspective of both customer and vendor.

First, map the contract stack

A modern SaaS relationship is rarely one document. Expect an order form (pricing, term, seat counts), a master subscription agreement (the legal core), a data processing addendum or DPA (privacy and processing terms), a service-level agreement (uptime and support), and referenced policies — acceptable use, support tiers, security descriptions — that often live at URLs the vendor can update.

Check the order of precedence clause and the amendment mechanics. A common trap: the master agreement is negotiated and signed, but it incorporates online policies "as updated from time to time," quietly letting the vendor rewrite operational terms mid-contract. Ask for notice-and-objection rights on material policy changes. Note also that traditional sale-of-goods rules under UCC Article 2 generally do not govern pure SaaS, which courts treat as a services arrangement — meaning the warranties you get are, with narrow exceptions, only the ones written into the contract.

Data: ownership, use rights, and the exit

The customer should own its data — most vendor templates say so — but ownership language alone settles little. The operative questions are use rights and exit mechanics.

On use rights, look for what the vendor may do with customer data beyond providing the service: aggregate it, "anonymize" it, benchmark with it, or use it to train models. None of these is automatically unacceptable, but each should be visible and priced into the deal. If personal information is involved, state privacy laws require specific processor obligations — purpose limitation, confidentiality, deletion duties, and audit cooperation — and a compliant DPA is not optional. The obligations differ by state, which is why it pays to understand the state privacy law patchwork before signing rather than after a regulator asks. If the service makes or supports consequential automated decisions about people, AI governance obligations may add another layer of required diligence and documentation.

On exit: the contract should state how long after termination the customer can retrieve data, in what format, at what cost, and when the vendor must delete residual copies. Thirty days of post-termination export access is a common floor. Silence here is how companies end up paying ransom-priced "professional services" fees to get their own records back.

Security: promises versus descriptions

Vendors describe security in marketing pages; contracts are where descriptions become promises. The difference matters after a breach.

• A commitment to maintain a written information-security program aligned to a named framework — the NIST Cybersecurity Framework or ISO 27001 are the usual references.
• Annual third-party attestation (commonly a SOC 2 Type II report) delivered on request, with a duty to remediate material findings.
• Encryption of customer data in transit and at rest, stated as an obligation rather than a description.
• A breach-notification clause with a concrete clock — "without undue delay, and in any event within 72 hours of confirmation" is a frequently negotiated formulation — plus cooperation duties.
• Subprocessor lists, flow-down of security obligations, and either approval rights or notice-and-termination rights when subprocessors change.
• Security-incident cost allocation: who pays for forensics, notification letters, and credit monitoring.

Regulators care about this layer too. The FTC has long treated deceptive security claims and unreasonable data practices as enforcement targets, and its business guidance on privacy and security is a useful baseline for what "reasonable" looks like. For vendors, the lesson is to promise what your program actually does; for customers, it is to convert the sales deck into contract language.

Service levels: reading the SLA like an adjuster

An SLA has three moving parts: the commitment (say, 99.9% monthly uptime), the exclusions (maintenance windows, force majeure, problems caused by the customer or third-party networks), and the remedy (service credits on a published schedule). Each deserves arithmetic, not vibes. A 99.9% monthly commitment tolerates roughly 43 minutes of downtime a month; 99.5% tolerates over three and a half hours. Exclusions can hollow out the number — broad "scheduled maintenance" carve-outs are the usual culprit.

Credits are typically small percentages of monthly fees, must be claimed within a short window, and are frequently stated as the sole and exclusive remedy for availability failures. That last phrase is the one to negotiate. A workable middle ground: credits remain the routine remedy, but chronic failure — for example, missing the commitment in three consecutive months, or any single outage beyond a defined length — triggers a right to terminate without penalty and receive a prorated refund of prepaid fees.

Liability caps, carve-outs, and indemnities

Nearly every SaaS agreement excludes consequential damages (lost profits, lost data value, business interruption) and caps direct damages, most often at fees paid in the preceding twelve months. The negotiation is rarely about removing the cap; it is about the carve-outs and any "super-cap."

Standard carve-outs from the cap include the vendor's IP-infringement indemnity, either party's confidentiality breaches, and amounts owed under indemnities generally. The contested middle ground is data: customers push for breach-of-security and DPA violations to sit outside the cap or under an elevated super-cap (two to five times annual fees is a common ask); vendors resist unlimited data liability because it is uninsurable at scale. Where the parties land usually reflects the sensitivity of the data and the price of the deal. If a failure does happen, remember that the analysis runs through ordinary contract doctrine — the framework described in how breach remedies are measured — filtered through whatever the cap and exclusions leave standing.

Also read the dispute-resolution clause before you need it. Many vendor templates route disputes to individual arbitration; the enforceability and consequences work much as they do in consumer arbitration clauses, and the choice matters more than most signers assume.

Quick answers

Our vendor's contract is take-it-or-leave-it. Is reviewing it still worth the time?

Yes, because review changes behavior even when it cannot change terms. Knowing the breach-notice clock, the SLA claim deadline, the renewal notice window, and the data-export period tells you what to calendar and what operational backstops to build — independent backups, exit runbooks, insurance. And vendors with published terms often still negotiate DPAs, security exhibits, and renewal caps for meaningful contracts.

What is the single most expensive clause people skip?

Auto-renewal. Multi-year terms that renew automatically unless canceled 60 or 90 days before expiration, sometimes with uncapped price increases, quietly lock companies in for another full term. Track every renewal notice date in a shared calendar, and negotiate a cap on renewal price increases — a percentage or an index — when you sign, not at renewal when leverage is gone.

Does a SOC 2 report mean the vendor is secure?

No. A SOC 2 Type II report means an auditor tested the controls the vendor chose to include, over a defined period, and reported results — including any exceptions. It is evidence of a functioning program, not a guarantee. Read the scope, the carve-outs, and the exceptions section, and confirm the report covers the actual service and data centers you will use.

Who is liable if the vendor's subprocessor causes a breach?

As between you and the vendor, the contract decides — which is why DPAs should make the vendor responsible for its subprocessors' acts and omissions as if they were its own. Without that flow-down, you may face a gap: your customers hold you responsible while the vendor points at a company you never contracted with. Insist on the responsibility clause and a current subprocessor list.

Your next moves

Assemble the full stack — order form, master terms, DPA, SLA, linked policies — and read the precedence clause first. Score the deal on the four clusters: data use and exit, security promises with real teeth, SLA math and remedies, and the liability cap with its carve-outs. Calendar the renewal notice date, the SLA claim window, and the post-termination export period before go-live. Protect the surrounding brand assets too — if your product's name matters, the guide to domain and trademark disputes explains what to do when someone registers it first. Then revisit annually: the contract that fit a pilot rarely fits the system your business now depends on.