When does an indemnity clause belong in an IT agreement? Without some rule or guiding principle, you’ll find it difficult to negotiate indemnity requests. You’ll find it hard to know when the other party’s request is reasonable, or when your own indemnity request makes sense and you should stick to your guns. Fortunately, the logic of indemnity does reveal a guiding principle. An indemnity makes sense where one party creates a risk that the other will be sued—and the suit is either very likely or would cost a lot to resolve.
As you can see, the rule focuses on risk, not wrongdoing. The indemnitor doesn’t grant the indemnity because it’s done something wrong or because it might in the future. Whether or not the indemnitor ever does anything wrong, its activities create a risk of lawsuits against the other party. The indemnity shifts that risk from the other party to the indemnitor.
The rule explains the IP indemnities you see in so many tech agreements. By providing technology, the vendor creates a risk of suits against the customer, where a third party claims the customer has infringed a patent or copyright by using the technology. These suits happen a lot, and they’re expensive, so the risk imposes a real burden on the customer. It doesn’t matter whether the technology actually does infringe third party IP rights or whether the vendor ever does anything wrong. IP suits involve a risk created by the vendor’s activities, and it’s the vendor who’s in the best position to reduce that risk, by running patent searches, hiring engineers who won’t pirate software, etc. So the indemnity shifts the lawsuit risk from the customer to the vendor.
A customer might grant an indemnity too, where its activities create a lawsuit risk for the vendor. A customer involved in a dangerous business, for instance, might indemnify vendors whose staff risk injury. Imagine the customer manufactures dynamite, and an IT vendor sends staff to the customer’s factory to do some computer programming. If an accident at the plant injures a vendor employee, that employee will probably sue the vendor (among others). So the customer’s activities create a risk for the vendor—a risk the customer has the greatest ability to mitigate, through good safety policies. In that case, many vendors will request an indemnity from the customer covering personal injury suits by vendor employees. Again, it doesn’t matter whether the customer actually does something wrong to trigger an accident. What matters is that the risk arises out of the customer’s business—dynamite—not the vendor’s. The indemnity shifts the lawsuit risk from the vendor to the customer.
What about a risk arising out of both parties’ businesses, where either could be sued over the other’s actions? That case doesn’t fit the rule because it’s not one party creating a risk that the other will be sued. So an indemnity would be a poor fit and probably impossible to negotiate (though if you’re on the receiving end and you can get one, great!). The exception is a bad event much more likely to result from one party’s actions than the other’s. There, an indemnity might work. Let’s look at a data management contract where the customer holds consumers’ private data and hires the vendor to manage that data. A data leak will probably trigger consumer lawsuits against both parties. If the vendor only touches the data briefly, we know in advance that a leak will probably result from the customer’s activities, even though it could result from vendor’s actions. So the customer might indemnify the vendor. Or maybe the customer is huge and holds millions’ of consumers’ private data, while the vendor is a tiny start-up. The key risk arises from the customer’s sheer size, regardless of who causes a leak, so in a meaningful sense, it’s a risk mostly attributable to the customer. Again, the customer might indemnify the vendor (and the vendor might not be able to afford the deal any other way). On the other hand, imagine the vendor’s whole sales pitch revolves around protection of a particular type of data, and the customer relies almost entirely on the vendor to secure the data. In that case, a leak would probably result from the vendor’s actions, and the vendor is likely to indemnify the customer.
You should never use fault to determine who indemnifies whom. In other words, don’t draft an indemnity saying the party at fault for a bad event will indemnify the other. The point is for the indemnitor to defend the other party. And at the start of the lawsuit, when defense obligations kick in, no one knows who’s at fault. That’s not clear until the end of the case, when a court rules on fault. The indemnitor should be on the hook for a particular type of claim, regardless of who’s at fault—because the indemnitor creates the risk. If that places an unfair burden on the indemnitor, then the loss in question isn’t a good candidate for indemnity. (For more on the role of fault, or the lack thereof, see Mirror Indemnities Dont’ Work.)
If indemnity doesn’t fit or you just can’t agree on one, try a lighter contract remedy: a representation or warranty. In other words, if the promisor refuses an indemnity covering some bad event, it can still represent or warrant that the bad event hasn’t happened or won’t. If the rep or warranty turns out wrong, the promisor has breached the contract and probably owes damages. That’s generally not as powerful a remedy as the lawsuit defense you get in an indemnity, but it’s still got teeth. And that’s how most contractual obligations get enforced.
- The Tech Contracts Handbook addresses indemnities in Chapter II.K.
© 2011 by David W. Tollen. All rights reserved.