Cloud Computing Customers' "Bill of Rights"
Needless to say, due in part to our numerous writings on the legal ramifications of Cloud computing, the InfoLawGroup lawyers have been involved in much Cloud computing contract drafting and negotiations, on both the customer and service provider side. As a result, we have seen a lot in terms of negotiating tactics, difficult contract terms and parties taking a hard line on certain provisions.
During the course of our work, especially on the customer side, we have seen certain “roadblocks” consistently appear which make it very difficult for organizations to analyze and understand the legal risks associated with Cloud computing. In some instances this can result in a willing customer walking away from a deal. Talking through some of these issues, InfoLawGroup thought it would be a good idea to create a very basic “Bill of Rights” to serve as the foundation of a cloud relationship, allow for more transparency and enable a better understanding of potential legal risks associated with the cloud.
Just a pre-emptive comment: while we use the strong term “rights,” we know that cloud arrangements vary and that every transaction has its own issues and circumstances that impact the nature and scope of a negotiation. Moreover, as with the real Bill of Rights, we realize that none of these rights are absolute and may appropriately be subject to reasonable limitations in certain contexts. This document should be viewed less as a universal mandate, and more as a tool for cloud customers and providers to engage in spirited debate about the issues addressed in this Bill of Rights.
The Bill of Rights is set forth below with annotations. In addition, you can download an un-annotated version here, and we have even provided a pocket-sized version that can be easily accessed by those who are actively engaged in vetting cloud deals (however, you may need to keep a magnifying glass in your other pocket in order to read this version). This is a work in a progress and we invite you to submit your ideas on additional “rights” that we should include as well as any comments and criticisms on the current listing.
Annotated Cloud Customers' Bill of Rights
The following provisions (explained in more detail below) make up the Cloud Customer’s Bill of Rights:
Article I – Data Location Transparency
Cloud service providers shall reveal the physical location of the servers that will be processing their cloud customers’ data, and shall provide reasonable advance notice if those physical locations change; cloud service providers shall coordinate with their customers to assure compliance with local laws and any applicable restrictions on the transfer of certain categories of data from one jurisdiction to another.
Comments: The bottom line for this right is that in this day and age, for better or worse, the nature of the data and the physical location of its processing dictate legal obligations of cloud customers. Transborder data flow issues are not new, but they are magnified in the cloud context where the free flow of data across borders may be the norm (and this free flow will only increase as the “Intercloud” arises and data processing begins to behave more like electricity).
The classic example is the EU Data Protection Directive. A company that moves data made up of personal information of EU residents outside of the EU to certain countries (like the U.S.) risks a violation of EU law. In addition, the recent privacy law passed by the Canadian province of Alberta prohibits the transfer of Canadian personal information outside of Canada without providing certain notices to the data subject. Another example is the desire for some entities to avoid having their data processed on U.S. soil because of the USA Patriot Act. The processing of data in an unexpected country might also generally implicate jurisdictional issues over a particular cloud customer. Finally, in another twist, having to disclose certain data that is subject to a discovery request could run afoul of privacy laws in certain jurisdictions -- forcing the cloud customer to choose between violating the law and losing their lawsuit if they don't produce the evidence.
Cloud service providers that fail or refuse to reveal where their customers’ data is being processed risk exposing their customers to significant regulatory and legal risk. Unfortunately there are some providers that simply to refuse to provide this information (either because they don’t want to, or perhaps because they don’t know or can’t keep track of where data is being processed). Other cloud providers are more sensitive to this issue and will actually contractually agree that their customers’ data will be processed only in certain countries or locations. Nonetheless, for cloud customers to truly understand the legal risk of the Cloud, they need this information.
Article II -- Security Transparency
Cloud service providers shall provide full information and access to documentation concerning their security policies and measures, including the ability for cloud customers to conduct periodic security assessments and obtain relevant security-related information and documents from the service provider; this information and documentation should address data integrity and availability as well as the confidentiality of customer data.
Comments: Cloud customers may be ultimately liable for security breaches suffered by their cloud service providers. Moreover, cloud customers may have legal obligations to maintain certain security measures. These obligations do not disappear just because a customer’s data is being processed by a cloud service provider. Yet, in many cloud transactions, getting good information about security can be very difficult. While many cloud service providers are willing to provide SAS70 reports, if not tied to established data security standards such as ISO 27002, these reports may provide only a limited picture of security (and often the picture limited to that which the provider desires to reveal). Unless the cloud customer is a large entity (and even then), most cloud providers will not allow for an independent security assessment by the customer. Moreover, in long term relationships, a cloud provider’s security stance may change. Even if in-depth information is provided at the outset of a cloud relationship, if security is not allowed to be revisited, cloud customers may be at risk. Similar to the data location issue, this can result in very unpleasant surprises in the form of security breaches, lawsuits and regulatory actions. As such, from the cloud customer point of view, transparency around a cloud provider’s security is of paramount importance.
Article III -- Subcontractor Transparency
Cloud service providers shall provide cloud customers with notice as to which third parties will have the ability to access customer’s data and for what purposes, including subcontractors, subcontractors of subcontractors and so on.
Comments: It is not an uncommon for cloud customers to discover that the cloud service provider with whom they are entering into an agreement is not the sole entity that will be processing their data. The classic example is a SaaS running on a third party cloud. These relationships may be more attenuated than meets the eye as there may be third and fourth levels of cloud providers processing customer data, and the cloud customer may have no idea who is actually handling their data. Even if a cloud provider has revealed its subcontractors at the outset, it is not unusual for a cloud provider to switch subcontractors in the middle of a contract term. From the cloud customer’s point of view it is important to know exactly who will have access to its data, and whether those entities pose additional risk. Unfortunately, these subcontracting relationships may not be revealed up front by cloud providers, and are even less likely to revealed in the middle of a cloud relationship. Rather, many cloud contracts contain clauses that provide the service provider with the right to use third parties, or are silent on the issue. As such, some cloud customers may want to impose certain contract conditions to govern the use of subcontractors.
Article IV -- Subcontractor Due Diligence and Contractual Obligations
Cloud service providers shall conduct reasonable due diligence and security assessments of subcontractors or other third parties that will have access to customers’ data or systems, and shall enter into contracts with such third parties that hold those third parties to substantially similar obligations as in their cloud agreements with their customers; cloud service providers shall manage and similarly limit the ability of their subcontractors to utilize other subcontractors.
Comments: As a corollary to Article III above, to the extent that cloud providers do utilize subcontractors to process their customers’ information, a proper vetting of those subcontractors is appropriate, as well as certain contractual obligations. The providers’ due diligence should include not only data security and privacy assessments of their subcontractors, but also more generally ensuring that their subcontractors are capable of carrying out the promises made by the cloud providers to their customers. This due diligence should be buttressed by contractual obligations imposed on subcontractors that match those made by the cloud provider to its customers. Finally, both for their own protection and the protection of their customers, cloud providers need to worry about and limit their subcontractors’ ability to use subcontractors further down the line.
Article V – Customer Data Ownership and Use Limited to Services
Cloud customers shall have the right to solely “own” the data they put into a cloud service provider’s cloud, and cloud service providers shall use their customers’ information solely for the purposes of providing services to the customer, unless otherwise explicitly agreed.
Comments: Certain types of data flowing through cloud providers’ systems is extremely valuable (e.g. personal information of users) and there may be some temptation to use or exploit this data (or perhaps it is part of their business plan). Customers will expect that their cloud providers acknowledge that the customers are the sole owners of that data relative to the providers, and that the data should only be used to provide services to the cloud customer. In fact, this was one of the key requirements of the City of Los Angeles when it agreed to use Google cloud services. If service providers are going to use data beyond the purpose of providing services, prior notice to their customers should be provided. Service providers that do use their customers' data beyond primary purposes risk hurting their customers’ relationships with their clients and customers, and risk rendering their customers in violation of their privacy policies or data privacy laws.
Article VI – Response to Legal Process
Cloud service providers shall provide notice (within hours, not days) of the service of any subpoena or other legal process seeking their customers’ data, and shall assist and cooperate with their customers in responding to such legal process.
Comments: The ability of a cloud customer to understand when the government is seeking their data is crucial for managing legal risk. If a cloud service provider sits on a subpoena or other legal process it could harm the target customer, and hamper its ability to adequately respond to such a request and develop legal positions. Cloud service providers should develop a process for promptly dealing with these requests and providing notice to their customers. In the cloud context, with data potentially distributed across multiple geographically distant data centers, developing an efficient process and information flow may be challenging.
Article VII -- Data Retention and Access
Cloud service providers shall reveal their data search, retention and destruction practices to their cloud customers; and shall develop and enable data search, retention and destruction capabilities in order to allow their customers to implement their own data retention programs, efficiently effectuate litigation holds, and locate, collect and preserve relevant data, including metadata; cloud service providers shall build in processes and controls that allow for the efficient authentication of data (e.g. accurate time-stamping; metadata; chain-of-custody indicators, etc.).
Comments: Most sophisticated organizations have data retention policies and procedures in place for executing a litigation hold and preserving data. Implementing these policies and procedures internally can be a challenge, and that challenge is magnified significantly in a cloud environments where the customer must rely on a third party, the flow of data is very fluid, and data may be intertwined with the data of multiple cloud customers. In an environment where proper eDiscovery and electronic evidence practices can make or break a lawsuit, the search, retention and preservation capabilities of a cloud provider are very important. Cloud customers will be seeking to ensure their own internal policies can be followed in their cloud provider’s environment. On the front end, this requires transparency and the availability of technologies that enable the efficient identification, collection and preservation of data. On the back-end, service providers will be expected to cooperate with and assist their customers with obtaining electronic evidence and responding to electronic discovery requests. As discussed with respect to Article VIII, this may be tricky in the cloud context, especially when it comes to a cloud customer's desire for an independent forensic investigation.
Article VIII -- Incident Response
In the event a cloud provider suffers a security breach, Cloud providers shall provide prompt notice of the security breach to their affected cloud customers, shall coordinate, cooperate and assist their customers with the investigation, containment and mitigation of the breach, and shall allow their cloud customers to conduct their own forensic assessment and investigation of the security breach.
Comments: Similar to issues around litigation holds and data preservation, cooperation and coordination is crucial when a cloud service provider suffers a security breach. Again, it is the service provider’s customers whose business will suffer due to a breach, especially if procedures are not in place for the containment and mitigation of a breach. This again requires service providers to provide transparency as to their internal incident response processes so that cloud customers can ensure that their own internal incident response policies match up. Also of significance is the ability of cloud customers to access their service provider’s facilities and systems in order to conduct their own forensic security assessment. This is important not only for data preservation, but also for substantive defense issues. Cloud customers need to be able to conduct such assessments to determine what went wrong, whether any laws may have been violated, the defenses that may be available to the company, and who was responsible for the breach. On the latter question, in some cases it may be the service provider who was at fault, which makes getting access an interesting proposition. Moreover, the multi-tenancy nature of cloud computing also poses challenges: some cloud providers claim that independent forensic assessment is not possible because it could expose the data of the provider’s other customers and potentially result in a violation of a non-disclosure agreement. Needless to say this is a very trick issue.
Article IX – Indemnification and Limits of Liability
Cloud service providers shall engage their customers in meaningful discussions and negotiations around indemnification and limitations of liability arising of security breaches, including consideration of exceptions to limits of liability for security breaches suffered by the cloud service providers.
Comments: The reality on this “right” is that for “commoditized” cloud service arrangements there will often be no or very limited negotiation on terms (terms will often be reduced to clicking “I agree” on a website). However, in other cloud service transactions, where the parties are on more equal ground in terms of bargaining power, these terms are and should be up for negotiation and debate.
From the customer perspective, it is ceding control of some of its most precious assets: its ability to provide its goods or services, and its data. When a customer suffers a breach internally its incentives are to mitigate the breach and potential adverse consequences to the organization. In the cloud context the service provider’s interests may not be aligned with those goals (in fact, to the extent the service provider was at fault, its interests may run counter to its customers'). Service providers, may choose to put their own considerations very high up. Also to the extent a breach involves multiple cloud customers, cloud service providers may also favor the interest of particular customers over others. This lack of control and reliance on the providers justifies serious consideration of indemnification clauses, consequential damages disclaimers and limitations of liabilities. In some cases, service providers may provide higher limits of liability (or even no limits of liability) for confidentiality breaches or security breaches.
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
