Indemnification

Concept

A contract clause promising that if something you supplied causes a third party to come after your customer, you cover what that costs them.

Why it exists

Buying software has always carried one unavoidable worry: you bring in a program someone else built, and only the people who built it know what went into it. If the vendor borrowed another company's code or licensed font without permission, the vendor is the only party who knows. The letter from the rights holder, though, lands on the desk of the customer running the software.

The shape it takes in practice is usually something like this. One morning a demand letter arrives from a type foundry saying their font is being used on the customer's website without a license and they want payment. The font turns out to have been dropped in by the agency that built the site, but the invoice goes to the company operating it, because what matters to a rights holder is not who installed something but who is using it.

The customer can call the agency and say they put it there so they should deal with it, but without a sentence in the contract saying so, that call carries no weight. The agency can reply that their contract covered building the site and nothing more. The customer then hires their own lawyer, argues the case on their own budget, and may still end up paying the license fee at the end of it. One party creates the problem, the other pays for it.

Indemnification drags that mismatch back inside the contract. It writes down in advance that whoever created a problem also carries its cost, which is why it's one of the first clauses a buyer's legal team looks for.

How it works

The defining feature is that three parties are involved. You and the customer have a contract, and a third party outside that relationship brings a claim against the customer. Most other clauses govern what happens between you and the customer. This one governs what happens between the customer and the outside world.

When it triggers, four things happen in order.

  1. The customer notifies you within a set window, usually in writing and within a few days. Contracts normally add that late notice releases you from the obligation, since the later you hear about a claim, the fewer options remain for responding to it.
  2. You take over the defense. Choosing counsel and deciding how to fight becomes your call. Whoever pays decides the approach — which also stops a customer from hiring the most expensive firm available and forwarding you the bill.
  3. You pay the costs. That covers legal fees, court costs, and whatever damages get awarded in the end. Even a case you win at zero damages has already cost you the legal fees.
  4. Settlement requires both sides to agree. Terms you can close out by writing a check are yours to accept. Terms that stop the customer from doing something going forward need the customer's consent.

The clause also names what it covers. Intellectual property (IP) infringement is the most common subject — your product infringes someone's patent or copyright and the customer gets a claim for using it. Data breaches and misconduct by your employees sometimes get added on top. The wider that list runs, the more risk sits on your side, which is why this is the sentence that gets negotiated hardest and the one worth pricing before you agree to it.

Where it shows up

It is close to universal in enterprise contracts. Indemnification lives in the master service agreement (MSA), the document holding the conditions that apply across the whole relationship, while the statement of work (SOW) attached to each project covers only what gets delivered this time. The indemnity doesn't change when the project does.

In enterprise sales this clause alone can add weeks to a deal. The bigger the buyer, the more thorough the legal review, and a sentence that started out covering IP comes back asking for security incidents and data breaches too. Sellers walk into that negotiation with a line already decided internally about how far they'll go.

There are places where the direction reverses. Terms of service usually include a sentence in which the user indemnifies you: if someone uploads copyrighted material to your product and the rights holder comes after you, the person who uploaded it carries the cost.

Writing the clause turns out to be smaller work than being able to honor it. If you don't know what third-party code sits inside your product and on what terms, the promise becomes a device with an unknown timer. An open source license sets the conditions for using publicly available software, and some of those conditions require publishing the entire product that includes the code. Ship that unknowingly and the claim your customer receives becomes yours.

How it sounds at work

"They want security incidents inside the indemnity scope. We can't accept that."

The exposure jumps far beyond what we carry today, so we'll push back.

"This clause sits outside the liability cap. It's uncapped."

Other damages stop at a ceiling; this obligation doesn't.

"We'll agree if we control the defense."

We'll pay, but we decide how the case gets fought.

At Pagedeck this clause took the longest during the first large enterprise contract. The draft from the buyer's legal team had Pagedeck indemnifying for IP, personal data, and security incidents, with all three carved out of the liability cap. The contract was worth $45,000 a year.

Grace and Sofia negotiated it down so that personal data and security incidents were capped at three times the annual contract value, leaving only IP uncapped. Theo, meanwhile, inventoried every piece of outside code in the product along with its license. Leaving an uncapped promise in place was only possible because that list came back clean.

What people get wrong

The most frequent mistake is reading the clause as protection for yourself. The word sounds defensive, and "indemnity" gets filed mentally alongside disclaimers and limitations. What it actually does is relieve the other party, with you absorbing what they would have paid. Read backwards, the heaviest sentence in a contract looks like one of the lightest, and a line waved through without review turns into an uncapped bill later.

The second mistake is assuming the obligation applies equally in both directions. Contracts feel like agreements between equals, so indemnities ought to be mutual. In practice they tilt. The indemnity the seller gives for its product is broad, while the one the buyer gives covers a narrow slice such as content they uploaded. Unless you check whether the sentence runs one way or both, and whether both directions cover the same ground, you can end up carrying all the exposure inside a paragraph that looks perfectly balanced.

Easily confused with

TermWhat it setsHow it differs
Limitation of liabilityThe ceiling on what you oweSets how much. Indemnification sets who pays, and it is commonly carved out as an exception to that ceiling
WarrantyA promise about the state of the productA promise between you and the customer. Indemnification deals with what happens between the customer and a third party

Where to go next

Last updated 2026-09-16