Untangling indemnification clauses
Nearly every automation contract has at least one provision that says the system integrator will "indemnify" the customer or end user. What exactly does this mean for the risk the integrator is undertaking for the project?
Despite all the legal jargon crammed into these provisions, the concept of indemnification at its core is quite simple. Through these provisions, the integrator is agreeing to pay a debt of the customer. If the customer has a claim or legal action filed against it and the alleged damages fall under the indemnification provision, the integrator is essentially agreeing to "step into the shoes" of the customer when it comes to financial responsibility.
For example, if the integrator negligently implemented a control system that ended up injuring someone, whenever that someone goes after the customer, the integrator promises to take responsibility for that injury.
Turning indemnification sideways
Unfortunately, that’s where the simplicity ends. There are several ways to turn that indemnity upside down and sideways.
Unconnected to fault. Some indemnification provisions are far too broad and encompass items for which the integrator should not be held responsible. It’s crucial to know the difference between what is reasonable and unreasonable.
It’s reasonable that the implementer takes responsibility for a bodily injury or property damage claim that is made against its customer "to the extent" the claim is the result of the integrator’s own negligence. (Plus, the integrator’s commercial general liability insurance coverage generally provides protection from this risk.) It’s also reasonable for the integrator to indemnify the customer from intellectual property claims that arise from infringing material the integrator created.
What is unreasonable is an indemnification provision that makes the integrator responsible for all damages in any way related to the project, even if the loss is caused by the customer’s own negligence. Such a provision is unfair and uninsurable, and in some states may be illegal. A requirement that the integrator pay for patent infringement damages, even when the problem is with commercial-off-the-shelf (COTS) hardware or software the integrator provided as part of its work, can also lead to a very large pay-out for a risk over which the integrator had no control.
Going beyond third-party claims. Another category of "overreaching" with indemnification provisions is when the customer or end user bends them beyond the reasonable goal of protecting the customer from the claims of others to making them a source of potential claims by the customer itself. Not only does this practice poke a hole in the insurance umbrella (commercial general liability policies typically do not cover first-party contract disputes), but it also makes indemnity clauses a place to hide nasty little legal time bombs—such as a requirement that the integrator pay for the attorneys hired by the customer no matter what the dispute.
Companion terms. A third category of problems can be found in the phrases that no well-dressed indemnification clause would go to market without. Rarely does one see the word "indemnify" without the companion phrases "hold harmless and defend."
These are not meaningless legalese; they actually expand the obligation. Between the two, the word "defend" is one that creates the most risk. It means that in addition to the integrator taking responsibility for claims made against its customer, the integrator will be hiring a lawyer to represent and go to court for the customer. This can make even the smallest dispute an expensive outing. Even worse, sometimes these clauses go on to explain that the lawyers get to be chosen and controlled by the customer. Apart from legal fees, the cost of court reporters, experts, and travel expenses also are covered.
The other term, "hold harmless," typically is much more harmless. With this one, the integrator is promising the customer it will not file a lawsuit that seeks to hold the customer responsible for a particular category of injuries or damage. Again, that additional promise is reasonable to the extent the injury or damage was caused by the integrator, but obviously is much less so if the integrator is promising to "hold harmless" the customer for its own negligence.
The good news is indemnification provisions can work both ways and can (and often should) be used to require the parties to indemnify each other. For instance, an important indemnification provision for integrators to consider including is one requiring the customer to indemnify the integrator from any claims for damages arising from the customer’s failure to maintain the health and safety of its facility and equipment, or for any claims arising from pre-existing conditions of the facility and equipment.A good rule of thumb for integrators: indemnify for third-party injuries and damage that you cause and can control (and, ideally, which can be insured). Try to refrain from indemnifying for anything else.
Mark Voigtmann and Brian Clifford are partners in the automation and robotics practice of Faegre Baker Daniels LLP, a law firm in the U.S., U.K. and China. Voigtmann is on the Control Engineering Editorial Advisory Board. Edited by Mark T. Hoske, content manager, Control Engineering, CFE Media, firstname.lastname@example.org.
Keywords: Legalities, indemnification
Indemnification can add contract complexity.Both parties can hold the other responsible, depending on language.
Third-party injuries and damage that you can control are best for indemnification.
Are you examining contracts for indemnification clauses?