• Why we leave out the phrase “hold harmless”<endsummary> “Hold harmless” is a familiar phrase, but not a clear one. Courts across the U.S. disagree on what it means, and whether it adds anything to an indemnity clause. Most jurisdictions treat “hold harmless” as a synonym for “indemnify,” but some courts try to give it independent meaning, suggesting it offers broader protection, such as covering the risk of loss rather than just reimbursement after costs are incurred. That kind of ambiguity can create disagreement later.  If courts or the parties themselves don’t read the phrase the same way, it can lead to arguments about what the clause really requires. If the parties want to draw distinctions about the types of protections or costs this clause covers, it’s better to say that directly.That’s why this clause leaves out “hold harmless” and instead states clearly what the Provider is responsible for.

• Why we use “pay” instead of “indemnify”<endsummary> We’re not against the word “indemnify.” We just don’t think it adds clarity.On its own, “indemnify” can be vague. Courts and lawyers don’t always agree on what it includes: whether it means reimbursing, paying upfront, or protecting someone from having to incur a cost at all.Even when paired with a list of covered losses, “indemnify” doesn’t make it clear when the Provider must pay. Is it only after a judgment? After the Customer pays out of pocket? Or does it include advancing costs during the claim? That lack of clarity creates confusion.That’s why this clause just says what we mean:
  • pay amounts awarded in the Claim
  • cover settlement payments
  • reimburse reasonable costs of assisting with the Claim (if that optional language is included)
  That’s the substance of indemnification, without relying on legal shorthand.Using “pay” doesn’t narrow the obligation. It just makes it easier for lawyers, business teams, and courts to see what’s covered and when payment is required.
• Why we include an obligation for the Provider to “defend” the Customer<endsummary>In SaaS deals, it’s often in both parties’ interests for the Provider, not the Customer, to handle the defense in a Service Infringement Claim. Litigation is resource-intensive, but the Provider usually wants to control lawsuits that challenge the intellectual property rights in their Cloud Services. That is especially true if they are already defending similar claims against themselves or other customers. And while Customers often prefer to control their own legal defense, many are happy to defer in this situation. The Provider typically has both the knowledge and the incentive to defend aggressively, particularly when the outcome could affect every customer using the service.

• Why the Provider’s obligations continue after the Customer’s access ends<endsummary>The Provider’s responsibility doesn’t end just because the Customer’s access does.If a Service Infringement Claim comes in later, even after Service Closure, this clause makes clear that the Provider is still obligated to defend and pay.That is typical in SaaS agreements. Most say that indemnification obligations “survive” the agreement, but they bury that point in a separate survival clause. We think it’s clearer to say it directly. No cross-referencing. Just a clause that explains when it applies.

• Why we include a carveout for the Customer’s Improper Customizations<endsummary>This carveout limits the Provider’s responsibility when a claim arises from something the Customer did, such as modifying the Cloud Services, combining them with other tools, or using them in unsupported ways. The goal is simple: to avoid making the Provider liable for risks it cannot reasonably control. But this carveout can also make enforcement more complex. When a claim arises, the Provider typically needs to act quickly to take control of the defense. The carveout introduces a threshold question: does the Provider even have an obligation to defend? That question often turns on facts that are not clear at the outset. Was the alleged infringement caused by something the Customer did? By a third-party integration? Or by the Cloud Services as delivered? Sorting that out can delay the Provider’s response or create friction between the parties at a time when coordination matters most. In some cases, the uncertainty may even affect whether the claim is resolved efficiently or escalates. Even so, we chose to include the carveout. The risk of friction or delay is real, but it’s outweighed by the importance of setting clear boundaries around the Provider’s responsibility. If the Customer introduces a risk the Provider did not create or control, it is reasonable to exclude that from the Provider’s indemnity obligations and to work through any case-specific gray areas if and when they arise.

• Why we specify the costs that the Provider must cover<endsummary>Instead of using broad terms like “liabilities” or “losses,” we spell out exactly what the Provider must cover: (1) amounts awarded or settlement payments; (2) costs of defending the claim; and (3) costs Customer incurred while assisting with investigation, defense, and settlement (if that optional language is included). General terms like "losses" can be interpreted to sweep in broader harms, such as lost profits or business interruption, that usually go beyond what indemnities are meant to cover. Naming the categories directly helps clarify the obligations and reduce the risk of disputes later.

