Info Law Group : Technology Lawyers & Attorneys : Information Law Group : Privacy, Security & Intellectual Property Law

The Basics

Before diving into the details of the contracts we must address the basics of the Google/Los Angeles relationships. First off, a third party service provider, Computer Sciences Corporation (“CSC”), is involved in this transaction, and actually has a direct contract with the City of Los Angeles (the “CSC Contract”). CSC has agreed to implement, migrate and deploy Google’s Software as a Service (SaaS) model Email and Collaboration System (e.g. Google Apps Premier Edition). The City also will have a separate contract with Google that they will accept via click-assent once the system is implemented (it is actually included as Appendix J-1 to the CSC Contract – hereinafter referred to as the “Google Contract”). As such, throughout this blogpost we will be looking at both contracts to determine the extent of CSC’s and Google’s obligations (and will attempt to point out material differences between the two).

A preliminary observation:  this arrangement is very interesting because there will be two contracts governing the transaction. In the Cloud context it is sometimes (perhaps often) the case that the front-end provider will not be the party operating the Cloud and actually storing, processing and transmitting the customer’s data. In most cases, however, only one contract would exist between the reseller/service provider and the customer, and there would not be one directly with the SaaS provider. Or, in some cases, the SaaS provider would offer a contract, but that contract would contain its “boilerplate” language (which is usually highly restrictive and provides little in terms of remedies). In this case, it appears that both contracts were negotiated (although there are some differences).

The contract is initially worth approximately $7 million to CSC and Google. However, we understand that other divisions of Los Angeles (City and County) and potentially state entities will be able to obtain these services. As such, the ultimate value to CSC and Google may be significantly higher. In addition, the intangible benefit of snagging one of the first major U.S. cities to adopt Cloud likely has extended intangible business value for Google.

What is Supposed to Be in The CSC and Google Contracts?

It has been reported by multiple outlets that the contract terms of the Google Contract/CSC Contract were a key part of the negotiations with Los Angeles. One magazine reported that Google moved to make the contract terms a key part of its negotiating strategy to compete against competitors. At SaaScon 2010, Kevin Crawford, Los Angeles assistant director of IT, reportedly discussed many of the relevant contract terms (his presentation is still up and provides some insight into the City’s thinking on what the Google and CSC contracts provided). Based on the reports, the Google deal included the following contract terms:

• unlimited damages for a data breach

• provisions allowing audits

• guarantees that the data remain in the contiguous 48 states, and that this guarantee is auditable

• penalties if Google's services are unavailable for any longer than five minutes a month

• unlimited damages if its nondisclosure agreement (NDA) is breached by Google (that clause aims to protect the city from a third party claim if personal data is release)

• requires Google to encrypt the city's data and break it into pieces when it is at rest so that no one can get their hands on a full file

• bars Google from viewing any data without permission from the city

As we review the Google and CSC contracts we will attempt to identify whether these terms are present in the agreement.

Analysis of the Contracts

The following breaks down some of the key contract terms present in the CSC Contract and Google Contract.

Security Control Requirements

CSC’s Security Obligations. Section 11.1 of the CSC Contract requires CSC to establish a security program to ensure the security and confidentiality of Protected Information (as this term is defined in the City’s own infosec program), including protecting against anticipated threats, unauthorized access and unauthorized use, and the proper disposal of Protected Data. CSC is required to make its subcontractors (including Google, which is defined as a subcontractor in section 4.5 of the CSC Contract) comply with such controls. The City has a right to conduct a security audit and CSC must implement any security safeguards identified by the City or its audit. In addition, the CSC must conduct a SAS-70 audit each year of Google’s information security program, and provide the findings of the SAS-70 upon the City’s request.  In addition, CSC has warranted in section 5.2.5 that it will use commercially reasonable virus detection computer software programs to test “Software” licensed under the agreement prior to delivery to LA and ongoing.

Google’s Security Obligations. The Google Contract also contains security obligations, but their scope may be limited relative to those under the CSC Contract. Section 1.2., entitled “Facilities” provides the following:

