Indemnification in B2B software agreements: what to give, what to refuse

What an indemnity actually does

Ordinary contract damages compensate a party for its own loss from the other side’s breach. An indemnity goes further: one party agrees to cover losses the other suffers from a defined event, typically a claim by a third party, whether or not the indemnifying party breached anything. That is why it matters so much where the boundaries are drawn.

The indemnity a vendor should give

Third-party IP infringement. If someone sues the customer claiming the vendor’s software infringes their patent, copyright or trademark, the vendor defends and pays. This is market-standard because only the vendor can assess and manage that risk; the customer had no part in building the product. Sophisticated customers will not sign without it, and a vendor that resists it looks either inexperienced or worried.

What makes it affordable are the exclusions. The indemnity should not cover claims arising from:

• Customer data or content the customer put into the system;
• Modifications not made by the vendor;
• Combinations of the product with things the vendor did not supply, where the claim would not have arisen without the combination;
• Use after the vendor has told the customer to stop, or use in breach of the agreement.

Two further limits are common and reasonable: restricting the indemnity to patents of certain jurisdictions (the US, or the countries where the service is offered), and giving the vendor the option to fix the problem — modify the product, procure a licence, or refund and terminate — rather than litigate forever.

Indemnities customers ask for that a vendor should refuse or narrow

“Any breach of this Agreement”

This turns every contractual breach into an indemnified event, usually outside the liability cap. It is not an indemnity, it is unlimited liability with a different heading. Delete it, or narrow it to the categories below.

Breach of confidentiality or data protection

Increasingly requested, and defensible in a narrow form: an indemnity for third-party claims (including regulatory fines, where insurable and lawful) arising from the vendor’s breach of its data obligations, subject to the super-cap discussed in the liability guide. What to resist is an uncapped version, or one that covers the customer’s own regulatory failures.

Breach of law

“Vendor shall indemnify Customer for any violation of applicable law” is unbounded. Narrow to laws applicable to the vendor’s provision of the service, exclude laws that apply because of the customer’s industry or use, and keep it inside the cap.

Personal injury and property damage

Standard in services agreements where people are on site. For pure SaaS it is close to irrelevant, and can be accepted as mutual if the customer insists.

What the vendor should ask for in return

A mutual indemnity from the customer for claims arising from customer data (that it infringes someone’s rights, or that the customer had no right to process it) and from the customer’s use of the service in breach of law or the agreement. This is not aggressive; it is symmetrical.

The procedure clause is where the money is

An indemnity without a procedure is an invitation to dispute. The standard mechanics:

• Prompt notice. The indemnified party must tell the indemnifying party about the claim quickly; late notice reduces the obligation only to the extent it caused prejudice.
• Control of the defence. The indemnifying party runs the defence and chooses counsel. The indemnified party may participate at its own cost.
• No settlement without consent. The indemnifying party cannot settle in a way that admits fault on the indemnified party’s behalf or imposes obligations on it, without consent not to be unreasonably withheld.
• Cooperation. The indemnified party helps, at the indemnifying party’s expense.