Kafka wrote in his Fourth Octavio Notebook that “by imposing too great a responsibility…on yourself, you crush yourself.” The same principle applies to tech contracts: not having effective limitation of liability clauses is a surefire recipe for being crushed. But what does an effective limitation of liability clause look like? How does one negotiate such a clause and get the counterparty’s agreement? What makes tech contracts different from, say, any other contract?
What do limitation of liability clauses do?
A limitation of liability clause largely does what it says: it puts an upper limit on how much a party has to pay the other party if something goes wrong. This clause often includes two elements: (1) a cap on monetary damages (e.g., 100% of fees payable); and (2) an exclusion of certain categories of loss considered too remote (e.g., indirect damages, consequential damages, punitive damages). Importantly (especially for lawyers!), there are often carveouts to limitation of liability—some types of loss can’t be capped. These carveouts often cover losses not directly tied to the goods or services (data breaches, stealing confidential information or IP, not complying with laws).
The dance usually goes something like this. The party who provides the initial draft (often, but not always, the seller—we’ll call them the “Drafter”) limits its own liability, but not the other party’s. The draft typically caps total liability at fees payable in X period or a specific (and often very low!) monetary amount. AWS’s customer agreement, for example, caps liability at 100% of fees paid in the 12 months before the claim arose. The Drafter generally omits the carveouts mentioned above—meaning that their responsibility is capped for everything.
The non-drafting party (we’ll call them the “Draftee”) is thus left in a conundrum: try to strike the whole clause, make it mutual, or accept that life is unfair and try to mitigate risk.
Indemnity ≠ Limitation of Liability
Limitation of liability clauses are not indemnity provisions. This distinction often confuses people new to contracts. Indemnity, or indemnification, spells out who pays for claims from third parties, not claims between parties to a contract. Good drafting involves keeping the two distinct—both in the contract and as items of negotiation. To avoid ambiguity, the best practice is to clarify that indemnity provisions are not subject to any agreed liability cap (see, e.g., M/S Bremen v. Zapata Off-Shore Co. on clarity in risk allocation). This is true even if your own damages are capped—you’re still taking a gamble by assuming a court will apply the cap to indemnity.
Making terms “conspicuous” across jurisdictions
You’ve undoubtedly seen limitation of liability and indemnity clauses written in ALL CAPS. In the U.S., this isn’t just for the gratification of lawyers. Courts sometimes require “conspicuous” drafting for certain clauses to be enforceable. All-caps is one common way to do that (others include bolding or boxed text). Outside the U.S., standards vary: the U.K. applies a “reasonableness” test under the Unfair Contract Terms Act. The E.U. focuses on transparency and consumer protection. Many Asian jurisdictions lean on civil-law principles of good faith. The tl;dr is that all-caps are a smart play for limiting exposure—particularly if the contract has a U.S. angle. Other jurisdictions still may consider additional factors when deciding whether to enforce limitation of liability clauses.
How to approach negotiations
The first thing to note is that limitation of liability clauses are always negotiable. There may be some clickwrap or scroll-wrap terms in which it’s not worth the hassle. With contracts though, it always takes two to tango. Both parties must agree on terms and manifest their assent for a contract to be valid.
For Drafters, this means making sure terms are airtight. The initial draft should exclude all non-direct damage categories (not just indirect!) on any theory of liability and be appropriately capped. Any exclusion to the cap should be reasonable and reflect applicable caselaw (e.g., damages which can’t be excluded under applicable law, gross negligence, willful misconduct). Drafters should also give Draftees sufficient time to review and request changes to preclude any defenses to contract enforceability.
Draftees should understand that they can request changes. In cases with minimal Draftee breach risk (e.g., prepayment for SaaS), it makes sense to just strike the whole clause. In more complex contracts involving more moving parts, the Draftee can propose to make the clause mutual. A mutual clause, if agreed, would feature language like: “Neither Party’s damages shall exceed…”
In such cases, the Draftee will generally also want make exclusions to the cap for identifiable risks such as data breach. If the Drafter agrees to make a clause mutual, however, the Draftee should generally avoid proposing cap exclusions where the Draftee has greater risk exposure (e.g., misappropriation of the Drafter’s IPR). The key is to find your likely risk points relative to the contract and ensure that they are adequately addressed.
While the parties can wrangle over the final terms, a few factors will determine what gets agreed. The first factor is whether there are any other outstanding clauses in the agreement. A limitation of liability clause concession is often exchanged for concessions elsewhere. The second factor is whether the parties have—and offer proof of—insurance. If a party provides proof of insurance, the other party may be willing to accept a less-than-ideal limitation of liability clause on the understanding that recourse will be relatively straightforward. A third factor is the contract subject itself. Speculative new technologies, projects in legal gray areas, and contracts involving new or foreign companies likely call for more robust limitation of liability clauses and fewer concessions.
What makes technology contracts different?
A few factors make tech contracts, particularly in software different from those in other industries:
- Scalability. Unlike a one-off services contract, a SaaS or tech product can impact thousands (or millions) of users simultaneously. A coding bug or data breach can easily affect a product’s entire customer base. The multiplier effect means limitation of liability clauses are not just boilerplate, but existential. The 2020 Solar Winds breach is a vivid example of what can go wrong.
- Data Risk. Technology agreements almost always involve handling sensitive data: customer PII, financial records, or proprietary algorithms. Data breaches or misuse trigger statutory penalties, class action exposure, and reputational damage. Because these losses are usually excluded as “consequential damages,” parties need to think carefully about carveouts.
- Cyber-insurance and alignment. Even the best-drafted limitation of liability clause is only as good as the insurance backing it. Most startups—and even some established companies—typically don’t have cash on hand to address data breaches or outages. This is where cyber-insurance comes in. In tech contracts, parties often negotiate carveouts to match cyber-insurance coverage (e.g., a higher liability cap for security incidents). Unfortunately, only around 55% of companies have cyber-insurance, according to a 2023 Marsh report. If insurance is absent or insufficient—as is often the case—risk allocation can be meaningless in practice.
Bringing it all together
Tech contracts aren’t just about abstract legal doctrine. They’re about managing real, tangible risks in fast-moving industries. Whether you’re a founder, investor, or in-house counsel, limitation of liability clauses sit at the center of this balancing act. Once you understand these clauses and tech-specific risk factors—scalability, data sensitivity, and cyber-insurance—you’re in a stronger position to negotiate better terms.
Conclusions & best practices
In approaching limitation clauses, a few practices will go a long way to mitigating risk and ensuring healthy and sustainable growth:
- Be willing to negotiate. All terms can be negotiated. You can walk away if the risk is too high. Even boilerplate terms with big players can be changed. Just ask!
- Understand your risk profile. This applies generally (“we’ve had data breaches in the past”) and specifically (“we’ll be sharing our API for this project”). A SaaS company handling user data will likely want different liability cap carveouts than a consultancy writing white papers. The key is knowing where you are vulnerable and negotiating clauses that protect you.
- Cover risks robustly. Make sure that any lists of liability exclusions—or carveouts—are robust and cover contingencies. Don’t assume that boilerplate terms from templates protect you. Each company’s risk profile is different, and each project present its own risks.
- Tailor language to your actual exposure. It is essential to make sure that your edits mitigate the risks you’ve identified. If IPR risk is primarily on your side, there’s no need to propose an IPR carveout. If indirect damages are significantly more likely to be caused by the other party, you probably don’t want an indirect damages exclusion.
- Take insurance seriously. A robust insurance strategy involves three elements: (1) having your own coverage; (2) getting proof of (sufficient) coverage from the other party; and (3) including a contractual obligation for the other party to maintain insurance. This tripartite strategy ensures that any contingency is adequately covered.
To pick up on Kafka’s quote, life is full of responsibilities. They don’t have to all fall on us. With robust limitation of liability clauses, we can reduce our own exposure and ensure that risk is well-distributed.
Disclaimer: This blog is for informational purposes only and does not constitute legal advice. Reading or interacting with this content does not create an attorney–client relationship. You should consult a qualified attorney for advice regarding your specific situation. Mehaffy, PLLC disclaims all liability for actions taken or not taken based on this blog.