Data Controller/Data Processor Contracts #3:
Indemnification

There may be no more confusing and misunderstood area of controller-processor contracts than insurance and indemnification. Controllers often expect processors to accept liability, while ignoring the quality (or existence) of processors’ underlying insurance coverage. Processors, on the other hand, often buy insurance products that provide minimal or no protection to meet those controller expectations.

This article will cover several of the realities and implications of the most common indemnification misconceptions and mistakes.

Reality #1: From a regulatory perspective, data controllers are financially responsible for the data security breaches of their data processors.*

Under the vast majority of data protection and privacy regulations, when a data processor experiences a data security breach, it is required to inform the affected data controller. That’s it. It is then the controller’s responsibility to inform regulators and the affected data subjects, and it is the controller who pays the fines and related expenses. And, while the quality of the criteria used to select the processor and the required processor contract can mitigate controller culpability, the most straightforward method for controllers to recoup the actual cost is to have the processor accept financial liability for their mistakes.

Note: Though it is not the subject of this blog, the failure of processors to report data security breaches to controllers is a very real risk. Contracts must be clear in establishing the processor’s responsibility and include a requirement for employees to attest to their individual responsibility. Absent such clarity, the controller could bear the more damaging consequences of allowing a breach to go unreported.

Reality #2: Cyber security or general liability coverages do not, in and of themselves, provide coverage for the financial damages caused by a data processor’s failure to prevent unauthorized access to regulated data.

Unfortunately, the confusion about data protection seems equally distributed among controllers, processors, and the insurance brokers to which they turn. This leads some controllers to erroneously believe a processor’s general liability coverage or cyber security coverage is evidence of indemnification. Neither is unless they have a professional liability provision or “rider.”  Cyber security coverage, in particular, because of its wording, is often misused. The fact is, unless the data breach is a result of unauthorized access to a processor’s computer network, it does not apply. Should a breach be caused by an intentional or negligent act of an employee or by access to hard copy data, the processor’s cyber security coverage, in and of itself, is useless. While such access does often cause a breach, many breaches have nothing to do with unauthorized access to the processor’s computer network.

Making matters more vexing, while professional liability, a.k.a. errors and omissions, insurance is the best coverage model by which a processor can indemnify a controller, it is a gross misrepresentation to say that any and all professional coverages will do the job. The truth is that most will not unless they are specifically crafted to do so.

Reality #3: No matter how well a contract establishes the processor’s liability for financial damages, it is irrelevant if they are unable to back up their obligation.

With controllers becoming more aware that they will be held responsible for their processors’ data breaches, it is more common than not these days for them to insist that processors accept liability for any financial damages they cause. And, while no controller hires a processor with the expectation that the processor is going to mess up, it is certainly a best practice to hold them financially accountable if the worst comes to pass.

Getting the processor to accept some liability is only half the job, however. The easy half. The other half of the job is making sure the processor has the insurance in place to cover that liability. Make no mistake, whatever liability they have accepted is only as good as the policy that backs it up. Should the worst come to pass, it’s the insurance that’s going to pay for it.

But believe it or not, there are a significant number of controller-processor contracts transferring liability to the processor, where the controller makes no effort whatsoever to ascertain if there is any insurance in place to back it up. And, making it worse, there’s no shortage of processors who are taking advantage of this controller omission.

The proper course of action when transferring liability, of course, is not only to verify the insurance is in place but also to review the actual policy to make sure the right language and right limits are present. In other words, it makes no sense to transfer liability to a processor, then just assume that they have the coverage or that the policy is properly written.

Reality #4: Requiring a processor to accept unlimited liability for financial damages is unrealistic for both controllers and processors.

Now and again, a controller will attempt to transfer unlimited liability to the processor. The thinking is that the processor should pay for any amount of damage they cause, no matter how high it goes.

In a perfect world, maybe, but not in this one.

As mentioned, verifying a processor has the insurance to cover their liability is important because that is how they will pay if push comes to shove. The thing is, there is no such thing as a professional liability policy without a limit. One million? Two million? Ten million? Yes, but not unlimited. Expecting a processor to pay more than the limit of their professional liability insurance is unrealistic.

In fact, any processor demonstrating a willingness to accept unlimited liability is a red flag. Clearly, they realize they cannot pay an unlimited amount. They could just close their doors because their corporate structure insulates them personally. In fact, a processor that is willing to accept unlimited liability is the least likely to have proper coverage or any ability to pay.

The best practice for assigning financial liability to the processor is to first establish a reasonable limit of liability based on the risk as well as the amount of money transacted, then evaluate the processor’s coverages to assure that the liability is underwritten.

MORE TO THE STORY

There’s a lot more to the controller-processor indemnification dynamic, not the least of which is navigating the confusing language of the insurance policies themselves. And, when getting any assurances from insurance brokers, make sure they are in writing. A wink and a nod are not admissible in court.

There are also other indemnification tools available that can be brought to bear on this issue, such as performance bonds that apply to individual contracts.

Lastly, however, in addition to taking indemnification more seriously, controllers need to understand that it comes at a cost, and they should not expect to pay the same amount for a processor who is fully embracing their indemnification capabilities as they would for a processor that is either completely in the dark on the topic or that is passing off some irrelevant policy.

* Australia’s data protection regulation, the Privacy Act, is an exception, assigning responsibility to the controller and/or processor depending on the circumstances of the breach. This puts more weight on the quality of the controller-processor contract since inadequate wording is most likely to work against the controller’s interests.