Summary. A software-as-a-service agreement is not a software license with a different delivery method. The customer never possesses the software, its data lives on the vendor's infrastructure, the vendor can change the product unilaterally, and switching costs are usually higher than either side admits during negotiation. This article explains what actually matters in cloud contracts and where the leverage is: the grant of access rights, service level agreements and why service credits are usually worth less than they appear, availability definitions and the exclusions that swallow them, and the escalation and termination rights that give an SLA teeth. It then turns to data: ownership, permitted vendor uses including model training, the data processing addendum and subprocessor controls, and cross-border transfers. Sections on security representations and audit rights, incident notification, business continuity, IP and feedback clauses, liability allocation, suspension, and exit follow. It closes with a negotiation playbook, a worked example, an FAQ, and related reading.

A company signs a three-year SaaS contract for the system that runs its order pipeline. Year two, the vendor is acquired, the roadmap changes, support degrades, and a competitor offers a better product.

The company reads its contract and finds: no termination for convenience, auto-renewal with ninety days' notice, service credits capped at five percent of monthly fees as the sole remedy for outages, a data export available only in the vendor's proprietary format, no transition assistance obligation, and a clause permitting the vendor to modify the service "in its sole discretion."

It is not trapped, exactly. It can leave in fourteen months, without its historical data in a usable form, after paying for a year it does not want.

Every one of those terms was negotiable at signing. None is negotiable now. That asymmetry is the entire subject of this article.

The short answer

The clauses that decide whether a cloud contract works, in rough order of how often they are neglected:

  1. Exit. Data export format, transition assistance, post-termination retention, and termination rights. Negotiate the ending first.
  2. Data. Who owns it, what the vendor may do with it, and whether it may be used to train models.
  3. Service levels. The uptime number matters far less than the definition of downtime, the exclusions, the measurement window, and whether repeated failures allow termination.
  4. Security. Specific obligations and evidence, not "industry standard."
  5. Change control. What the vendor may unilaterally change, and what happens if it degrades or removes functionality you rely on.
  6. Liability. Caps, carve-outs, and whether the data-breach exposure bears any relationship to the harm.
  7. Renewal and pricing. Auto-renewal notice periods and uplift caps.

Part I: The grant, and why SaaS is not a license

In an on-premises license, the customer receives a copy of software and a license to use it. In SaaS, the customer receives a right to access a service the vendor operates. That difference drives everything else.

Practical consequences:

  • You cannot keep using it after termination. There is no copy to retain. When access ends, the capability ends.
  • The vendor controls the version. There is no "we'll stay on 4.2 until we're ready." Multi-tenant architecture means everyone is on the same build.
  • Your data is on their infrastructure, subject to their security, their subprocessors, and their jurisdiction.
  • Escrow is largely theatrical. A source code escrow releases code you cannot run without the vendor's operational environment, data model, and integrations. If continuity genuinely matters, negotiate for a hosted continuity option (a third party contracted to run the service), a data escrow with regular exports in a documented schema, or accept the risk knowingly.

Drafting points on the grant:

  • Define the authorized users and whether affiliates, contractors, and outsourcers are included. Growth through acquisition makes this expensive if it is drafted narrowly.
  • Define the metric precisely: named users, concurrent users, API calls, seats, records, transactions, or consumption. Ambiguity here becomes an audit dispute.
  • Address overage: what happens if you exceed the metric, at what price, and with how much notice.
  • Confirm the right to use the service for the benefit of affiliates and, where relevant, to provide services to your customers.
  • Reserve the right to use third-party integrators and to connect through documented APIs.

Part II: Service levels

The number is the least important part

Almost every SLA promises 99.9 percent or better. What differs, and what determines whether the promise means anything, is everything around it.

How is availability defined? "The Service is available" can mean the login page loads, or it can mean core transactions complete within a defined latency. A service that is technically up but returns errors on 40 percent of API calls satisfies a naive definition. Negotiate a definition tied to successful completion of defined transactions, and include latency where performance matters.

What is the measurement window? Monthly is standard. A quarterly or annual window lets a vendor absorb a catastrophic day. A monthly window on 99.9 percent permits about 43 minutes of downtime; 99.5 percent permits about 3.6 hours; 99.99 percent permits about 4.3 minutes. Know which one you are buying.

