Not long ago, customers purchased software as a tangible product, often as a CD or a hard install managed by a company’s IT department. Today, software implementation usually takes just a few clicks, a login, and a subscription. The evolution from on-premises installation to cloud-based platforms has brought exceptional convenience, efficiency, and flexibility to businesses of all sizes. However, with the abundance of benefits comes new risks – especially when something goes wrong, such as a data breach.

WHAT IS SAAS & WHY IS IT SO SPECIAL?

 “SaaS,” or Software as a Service, is a cloud-based software model where customers access software applications online while the SaaS provider manages security, maintenance, and updates.[1] Traditionally, businesses purchased software outright and managed it on-premises, with installation, updates, and security measures falling on internal IT teams.[2] In contrast, a company that purchases a SaaS solution, typically in the form of a subscription, purchases the use of the program, while the SaaS provider serves as a host.[3]

The SaaS model is attractive to both the service provider and customers because it reduces costs on both sides of the transaction, saves time for the customer base, and allows for prompt updates and improvements.[4] However, in a SaaS agreement, the customer essentially releases exclusive control over their IT to a third party and agrees to the providers’ terms.[5]

The shift in popularity from on-premises software to cloud-based SaaS solutions also alters the legal relationship between software providers and business clients.[6] Since SaaS customers do not own the software, the contractual agreement (and sometimes government regulation) governs the parties’ rights and responsibilities rather than ownership.[7]

THE IMPORTANTCE OF UNDERSTANDING TERMS IN A SAAS AGREEMENT

With transactions of this nature, a key question arises in the event of a data breach: who is responsible to those affected by a data breach? Is it the SaaS provider, the business client, or an outside vendor? As businesses increasingly rely on cloud-based solutions, understanding how SaaS agreements allocate risk and liability is essential – not only to reduce risk exposure, but to anticipate how courts may interpret the agreement as a whole, or a specific provision when something involving consumer data goes awry. The following provisions are critical when assessing how risk is allocated and who may be held responsible (and how much responsibility a party carries) should a breach occur.[8]

INDEMNIFICATION

Indemnity clauses are relevant to SaaS agreements to protect a customer from financial loss due to non-compliance with privacy regulations and data breaches.[9] While these clauses traditionally cover claims from third parties, in the SaaS context, they may reach further. [10]

Customers should negotiate indemnification for breaches of confidentiality, data security, or failing to comply with data and privacy laws.[11] If a SaaS provider does not agree to fully indemnify the customer, the customer should at least seek coverage for breach-related costs, such as investigation and regulatory notice obligations.[12]

On the other hand, SaaS providers may negotiate for indemnification from the customer for instances of IP infringement, violations of acceptable use policies, or misuse of the platform.[13] Indemnities often come with limitations and conditions, defining the scope of coverage, the circumstances under which indemnification applies, and caps on the amount that a vendor will pay.[14]

Indemnification clauses illustrate competing concerns on each side of a SaaS transaction: customers seek protection from failures in the provider’s system, while providers aim to limit liability tied to how the customer uses the platform.[15] The same dynamic resurfaces when parties negotiate liability caps.

LIMITING LIABILITY

 Provisions addressing limitations on liability are just as critical as indemnification clauses in shaping the legal and financial outcome after a data breach. While indemnification focuses on which party pays, limitation of liability clauses determine how much.[16]

From the perspective of a SaaS provider, tight liability caps are favorable.[17] The customer chooses to outsource a service, along with the legal, operational, and compliance-related risks, rather than providing and managing the service on its own.[18] However, as one commentator notes, “the cloud provider is not the insurer of the customer’s risks,” and should not be expected to absorb liabilities the customer was unwilling to accept.[19] Liability caps often cover liability to the amount a customer paid over a defined period, oftentimes the previous twelve months.[20] While that may seem commercially reasonable on its face, it can leave a customer with little to no recourse if a serious breach occurs.

From the customer perspective of a SaaS transaction, uncapped vendor liability is preferred, namely for issues involving data breaches, IP violations, or gross negligence.[21] A middle ground that balances the interests of both parties is needed to carve out exceptions within the liability cap, often referred to as “super caps,” which allow a higher cap or no cap at all for certain high-risk scenarios.[22]

While courts generally enforce liability caps in an agreement, they may refuse to do so if they are overly broad, one-sided, or against public policy.[23] In Clark Street Wine & Spirits v. Emporos Systems Corp., the court did not enforce a broad limitation of liability clause where the provider acted in a grossly negligent manner, resulting in a significant loss of the customer’s data.[24]

Therefore, effective liability caps should ultimately balance commercial efficiency and fairness, especially when supported by clear data security and breach response obligations.

 DATA SECURITY & SUBPROCESSORS

Separate articles, if not an entire blog series, could be dedicated to the security and privacy issues baked into SaaS agreements, particularly in light of the evolving regulatory landscape surrounding data protection. For now, this section offers a high-level glance at two often-overlooked areas: the provider’s data security obligations and the use of third-party subprocessors.

Entering into a SaaS agreement requires customers to entrust providers with their data. Thus, clearly defined security obligations are essential.[25] A well-drafted agreement should define the SaaS provider’s physical, technical, and administrative security responsibilities, identify specific standards (such as SOC 2 or ISO 27001), and establish whether subprocessors must meet the same requirements.[26]