• Why we avoid listing affiliates or other protected parties<endsummary>Some agreements list affiliates, employees, or other individuals or entities as additional indemnified parties. We do not. This clause focuses on the relationship between the two contracting parties: the Provider and the Customer.  Our rationale:
  • A Provider cannot fulfill its defense obligations effectively without coordinating with the party it is defending. That coordination includes timely notice, strategy decisions, settlement approval, and ongoing cooperation. Without a direct contractual obligation to cooperate with that entity, it is not practical for a Provider to take on responsibility for defending that entity.
  • Limiting the clause to the Customer avoids complicated legal questions about whether non-Customer entities truly qualify as third-party beneficiaries with a direct and enforceable right under the contract.
  Even so, many agreements still include broader lists of indemnified parties. This often reflects a customer’s desire for broader perceived protection across their ecosystem. For providers, accepting broader language, despite the legal and practical challenges mentioned above, is often a pragmatic business decision. In many SaaS contexts, the likelihood of a messy defense is low, and the perceived benefits of faster deal-making, customer goodwill, or market norms may outweigh those risks.Still, for clarity and control, if the goal is to protect specific non-Customer entities, a potentially better approach is to create a separate clause or add language that clearly defines the Provider’s obligations toward them. Simply listing additional parties here, without adjusting the obligations, creates uncertainty about what protections they have and how those protections are enforced.

‍

• Why we leave out the phrase “hold harmless”<endsummary>“Hold harmless” is a familiar phrase, but not a clear one. Courts across the U.S. disagree on what it means, and whether it adds anything to an indemnity clause. Most jurisdictions treat “hold harmless” as a synonym for “indemnify,” but some courts try to give it independent meaning, suggesting it offers broader protection, such as covering the risk of loss rather than just reimbursement after costs are incurred. That kind of ambiguity can create disagreement later.  If courts or the parties themselves don’t read the phrase the same way, it can lead to arguments about what the clause really requires. If the parties want to draw distinctions about the types of protections or costs this clause covers, it’s better to say that directly. That’s why this clause leaves out “hold harmless” and instead states clearly what the Provider is responsible for.

• Why we use the word “pay” instead of “indemnify” <endsummary>We’re not against the word “indemnify.” We just don’t think it adds clarity.On its own, “indemnify” can be vague. Courts and lawyers don’t always agree on what it includes: whether it means reimbursing, paying upfront, or protecting someone from having to incur a cost at all.Even when paired with a list of covered losses, “indemnify” doesn’t make it clear when the Customer must pay. Is it only after a judgment? After the Provider pays out of pocket? Or does it include advancing costs during the claim? That lack of clarity creates confusion.That’s why this clause just says what we mean:
  • pay amounts awarded in the Claim
  • cover settlement payments
  That’s the substance of indemnification, without relying on legal shorthand.Using “pay” doesn’t narrow the obligation. It just makes it easier for lawyers, business teams, and courts to see what’s covered and when payment is required.
• Why we include an obligation for the Customer to “defend” the Provider<endsummary>When a third party brings a claim based on Customer conduct, such as uploading infringing content, submitting regulated data without consent, or using the Cloud Services for an unlawful purpose, the Customer is the one with the relevant facts. The Provider may have had no visibility into the conduct and played no role in it. This clause requires the Customer to lead the defense so that the party best positioned to respond quickly and accurately is the one handling the claim.

• Why the Customer’s obligations continue after it stops using the Cloud Services<endsummary>The Customer’s obligations don’t just end because the Customer’s access does. If a Claim shows up later, even after Service Closure, this clause makes  clear that the  Customer is still obligated to defend and pay. That is typical in SaaS agreements. Most say that indemnification obligations “survive” the agreement, but they bury that point in a separate survival clause. We think it’s clearer to just say it here. No cross-referencing. Just a clause that explains when it applies.

• Why we specify the costs that Customer must cover<endsummary>Instead of using broad terms like “liabilities” or “losses,” we spell out exactly what Customer must cover: (1) amounts awarded or settlement payments; and (2) costs of defending the claim. General terms like "losses" can be interpreted to sweep in broader harms, such as lost profits or business interruption, that usually go beyond what indemnities are meant to cover. Naming the categories directly helps clarify the obligations and reduce the risk of disputes later.