Who measures? Vendor-reported metrics with no audit right are self-graded homework. Ask for the methodology, the right to review raw monitoring data, and ideally the right to rely on your own monitoring where it materially conflicts.

What is excluded? This is where SLAs are won and lost. Standard exclusions include scheduled maintenance, emergency maintenance, force majeure, customer-caused issues, third-party network failures, and issues with customer equipment. Each is reasonable in principle and abusable in practice. Negotiate:

  • Scheduled maintenance windows that are defined, capped in duration and frequency, and outside your business hours across your actual geographies.
  • Emergency maintenance limited to genuine emergencies with prompt notice, not a general escape hatch.
  • Third-party failures excluded only where the vendor could not reasonably have designed around them. A single-cloud-region architecture is a design choice, not an act of God.

Service credits, and their real value

The standard remedy is a service credit: a percentage of monthly fees, applied to a future invoice, that must usually be requested within a short window.

Three reasons credits are worth less than they look:

  1. They are tiny relative to the harm. A ten percent credit on a $12,000 monthly subscription is $1,200. A day of order-pipeline downtime at a mid-sized business costs multiples of that.
  2. They are usually the "sole and exclusive remedy." That phrase converts a modest credit into a cap on all liability for performance failure. It is often more consequential than the liability cap itself.
  3. They require you to ask. Credits that must be claimed within thirty days of the incident go unclaimed constantly.

What to negotiate instead of, or in addition to, bigger credits:

  • Chronic failure termination. The single most valuable SLA term: if the service misses the SLA in any two of three, or three of twelve, consecutive months, the customer may terminate for cause without penalty and receive a pro rata refund of prepaid fees. This gives the SLA teeth without requiring the vendor to underwrite your business losses.
  • Escalation commitments. Defined response and restoration targets by severity, with named contacts and executive escalation at defined intervals.
  • Root cause analysis delivered within a defined period after a Severity 1 incident.
  • Carve the sole-remedy language so that credits are the sole remedy for the SLA specifically, while breaches of security, confidentiality, and data obligations remain fully actionable.

Support versus service levels

Keep them separate. Availability is whether the service runs. Support is how fast someone helps when it does not, or when you have a question. Both need defined severity levels, response times, restoration targets, hours of coverage, and escalation paths. A 99.9 percent SLA with business-hours-only support in a single time zone is a poor fit for a 24-hour operation.

Part III: Data

Ownership

The customer should own its data, unambiguously. The standard formulation:

As between the parties, Customer retains all right, title, and interest in and to Customer Data. Vendor acquires no rights in Customer Data except the limited rights expressly granted in this Agreement.

Define Customer Data broadly enough to include data the customer uploads, data its users generate, and data the service derives from those inputs on the customer's behalf. Vendors often carve out "usage data," "telemetry," or "metadata"; scrutinize the definition, because with modern products the derived data can be more valuable than the uploaded data.

What the vendor may do with it

This is now the most contested clause in cloud contracting, for one reason: machine learning.

The uses to enumerate and constrain:

  • Providing the service. Necessary and uncontroversial.
  • Support and troubleshooting. Should require customer authorization for access to production data, with logging.
  • Aggregated and anonymized analytics. Common and often acceptable, but define the standard: true aggregation and de-identification that cannot reasonably be reversed, and a prohibition on re-identification and on disclosing anything attributable to the customer.
  • Product improvement. Vague and dangerous as written. Narrow it.
  • Training machine learning models. Address this expressly, because silence is not safety. Decide whether the vendor may train any model on your data; whether models trained on your data may serve other customers; whether outputs may embed your data; and what happens on termination to models already trained. Many enterprise vendors now offer a contractual no-training commitment as standard, and if yours does not, ask why.

For regulated data, the answer is usually no training, no secondary use, and no cross-tenant model sharing, full stop.

The data processing addendum

