EMI v. Comerica: Comerica's Motion for Summary Judgment
Back in February 2010, we reported on an online banking lawsuit filed by by Experi-Metal Inc. (“EMI”) against Comerica (the “EMI Lawsuit”). As you might recall this case involved a successful phishing attack that allowed the bad guys to get the EMI’s online banking login credentials and wire transfer about $560,000 from EMI’s account (the original amount was $1.9 million, but Comerica was able to recover some of that). The bad guys were able to foil Comerica's two factor token-based authentication with a man in the middle attack. Comerica did not reimburse EMI for the loss, and this lawsuit resulted. In April 2010, Comerica filed a motion for summary judgment in order to dismiss the case. The motion has been fully briefed by both sides, and this blogpost looks at the arguments being made by the parties (you can find EMI’s response brief here and Comerica’s reply brief here).
P.S. I have linked to some of the key documents and have not included all of the supporting exhibits. I have all of the exhibits supporting all of these briefs, including relevant contracts and guides. If you want them all, please contact me at dnavetta@infolawgroup.com and we can arrange something.
Background
This matter revolves around a couple sections of Michigan’s version of the Uniform Commercial Code, in particular MCLA 440.4702(2), which provides in relevant part:
(2) If a bank and its customer have agreed that the authenticity of payment orders issued to the bank in the name of the customer as sender will be verified pursuant to a security procedure, a payment order received by the receiving bank is effective as the order of the customer, whether or not authorized, if (i) the security procedure is a commercially reasonable method of providing security against unauthorized payment orders, and (ii) the bank proves that it accepted the payment order in good faith and in compliance with the security procedure and any written agreement or instruction of the customer restricting acceptance of payment orders issued in the name of the customer. The bank is not required to follow an instruction that violates a written agreement with the customer or notice of which is not received at a time and in a manner affording the bank a reasonable opportunity to act on it before the payment order is accepted. (emphasis supplied)
MCLA 440.4702(3) explains how “commercial reasonableness” is to be determined under MCLA 440.4702(2):
(3) Commercial reasonableness of a security procedure is a question of law to be determined by considering the wishes of the customer expressed to the bank, the circumstances of the customer known to the bank, including the size, type, and frequency of payment orders normally issued by the customer to the bank, alternative security procedures offered to the customer, and security procedures in general use by customers and receiving banks similarly situated. A security procedure is deemed to be commercially reasonable if (i) the security procedure was chosen by the customer after the bank offered, and the customer refused, a security procedure that was commercially reasonable for that customer, and (ii) the customer expressly agreed in writing to be bound by any payment order, whether or not authorized, issued in its name and accepted by the bank in compliance with the security procedure chosen by the customer. (emphasis supplied).
Finally, the definition of “security procedure” under MCLA 440.4701 is relevant in this context:
“Security procedure” means a procedure established by agreement of a customer and a receiving bank for the purpose of: (i) verifying that a payment order or communication amending or cancelling a payment order is that of the customer, or (ii) detecting error in the transmission of a the content of the payment order or communication. (emphasis supplied)
In short, what these laws do is assign the risk of loss with respect to payment orders that may not have been actually initiated by the customer. Even if a payment order is initiated by a criminal that payment order will be deemed effective under the law as long as the requirements of MCLA 440.4702(2) are satisfied. If those requirements are satisfied, the losses may fall on the banking customer rather than the bank (at least with respect to this particular law – there may be other theories of liability that could apply).
Comerica’s Motion for Summary Judgment
The following summarizes the main arguments put forth by Comerica in its motion for summary judgment ("MSJ").
- Comerica’s security procedure was commercially reasonable as a matter of law.
Comerica had established two-factor authentication using RSA secure token technology for its online banking. In order to access its online banking account EMI was required to input a user ID, password and PIN number generated from the RSA token(s) posesed by EMI (the PIN is randomly generated and changed every sixty seconds). Comerica maintains that EMI agreed that this security scheme was commercially reasonable. Support for this contention is found in the NetVision Wire Transfer Agreement entered into by EMI, which provided:
Customer [EMI] agrees that the selected Security Procedures are commercially reasonable for the type of entries which Customer may transmit to Bank, and Customer shall hold Bank harmless for any action taken in reliance upon the use of the Security Procedures.
Comerica also argues that 2-factor authentication is the same security it uses for its high volume wire transfer customers (i.e suggesting that it was providing more security than would normally be afforded to a low volume customer like EMI).
Key to its argument is the language of MCLA 440.4702(3)(i) italicized and bolded above. Comerica argues that it offered EMI the ability to require up to two users to confirm every wire transfer payment order made by an EMI employee (the evidence for this offer is an affidavit from a Comerica VP indicating that she told EMI’s online account administrator about this security option). Following the relevant language in MCLA 440.4702(3), Comerica argues that EMI was offered this security option, but refused it, and therefore the two-factor authentication that EMI used is automatically “deemed” commercially reasonable.
- Comerica followed the security procedure EMI agreed to use and acted in good faith
Comerica argues that there is no evidence suggesting that it failed to follow its security procedures consistent with MCLA 440.4702(3)(ii), and it maintains that it acted in good faith accepting the fraudulent payment orders. Specifically, Comerica indicates it followed the two-factor authentic procedure that had been established. It also uses this argument to support its position that it acted in good faith. In addition, Comerica points to the assistance it provided EMI in recovering a large portion of the transferred funds as evidence of its good faith.
- EMI admitted it was the source of the security breach
Comerica also argues that EMI was responsible for keeping passwords and PINs confidential, and that its actions resulted in the breach when it provided the information to the phishing attacker. To support this argument, Comerica sites a comment to UCC section 4A-203 which states:
The burden on the customer is to supervise its employees to assure compliance with the security procedure and to safeguard confidential security information and access to transmitting facilities so the security procedure cannot be breached.
EMI’s Response to Comerica’s Motion for Summary Judgment
EMI sets forth several arguments as to why it believes that summary judgment is unwarranted. As a reminder, the general rule is that motion for summary judgments should be granted only if there is no genuine issue as to any material fact (such that judgment is appropriate as a matter of law). Focusing on MCLA 440.4702(2) and the definition of “security procedure” under MCLA 440.4701, EMI sets forth four arguments contending that genuine issues of material fact do exist (making summary judgment inappropriate).
- EMI never agreed to the RSA Token security procedures, therefore they are not “security procedures” as defined under MCLA 440.4701
MCLA 440.4702(2) only applies to “security procedures” as defined under MCLA 440.4701. EMI contends that it never agreed to the RSA token security procedures, and therefore MCLA 440.4702(2) is not applicable.
This argument rests on the allegation by EMI that Comerica switched wire transfer services, and EMI never agreed to the security procedures for the new services. EMI argues that it had entered into an agreement for NetVision Wire Transfer Services in November 2003. As mentioned in Comerica’s MSJ, EMI signed the agreement for NetVision services that included a specific agreement by EMI that Comerica was using commercially reasonable security. The authentication security for NetVision was a “digital certificate” process.
However, in May 2008 Comerica apparently changed to “TMC Web wire transfer services,” which used the RSA token security. EMI contends that it never entered into a written agreement for the new TMC Web services, never agreed to the RSA token security, and never agreed that such security was commercially reasonable. EMI also argues that it was not a signatory to various other documents referenced by Comerica, including an online banking user guide and Comerica’s Treasury Management Services Master Agreement (both of which provided more information concerning Comerica's security procedures).
Finally, EMI disputes Comerica’s contention that EMI’s use of wire transfer services constitutes acceptance of the RSA token security procedures. According to EMI, it actually never sent a wire transfer using the TMC Web wire service that utilized the RSA token security, and therefore it never accepted this security procedure. Since the RSA token security was never “agreed to” by EMI, it contends that MCLA 440.4702(2) does not apply or shift the risk of loss to EMI, and that Comerica is responsible.
- Genuine issues of material fact exist as to whether Comerica’s RSA token security was “commercially reasonable”
EMI disputes Comerica’s contention that the RSA token security should be deemed reasonable under MCLA 440.4702(3). As summarized above, under that section if a customer refuses a security procedure that was commercially reasonable, but the customer agrees to another security procedure, the latter procedure is deemed commercially reasonable. This is basically a timing argument supported by dueling affidavits.
EMI claims that, at the time the TMC Web wire service was initiated, it was never advised that it could require approval from two authorized users prior to wire transfer, nor did Comerica offer additional security procedure options in connection with TMC Web services. This argument also rests on the prior EMI argument that it never entered into an agreement concerning the security of the TMC Web wire services in the first instance.
EMI then takes on the substance of "commercially reasonable security" using expert witness testimony. EMI’s expert contends that secure token technology was known to be lacking in any reasonable defense to a “man-in-the-middle” phishing attack. EMI’s expert opines that secure token technology has been unacceptable for banking logins since 2003. EMI’s expert also argues that Comerica’s particular implementation of this security was flawed based on prior practices of Comerica. In particular, with respect to the Netvision wire services that predated the TMC web wire services, Comerica allegedly regularly sent EMI unsolicited emails that lead to links requesting confidential login information. Essentially Comerica's prior practice caused EMI personnel to be off guard when the phishing attack came in.
EMI also takes issues with the warnings that Comerica sent out concerning phishing attacks. It points to Comerica’s April 28, 2008 communication in which Comerica indicated that it would never ask for confidential information in an email. EMI contends that the very next day it received an email from Comerica asking EMI to provide confidential login information.
Finally, EMI argues that the RSA token based security used by Comerica was not commercially reasonable because Comerica did not also implement security protection related to transaction verification and verifying wire transfers initiated after the initial login. In other words, EMI contends that an online banking system that allows unfettered wire transfers after a single successful login is not commercially reasonable. Had the token generated PIN been required for each wire transfer (e.g. the RSA token generates a new random number every sixty seconds), then the bad guys would have been stopped after the first fraudulent wire transfer (instead of being able to do 93 separate wire transfers for a total of $1.9 million).
- Genuine issues of material fact exist as to whether Comerica accepted payment orders in good faith and in compliance with the security procedures
EMI first argues that Comerica failed to accept the payment orders in good faith because it allowed 47 wire transfers to happen within a few hours even though EMI had only made two wire transfers in the prior two years. Moreover, EMI argues that Comerica’s lack of good faith is evidenced because it allowed 46 wire transfers to go through after EMI notified Comerica that EMI had not initiated the transfers. EMI also maintains that the failure to implement a simple fraud scoring system or fraud monitoring program to stop these types of wire transfers was evidence of a lack of good faith.
Comerica’s Reply to EMI’s Response
Comerica also filed a reply brief to address the arguments set forth in EMI’s response to the MSJ. This section summarizes Comerica’s arguments.
- The NetVision and TM Connect Web wire services were the same service governed by the 2003 NetVision contract
Comerica attempts to nullify EMI’s argument that it never entered into an agreement for security procedures related to TM Connect Web wire services. It contends that NetVision and TM Connect are the same systems. Comerica argues it simply changed the name of its online banking system. Comerica argues that the “Services” governed by the 2003 NetVision contract were the same and that all of EMI’s online transactions were subject to that contract. Comerica notes that the NetVision contract incorporates Comerica’s Treasury Management Services Master Agreement and a related user guide which Comerica uses to buttress its MSJ.
The NetVision contract also allows Comerica to update its security procedures, and indicates that after notice is provided by Comerica to EMI, EMI’s use of the services constitutes acceptance of the new security procedure. While EMI did not use wire transfer services until after NetVision changed its name to TM Connect Web, it had received wires from outside parties. Comerica contends that EMI’s continued receipt of wire transfers it its account constitutes use of the services and acceptance of the RSA token based security procedures for outgoing wire transfers. Of course EMI's acceptance is crucial if Comerica wants to rely on the risk-transfer mechanism set forth in MCLA 440.4702(2).
- Under MCLA 440.4702(3) the issue of the “commercial reasonableness” of a security procedure is a question of law, not fact
On this issue, Comerica points to the explicit language of MCLA 440.4702(3) which indicates that “commercial reasonableness of a security procedure is a question of law.” As such the court can decide that issue on a motion for summary judgment. Comerica contends that EMI acknowledged that Comerica’s security procedures were commercially reasonable in the NetVision agreement, making appropriate summary judgment in Comerica's favor.
- Comerica followed its procedures and acted in good faith
Comerica contends that it followed the procedures in place for online banking and denies that other procedures, such as requiring the initiation of wire transfers by phone call, were relevant. It attempts to counter EMI’s arguments concerning good faith by noting that it was not physically possible to stop some of the wire transfers after EMI informed Comerica that those transfers were not authorized. Moreover, Comerica argues that when it was able to stop or recall wire transfers it did so despite not being bound to do so, and ultimately decreased the loss from $1.9 million to $560,000.
Finally Comerica addressed EMI arguments concerning prior Comerica requests for confidential information via email. It argues that those emails did not send the user back to a Comerica website, but rather to a website hosted by their security vendor, Verisign. Secondly, the information that was requested was not online banking login credentials, but rather an ID/PIN sent each year for the sole purpose of renewing EMI’s digital certificate. As such, Comerica’s warning that it would never ask for online banking credentials via email was not untrue as EMI suggested.
Conclusion
These cases always get interesting when a little discovery ensues and the litigants begin digging into the relevant documents and contracts. As you can see, there is a lot going on here that has little do with actual security, and more to do with procedural issues around security acceptance, contracting and the UCC. Nonetheless, on some level the issue of commercially reasonable security will have to be addressed (either by the court on this motion for summary judgment) or later in proceedings by the ultimate trier of fact.
What can be gathered from this case and this MSJ is the importance of contracts in this context, and apparently the importance of contract timing issues and clear indications of “accepting” security procedures related to online banking. While there is a paper trail here with some favorable contract language, the record does look muddied, and this can make it more difficult to win at this stage of litigation. Had the bank thought it through in more detail it probably could have created a more solid record to back its arguments. For instance, while contracts incorporating other documents that are constantly changing may be efficient, they may lack the same degree of acceptance as compared to requiring a new contract or other document certifying acceptance. Based on the dueling arguments, it is difficult to determine exactly where the court will come down on this motion for summary judgment. I believe that oral arguments are scheduled and thereafter we will get a written opinion from the court. Until then, have fun breaking these documents down and feel free to ask any questions you may have in the comments.
What's in Google's SaaS Contract with the City of Los Angeles? Part Three.
This blogpost is the third (and final) in our series analyzing the terms of Google's and Computer Science Corporation’s (“CSC”) cloud contracts with the City of Los Angeles. In Part One, we looked at the information security, privacy and confidentiality obligations Google and CSC agreed to. In Part Two, the focus was on terms related to compliance with privacy and security laws, audit and enforcement of security obligations, incident response, and geographic processing limitations, and termination rights under the contracts.
In Part Three, we analyze what might be the most important data security/privacy-related terms of a Cloud contract (or any contract for that matter), the risk of loss terms. These are the terms that allocate responsibility between the parties for a security or privacy breaches and the potential consequences of such breaches (including liability, breach notice obligations, lawsuits and regulatory actions). The risk of loss terms we will explore include limitation of liability clauses, consequential damage disclaimers, warranty disclaimers and indemnification clauses.
As a reminder, the City of LA will ultimately be entering into two contracts as part of this SaaS deal: one with CSC, the “CSC Contract” (which is acting as a reseller/implementer of Google SaaS solution) and one with Google itself for the SaaS services (the “Google Contract”). Again, we will analyze both contracts. However, since these risk of loss terms are all interconnected within each contract, we will analyze all of the terms together for each contract (rather than side-by-side as was done in previous posts) and look at how they work together. Final note: to fully understand this post it might be helpful to go back to Part One and refresh your memory as to the specific promises made by Google and CSC around security, legal compliance and confidentiality. Those duties and obligations play into the risk of loss terms that are highlighted in this post.
Author’s Note: Wow, this blogpost became very long. I did not realize how difficult it would be to try to explain complex risk of loss provisions in something closer to plain English. This post is may be difficult to wade through. However, it contains a good deal of valuable information (or at least I think so anyway). In short, these are the types of issues that are best explained orally. So if you would like to discuss these matters, feel free to contact me at 303.325.3528. Also, I will respond to comments here on the blog if you have any questions. Thanks – Dave.
Risk of Loss Contract Terms Primer
This is just a very quick general primer concerning the risk of loss terms that often appear in contracts:.
- Limitation of Liability Clauses. Limitation of liability clauses (“LOLs” for short) are fairly straightforward. They simply set the cloud provider’s monetary cap for loss or damages owed to the customer under the contract. The amount of the cap often relates to the revenue or income being generated by the service provider (e.g. liability is limited to the amount of fees earned over the prior twelve month period by the service provider). Most limits of liability purport to limit liability for any liability arising out of the services provided under the agreement, whether such liability arises out of the contract, tort or statute. Significantly, even if a customer is able to get favorable privacy and security terms from a cloud provider, they may only be able to recover up to the LOL should the provider breach those terms. Also important, cloud contracts may have exceptions to the LOL that allow the customer to recover for certain types of losses, including for example, confidentiality breaches and indemnification-related losses.
- Warranty Disclaimers. Service providers may provide certain warranties concerning their services, but then typically desire to disclaim all other warranties and guarantees concerning their services. The reason is obvious; they do not want to be held to a higher standard of care that a warranty may encompass. Service providers want to also avoid liability for implied warranties because of uncertainty and legal risk associated with potential warranties their services may imply. Customers desire to get as many warranties as possible, and to have loss arising out of warranty breaches of those warranties not be subject to contractual limitations of liability.
- Consequential Damages Disclaimers. Many Cloud contracts will contain clauses whereby the service provider disclaims any liability for “consequential damages.” Examples of consequential damages include loss of profits, loss of use of goods and reputation loss. While these examples are more straightforward it is often difficult to ascertain whether a particular loss constitutes consequential damages (not recoverable if disclaimed properly) versus “direct damages” (recoverable). For example, some Cloud providers may argue that breach notice costs or fines or penalties arising out of a security breach in violation of a contract may constitute consequential damages, and therefore be disclaimed and not recoverable by a customer.
- Indemnification Clauses. Certain actions by a Cloud provider, such as a security breach or non-compliance with a security or privacy law, could lead to certain losses suffered by the customer, including lawsuits, claims, regulatory actions and the incurring of breach notice expenses, forensic expenses or attorney fees. Indemnification clauses allow the indemnitee to recover losses associated with these types of claims and expenses from the indemnitor.
In this context for example, a Cloud provider might agree to indemnify a customer for lawsuits by the customer’s consumers who were impacted by a security breach suffered by the Cloud provider. The indemnification clause may require the service provider to pay for the cost to mail notice to individuals impacted by a security breach as dictated by breach notice laws. Note that indemnification clauses may be subject to a contract’s LOL if the clause does not include a carve-out or exception for indemnification obligations.
Now let's look at how these contract terms are used in the CSC and Google contracts.
Risk of Loss Terms in the CSC Contract
It appears that LA was able to obtain some favorable risk of loss terms, including unlimited liability for CSC with respect to certain loss elements related to security and privacy breaches. Significantly, CSC has agreed to be responsible for certain liabilities that may arise from Google’s (its subcontractor) acts, errors and omissions. Nonetheless, some interpretative issues exist arguably limit CSC’s obligations.
Warranties and Warranty Disclaimer
CSC provides some generic warranties in the CSC Contract (e.g. such as warranting that they are duly incorporated and in good standing), but also provides two additional warranties relevant to data security and privacy, including a warranty to comply with all laws and regulations “applicable to the performance by it of it is obligations under the Contract” (section 5.1.5), a warranty to use commercially reasonable virus detection software with respect to the software licensed under the CSC Contract, and a warranty to refrain from intentionally including computer viruses in the licensed software. CSC disclaims all warranties beyond those explicitly set forth in Section 5 of the CSC Contract.
While these warranties are substantive and provide the City of LA with a basis to claim breach of contract or breach of warranty if CSC violates them, any loss that arises out of a warranty breach is subject to and capped by the limitation of liability clause in the CSC Contract (discussed below). This raises an important point for customers negotiating Cloud contracts – you may fight hard and negotiate for a long time on substantive obligations such as warranties, but unless you get an exception to the LOL for breaches of warranties, your ability to fully recover loss for breach of warranty may be limited.
Consequential Damages Disclaimer
Section 15.1. of the CSC Contract sets forth a fairly typical consequential damages disclaimer, which purports to relieve CSC of any liability arising out of “special, indirect, consequential or incidential losses or damages.” There are, however, two issues that jump out from the clause.
First, the clause also disclaims any liability for “penalties.” Penalties can arise in the security/privacy context out of contractual arrangements (e.g. fines and penalties imposed by Visa due to a payment card data breach) or regulatory actions (e.g. fines and penalties imposed by regulators due to violations). While some may argue that fines and penalties are “direct damages,” one could argue that this CSC clause pulls “penalties” out of the consequential/direct damages dichotomy and puts them in a separate category of loss that CSC is not responsible for.
Second, CSC’s disclaimer specifically references “lost or damaged data” as a consequential damage. As such, in the event of a security breach involving personal, CSC may argue that it has no liability to the extent such breach involved “lost or damaged data.”
Notably there are no exceptions to the consequential damages disclaimer, which may be problematic for the City. For example, assume that LA gets sued after a security breach involving credit cards and is required to pay a penalty to a card brand. Despite the indemnification language, CSC might take the position that it is not responsible for such penalty.
Indemnification
The CSC Contract contains several indemnification clauses whereby CSC agrees to indemnify LA under certain circumstances. We will focus on those related to security and privacy, which are set out in sections 15.5.2 an 15.5.3 of the CSC contract. Section 15.5.2, provides as follows:
In addition, Contractor undertakes and agrees to defend, indemnify and hold harmless City [ . . .] from and against all third party suits and causes of action, claims, losses, demands and expenses, including but not limited to, attorney’s fees and costs of litigation, damage or liability of any nature whatsoever, that [CSC or its Subcontractor] have breached its obligations to City under Section 10 (Confidentiality and Proprietary Rights) only with respect to the disclosure of such End User’s information and to the extent such disclosure is the result of actions predominantly attributable to (as agreed by the parties, said agreement, not to be unreasonably withheld) [CSC or its Subcontractors]
In addition, section 15.5.3 requires CSC to indemnify LA for similar loss elements arising out of “lost City Data.” Such indemnification obligations appear unlimited with respect to events occurring within 30 days after LA’s full and final acceptance of the services, and are capped at $7.7 million after that 30 day period.
Limitation of Liability
Section 15.1.2 sets forth an interesting limitation of liability clause. The limitation of liability under the CSC contract actually changes over time during the contract. During the first 12 months the LOL is $2.1 million, for months 13-24 the LOL is $1.4 million, for 25-36 it is $1.4 million, etc. through the end of the 60 month contract. What is somewhat unclear is whether the LOL’s for each year are cumulative. 15.1.2 does indicate a $7.7 million "total", but that may be for the entire contract not a given year. For example, the total for months 25-36 is $4.9 million, but the LOL for those months is $1.4 million. Does that mean that the most the company can recover during those months is $1.4 million, or can they recover up to the total of $4.9 million in that year? Not clear.
The scope of this LOL is also arguably unclear. For example, does this LOL apply to liability that arises out of breach of contract only, or does it also limit liability for torts outside of the contract such as negligence or fraud? Many LOLs that I have seen specifically indicate that the LOL applies to contract, tort, statute or any other theory of liability.
As part of the limitation of liability section, 15.1.3.1 sets forth a liquidated damages provision that allows LA to recover $10,000 for an incident involving a breach of confidentiality obligations by CSC. Incident in this case means “all disclosures of City Data to unauthorized recipients arising from the same specific cause or causes.” This provision does not apply to confidentiality breaches by Google or its subcontractors. The contract gives the City the ability to waive this provision and seek actual damages.
Significantly, CSC’s indemnification obligations in section 15.5 are not subject to the LOL. This means that CSC’s indemnification obligations under 15.5.2 (for breach of confidentiality) are unlimited. CSC’s indemnity obligations for “lost City Data” under 15.5.3 are also not subject to the staggered LOL in 15.1.2. Rather, as mentioned above, section 15.5.3 has its own built in $7.7 million LOL. In addition, under 15.1.3., liability for breach of any confidentiality obligation is not subject to the limitation of liability under 15.1.2. All other provisions, breaches, liabilities and losses are purportedly subject to the LOL.
Observations
The risk of loss terms in the CSC Contract raise several issues related to privacy, security and legal compliance. The following matters suggest that CSC is accepting a broad range of liability:
- Google is defined as a CSC “Subcontractor.” Therefore, as respects indemnification for a breach of confidentially obligations or for lost City Data, CSC would be responsible to pay for Google’s act or error.
- CSC’s Indemnification Obligations for End User Information Confidentiality Breaches are Unlimited. The LOL in the CSC contract explicitly exempts CSC’s indemnification obligations under 15.5.2 from the damage cap of the LOL.
- "Direct Damages" for Breach of Confidentiality Obligations are Unlimited. Section 15.1.3, specifically indicates that the contract’s LOL does not apply to breaches of confidentiality obligations. However, as mentioned in Part One, some service providers might take the position that a third party accessing and stealing data is not an “affirmative disclosure” by CSC or its Subcontractors (e.g. CSC did not consciously disclose such information). Moreover, since CSC attempts to disclaim liability for "lost or damaged data," the scope of "direct damages" arising out of a security breach may be limited.
The following issues are potential limiting factors with respect to the liability accepted by CSC under the contract:
- No CSC Liability for "lost or damaged data”. As mentioned above, the consequential damages disclaimer explicitly includes “lost or damaged data” as part of consequential damages. While awkwardly drafted, this provision may essentially eliminate CSC liability for some data security breaches. However, depending on the definition of "lost" in the security breach context, the scope of this limitation may be narrow.
- No Indemnification for Failure to Implement Security. There are no explicit indemnification obligations with respect to CSC’s information security obligations set forth in section 11 of the CSC contract, and any recovery by LA would be argued to be limited by the LOL and the consequential damage disclaimer.
- No Indemnification for Breaches of Privacy and Security Laws. There is no explicit obligation to indemnify the City should CSC or its Subcontractors violate a security or privacy law.
- Breaches of Warranty are Subject to the LOL. In some service provider contracts, a breach of warranty may not be limited by the limitation of liability clause. Not so for purposes of the CSC contract.
- No Explicit Security Breach Indemnification and the Meaning of “Disclosure”. In Section 15.5.2, there is no explicit indemnification for a security breach that involves a third party gaining unauthorized access to City Data. While there is indemnification for “disclosure” of End User data, as mentioned in Part One, some service providers might take the position that a third party accessing and stealing data is not an “affirmative disclosure” by CSC or its Subcontractors (e.g. CSC did not consciously disclose such information).
- No Explicit Security Breach Indemnification and the Meaning of “Lost.” Section 15.5.3 also provides indemnification for “lost City Data,” and that could arguably encompass a security breach situation (or at least a subset thereof). However, some might argue that data taken by a third party is not “lost.” If a copy of the data remains, has it been “lost?” Does “lost” apply only to situations such as lost laptops with data on them, such that the data is irretrievable? The City could have clarified CSC's obligation by inserting into the contract references to unauthorized access or use of City Data, and perhaps stolen or unauthorized copying of data.
- Breach Expense Elements. There is no explicit indemnification for breach notice expenses, forensic expenses, credit monitoring expenses or call center expenses (although such expenses could be argued to be included as indemnifiable expenses in general).
- Mutual Agreement for Indemnification for Confidentiality Breaches. CSC's indemnification obligations in section 15.5.2 may be hard for LA to enforce because it requires that CSC and LA mutually agree that the disclosure of End User information was “predominantly attributable” to CSC and its Subcontractors. While there is a reasonableness standard built into that mutual agreement requirement, the practical reality is that it might be difficult to get CSC agree to indemnify, especially if large amounts of money are at issue.
- Indemnification for Confidentiality Breaches Limited to End User Data. Rather than indemnifying for breaches involving any City Data, section 15.5.2 only applies to “End User’s information.” The term “End User” appears to have been pulled from the Google Contract (which is attached as an exhibit to the CSC Contract) and is defined as the individuals the City permits to use the Services.
The scope of “End User information” is not clear. For example, End User information might refer to the personal information of Google’s SaaS users that they input in order to use the software (e.g the name and particulars of City employees that use Google’s SaaS). In that case it might not include, for example, a database sent by LA employees using the software containing the personal information of City residents. It would probably have been better from the City’s point of view to define that term, or to have used a broader term such as “protected information” as set defined in Section 11 of the CSC Contract.
Risk of Loss Terms in the Google Contract
The Google Contract also has its own risk of loss contract language. While the Google contract has some of the same provisions as the CSC Contract, some of Google’s risk of loss terms are actually simpler and more straightforward. Overall, the Google Contract does provide unlimited liability for security and privacy breaches in some circumstances, and actually may provide slightly more protection to LA (as compared to the CSC contract).
Warranties and Warranty Disclaimer
Google provides some very basic warranties, which are not really related to security or privacy. Google does, however, warrant that it will comply with its service level agreement, which relates to availability aspects of security. All other warranties are disclaimed.
Consequential Damages Disclaimer
Section 14.1 of the Google Contract disclaims “consequential damages” as follows:
NEITHER PARTY WILL BE LIABLE UNDER THIS AGREEMENT FOR LOST REVENUES OR INDIRECT, SPEICAL, INCIDENTIAL, CONSEQUENTIAL, EXEMPLARY OR PUNITIVE DAMAGES, EVEN IF THE PARTY KNEW OR SHOULD HAVE KNOWN THAT SUCH DAMAGES WERE POSSIBLE AND ENVE IF DIRECT DAMAGES DO NOT SATISFY A REMEDY.
Significantly, however, section 14.3. of the Google Contract indicates that the consequential damages disclaimer does not apply to breaches of confidentiality obligations or indemnification obligations.
Indemnification
Section 13.2.3 of the Google Contract contains an indemnification clause that is very similar (if not exact) to the version contained in section 15.5.2 of the CSC Contract, which provides indemnification for breaches of section 7 of Google’s Contract (Confidential Information section), but only with respect to disclosure of End User information, and only if the Google and LA mutually agree that the disclosure was “predominantly attributable” to Google (or its subcontractor).
Section 13.2.4 of the Google Contract also contains a provision providing indemnification for “lost Customer Data” (again similar to/same as section 15.5.3 of the CSC Contract). Liability is unlimited for indemnification under 13.2.4 until 30 days after the City has accepted the services, and thereafter is capped at $7.7 million.
Limitation of Liability
The limitation of liability clause of the Google Contract provides as follows:
NEITHER PARTY MAY BE HELD LIABLE UNDER THIS AGREEMENT FOR MORE THAN THE AMOUNT PAID BY CUSTOMER TO RESELLER DURING THE TWELVE MONTHS PRIOR TO THE EVENT GIVING RISE TO THE LIABILITY.
However, section 14.3. of the Google Contract indicates that the LOL does not apply to breaches of confidentiality obligations or indemnification obligations.
In addition, this LOL may arguably relate only to liability for breach of the Google Contract (“this Agreement”). The LOL does not specifically indicate that liability is limited for torts outside of the contract such as negligence or fraud, or violations of statutes. As such, if LA sued Google under a negligence theory some might argue that Google is not protected by this LOL.
Observations
The risk of loss terms in the Google Contract raise several issues related to privacy, security and legal compliance. The following matters suggest that Google is accepting a broad range of liability in the Google Contract:
- Direct Damages and Consequential Damages Unlimited for Breaches of Confidentiality Obligations. Breaches of confidentiality obligations under the Google Contract are not subject to the LOL, and therefore Google's liability arising out of such breaches is potentially unlimited. Note, however, that there may be some “natural limits" with respect to consequential damages that may apply (e.g. foreseeable loss). On its face, the Google Contract is broader in terms of the liability Google has explicitly agreed to for confidentiality breaches. Nonetheless, the true scope of Google's liability depends on the meaning of confidentiality breach under the Google Contract (discussed further below).
- Google’s Indemnification Obligations for Confidentiality Breaches are Unlimited. If Google’s indemnity obligation is triggered, it is not limited by the LOL in Google's Contract. However, as discussed below, the scope of those indemnification obligations may be limited, and it may be difficult to actually trigger those obligations.
- Broader Confidentiality Obligations? Unlike the CSC contract, Google's confidentiality obligations also explicitly require Google to “protect” LA’s confidential information using the same standard of care that Google uses to protect its own confidential information (and in no event less than reasonable care). This is in addition to an explicit duty to “not disclose” LA’s confidential information (by the way, Confidential Information as defined explicitly includes “Customer Data.”). The addition of this explicit duty to protect arguably would encompass a security breach where a third party was able to obtain or access LA’s data stored or processed by Google. Ironically, CSC might use Google’s explicit reference to this protection obligation to argue that its obligations were limited to “disclosure” (in the affirmative sense of giving away confidential information). However (as discussed), based on the same logic set, Google may have an argument that is indemnification obligations for confidentiality breaches are limited to "dislcosures."
The following identifies potential limiting factors with respect to the liability accepted by Google under the contract:
- No Indemnification for Breaches of Privacy and Security Laws. There is no explicit obligation to indemnify the City should Google or its subcontractors violate a security or privacy law.
- No Explicit Security Breach Indemnification and the Meaning of “Disclosure” in 13.2.3. There is no explicit indemnification for a security breach that involves a third party gaining unauthorized access to the City’s data. Moreover, the indemnification clause set forth in 13.2.3 relates only to the “disclosure” of End User information, as mentioned in Part One, some service providers might take the position that a third party accessing and stealing data is not a “affirmative disclosure” by Google. This argument might be buttressed by the fact that the Confidentiality section of the Google contract also references a duty to “protect,” but that duty is not referenced in the indemnification clause.
- Indemnification for Confidentiality Breaches Limited to "End User information". Rather than indemnifying for breaches involving any Customer Data (a term defined int the Google Contract), section 13.2.3 only applies to “End User’s information” (an undefined term). While the term “End User” is defined as the individuals the City permits to use the Services, the meaning of “End User information” is not clear. However, the definition of “Customer Data” which was not used in the indemnification clause, arguably provides some indication as to the meaning of “End User information”:
“Customer Data” means all data and information provided by End Users via the sign-up process for the Services, as well as data, including email, documents, spreadsheets, presentations, and videos provided, generated, transmitted or displayed via the Services by Customer, or Reseller on behalf of Customer.
If Google wanted to argue for the limitation of its indemnification obligations, it might point to the Customer Data definition and maintain that “End User information” means the information End Users provide during the sign-up process (e.g. basically LA employee and contractor personal information). Google could argue that the data provided, generated or transmitted via the services is not End User information. This information could include, for example, personal information in a data base of LA residents that is sent in an email via Google's SaaS. Google would claim that if it intended to provide indemnification for confidentiality breaches involving this type of information it would have used the term Customer Data instead of “End User information” in the indemnification clause. The bottomline is that LA could have taken away any ambiguity simply by demanding indemnification with respect to Customer Data; they did not, so that uncertainty will linger. Note that this could impact the scope of CSC's indemnification obligation since it refers to "End User information" as well.
- Mutual Agreement for Indemnification for Confidentiality Breaches. Section 13.2.3 may be hard for LA to enforce because it requires Google and LA to mutually agree that the disclosure of End User information was “predominantly attributable” to Google or its subcontractors. While there is a reasonableness standard built into that mutual agreement requirement, the practical reality is that it might be difficult to get Google agree to indemnify, especially if millions of dollars are at issue.
- No Explicit Security Breach Indemnification and the Meaning of “Lost.” This is basically the same issue discussed above concerning the CSC Contract. The Google Contract also provides indemnification for “lost Customer Data,” but again some might argue that data taken by a third party is not “lost.” If a copy of the data remains, has it been “lost?” Does “lost” apply only to situations such as lost laptops with data on them, such that the data is irretrievable? References to “unauthorized access” or “unauthorized use” of Customer Data, and perhaps stolen data may have expanded these indemnification obligations to cover security breach situations.
- Breach Expense Elements. There is no explicit indemnification for breach notice expenses, forensic expenses, credit monitoring expenses or call center expenses (although such expenses could be argued to be included as indemnifiable expenses in general).
Conclusion
So now that we arrive at the end of this blog series it is worthwhile to go back to the beginning. One of the goals of this series to was to validate reports that LA had convinced Google to be responsible for unlimited liability arising out of security breaches. At the end of the day, it appears that this statement is true at least with respect to some “security breaches,” but with many caveats and limitations.
It appears that Google has provided unlimited liability for direct and consequential damages for security breaches that are violations of the confidentiality obligations. While CSC’s obligations are arguably limited to unauthorized disclosures, Google could be in violation of its confidentiality breaches if it fails to protect LA’s information using the same standard Google employs internally and/or reasonable care (note that many would argue that "disclosure" includes this protection obligation, so CSC's obligations may be similar). So, with respect to the specific "protection" obligation, unlimited liability is available from Google for security breaches only if LA can establish that Google failed to protect LA’s information the same way Google protects its own or if Google used less than “reasonable care.” In other words, Google is not automatically liable for all of LA’s loss arising out of a security breach under this protection prong (note again, arguments may exist with respect to Google's disclosure obligations).
It is also possible for LA to get unlimited indemnity for City data “lost” (e.g. a lost laptop with personal information on it) due to acts or CSC or Google within 30 days of Google’s services being finally accepted by the City. It may also be possible (but is less likely) to get unlimited liability indemnification arising out of breaches of confidentiality involving “End User information.” This will depend, however, on the meaning of “disclosure” and “End User information.” It will also require CSC and/or Google to essentially consent (e.g. mutually agree) to provide such indemnification (in my book this is not really a workable indemnification scenario, especially for big breaches where a lot of money is on the line; CSC and Google are not likely to provide consent and there is no additional contract remedy if such consent is unreasonably withheld).
One final note, LA does have an advantage in terms of risk of loss because it has separate contracts with CSC and Google. As such, it can go after each company should a security or privacy breach occur. Moreover, even if a LOL applies, it may be able to collect from both Google and CSC (effectively doubling the LOL that is applicable to this transaction).
Thanks for reading through this series (assuming you made it this far). If you have any questions, you can contact me at 303.325.3528 or via email at dnavetta@infolawgroup.com
Information Security Clauses and Certifications - Part 1
Outsourcing business and IT functions often means outsourcing compliance and liability risks as well. When a service contract involves protected categories of personal information, both parties need to understand the security requirements and risks. The contract should allocate responsibilities to prevent and respond to security breaches. The contract may also set expectations more precisely by incorporating a written security policy or referring to a widely accepted information security standard, sometimes accompanied by a requirement for a third-party security audit or assessment.
What contractual information security provisions should you consider, as a customer or as a vendor or business partner, when the contract contemplates the exchange of protected information? What do security standards and audits entail for a vendor, and what do they offer for a customer?
With heightened liability and compliance risks associated with handling protected categories of data, it is becoming more common to see contractual requirements holding vendors accountable for information security or requiring them to conform to a specified information security standard. Formerly, certification requirements were largely confined to contracts procuring data processing services for government agencies, financial services firms, and healthcare providers. Now, such provisions are appearing in a wide variety of outsourcing, cloud computing, software as a service (SaaS), infrastructure as a service (IaaS), and consulting contracts where the vendor will be processing or storing Social Security Numbers (SSNs), payment card or bank account details, medical information, or virtually any personal data from Europe, Canada, or other jurisdictions with more comprehensive data protection laws.
Often, the contract requires a self-certification of conformance with a particular set of information security safeguards and control procedures, such as the Payment Card Industry Digital Security Standard (PCI DSS) for credit and debit card data, ISO 27001/27002 (formerly ISO 17799), or the US government’s NIST 800 series of Federal Information Processing Standards (FIPS). But many contracts go beyond representations, warranties, or conditions concerning information security and require the vendor to submit a third-party expert assessment or audit of the vendor’s security practices.
Security audits can be costly and time-consuming, and an audit requirement may or may not be reasonable given the type and amount of data at issue. On the other hand, a neglected or casually performed self-assessment can result in contract termination, denial of insurance claims, or the shifting of liability following a security breach incident.
How well do lawyers drafting or vetting contracts know what their clients need, or what they are committing to, when it comes to the clauses or annexes detailing the parties’ information security obligations? Despite the sometimes mind-numbing acronyms and technical content, lawyers and business managers need to have a basic understanding of what is entailed with the more common forms of information security clauses and certifications. This will also help them determine which are the most useful and appropriate standards, representations, and certifications for a particular services contract.
Common Information Security Clauses
Confidentiality and nondisclosure provisions typically include a definition of “Confidential Information” accompanied by nondisclosure obligations. The definition usually amounts to “proprietary,” nonpublic information that could be legally protected as trade secrets or confidential commercial information. Sometimes the definition specifically includes “personal information” shared between the parties, such as customer and employee data or marketing lists, which may be both proprietary and protected by privacy laws. Typically, the clause obliges the parties to protect each other’s Confidential Information in the same manner that they customarily protect their own Confidential Information (“the same care and discretion” is a common formulation).
A simple, reciprocal confidentiality obligation works well where the parties have similar interests and capabilities in information protection. However, if one of the parties is relatively inexperienced or lacks sufficient resources or motivation, it may not be satisfactory to rely on such a provision without naming (or attaching) any special security requirements that apply to some of the data, or referring contractually to a widely accepted security standard.
Personal Information Security Clauses
Many contracts involving the sharing of protected categories of nonpublic personal information now also include a Personal Information or Personal Data provision. This is typically designed to help ensure compliance with any applicable privacy laws or standards, such as the federal HIPAA and HITECH acts governing medical data in the US, state personal information security and breach notice laws, and data protection legislation outside the US. The clause will often require the parties to implement “reasonable and appropriate” security measures to protect either defined categories of personal data or, more broadly, any personally identified or identifiable information (“PII”) furnished in connection with contract fulfillment.
The clause may refer generally to compliance with “any applicable laws and standards,” but it is prudent to add a specific reference to any particular information security regimes that are known to apply, such as PCI DSS (payment cards), HIPAA and HITECH (medical records), GLBA (financial accounts), FCRA (consumer reports), national laws based on the EU Data Protection Directive, or the Massachusetts personal information security requirements contained in Massachusetts M.G.L. c. 93H and 201 CMR §§ 17.00-17.05. This helps ensure that the parties understand the operational security requirements and avoids disputes about precisely what was required of the vendor.
Related provisions that may appear in this clause or separately include those relating to indemnification in the event of a security breach or abuse of personal information, insurance to cover such events, notice obligations in the event of a suspected breach of security, and a duty to cooperate in the investigation and resolution of security incidents involving protected personal information. Depending on the sensitivity of their consumer, employee, or government relations, some customers insist on a provision that allows them, or their designated experts, to control the investigation and any notifications to affected individuals or to law enforcement or regulatory bodies, even if the vendor is responsible for some or all of the related costs. Occasionally, the personal information clause will expressly deny any intent to create third-party beneficiary rights for the individuals who are the subjects of the data. This is not possible, however, in the case of European personal data transferred abroad under EU-approved standard contract clauses, as mentioned below.
The personal information clause may also include reference to a specified information security standard and possibly to a required third-party certification. The more common forms of these will be discussed in the next posts in this series.
Clearly, the personal information provisions of the contract can involve substantial risks and costs. The vendor should be careful to understand the requirements and not commit to more than it can perform (or afford). The Customer needs to exercise due diligence in ascertaining that the vendor has the technical and financial capability to perform as required, since the customer may be held accountable in any event by courts, regulators, and the public.
Transborder Personal Data Transfer Agreements
Personal data from the European Union, European Economic Area (the EU plus Norway, Iceland, and Liechtenstein), and other jurisdictions (such as Switzerland and Russia) with laws based on the EU Data Protection Directive are usually covered as well by a transborder data transfer clause. This may refer to the receiving party’s obligations as a data “controller” under laws based on the EU Directive, including obligations to provide notice and access and to secure the data with appropriate “technical and organizational” measures proportionate to the privacy risks inherent in handling the data at issue. If the receiving party is a mere “processor” under EU law, it is mandatory for the contract to include an “Article 17” clause (usually under the heading “Personal Data” or “Data Protection”) to the effect that (a) the processor will handle the data only according to instructions from the data controller and (b) the processor will employ “technical and organizational” security measures equivalent to those required of controllers. (Note that Article 17 clauses are required in contracts between controllers and processors even if the personal data remain in the EU / EEA.)
Whether a party receiving European personal data outside the EU / EEA is a controller or a processor, it must have a legal basis for receiving the data. The data may be received in any of the handful of countries deemed by the EU to afford an “adequate” level of protection, such as Switzerland and Canada (to the extent that the data are protected by the Canadian federal PIPEDA act). Data from EU / EEA countries, Switzerland, and Israel may also be received lawfully in the United States by a company that participates in the International Safe Harbor program. Otherwise, the transfer of such data must be covered by informed consent or another of the accepted “derogations” under Article 26 of the EU Directive. The most common of these are EU-approved standard contract clauses (or “model contracts”) and, more recently, nationally approved binding corporate rules (BCRs).
The EU standard contract clauses typically appear in a separate document or annex, with mandatory terms and a description of the data transfers according to EU requirements. There are only a few approved options in the terms themselves, but the descriptive annex must be carefully drafted to cover all of the contemplated data categories, uses, and recipients. The current sets of EU-approved standard contract clauses do not require a detailed description of security measures, but they do require reference to any special measures that must be taken to safeguard “sensitive” data. (In the EU context, sensitive data refers to information concerning race or ethnicity, health or sex life, religious beliefs, political or trade union activity, and, depending on the country, criminal history, national ID numbers, civil judgments, and any other categories of data deemed especially risky under national law or regulations). In some countries, such as France and the Netherlands, the data transfer agreement and descriptive annex must be submitted for review by a national data protection authority (DPA). DPAs have been known in some instances to request more information about the security measures to be employed (such as encryption), particularly where sensitive data are involved, and they may require that these be included in the data transfer agreement. This information is not made public, however, lest it compromise the security measures.
Several other jurisdictions with comprehensive data protection laws (such as Argentina, Australia, Canada, Dubai, Israel, and Japan) require “reasonable” or “appropriate” security measures proportionate to the risks; they also require or recommend contractual safeguards when transferring personal data to the US, India, and other jurisdictions lacking similar data privacy laws. So far, these countries have not specified security standards or detailed requirements that must be reflected in the data transfer agreement.
***
In the following posts in this series, we will look at the more common information security standards and certifications that may be included in service contracts.