• Why we leave out any obligation to reimburse assistance costs<endsummary>Unlike the Provider indemnity for Service Infringement Claims, in which Provider is obligated to reimburse Customer for reasonable costs it incurred while assisting with Provider’s defense, this clause doesn’t include any reimbursement obligation. Here, the Customer controls the defense and is responsible for resolving the claim. The Customer might occasionally request help from the Provider, like access to logs, product behavior details, or technical background, but that assistance tends to be specific and limited. By contrast, Service Infringement Claims often require deeper, ongoing involvement from the Customer to support the Provider’s defense of its Cloud Services. That’s why reimbursement appears in the Provider clause but not here.  Including it in this clause would likely create negotiation friction without addressing a frequent or high-burden need.

• Why we avoid listing affiliates or other protected parties<endsummary>Some agreements list affiliates, employees, or other individuals or entities as additional indemnified parties. We do not. This clause focuses on the relationship between the two contracting parties: the Provider and the Customer.  Our rationale:
  • A Customer cannot fulfill its defense obligations effectively without coordinating with the party it is defending. That coordination includes timely notice, strategy decisions, settlement approval, and ongoing cooperation. Without a direct contractual obligation to cooperate with that entity, it is not practical for the Customer to take on responsibility for defending that entity.
  • Limiting the clause to the Provider avoids complicated legal questions about whether non-Provider entities truly qualify as third-party beneficiaries with a direct and enforceable right under the contract.
  Still, for clarity and control, if the goal is to protect specific non-Provider entities, a better approach is to create a separate clause or add language that clearly defines the Customer’s obligations toward them. Simply listing additional parties here, without adjusting the obligations, creates uncertainty about what protections they have and how those protections are enforced.

‍

‍

• Why we include a claim coordination section at all<endsummary>Many “indemnification” clauses say who pays, but not what happens when a claim actually arises. That can leave both parties guessing, and potentially arguing, when a claim hits. Without coordination language, they might disagree about:
  • Who gets to choose the lawyer?
  • Who decides the litigation strategy?
  • Who has the final say on settlements?
  By spelling out these steps, the clause gives both sides a clearer roadmap. It explains who controls the defense, what conditions apply to settlements, and what kind of help the other party must provide.This will not prevent every disagreement, but it can reduce surprises and help the parties respond more quickly when a real claim comes in.
• Why we let one party lead the defense<endsummary>Disagreements over claims often go beyond who pays. They can turn into disputes over how the claim should be handled. If both parties try to steer the defense, they may clash over strategy, timelines, or settlement decisions, especially when their interests do not fully align. This clause gives exclusive control to the party bearing the risk, which helps avoid that friction. The controlling party can respond quickly, make consistent decisions, and focus on resolution. Meanwhile, the other party can still have visibility and safeguards, such as the right to hire its own non-controlling counsel and approve in advance any settlement that would require it to admit fault or a legal violation (see Optional Variations). This structure works well for many types of claims, not just IP, because every claim involves judgment calls. The agreement should make clear who has authority to make those calls.

• Why we define a clear scope and process instead of relying on strategic vagueness<endsummary>Many “indemnification” clauses are written in vague language. They promise protection, but often use unclear categories of claims and leave out how the parties will coordinate. That vagueness can give the party tasked with defense more room to push back or delay. If the clause is hard to interpret or apply, the party facing the claim may decide not to press for protection or may let it drop when the legal costs of enforcement outweigh the benefit. In practice, vague indemnification provisions often go unused unless the claim is large enough to justify the uncertainty and expense. But the same vagueness that makes it easier for one side to delay or dispute its obligations also makes it harder for the other to enforce them when it matters. If a real claim comes in and the clause is unclear about what is covered, the parties are more likely to argue over interpretation before they can address the substance of the claim. That adds cost, delays the response, and increases the chance of disagreement. The tradeoff is real.  We chose clarity because the “Handling Claims from Others” section covers a narrow set of claims where the parties’ incentives already support cooperation. The claims assigned to each side are ones each party is naturally positioned to lead, either because they have the relevant information or because the claim involves their own service or data. In that context, a clear roadmap makes the clause more usable, easier to negotiate, and more dependable in practice.

‍