Where personal data is involved, a DPA is required by essentially every modern privacy statute. Core content:

  • Roles: controller/processor (or business/service provider under California law), and confirmation that the vendor processes only on documented instructions.
  • Purpose limitation and a prohibition on selling or sharing personal data.
  • Confidentiality obligations on personnel.
  • Security measures, ideally referencing a specific standard.
  • Subprocessors: a current list, advance notice of changes, a right to object, and flow-down of equivalent obligations.
  • Assistance with data subject requests, impact assessments, and regulator inquiries.
  • Breach notification with a defined window.
  • Deletion or return on termination, with certification.
  • Audit rights, usually satisfied by a current third-party report plus a questionnaire, with on-site audit reserved for cause.
  • Cross-border transfer mechanism: Standard Contractual Clauses, a transfer impact assessment, and any supplementary measures. See International Data Transfers After Schrems II and State Consumer Privacy Laws.

Precedence matters. Add an ordering clause and check that it says what you want; DPA-versus-MSA conflicts on liability are a recurring source of disputes.

Residency and access

For some customers the location of data is a hard requirement. Negotiate data residency commitments by region, notice before relocation, and, where relevant, restrictions on support access from specific countries. Understand that residency commitments often cover primary storage but not backups, logs, or support tooling, so define the scope.

Part IV: Security

Do not accept "industry standard"

"Vendor will maintain commercially reasonable, industry-standard security measures" is unenforceable in any practical sense. Replace it with specifics, in a security addendum:

  • Certification: SOC 2 Type II (with the relevant trust services criteria), ISO/IEC 27001, or a sector standard, with the report delivered annually and material findings disclosed.
  • Encryption: at rest and in transit, with named minimum algorithms and key management practices; customer-managed keys where the risk justifies it.
  • Access control: least privilege, MFA for administrative access, quarterly access reviews, prompt deprovisioning.
  • Vulnerability management: defined remediation timelines by severity.
  • Penetration testing: at least annually by a qualified third party, with an executive summary provided.
  • Logging and monitoring: retention period, and customer access to relevant logs.
  • Personnel: background screening and security training.
  • Secure development: code review, dependency scanning, and a software bill of materials on request.
  • Business continuity and disaster recovery: a defined RTO (how long until service is restored) and RPO (how much data may be lost), tested annually, with test results shared.

Incident notification

The clause customers most often accept as drafted and most often regret.

Negotiate: notification without undue delay and in any event within a defined number of hours of determining that an incident affecting customer data has occurred; a defined minimum content for the notice; an obligation to cooperate with the customer's own investigation and notification obligations; preservation of forensic evidence; and clarity on who notifies affected individuals and regulators, since the customer usually bears that duty and needs the vendor's facts to discharge it.

Watch for definitions of "Security Incident" narrowed to exclude unsuccessful attempts and "unauthorized access" narrowed to exclude access by the vendor's own personnel. See Data Breach and Incident Response Toolkit and Cybersecurity Incident Response and IP Protection.

Part V: Change, suspension, and the other one-sided clauses

Unilateral modification. Most SaaS agreements permit the vendor to modify the service. Constrain it: no material degradation or removal of functionality the customer relies on during a term; notice before material changes; and a right to terminate with a pro rata refund if a change materially and adversely affects the customer. Distinguish changes to the service from changes to the terms, which should require notice and, for material changes, consent.

Suspension. Vendors reserve the right to suspend for non-payment, security risk, or acceptable-use violations. Negotiate notice and a cure period for non-payment, suspension limited to the affected users or components where feasible, and immediate suspension only for genuine security threats or legal compulsion.

Acceptable use. Read it. Broad AUPs can prohibit ordinary customer activity (competitive benchmarking, security testing, automated access). Carve out what you actually do.

IP and feedback. The vendor owns its service; the customer owns its data. The clause to watch is feedback: a broad assignment of any suggestion the customer makes. That is market standard and usually acceptable, but confirm it does not sweep in customer confidential information or customer-developed configurations, integrations, and reports.

Publicity. Do not agree to be a named reference or logo customer by default. Make it opt-in.

Part VI: Liability, and the mismatch

Standard SaaS liability terms cap at twelve months of fees and exclude consequential damages. For a $60,000-a-year subscription that is a $60,000 cap on a vendor that holds records for 300,000 of your customers.