All facilities used to store and process Customer Data will had adhere to reasonable security standards no less protective than the security standards at facilities where Google stores and processes its own information of a similar type. Google has implemented at least industry standard systems and procedures to ensure the security and confidentiality of Customer Data, protect against anticipated threats or hazards to the security or integrity of Customer Data, and protect against unauthorized access to or use of Customer Data

First, since this section is entitled “Facilities” one might argue that the security promises are related to physically securing Google’s facilities (at least in the first sentence). Creating a separate information security section (not entitled Facilities) that references reasonable technical, administrative and physical security may have been useful to address an argument of potentially limited scope.

Second, the last sentence reads in the past tense and some might argue that it amounts to an agreement with, or recognition by, LA that Google’s current controls (as of the time of contract execution) are in compliance with “industry standards.”  For this obligation, it may be useful to modify the sentence in terms of ongoing obligations for Google to implement and maintain reasonable security that at all times during the term of the contract (or while holding LA's information) must be at least consistent with industry standards. Also note, while industry standard are important, every first year law student knows that industry standards themselves may not be reasonable under the law.  As such explicitly imposing a duty of "reasonable security" may be helpful.

Significantly, there does not appear to be any obligation in the Google Contract for Google to encrypt LA's data or “break it into pieces" (as reported in the media). While the systems may actually do this, there does not appear to be a contractual obligation that tracks to this functionality. Also of note, while CSC may have an obligation to require Google to adhere to LA’s Information Security Program, LA would not be able to directly enforce that obligation against Google using the Google Contract (since that obligation is not in the Google contract).

Confidentiality/Data Privacy Obligations

There is often some overlap between information security contract terms and contractual confidentiality obligations and NDAs. This overlap can have significant liability consequences since a breach of confidentiality obligations is typically not limited by a contract’s limitation of liability clause. Put another way, if a service provider breaches a confidentiality provision, it may be subject to unlimited liability for such breach (as opposed to other contract breaches which may be limited by a liability cap or consequential damage disclaimer). For this reason, service providers may seek to limit their confidentiality obligations, especially when it comes to potential liability arising out of an information security breach.

Some service providers may take the following positions to limit their exposure for confidentiality breaches that arise out of security breaches:

• a “disclosure” of confidential information is not the same thing as allowing an unauthorized third party (e.g. a hacker) to access or use confidential information in the service provider’s possession, and only “affirmative disclosures” (e.g. a decision by the service provider to disclose) of confidential information amount to a breach of confidentiality obligations

• personal information is not confidential information, and therefore a security breach exposing personal information is not a breach of a contract’s confidentiality obligations

• a service provider is only liable for a security breach, if it also breached those parts of the contract that required it to have certain controls or protections in place

• liability arising out of security breach should be capped using a limitation of liability (although it may be different than the general limitation of liability present in the contract)

The purpose of this post is not to debate whether these positions have merit or not (that would take a lot of research), but rather to take a look at how these matters are reflected in the Google and CSC Contracts.

CSC’s Confidentiality/Privacy Obligations. Section 10. (CONFIDENTIALITY AND PROPRIETARY RIGHTS) of the CSC Contract and the NDA contained in Appendix I set forth CSC’s confidentiality obligations. Section 10.1 limits CSC’s use of any information of LA’s “contained in any [CSC] repository” and defines such information as “Confidential Information.” CSC may not disclose such information to any third party without LA’s written consent (except for approved subcontractors) and has a limited right to use that information only to the extent necessary to provide services. This section makes clear that LA is the sole owner of all City information. Notably, however, section 10 does not contain any explicit reference to a duty to “protect” the city’s information.

Under the NDA contained in Appendix I, neither party may “disclose or divulge to others” certain confidential information defined in the NDA, including “technical information,” “business information,” “security,” or “rights.” Notably there is no explicit reference to personal information or “Confidential Information” as defined in the main agreement (although the definition of “business information” may encompass that). Also, there does not appear to be any explicit duty to “protect” confidential information or personal information.

CSC’s confidentiality obligations are interesting in light of the potential positions that service providers may take. If a hacker were to obtain personal information in CSC’s control, CSC may take the position that it did not affirmatively “disclose” or “divulge” such information, and therefore did not violate the confidentiality provisions of the contract.  Nonetheless, it is possible that a different provision of the CSC Contract was breached by CSC by allowing the hacker to steal personal information (see for example section 11. of the CSC Contract – INFORMATION SECURITY). However, any liability due to CSC's breach of section 11. would be subject to the CSC’s limit of liability (see section 15.1.2 of the CSC Contract).  In other words, if a security breach does not constitute a confidentiality breach, then LA will not be able to recover for liability amounts above the liability cap in the CSC Contract. We will discuss how these risk of loss provisions work in a later installment of this blog series.

Googles Confidentiality/Privacy Obligations. Google’s confidentiality obligations to the City exist under section 7. of the Google contract. Under that section, Confidential Information explicitly includes “Customer Data,” which is defined as:

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.

This would appear to include personal information stored, processed or transmitted through Google’s services.

Under section 7., Google agrees to refrain from disclosing confidential information (similar to the promises made by CSC in its contract). In addition, however, Google agrees to “protect” LA’s confidential information “with the same standard of care it uses to protect its own confidential information, but in no event less than reasonable care.”

With the addition of “protection” obligations, Google’s confidentiality obligations are explicitly broader than CSC’s in the CSC contract (although one can argue that the concept of “protection” is included in the concept of disclosure). Based on the explicit protection obligation, Google’s confidentiality obligations would appear to be violated if it allows an unauthorized third party such as hacker to access personal information. Note that many would argue that Google’s promise not to disclose confidential information was also violated. In addition, some may see the existence of two explicit confidentiality duties, one geared toward protection and the other focused on disclosure, evidences an intent for disclosure to mean “affirmative disclosure" (see list of positions that may be taken by service providers above).

This all said, the ultimate issue, and the reason we are looking carefully at this language, is to determine if Google has promised unlimited liability for security breaches. That question, will be more fully answered in subsequent installments of this series. However, as a sneak peak, whether Google promised some sort of unlimited liability for security breaches involving personal information (or other confidential information) may hinge on whether there is a distinction between “disclosure” and “protection.”

Conclusion

This is first installment of our review of Google/CSC's ninety-one page contract with LA.  In the coming installments we will look at contract provisions related to due diligence, auditing and enforcement, incident response, compliance with privacy and security legal obligations, termination rights, and most importantly risk of loss terms (e.g. limits of liability, consequential damages disclaimers, indemnification).  Stay tuned.

On that issue the PC World article reported the following:

Google moved early to make this a contest over which company offers the best contract terms and legal protections in cloud environments. The city of Los Angeles, which may be Google's marquee government user, has been frank in disclosing details of its agreement. By the end of June, Los Angeles expects to complete a transition of some 30,000 employees to Google Apps.

In a sense, Kevin Crawford, Los Angeles assistant director of IT, is Google's de facto public sector evangelist. He doesn't market Google directly, but he answers questions from many other local government and state officials who want specifics about the city's deal with Google. Indeed, at the SaaScon conference on cloud computing and software as a service here this week, Crawford has been peppered with questions about the contract terms.

Los Angeles has been frank about the contract, which includes unlimited damages for a data breach, provisions allowing audits, guarantees that the data remain in the contiguous 48 states, and penalties if Google's services are unavailable for any longer than five minutes a month.

The contract also gives the city the right to cancel its contract with Google "for convenience," Crawford said.

Moreover, the contract reportedly includes specific data security and privacy controls and requirements and "unlimited damages" if Google breaches confidentiality obligations:

Los Angeles spent months negotiating a contract with Google that includes a provision providing the city with unlimited damages if its nondisclosure agreement (NDA) is breached by Google, said Kevin Crawford, the assistant general manager of IT for Los Angeles and the person who is managing the transition. That clause aims to protect the city from a third party claim if personal data is release, said Crawford.

Crawford said the most important clause in the contract requires that Google to encrypt the city's data and break it into pieces when it is at rest so that no one can get their hands on a full file. If hacker somehow accesses a file, he will only see "a whole bunch of gibberish," Crawford said. The contract also bars Google from viewing any data without permission from the city.

Los Angeles data will be administered from inside LA's firewall by city staffers through an administrative console built by Google, said Crawford. "We have control of our portion of the data," he said.

Moreover, the data must remain on systems within the continental U.S. That can be verified via auditing by the city, Crawford added.

"We're going to have a more secure system then we have today," said Crawford, noting that Google personnel does more work on security "than we could ever afford to do."

The Information Law Group has previously discussed the importance of data security, privacy and compliance in the Cloud context.  This situation seems to validate the premise that Cloud providers are going to (and willing to) compete on these issues and the contract terms that relate to them. 

From the InfoLawGroup's own recent experience, data security and privacy terms (and associated indemnities and shifting of risk of loss) have become much more important in IT outsourcing arrangements (whether Cloud or "traditional").  Lately it seems that right after price and service description/promises, significant time, effort and expense are being expended drafting and negotiating data security and privacy terms.  In fact, because of the complexity of security and privacy, and associated laws, in InfoLawGroup's recent experience, these terms can take more time to settle out then more "basic" contract terms.  Overall, the key reality at this juncture is that there is significant financial risk associated with poor data security and privacy and related regulatory requirements.  In many cases, in terms of pure dollar amount this risk can dwarf the value of the contract (or the savings of the contract) if favorable contract terms are not negotiated.

One thing to note, having reviewed the Google contract (and the related Computer Science Corporation contract), which can be found at the end of this report, the scope of Google's contractual promises may not be quite as clear cut as described by LA officials (a breakdown of the Google data security and privacy contract terms will be the subject of a second post on this issue).

What does this mean for customers entering into Cloud (or other outsourcing) contracts?

So what does this all mean to companies looking to go into the Cloud and hoping for contract arrangements that offer protection?  A lot.  Organizations are giving up a great deal of control when they outsource into the Cloud, and only good contract terms can compensate for that loss of control.  Unfortunately, many companies are focused on basic contract terms like price and often find themselves in a "take it or leave it" position when it comes to data security and privacy terms.  In terms of timing, lawyers working on these contracts often find that the service provider is more or less "locked in" at the point where data security and privacy contract terms are first addressed.  Oftentimes competitors have been eliminated and are no longer in the picture, and as a result the customer has little leverage to negotiate more favorable terms.

To be in a better position to negotiate favorable data security and privacy terms the current leverage dynamic needs to change.  This LA-Google situation is a very favorable sign that service providers, if handled properly, are willing to negotiate on these terms in order to win a contract.  However, customers must realize that most service providers are not going to approach a contract this way unless the customer creates an environment that provides it with leverage.  To achieve this customers looking to enter into IT outsourcing arrangements (Cloud or otherwise) should consider the following:

• Approach multiple vendors.  In many cases the only viable threat a customer has is to walk away to a competitor.  If no competitors are in the picture then there is not realistic threat and no leverage exists.  The problem is that many companies are attracted to a specific vendor, or other vendors don't quite have the same service offering as the preferred vendor.  Nonetheless, rather than becoming blindly enamored with a particular vendor, organizations would be well-served to find and look at competing offerings (at least to get some negotiating leverage against the primary vendor).

• Address these issues at the "Request for Proposal" phase.  Price and service offering description are the key components that go into a RFP, but considering the material financial risk posed by data security and privacy, why shouldn't those terms be highlighted in an RFP as well?  Rather than getting locked-in to a service provider after the RFP phase, it is better to lock the service provider into the data security and privacy terms you desire at the outset.  This is the time where the providers will be hungry and more willing to concede on issues.  The RFP should include the specific security and privacy requirements the organization desires, as well as specific contract language that should be included in the contract.  For companies that do a lot of IT outsourcing, these documents can be standardized and simply plugged into the RFP (which also has the benefit of creating consistency across the organization).  If you don't have an RFP process, then you should.  Adding data security and privacy requirements (and contract language) ♠changes the dynamic and makes the service provider compete on all aspects of the transaction.

• Keep competitors around.  Rather than eliminating alternatives at the outset, keep other competitors around (even if their offering may not be 100% ideal).  Again, the longer you can maintain your threat to walk away to a competitor, the stronger your position will be to achieve concessions.  Moreover, the "less than ideal" competitors can start to look more attractive when your "ideal" service provider refuses to accept any responsibility for your data security or privacy.

• Pre-establish your positions and your fall-backs.  It is important to predetermine your positions regarding data security and privacy risk and the contract terms your organization is willing to accept.  Organizations that routinely enter into contracts implicating these issues should develop a security and privacy schedule that indicates specific controls that are required.  The legal team should develop primary and secondary positions for confidentiality obligations, indemnification, limitations of liability, consequential damages disclaimers, compliance with privacy and security laws, and other related contractual requirements.  These back-end contract terms can be folded into and made part of the RFP.  They also provide for consistency across the organization and let the company understand and manage its exposure when using third parties to store, transmit or process data.

Conclusion

From the customer perspective, it is very encouraging to see a major Cloud provider willing to negotiate on data security and privacy contract terms in order to win business.  However, it is likely that the result in this case was very much due to how Los Angeles handled the negotiation. Organizations that are concerned about these risks when they enter into the Cloud need to position their organization and the transaction in a manner that changes the leverage dynamic in their favor. Otherwise, they may find themselves at the end of a contract negotiation taking on enormous risk with little actual control over the risk.

The Multiple Functions of a Data Security and Privacy Schedule

InfoSec-Privacy Schedules serve multiple functions, some of which are for “consumption” outside of the contractual relationship. Schedules function in traditional ways by establishing the relative duties of the parties and transferring risk of loss. However, information security schedules are also “proactive” in nature in that they mandate the implementation of certain measures to prevent a security breach and comply with certain laws. In addition, Schedules serve a “compliance” function that comes into play in the event of a regulatory action or lawsuit.

Proactive Nature of an Info-Sec Privacy Schedule

InfoSec-Privacy Schedules are interesting because they require Service Providers to implement measures to (hopefully) prevent a security incident, and potential legal liability. Contrast this with a traditional non-disclosure agreement. For the most part, NDAs do not dictate how a Service Provider must protect the confidentiality of confidential information, but rather simply mandate that Service Providers not disclose or expose such information. If such exposure occurs, the Customer’s remedy is to sue the Service Provider.

In contrast, one of the overarching goals of the security schedule is to contractually increase the likelihood that the Service Provider is actively implementing measures and policies to prevent a confidentiality breach in the first instance. This outcome is advantageous for Customers:  to never experience a security breach is much better than experiencing the breach and having the right to sue for breach of contract. This is especially true where a Customer’s ability to recover is limited by limitation of liability clauses, consequential damages disclaimers and the like (described more fully in Part Two of this series).

Overall, to the extent that the Service Provider essentially becomes an extension of the Customer’s internal security, the nature of these obligations makes sense. Of course, as discussed below, for both compliance and general operational risk purposes, the trick is consistency between the Customer’s internal security environment and the environments of its Service Providers.

The Infosec-Privacy Schedule as a Compliance Document

Another crucial purpose of an InfoSec-Privacy Schedule is its compliance function. When drafting a Schedule, lawyers should consider how the contract terms relate to specific requirements imposed by applicable information security and privacy laws, and reflect efforts to maintain “reasonable security.” In addition, many laws require Customers to contractually obligate Service Providers to maintain specific security and privacy measures, and the Schedule should reflect those obligations. Ultimately, lawyers negotiating these terms should ask themselves the following question:

If put before a privacy regulator in a regulatory action, or a judge or jury in a lawsuit, will the security and privacy terms in this document reflect efforts to achieve a compliant status and “reasonable security” under the law?

To address this point there are several items lawyers should consider in developing a Schedule:

• Security assessment process. Although the Schedule can serve as a useful document to support a Customer’s arguments in favor of compliance, it should typically be coupled with some sort of due security assessment or investigation. Conducting a security assessment of a Service Provider’s security measures allows the Customer to determine whether appropriate controls are in place and risk adequately mitigated. It also allows the Customer to get an idea whether specific compliance obligations can be met by the Service Provider’s systems and processing.  Moreover, (as discussed below) the security assessment process can inform the Customer as to the specific requirements that should appear in the Schedule. This process should be documented so that the Customer has the ability to establish (in a regulatory or litigation context) that it properly vetted its Service Provider prior to allowing it to process, store or transmit sensitive information.

Without a due diligence process, the effectiveness of the Schedule to establish compliance will be diminished. A Schedule filled with hollow promises is not a good compliance tool. The best policy in this situation (as in many others) is to “trust, but verify” the Service Provider’s security and privacy measures.

• Reference specific information security and privacy laws. The Schedule should specifically reference those laws that the Service Provider must comply with. This can be done by using a definition for “Privacy Laws” or “Security Laws,” and indicating applicable laws within that definition. Using this approach Customers put Service Providers on notice concerning their obligations while being able to show regulators or other parties that they were specifically addressing applicable law.

• Customer’s internal control structure reflected in Service Provider’s security and privacy obligations. When outsourcing, for purposes of information security and privacy, a Customer should view their Service Provider as an extension of itself. Most Customers have gone through an extensive process of measuring their information security and privacy risk and implementing security and privacy measures to mitigate their risk to a reasonable level. The second sensitive information or systems are outsourced to a Service Provider, those internal measures no longer apply and the Customer is completely reliant on the Service Provider’s security measures.

Problems arise when the Service Provider’s measures provide less protection than the Customer's own internal controls.  Allowing a Service Provider with weaker controls to handle sensitive information will be very difficult to defend in a litigation or regulatory context. As such, the Schedule should reflect a matching of risk and controls between the Customer and Service Provider, and the Service Provider’s security and privacy measures should meet or exceed those of the Customer.

• Specific controls relevant to the transaction. It may be necessary to specify specific security and privacy measures and policies that a Service Provider must have in place. For example, the Schedule might explicitly require 256-bit encryption of data at rest, or anti-virus protection. Some of these individual requirements may be dictated by specific obligations in laws, or just may be of special significance to the Customer in light of its internal infrastructure. Another approach is to tie the Service Provider’s existing security measures (assessed during the Customer’s security assessment process) to the Schedule (with requirements to update those measures, especially for long term contracts).

• Reasonable security. In addition to specific privacy and security measures, the Schedule should require an over-arching duty for the Service Provider to always maintain “reasonable security.” This duty should supersede all other security-related obligations, and reflect an ongoing obligation (as opposed to reasonable security just at the outset of the contract). As part of the general duty, the Schedule should also impose obligations to comply with industry standards. Note that industry standards may constitute reasonable security, but it is also possible that industry standards do not meet the level of reasonableness under the law. As such, the Service Provider’s reasonable security obligation should include industry standards, but not be limited to those standards.

• Assessment and enforcement rights. Things change: new vulnerabilities arise; safer security measures are developed; and Service providers can become lax or fall behind. This is especially true for long term contracts. Schedules should provide Customers with rights to conduct periodic security assessments to confirm compliance with the Schedule, regulatory compliance and whether reasonable security measures are being maintained in light of the existing risk environment. The Schedule can also require the Service Provider to give the Customer access to the Service Provider's own internal assessments or provide notice if it is in non-compliance with applicable standards or otherwise. If material non-compliance is found there should be contractual consequences, including the right to terminate the contract for cause.

These provisions serve two functions. First, just having the right to conduct an assessment can act as deterrent – Service Providers are more likely to stay compliant if they fear an assessment and contractual remedies. Second, they allow the Customer to understand the security and privacy risks they face, and whether the Service Provider is addressing these risks and achieving compliance with applicable laws. This second function is especially important for long term contracts where the risk environment is likely to change over time.

Please note that the need to address the issues above may vary depending on the nature of the transaction. Moreover, the relative bargaining power of the parties and the positions taken by the Service Provider may impact a Customer’s ability to get certain terms into a Schedule. Regardless, when drafting information security and privacy terms, thinking about how those terms might be viewed from a compliance standpoint is very important.

The Schedule serves other important functions beyond being created and used as evidence of compliance.  In Part Two we address security incident response provisions and contract terms allocating risk of loss between the Customer and Service Provider.