• 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.

‍

• Why this “Limiting Each Party’s Liability” Section starts with with Uncapped Liabilities<endsummary>Most liability caps are phrased as: “Except for x, y, and z, liability is limited to…” That structure can be cognitively harder to parse and reference. By first listing the Uncapped Liabilities, then showing how the remaining liabilities are handled under special or general caps, we mirror how lawyers and contract reviewers typically think about risk. Organizing the clause this way makes it easier to see which risks are never limited, which are capped at a specific amount, and which are covered by the general cap, giving the reader a clearer mental map of how liability is allocated.

• Why we made indemnification (and defense) liabilities uncapped.<endsummary>We treat indemnification obligations as uncapped liabilities because capping them often leads to real-world dilemmas. For example, if the Provider is responsible for defending a claim, what happens when the cap is exhausted? Do they stop midway through litigation or refuse to pay a full settlement? That is not a workable outcome. That is why liabilities under both the “Provider’s Obligations to Handle Service Infringement Claims” and “Customer’s Obligations to Handle Claims Arising from Misuse” Sections are uncapped. This reflects how many parties and courts already interpret indemnity obligations: as commitments to fully defend and resolve a claim, not just up to a dollar limit.

• Why we made breaches of confidentiality uncapped, but not those pertaining to Customer Content.<endsummary>It is common to treat general confidentiality breaches as uncapped liabilities, because misuse of sensitive non-public information (like trade secrets or financials) can cause significant harm and is often difficult to value in advance. But we do not treat breaches involving Customer Content the same way. Most providers cannot take on unlimited liability for breaches involving Customer Content, especially when that content includes sensitive or regulated data.  The potential exposure is too great and too uncertain, even when the data is not regulated. That is why we cover breaches involving Customer Content under the Data Breach Liabilities cap, which offers a realistic but still meaningful layer of protection.

• Why we use the catch-all: “liabilities that cannot be limited by law”<endsummary>Certain types of liability, like those for gross negligence, willful misconduct, or violations of specific statutes, often can’t legally be capped, depending on the jurisdiction. Some agreements list these categories explicitly, but those lists can become incomplete, inconsistent, or legally redundant. Instead, we use a catch-all phrase: “liabilities that cannot be limited by law.” It’s cleaner, more adaptable across jurisdictions, and ensures the agreement doesn’t conflict with any applicable legal limits, without needing to guess which types of liability a court might treat as non-waivable.

‍

• Why we focus on the phrase “special circumstances” as the basis for “consequential damages”<endsummary>This clause uses the term “consequential damages”, but it doesn’t rely on that label alone. Instead, it addresses the legal principle that is often used to explain when consequential damages are recoverable — a test that comes from Hadley v. Baxendale, a foundational contract case still followed by courts today. Under it, a party is only liable for losses caused by special circumstances if, at the time of contracting, those circumstances were disclosed — and the resulting losses were reasonably foreseeable.Although Hadley didn’t use the phrase “consequential damages,” that term later became a shorthand for this second category of recoverable losses. But over time, lawyers and courts have used it to mean very different things — sometimes referring to indirect or ripple effect losses, and other times to damages that are remote or unforeseeable. That kind of ambiguity leads to confusion and mismatched expectations.  Many other legal scholars and commentators have questioned the consequential damages waiver in various contexts, such as here, here, and here.That’s why this clause expresses the concept directly — and then excludes those damages, even when the legal test would otherwise allow them.Why “consequential damages” is especially confusing in cloud agreementsThe phrase “consequential damages” appears in many contracts by default, often without a shared understanding of what it actually covers. Courts interpret it inconsistently, and even experienced lawyers can’t always agree on what’s in or out. That makes it harder to know what’s really being excluded — and whether the parties actually intended that result.This is especially problematic in cloud services agreements, where data breach fallout can be a major risk. Many of the most costly consequences of a breach — such as:
  • Regulatory fines
  • Notification costs
  • Forensic investigation costs
  — are often treated as consequential damages. Yet when those costs result from a failure to meet contractual obligations, neither party typically intends to exclude them. The label creates more confusion than clarity.Why this clause takes a clearer approachRather than relying on the term “consequential damages” to carry the weight, this clause spells out what’s excluded: damages arising from special circumstances — including risks tied to a Customer’s unique operational setup, their high-value contracts with others, or their specialized regulatory obligations. These are the kinds of losses that might be foreseeable if disclosed, but the clause makes clear that the Cloud Services are a standardized offering — and that disclosure alone doesn’t make those losses recoverable.