Negotiate a super cap for data-protection and confidentiality breaches, sized to the plausible response cost and backed by insurance requirements, and confirm that the consequential damages exclusion does not swallow the enumerated breach response costs. The full framework is in Indemnification and Limitation of Liability.

Also confirm an IP infringement indemnity covering the service, with a narrow combination exclusion and a remedy ladder that does not permit the vendor to terminate and refund one month's fees as its first option.

Part VII: Exit

Negotiate the ending at the beginning, because it is the only time you have leverage.

Term and renewal. Auto-renewal is standard. Negotiate a notice period you can actually meet (thirty to sixty days, not ninety), a calendar reminder obligation on the vendor where possible, and a cap on renewal price increases (a fixed percentage or a published index). Uncapped renewal pricing is the most common source of post-signature regret.

Termination rights. For cause with cure. For chronic SLA failure. For a material adverse change in security posture. For a change of control to a competitor, where the service is sensitive. For convenience, if you can get it, usually with a fee.

Data export. The clause that determines whether you can leave:

  • Format: a documented, non-proprietary, machine-readable format with a published schema. "CSV export" without a schema is not enough for relational data.
  • Scope: all customer data, including attachments, audit logs, historical records, and configuration.
  • Self-service access throughout the term, so you are not dependent on cooperation at the end.
  • Frequency and cost: included in the subscription, not billed at professional-services rates.

Transition assistance. A defined period (often sixty to one hundred eighty days) after termination during which the vendor continues the service at the then-current rate and provides reasonable migration support at agreed rates. Without this, termination means an immediate cliff.

Post-termination deletion. Deletion of customer data within a defined period after the export window, with written certification, and defined treatment of backups (usually deletion on the normal backup rotation).

Survival. Confirm which clauses survive: confidentiality, data deletion, liability, indemnities, and audit rights for a defined tail.

Part VIII: Multi-tenancy, subprocessors, and the supply chain you did not sign up for

Cloud contracts create obligations that run several parties deep, and the customer's exposure is to the whole chain, not just to the counterparty on the signature page.

Multi-tenancy. Most SaaS runs a single application instance serving many customers, with logical rather than physical separation of data. That is efficient and usually secure, but it has consequences worth understanding. A performance problem caused by another tenant can affect you (the "noisy neighbor" issue), which is why an SLA that excludes "issues caused by other customers" is doing more work than it appears. A configuration error can expose data across tenants, which is the recurring pattern in cloud breach reports. And a legal hold or law-enforcement seizure directed at another tenant can, in poorly designed systems, reach infrastructure you share.

Ask: is separation logical or physical; is encryption per-tenant with separate keys; how is tenant isolation tested; and has an isolation failure ever occurred?

Subprocessors. Your vendor runs on someone else's infrastructure, uses a third party for email delivery, another for analytics, another for support ticketing, and often an offshore development or support partner. Each is a subprocessor with access to some slice of your data.

Contract for: a current published list; advance notice (thirty days is typical) before adding one; a right to object, with a meaningful consequence if you do (usually termination of the affected service without penalty); flow-down of equivalent data protection and security obligations; and the vendor's full responsibility for subprocessor acts and omissions. That last point matters: a vendor that disclaims liability for its subprocessors has effectively disclaimed liability for its service.

Fourth parties and concentration risk. Several major outages in recent years have taken down large parts of the internet because thousands of independent services shared one cloud region, one DNS provider, or one authentication service. Your vendor's SLA does not protect you from correlated failure across your whole stack. For genuinely critical systems, ask about region redundancy and single points of failure, and consider whether your business continuity plan assumes independence that does not exist.

Insolvency and acquisition. Two events that change a cloud relationship overnight. On acquisition, the acquirer may reprice at renewal, deprecate the product, or become your competitor. Negotiate a change-of-control termination right where the service is sensitive. On insolvency, rejection of the contract in bankruptcy is a breach rather than a rescission, but the practical problem is operational: a debtor that stops paying its own cloud bill takes your service down regardless of your contract rights. Data escrow and a tested export are worth far more here than any clause. See Intellectual Property Licenses in Bankruptcy.

Part IX: Governance after signature

