The default software indemnity caps the vendor's protection at the fees you paid in the prior 12 months, which means a $500K contract leaves you carrying every dollar of a multimillion-dollar third-party claim above that line. Indemnification is the contract's risk-transfer engine. It decides who defends and who pays when someone outside the contract brings a claim, most often an intellectual property infringement claim or a data-breach claim. Vendors draft it narrow. Buyers should reset it on three axes: scope, cap, and carve-outs.
What indemnification covers
An indemnity is a promise by one party to defend the other against specified third-party claims and to pay the resulting damages and settlement. It is distinct from the limitation of liability clause, which governs what the two parties can claim against each other. Indemnity faces outward, toward claims brought by someone else. In software contracts the two indemnities that matter most are intellectual property infringement, where a third party alleges the software violates a patent or copyright, and data protection, where a breach of personal data triggers regulatory and civil claims.
The main types of indemnity
Three indemnities appear in nearly every enterprise software contract, and a fourth is now standard for anything involving AI.
| Indemnity type | Protects against | Buyer's target position |
|---|---|---|
| IP infringement | Third-party patent, copyright, trademark claims on the software | Uncapped, defense plus damages plus settlement |
| Data breach | Claims arising from vendor's mishandling of personal data | Super-cap of 2 to 3 times annual fees |
| Confidentiality breach | Misuse or disclosure of confidential information | Carved out of the general liability cap |
| AI output indemnity | Claims that AI-generated output infringes third-party rights | Explicit, with no carve-out for model training data |
The vendor draft typically offers a single IP indemnity, subjects it to the general liability cap, and is silent on data breach and AI output. Each gap is a negotiation point. The AI-specific gap is addressed in our AI contract clauses guide and AI IP ownership analysis.
Caps and the super-cap structure
The most consequential edit is decoupling indemnity from the general liability cap. A general cap of one times annual fees is normal for direct damages between the parties. Applying that same cap to a third-party IP claim is not, because the buyer did not create the infringement and cannot control its size. The market position for sophisticated buyers is an uncapped IP indemnity and a separate super-cap, usually two to three times annual fees, for data-breach indemnity.
The cap-stacking lever: Vendors resist uncapped indemnity by pointing to their own insurance limits. The productive counter is a tiered structure: uncapped for IP infringement where the vendor controls the risk through its own code, a super-cap of two to three times fees for data-breach claims, and the standard cap for everything else. This gives the vendor a defined maximum exposure on the risks it cannot fully control while removing the cap on the risk it created. Most enterprise vendors accept this structure once it is framed as risk allocation rather than as an open-ended liability.
Carve-outs that gut the protection
An indemnity is only as strong as its exceptions. Common vendor carve-outs exclude claims arising from the buyer's modification of the software, from combination with third-party products, from use outside the documentation, and from continued use after notice of an infringement. Read individually each sounds reasonable. Together they can swallow the indemnity, because almost all enterprise software is combined with other products. The buyer's job is to narrow each carve-out to genuine buyer fault. A combination carve-out, for example, should apply only where the infringement arises solely from the combination and not from the vendor's product on its own.
Mutual versus one-sided indemnity
Vendors increasingly ask the buyer to indemnify them, most often for the buyer's data and for the buyer's use of the software. Some buyer indemnity is reasonable, such as protection against claims that the buyer's own data infringes a third party's rights. What is not reasonable is a broad buyer indemnity that mirrors the vendor's, because the buyer does not control the software and should not insure the vendor against the product. Keep buyer indemnity narrow and tied to things genuinely within the buyer's control.
AI-specific indemnity in 2026
Generative AI products created a new indemnity question: who pays if AI output infringes a third party's copyright. Several major vendors now offer an output indemnity, but the conditions vary, and many carve out cases where the customer disabled content filters or the claim relates to training data. Buyers should require an explicit, written AI output indemnity, confirm it survives across model versions, and reject carve-outs that depend on the model's own training process, which the buyer cannot inspect. This sits alongside the data-rights and IP-ownership terms covered in our AI IP ownership guide.
Who controls the defense
The party that controls the litigation controls the outcome, so the defense-control clause matters as much as the indemnity itself. The standard position gives the indemnifying vendor the right to control the defense and settlement of a covered claim, because the vendor is paying for it. The buyer's protection is a consent right: the vendor cannot agree to a settlement that imposes any obligation on the buyer, admits buyer fault, or fails to fully release the buyer, without the buyer's written consent. The buyer should also retain the right to participate with its own counsel at its own cost, which keeps visibility over a case that could affect its operations. Without these protections an indemnity can technically pay out while leaving the buyer bound by terms it never agreed to.
Infringement remedies: repair, replace, refund
An IP indemnity usually pairs with a remedies clause that gives the vendor three options if the software is found to infringe, and the order matters to the buyer. The vendor may procure the right for the buyer to keep using the software, modify it to be non-infringing, or replace it with a functionally equivalent product. Only if none of those is commercially reasonable may the vendor terminate and refund. The buyer's concern is the refund formula, because vendors often offer a refund depreciated over a short period, which on a perpetual license can be near zero after a few years. The buyer should require that the refund reflect the actual value lost, including a fair portion of the fees paid, not a steeply depreciated book value.
| Remedy | Vendor preference | Buyer's target |
|---|---|---|
| Procure right to continue use | Preferred, lowest cost | Acceptable, first choice |
| Modify to non-infringing | Acceptable | Only if functionality preserved |
| Replace with equivalent | Acceptable | Only if functionally equivalent |
| Terminate and refund | Last resort | Refund must reflect real value lost |
Sample language buyers should request
Strong indemnity language shares four features that buyers can request directly. The defense obligation should read that the vendor will defend, indemnify, and hold harmless the buyer, which is broader than a bare obligation to indemnify. The covered claims should include damages, settlements, and reasonable attorney fees, so the buyer is not left carrying its own legal cost. The trigger should be any third-party claim that the software infringes, not only a claim that has been finally adjudicated, so the duty to defend starts when the claim is made. And the survival clause should keep the IP indemnity in force after the agreement ends, because infringement claims can arise years later. These four asks are standard among sophisticated buyers and rarely break a deal.
Insurance backing and financial capacity
An uncapped indemnity is only worth as much as the vendor can pay, so financial capacity is part of the analysis. For a large, well-capitalized vendor the indemnity is backed by the balance sheet. For a smaller vendor or a startup, the buyer should require evidence of technology errors-and-omissions insurance and cyber liability insurance at limits proportionate to the contract value, and should name the buyer as an additional insured where appropriate. The insurance does not replace the indemnity. It provides a funded source behind it, which matters most precisely when a claim is large enough to threaten a smaller vendor's solvency.
How indemnity interacts with the liability cap
Indemnity and the limitation of liability clause must be read together, because a generous indemnity can be quietly neutralized by a liability cap that sweeps it in. Vendors frequently draft a single overall cap that applies to all claims, then place the IP indemnity inside it, so a third-party infringement claim larger than the cap leaves the buyer exposed for the excess. The fix is structural: name the indemnities as express exclusions from the general cap, then set their own limits, uncapped for IP infringement and a defined super-cap for data breach. A buyer who negotiates a strong indemnity but accepts a single all-claims cap has, in effect, given the protection back.
The same logic applies to the exclusion of consequential and indirect damages. That exclusion is reasonable between the parties for ordinary contract claims, but a third-party claim the buyer must satisfy is a direct cost to the buyer regardless of how the vendor's contract characterizes it. The indemnity should make clear that amounts the buyer pays to a third party under a covered claim are recoverable in full, and are not cut down by the consequential-damages exclusion. Vendors resist this in the abstract and concede it once it is framed as the buyer being made whole for money it actually pays out.
Reading the two clauses as one system is what separates a contract that looks protective from one that is. The redlines below assume this system view, because each edit only holds if the liability architecture around it is set correctly first.
What is realistically negotiable
Not every ask carries equal weight, and knowing which positions vendors concede saves the negotiating capital for the ones that matter. Uncapped IP indemnity, a consent right on settlement, and recovery of third-party payments outside the consequential-damages exclusion are widely accepted by enterprise vendors once framed as standard risk allocation. A data-breach super-cap of two to three times annual fees is common and usually moves with modest pressure. Harder asks include uncapped data-breach liability, which most vendors refuse, and a fully mutual indemnity, which is rarely appropriate anyway. Spending the negotiation on the achievable core, rather than on positions the vendor will never grant, is what produces a signable contract that still protects the buyer.
The redlines that matter most
Five edits carry most of the value. Decouple IP indemnity from the liability cap and make it uncapped. Add a data-breach super-cap of two to three times annual fees. Narrow the combination and modification carve-outs to sole-cause buyer fault. Add an explicit AI output indemnity with no training-data carve-out. Confirm the vendor controls the defense but cannot settle in a way that admits buyer liability without consent. The complete clause-by-clause method sits in our software contract negotiation guide, with related risk terms in our escalation clause and SLA negotiation guides. For a redline against benchmarked positions, see our software licensing advisory service.
Enterprise Software White Papers
Buyer-side playbooks for licensing and negotiation.