Subprocessors are third-party vendors used by SaaS providers to help deliver their services.[27] Examples include cloud hosting platforms, analytics tools, or payment processors. Since subprocessors often handle customer data on the primary SaaS provider’s behalf, they can introduce additional risks if they are not held to the same privacy and security standards as the primary SaaS provider.[28] By clearly defining security responsibilities and extending those standards to subprocessors, a SaaS agreement can minimize the risk of confusion when a breach occurs.

BREACH NOTIFICATION

Even with well-defined security obligations in an agreement, breach notification provisions are important because they govern what happens when safeguards fail.[29] Depending on the type of software, the sensitivity of the data involved, and the nature of the relationship between the SaaS vendor and customer, simply complying with data privacy laws may not be enough to yield a fair or favorable outcome for the customer.[30]

A strong SaaS agreement should require the provider to notify the customer immediately in the event of a data breach or suspected breach and should provide a written summary of the incident and response.[31] Provisions concerning breach notification should also assign responsibility for complying with applicable breach notification laws, clarifying who sends the notice, who pays for it, and how resulting legal obligations will be handled.[32] Clear breach notification terms can reduce confusion, ensure timely responses, and protect both parties from regulatory and reputational fallout.

Ultimately, a SaaS agreement is more than a mere formality; it sets out rules and procedures in the event of a data breach. When a data breach occurs, the SaaS agreement, not just the law, will determine what happens next. That is why terms covering data security should be specific, measurable, and extended to all third-party vendors. Similarly, subprocessor obligations must be clearly defined to avoid gaps in responsibility, and parties should utilize indemnification clauses and breach notifications to shape liability and directly impact customer responsiveness. Through these key provisions, both parties can manage risks and avoid costly surprises.

[1] What is Software as a Service(SaaS)?, MICROSOFT AZURE, https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-saas (last visited March 27, 2026).

[2] Rachel M. Wolkinson & Alan L. Friel, SaaS Agreements – Key Contractual Provisions, LEXOLOGY (Nov. 11, 2021), https://www.lexology.com/library/detail.aspx?g=1277a6d5-f738-40c6-a4f6-c64d845694f9.

[3] Id.

[4] Henry Ward Classen, SaaS Agreements: Key Contractual Provisions, BUS. L. TODAY (Nov. 15, 2021), https://www.americanbar.org/groups/business_law/resources/business-law-today/2021-november/saas-agreements-key-contractual-provisions/

[5] Id.

[6] Christopher Lyle, Top 15 Legal Issues in SaaS Agreements, KICKSAAS LEGAL (Sept. 6, 2024), https://kicksaaslegal.com/blogs/news/top-15-legal-issues-in-saas-agreements?srsltid=AfmBOor0sklWKiI_301IXRjkTExLgBSGHcO1fN_yLTTMDnjgVDJdDSQH.

[7] See Lyle, supra note 6; Classen, supra note 4.

[8] See Lyle, supra note 6; Wolkinson & Friel, supra note 2; Classen, supra note 4; Brian Heller, Top 15 Legal Issues in a SaaS Agreement, OUTSIDE GC (Feb. 29, 2024), https://www.outsidegc.com/blog/top-15-legal-issues-in-a-saas-agreement.

[9] See Lyle, supra note 6.

[10] See Classen, supra note 4.

[11] See Classen, supra note 4; Heller, supra note 8.

[12] Id.

[13] See Classen, supra note 4; Heller, supra note 8.

[14] See Lyle, supra note 6.

[15] See Heller, supra note 8.

[16] See Classen, supra note 4; Lyle, supra note 6.

[17] Brian Heller, What is a Cap on an Indemnity Clause and Why Should I Care, LINKEDIN (June 2, 2014), https://www.linkedin.com/pulse/20140602192923-1102979-what-is-a-cap-on-an-indemnity-clause-and-why-should-i-care/

[18] See Classen, supra note 4.

[19] Id.

[20] See Lyle, supra note 6.

[21] See Lyle, supra note 6; Heller, supra note 8.

[22] See Classen, supra note 4; Lyle, supra note 6; Heller, supra note 8.

[23] Clark St. Wine v. Emporos Sys. Corp., 754 F. Supp. 2d 474, 481-482 (E.D.N.Y. 2010).

[24] Id. See Classen, supra note 4; Lyle, supra note 6.

[25] See Classen, supra note 4.

[26] SOC 2 and ISO 27001 are widely recognized security standards; SOC 2 uses five trust service principals to assess how organizations manage customer data, while ISO 27001 provides a global standard for establishing, implementing, and maintaining an information security management system. See SOC 2, GOOGLE CLOUD, https://cloud.google.com/security/compliance/soc-2 (last visited March 27, 2026); Implementing ISO 27001, IT Governance USA (Nov. 21, 2025), https://www.itgovernanceusa.com/iso27001.

[27] See Classen, supra note 4; Lyle, supra note 6.

[28] See Classen, supra note 4; Lyle, supra note 6.

[29] See Classen, supra note 4; Lyle, supra note 6.

[30] See Classen, supra note 4; Lyle, supra note 6.

[31] See Classen, supra note 4.

[32] Id.