Most of the value of a well-negotiated cloud contract is lost because nobody administers it. Four practices capture it.

A contract register. Vendor, service, term end date, non-renewal notice deadline, renewal price mechanism, data categories held, DPA in place, security evidence due date, and named business owner. This is unglamorous and it is the single highest-return governance artifact in a technology organization.

Calendar the notice dates the day you sign. Set the reminder for sixty days before the non-renewal deadline, not on it, so there is time to make a decision.

Collect the evidence you contracted for. Annual SOC 2 reports, penetration test summaries, and business continuity test results are worthless if nobody requests and reads them. Assign the review, and escalate material findings.

Test the exit. Run a full data export annually and confirm you can actually load it somewhere. Companies routinely discover, at the worst moment, that the export is missing attachments, that the schema is undocumented, or that it takes six weeks to generate. An export you have never tested is a promise, not a capability.

Review the acceptable use policy and terms on change. Many vendors reserve the right to update ancillary policies by posting. Someone should be watching, and the contract should require notice of material changes.

Part X: Sector overlays

Three regulated contexts change the baseline analysis enough to be worth flagging.

Healthcare. Protected health information triggers HIPAA, which requires a business associate agreement with defined content, imposes breach notification obligations with a sixty-day outer limit, and reaches the vendor directly as a business associate rather than only through your contract. Subcontractors of business associates are themselves business associates. Confirm the BAA controls over conflicting MSA terms and that the security addendum meets the Security Rule's administrative, physical, and technical safeguards.

Financial services. Bank and credit union vendors face regulator expectations for third-party risk management, including due diligence, ongoing monitoring, contingency planning, and, for material relationships, regulator access to the vendor's books and records relating to the service. The Gramm-Leach-Bliley Safeguards Rule imposes its own vendor oversight duties. Contracts for these customers routinely include audit and examination clauses that vendors resist and regulators expect.

Government. Federal customers require FedRAMP authorization at the appropriate impact level, and state and local programs increasingly mirror it. Selling into government also imports flow-down clauses, accessibility obligations under Section 508 (see Website and Mobile App Accessibility Under the ADA), and records-retention obligations that conflict with standard deletion terms.

Education. Student data triggers FERPA and, for services directed at children, COPPA, plus a growing set of state student-privacy statutes that restrict targeted advertising and secondary use. Many require specific contract terms as a condition of the vendor receiving data at all.

In each case the pattern is the same: a sector statute imposes contract-content requirements that a vendor's standard paper does not satisfy, and the customer, not the vendor, bears the regulatory consequence of the gap. Identify the applicable overlay before you start redlining, because it converts several negotiation asks from preferences into requirements.

A worked example

Ridgeway Diagnostics (fictional), a 140-person clinical lab, is buying a SaaS lab information system for $210,000 a year on a three-year term. The vendor's standard paper is customer-hostile in five specific ways.

1. SLA. 99.5 percent monthly, measured by the vendor, with maintenance excluded and no cap on maintenance windows; five percent credits as sole remedy. Ridgeway's asks: 99.9 percent; availability defined by successful completion of specified transactions; maintenance windows capped at four hours per month outside 06:00-20:00 local; credits raised and, more importantly, termination for two misses in any rolling three months; sole-remedy language limited to the SLA only.

2. Data. Vendor may use "Service Data" for "product improvement and analytics," undefined. Ridgeway's asks: customer owns all data including derived data; permitted uses enumerated; no training of machine learning models on customer data; aggregation permitted only if irreversibly de-identified and never attributable to Ridgeway; because the data is protected health information, a HIPAA business associate agreement with precedence over conflicting terms. See HIPAA, Business Associates, and Cloud Computing.

3. Security. "Commercially reasonable measures." Ridgeway's asks: a security addendum with SOC 2 Type II delivered annually, encryption specifics, annual penetration testing with summary delivered, defined RTO of four hours and RPO of fifteen minutes tested annually, subprocessor list with thirty days' notice and a right to object, and incident notification within twenty-four hours of determination.

