X.X.  Capped Liabilities
  1. Special Cap for Data Breach Liabilities.  A party’s cumulative total liability for any claims resulting from its breach of the “Maintaining Confidentiality” Section (solely those obligations pertaining to Customer Content), the “Implementing Security and Privacy Measures” Section, or the DPA (collectively, “Data Breach Liabilities”) {"changeText":"will not exceed One Year of Fees multiplied by 3"}.
  2. General Cap.  Except for a party’s Uncapped Liabilities, Data Breach Liabilities, and liabilities under the “Paying for Services” Section, a party’s cumulative total liability arising out of or related to this Agreement and all Orders will not exceed One Year of Fees.
Before you copy and paste
  • Should we stick with the Special Cap’s 3x multiplier? <endsummary>
    Evaluate whether the chosen multiple (e.g. 3x, 5x, or 10x) is appropriate based on the sensitivity of data, the Cloud Services’ risk profile, and the risk tolerance of you and your customers. The current 3x cap for Data Protection Liabilities is based on the Bonterms Cloud Terms (v1), a form drafted by a committee of lawyers representing both providers and customers.
  • Should we add any other Special Caps?<endsummary>
    Consider whether any other specific risks justify additional supercaps, for example, for liabilities tied to violations of specific regulations.
  • Should we make the Special Cap apply only to Provider breaches, not Customer ones?<endsummary>
    In most SaaS agreements, elevated liability for data breaches applies only to the Provider, even if the Customer has its own security obligations that could contribute to the risk. This clause takes a different approach: it applies the Special Cap to each party’s own breach of their responsibilities.  Read below (“Why we made the Special Cap apply to Customer too”) to learn about our rationale for this position. Our approach may feel more balanced, since both parties can introduce security risk. But it may also surprise some Customers who are not expecting elevated liability on their side. If you think this will lead to friction in negotiation, consider limiting the Special Cap to breaches by the Provider only. That still provides meaningful protection for the Customer while reducing pushback.
  • How will we make this clause conspicuous?<endsummary>
    We’ve used boxed formatting here to make the section stand out, but that won’t carry over when you paste it. All-caps can hurt readability, so legal teams are starting to use bold text or visual cues (like shading or borders) to meet conspicuousness requirements. Remember to apply that styling in your document.

Why we wrote it this way
  • Why Data Breach Liabilities get a “Special Cap”<endsummary>We do not treat these liabilities as uncapped because the potential exposure may be too high for either party to reasonably take on. But we also do not treat them as ordinary liabilities under the general cap, which may be too low given the scale and seriousness of a data breach. Instead, we use a Special Cap. It reflects the unique risk profile of data-related obligations, offering predictability for both sides while still holding each party meaningfully accountable for their own breach.
  • Why the Special Cap applies only when a party breaches its defined obligations<endsummary>Data breaches can happen for many reasons, including mistakes, misconfigurations, novel attack methods, or external causes such as third-party failures or social engineering. Not all of these are within either party’s control. To avoid assigning liability for outcomes that neither side could have prevented, this cap applies only when a party fails to meet its defined obligations, such as Provider’s infrastructure security commitments or Customer’s access control duties. This approach keeps the risk focused on avoidable failures and avoids turning the agreement into a catch-all insurance policy for every security incident.
  • Why we made the Special Cap apply to Customer too<endsummary>In this agreement, both Provider and Customer have clearly defined security obligations, not just in the DPA, but also in the “Implementing Security and Privacy Measures” Section. For example, Customer must manage access controls, apply updates, and prevent malware. These are not passive duties.  They materially affect system security. By applying the supercap to each party’s own breach of its obligations, we reflect the shared responsibility model of cloud services. Security depends on both sides doing their part. This isn’t always how agreements are structured.  In many templates, only the Provider is subject to this elevated cap. But that’s usually because Customer-side obligations aren’t spelled out clearly in the agreement. In this agreement, they are, and the cap applies only if a party breaches those defined duties.
  • Why the definition “One Year of Fees” addresses liability for post-service claims<endsummary>Liability caps often use a one-year fee baseline because it aligns the cap with what the Provider actually earned, and offers a predictable limit on risk for both sides.  But claims do not always appear during active service. Some arise after the Cloud Services have ended. To clarify how to calculate the baseline after the Cloud Services have ended, our definition of “One Year of Fees” includes a reference point even after Service Closure. It looks back to the most recent 12-month period when fees were paid, so there is always a consistent and fair way to calculate the cap, regardless of timing.

Optional variations
Modify text below to replace it.
Oops! Something went wrong while submitting the form.
{ "changeVariations": { "change1": { "name": "Special cap not to exceed", "contextText":"One Year of Fees multiplied by {3}", "displayedText":"Special cap not to exceed" }}}
Definitions
  • Customer Content<endsummary>[Customer Account Information and] any data or content that Users: (1) submit to their Cloud Services accounts, including from External Tools, or (2) generate from use of the Cloud Services, but excluding Customer Usage Data or any Generative AI Outputs.
  • One Year of Fees<endsummary>the total amount paid or payable by Customer to Provider under all Order(s) during the 12 months immediately preceding the first incident giving rise to liability, or, if the first incident giving rise to liability occurs after Service Closure, the total amount paid or payable by Customer to Provider under all Order(s) during the most recent 12-month period in which Customer paid fees to Provider.
  • Service Closure<endsummary>the end of a Service Period (whether by expiration or Early Termination), without a subsequent Order for the same Cloud Services taking effect immediately after.

Close Modal