• Why we don’t use the phrase “special damages”<endsummary>Most drafters use the term “special damages” as a synonym for consequential damages — but this clause already addresses that concept directly. Including both terms is a common boilerplate habit, but it creates unnecessary ambiguity: if a contract waives both “special” and “consequential” damages, courts may assume they mean different things and try to distinguish them. That’s where confusion creeps in. Some courts interpret “special damages” using tort-based definitions — like specific, measurable losses — which have nothing to do with contract foreseeability. To avoid that kind of interpretive guesswork, this clause leaves the term out entirely and focuses on the well-established principle of special circumstances and foreseeability instead.

• Why we don’t use the phrase “indirect damages”<endsummary>“Indirect damages” is a vague and inconsistently applied term. Some contracts use it as a synonym for consequential damages, while others treat it as a broader catch-all for ripple-effect losses — but few define it clearly. Courts often struggle to distinguish it from other damages categories, and the result is legal uncertainty about what’s actually being excluded. In practice, most parties who want to exclude “indirect damages” are really trying to avoid responsibility for business impact losses — like diminished goodwill, lost market share, or reduced future revenues. These are ripple-effect harms that aren’t tied to a specific failure, but instead reflect broader commercial fallout. Rather than rely on the unclear label “indirect damages,” this clause identifies those risks directly — and excludes them. That gives both parties a clearer understanding of what’s in and what’s out, without relying on an imprecise term.

• Why we don’t use the phrase “incidental damages”<endsummary>While “incidental damages” is defined under the Uniform Commercial Code for goods, the term has no clear or consistent meaning in SaaS or service contracts. Courts have treated it differently, sometimes as a subset of consequential damages, sometimes as a separate category covering mitigation or workaround costs, like engaging a temporary vendor or restoring lost data. That vagueness creates risk. In a data breach, for example, a customer’s reasonable costs to respond—like hiring a breach response team or complying with legal notice obligations—might be labeled “incidental.” A blanket exclusion could be read to bar those entirely, even though both parties would likely expect them to be recoverable. Some providers exclude incidental damages as another method of reducing liability. But in our view, a well-scoped monetary cap already serves that purpose. Including the term risks cutting off recovery for reasonable, foreseeable costs the contract should cover—so we’ve chosen not to use it.

• Why we don’t use the phrase “exemplary damages”<endsummary>Exemplary damages (also called punitive damages) are intended to penalize especially wrongful conduct — like fraud, bad faith, or intentional harm. Many contracts exclude exemplary damages by reflex — as part of a boilerplate list of damages categories. But including that kind of exclusion may suggest the agreement is trying to shield both parties from liability, even if they commit serious misconduct. That’s not the intent here, so we leave exemplary damages out.

• Why we don’t use the phrase “punitive damages”<endsummary>This clause doesn’t use the phrase “punitive damages” (or its synonym, “exemplary damages”). These types of damages are meant to punish especially wrongful conduct — like fraud, bad faith, or intentional harm — and are rarely awarded in commercial contract disputes. Many contracts exclude them reflexively, as part of a boilerplate list of damages categories. But doing so may suggest that the agreement is trying to shield the parties from liability even for serious misconduct. That’s not the intent here, so this clause leaves both terms out.

• Why we use “lost revenues” instead of “lost profits”<endsummary>This clause excludes lost revenues rather than just lost profits to draw a clearer, more defensible boundary around income-based claims. Using the phrase “lost profits” can lead to disputes, not just about how much was lost, but about what counts as profit in the first place. Determining which profits were loss depends on  assumptions about which costs would have applied, what margins would have been, and how to account for hypothetical outcomes. That complexity can make the exclusion harder to enforce. Excluding lost revenues helps avoid those definitional debates. It focuses the exclusion on the total income the customer expected to earn — without having to argue over what portion of that income would have been retained as profit. And because profits are just a portion of revenue, this exclusion still covers them by default. While revenue loss claims can still raise factual questions about the amount, this approach gives both sides a cleaner starting point for what’s in or out of scope.

‍