4. Liability. Cap at twelve months of fees, all consequential damages excluded. Ridgeway's asks: general cap at twelve months; super cap of $5,000,000 or the limit of vendor's cyber policy, whichever is greater, for breaches of the security and data provisions, expressly covering forensic, legal, notification, call center, and credit monitoring costs; cyber insurance at $10,000,000 evidenced by certificate.

5. Exit. No transition assistance; export "upon request." Ridgeway's asks: self-service export throughout the term in a documented schema; ninety days of post-termination transition at the then-current rate; deletion with certification thirty days after the export window; renewal increases capped at four percent or CPI, whichever is lower; sixty days' non-renewal notice.

What Ridgeway should expect to concede: the vendor's standard IP ownership, feedback assignment, publicity opt-out, and mutual limitation structure. Those are reasonable. The negotiation should spend its capital on the five items above, in that order, and Ridgeway should be prepared to walk if the data-use and exit terms do not move, because those are the ones that cannot be fixed later.

Negotiation playbook

Before you negotiate

  • Identify what data will actually be in the system, and whether it is regulated.
  • Quantify the cost of a day of downtime and of a breach; these numbers drive every other ask.
  • Estimate switching cost honestly, including integrations and historical data.
  • Confirm what the vendor's competitors offer, which is your only real leverage.

Priority asks, in order

  • Data ownership, permitted uses, and a no-training commitment.
  • Export format and transition assistance.
  • Chronic-failure termination right.
  • Security addendum with evidence obligations and incident notification window.
  • Data-protection super cap backed by insurance.
  • Renewal price cap and workable non-renewal notice.
  • Constraints on unilateral change and suspension.

Things not worth fighting over

  • The vendor's ownership of its own service.
  • Standard feedback assignment.
  • Mutual confidentiality on standard terms.
  • A modest general liability cap, provided the carve-outs are right.

Frequently asked questions

Is a SaaS agreement a license? Functionally it is a service subscription with a right of access. That matters for termination (no copy survives), for versioning (you get the vendor's build), and for insolvency (see Intellectual Property Licenses in Bankruptcy).

Who owns the data? The customer should, expressly, including derived data. Read the definition of "Customer Data" carefully, because vendors often carve out usage and telemetry data.

Can the vendor train AI on our data? Only if the contract permits it. Silence is not protection. Ask for an express no-training commitment, and if the vendor's model is trained across tenants, understand what that means before signing. See AI Governance and Compliance.

Are service credits worth negotiating? Somewhat. The chronic-failure termination right is worth far more, because it converts a small monetary remedy into a real consequence.

Do we need source code escrow? Rarely useful for SaaS. Prefer regular data exports in a documented schema, a documented migration path, and, where continuity is critical, a contracted hosted-continuity arrangement.

What is the difference between RTO and RPO? RTO is how long until service is restored after a disaster. RPO is how much data you may lose. Both should be numbers in the contract and both should be tested.

Can the vendor just change the product? Usually yes under standard terms. Constrain material degradation, require notice, and take a termination right with a refund if a change materially harms you.

What happens to our data if we leave? Whatever the contract says. If it says nothing specific, expect a proprietary-format dump on request, no transition help, and a deletion timeline you do not control. Negotiate this at signing.

Should we agree to auto-renewal? It is nearly unavoidable, so make it workable: short notice period, capped increases, and an internal calendar entry the day you sign.

We are a small buyer with no leverage. What should we insist on? Three things, and vendors usually concede them even to small customers: ownership of your data, a usable self-service export, and a no-training commitment. Those preserve your ability to leave, which is the only leverage you will ever have again.

Closing thought

The recurring mistake in cloud contracting is negotiating the beginning of the relationship instead of the end of it. Buyers spend weeks on price and implementation dates, sign a standard exit clause without reading it, and discover three years later that leaving is technically possible and practically impossible.

The three provisions that matter most, in a contract nobody will read again until something goes wrong, are: you own your data, you can get it out in a format you can use, and you can leave when the service stops working. Everything else is negotiable comfort.

Sort those out first, and the rest of the agreement becomes what it should be — a description of a working relationship rather than a description of a trap.

Related articles

This article is provided for general informational purposes and does not constitute legal advice. Cloud contracting terms vary widely by vendor, sector, and regulatory context. Consult qualified technology counsel about any particular agreement.