What's in Google's SaaS Contract with the City of Los Angeles? Part Two.
This blogpost is the second in our series analyzing the terms of Google and Computer Science Corporation’s (“CSC”) Cloud contract 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 this installment, we will focus on terms related to compliance with privacy and security laws, audit and enforcement of security obligations and incident response.
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”). We look at the provisions of both contracts.
Compliance with Privacy and Security Laws
The CSC Contract
In sub-section 5.1.5 of the CSC Contract each party represents and warrants that it will comply with certain laws as follows:
[each party represents and warrants that] it shall comply with all applicable federal, state, local, international or other laws and regulations applicable to the performance by it of its obligations under this Contract . . .
Appendix A has a similar provision in it. While this warranty does not explicitly reference privacy or data security laws it is broad enough to encompass them. As discussed further below, because of some quirks in data security and privacy laws related to distinctions between “service providers/processor” and data owners/licensees/controllers, some might argue that the scope of this obligation is limited for service providers.
The Google Contract
In section 7.5, Google agrees to comply with applicable state or federal security breach notice laws in the event of a Security Breach (a defined term we will be coming back to in the final installment of this series). Note that for most breach notice laws, Google would argue that it is a service provider (rather than a licensee or owner of personal information), and its only obligation is to provide notice to the City of LA of a security breach (and LA would have to provide notice to impacted individuals).
However, in the Google contract, it does not appear that Google made any specific promise to comply with privacy or data security laws that require specific controls or security measures. In fact, section 2.4 of the Google Contract actually requires the City of Los Angeles to comply with applicable privacy laws and regulations. In essence, if LA violates a privacy law it might be in breach of the Google Contract, but the same would not be true if Google violated a privacy law (despite the fact that Google is the party actually storing and processing personal information).
These regulatory compliance terms are always tricky in the data security and privacy contracting context. The problem arises based on the relationship of the parties. For a given data security law, the data owner or controller may have the primary obligation to comply with such law. This is the case for the EU Data Privacy Directive, as explained here, data controllers have the primary obligation to comply with the Directive, while processors may take on certain compliance obligations through their contracts with data controllers. Some service providers may take the position that any agreement to comply with “applicable laws” means any laws that are directly applicable to the service provider (and in the case of the EU Directive their position would be that the Directive is not directly applicable to it, but rather the data controller).
The problem for data owners is when they cede the storage, processing and transmission of personal information to service providers, if the service provider’s practices and security controls violate a data security law applicable to the data owner, the data owner could be held liable. Thus, data owners when entering into a contract like the Google Contract would prefer to have the service provider agree to comply with all laws applicable to the data owner and the personal information the data owner is working with. In contrast, service providers may take the position that it is the data owner’s responsibility to vet the service provider’s practices and controls to make sure they comply with laws applicable to the data owner.
Of course, if a service provider wants to serve a data owner that they know is subject to certain laws, it does not seem unreasonable to expect the provider to have addressed those laws. Unfortunately, this may not always be the case in the Cloud where offerings are standardized and built to scale to many different customers. At some point, to counter this we may see some competition between service providers offering CaaS (“Compliance as a Service”). So a Cloud provider serving the financial industry might design their Cloud offerings to be compliant with GLB security requirements, or those serving retailers would promise to comply with the PCI Standard (and in fact this is already happening with the PCI Standard).
In the case of the Google and CSC contracts, the privacy and data security legal compliance provisions are thin. The Google Contract does not appear to have such an obligation despite the fact that it will be storing, processing and transmitting LA’s information. While the CSC Contract does have a provision that appears fairly broad, as the implementer of the SaaS offering, their data handling activities are likely more limited than Google’s. Moreover, the provision cited above references laws applicable to the performance of CSC under the contract. Both sides would have arguments as to whether this language requires CSC to comply with privacy and security laws applicable to the City of LA.
Audit and Enforcement Terms
Getting a promise in writing from a service provider to implement certain data security controls is one thing. Being able to confirm that a service provider is actually implementing those controls, and if not, being able to make them comply, is another. The difference highlights philosophical differences as to the purpose of a contract in this context. Is the purpose of the contract to establish security duties and provide remedies if those duties are breached to allow for potential recovery after-the-fact, or is the purpose of the contract to proactively prevent a security breach or legal non-compliance in the first place. When it comes to data security and privacy, and legal compliance obligations related thereto, I contend that the latter applies. A customer is in a much better position if it can assess its service provider’s security and address weaknesses in order to (hopefully) prevent a security breach or legal non-compliance (rather than waiting for it to happen and suing for damages). This is especially true for long term contracts, and contracts where liability has been limited by the service provider significantly (the topic of the next blog post on the Google/LA contracts).
The CSC Contract
Section 11.2 of the CSC Contract provides the City with certain rights to review and audit CSC’s information security program. The City may review CSC’s security program before commencement of the services and “time to time” during the term of the contract. The audit may be an on-site audit, or at CSC’s option, CSC may instead complete a security audit questionnaire. In addition, CSC is required annually to perform a “SAS 70 or equivalent” audit of Google’s information security program and provide it to the City upon written request. Significantly, CSC must implement any “required safeguards” as identified by the City or information security program audits.
On its face, the contract provides strong audit and enforcement rights. The City has multiple audit options and no limits in terms of timing or frequency. On the enforcement front the City, CSC has an obligation to implement required safeguards identified by the City (while it may be intended, I would have clarified that CSC could not charge LA for the implementation of those safeguards). However, it is not clear to what extent CSC’s security program is relevant. Again, it appears that it will mainly be Google that will be storing, processing and transmitting LA’s data (although admittedly CSC could have a larger role with respect to data processing, it is just not clear from the contract, or my limited reading of it; as far as I can tell CSC may have some LA data while testing the SaaS set up, and perhaps be holding some back-up data).
CSC’s obligation to perform a SAS-70 audit or equivalent of Google is interesting and probably more relevant to the risk faced by LA. However, the usefulness of a SAS-70 audit, especially a SAS-70 Type I, is debatable. It may be more useful to peg compliance to an established security standard like ISO 27001/2, which has an international scope and was developed by an outside standards body (rather than the subjective judgment of the service provider). That said, if the City can have some input into the design of the SAS-70 audit, it may be more useful (although that right does not appear in the contract). However, even more powerful would be the ability of the City to directly audit Google. If that right existed it would have to be in the Google Contract.
The Google Contract
Under the Google Contract, the City does not appear to have any right to conduct an audit or security assessment of Google’s security program. While it is possible that CSC’s SAS 70 audit will discover security program problems, the Google Contract does not have any provision that requires Google to implement any controls to address those problems. The City of LA’s only remedy if deficiencies are found would be to threaten an action for breach of contract or termination of the Google contract (notably, however, the City of LA does not have an explicit right to terminate the Google contract for convenience). The bottom line is that with respect to Google, the City has limited audit and enforcement rights. This is the case even though Google will be the primary party handling LA’s data.
Incident Response Contract Terms
When it comes to data security and privacy and using service providers, I often advise my clients to think of their service providers’ security as an extension of their own. The same concept holds true for incident response. The key issue here is understanding how the service provider and customer will communicate, coordinate and mitigate when the service provider suffers a security breach exposing the customer’s data.
As a first step, as part of its due diligence, the customer should carefully review the service provider’s incident response plan and policies. Key issues to consider include whether the provider has monitoring and detection capabilities (IDS, log reviews, etc.), the information the provider captures that may relate to a breach, how breaches are categorized, the escalation rules that result in key stakeholders discovering the breach, etc. In many cases, if the service provider’s procedures are adequate, a contractual requirement to follow those procedures would be appropriate. If there are weaknesses and gaps, specific obligations and controls can be imposed in the contract.
However, even if the service provider’s internal incident response policy is solid, there is still a need to consider how the service provider and customer will coordinate if the provider suffers a breach. The Cloud contract should address this issue.
The CSC Contract
The CSC Contract does not appear to explicitly contain any security incident response obligations owed by CSC. It may be generally covered under the contract’s SLA with reference to various Severity Levels, but those Severity Levels relate to events discovered by the City and notified to CSC. There does not appear to be any duty for CSC to report a security breach to LA. Again, since CSC's data processing role seems limited in this arrangement, not having these obligations may be appropriate (i.e. CSC may not be in a position to even discovery breaches that occur on Google's systems).
The Google Contract
Section 7.5 of the Google contract contains some sparse incident response language. First, it confirms that Google will comply with breach notice laws (most of which would require Google to provide LA with notice of a breach exposing personal information). For security breaches that don’t trigger breach notice laws, the Google Contract provides as follows:
Google will notify Customer of a Security Breach, following the discovery or notification of such Security Breach, in the most expedient time possible under the circumstances, without unreasonable delay, consistent with the legitimate needs of applicable law enforcement, and after taking measures necessary to determine the scope of the breach and restore the reasonable integrity of the system.
As you might imagine, that laundry list of caveats creates plenty of flexibility for Google to delay notifying LA of a breach (e.g. taking measures necessary to ascertain scope can go on for some time). A better clause for a customer would be to impose a certain timeframe by which notice of a breach or reasonably suspected breach must be reported (e.g. 12 hours, 24 hours, etc.).
Since incident response obligations may be crucial for mitigating harm caused by a security breach impacting customer data, additional contract terms should be considered, including a duty to:
- collect and retain certain information that might be relevant to security breaches
- conduct a reasonable investigation of the security breach
- contain, prevent and mitigate a security breach
- provide notice to the customer within XX hours of discovering the breach
- provide a written report concerning the security breach within XX days of the breach
- collect and preserve all data and evidence concerning the security breach
- document and detail the remedial action taken, and planned to be taken, to remediate the breach
- allow a post-breach security assessment or audit
- allow the customer to perform its own on-site forensic examination of the security breach
One point to highlight with respect to post-incident forensic assessment. Being able to conduct an independent forensic assessment may be crucial for a customer whose data was exposed. That assessment will allow for the gathering and preservation of potential evidence to support the customer's defense in the event of a lawsuit or regulatory action. That information may also reveal whether and to what extent the service provider itself may have breached its contract or violated the law.
In the Cloud, however, where multiple clients may have data on a single server (e.g. multi-tenancy), conducting a forensic investigation may be more challenging. Such an investigation could reveal data belonging to the service provider's other customers (and could even result in a breach of NDAs by the service provider), or potentially disrupt the services being provided to other service provider customers. Yet without such rights, the customer may be completely reliant on the service provider's forensic investigation. One could argue that this imposes an inherent conflict of interest. Moreover, if the service provider makes a mistake, and say fails to retain crucial relevant data, the customer could face spoliation issues in court. Unfortunately, this is another tricky issue for Cloud providers and customers to work out.
Conclusion
As you can gather from reading the above, the terms and conditions of Cloud contracts can become very complex and involved and take a great deal of foresight and knowledge to understand and put together. In our next installment we wade into the thicket that is “risk of loss” contract terms, arguably the most important terms in these contracts.
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.
