FAQ on the "BEST PRACTICES Act" - Part One
Congressman Bobby Rush has introduced a new data privacy bill to Congress known as the “Building Effective Strategies to Promote Responsibility Accountability Choice Transparency Innovation Consumer Expectations and Safeguards" Act (a.k.a. “BEST PRACTICES Act” or “Act”). Congressman Rush has been active in the data security/privacy legislation space. In December of 2009, his “Data Accountability and Trust Act” or (“DATA Act”) passed the House of Representatives. While DATA focused more on data security and breach notice, the stated focus of the BEST PRACTICES Act is as follows:
To foster transparency about the transparency about the commercial use of personal
information, provide consumers with meaningful choice about the collection, use, and disclosure of such information, and for other purposes.
This Act comes on the heels of the Boucher Bill, which also represents a comprehensive data privacy approach (for more information on the reactions to the Boucher Bill you can look here and here).
We have put together a summary of the Act in “FAQ” format. In Part One we look at some of the key definitions, requirements concerning transparency, notice and individual choice, mandates around accuracy, access and dispute resolution, and finally data security and data minimization requirements under the Act. Part Two will focus on the “Safe Harbor” outlined in the Act, various exemptions for deidentified information, and provisions concerning the application and enforcement of the Act. Final note, this is not a law, but rather only a bill -- if passed at all, it is likely that the final version will vary from this initial proposal.
What kinds of entities does the Act apply to?
The Act defines “covered entities” to mean any person engaged in interstate commerce that collects or stores data containing covered information or sensitive information. However, section 601 of the Act limits the application of the Act to only those persons over which the Commission has authority pursuant to section 5(a)(2) of the FTC Act (Note: this section previously indicated that the Act applied to all persons engaged in interstate commerce [which is in the definition of covered entity]; the error was noted by a reader and the correction made here). Covered entities do not include any divisions of Federal or state government or some entities that meet specified criteria (e.g. store less than 15,000 records; collect less than 12,000 records in a year, etc.; see definition of “covered entity” for more detail).
Observations: Significantly, it does not appear that the definition of covered entity makes the traditional distinction between data owner/controller and service provider/processor. As such, service providers may be directly subject to the Act as a result of collection or storage of covered/sensitive information on behalf of their customers.
What kinds of information does the Act regulate?
The Act regulates “covered information” and “sensitive information.”
“Covered information” includes such information elements as first name or initial and last name, postal address, email address, telephone/fax number, government issued identification numbers (e.g. tax ID, driver’s license number, etc.), financial account numbers, credit/debit card number, access codes/passwords, “unique persistent identifiers” used to collect, store or identify information about a specific individual or create a profile (e.g. customer numbers, IP addresses, unique pseudonym), and any information collected, stored, used or disclosed in connection with the foregoing information. Section (B) of the definition also lists a number of important exclusions concerning certain business-related information.
“Sensitive information” means information associated with covered information of an individual that relates directly to the individual’s medical history or health, race or ethnicity, religious beliefs/affiliations, sexual orientation/behavior, financial information (income, assets, liabilities, etc.), a person’s geolocation information, unique biometric information or social security number.
Observations: The definitions of information regulated under the Act go well beyond any U.S. definition of personally identifiable information. For example, the “traditional” definition of PII normally requires first name and last name combined with additional information such as financial account numbers. The definition of “covered information” in the Act does not require such a combination – each data element stands on its own and may not need to be tied to or identify a specific person. If I, as an individual, had an email address that was wildwolf432@hotmail.com, that would would appear to satisfy the definition of covered information even if my name was not associated with it.
The definition of “sensitive information” echos similar definitions under the EU Data Protection Directive and other laws based on an EU Model. Interestingly, however, it also specifically includes geolocation information (which some believe may become a larger privacy issue with the prevalence of mobile computing and smartphones).
How does the Act promote transparency about the commercial use of information?
Section 101 of the Act purports to promote transparency by requiring covered entities to provide certain information about the covered entity’s information practices and the individual’s options with respect to such practices, including:
- the identity of the covered entity
- description of covered/sensitive information collected or stored by covered entity
- the specific purposes for which the covered entity collects and used the covered information, including how the covered entity customizes products/services/prices based on such information
- the specific purposes for which covered/sensitive information may be disclosed to third parties and the categories of third parties who may receive such information the choice and means for limiting the collection, use and disclosure of covered/sensitive information
- a description of the information any individual may request access to and the means for making such a request
- how the covered entity may merge, link or combine covered/sensitive information
- the retention schedule for covered/sensitive information including whether the entity will retain information permanently
- whether the individual can direct the deletion of information collected from or about the individual
- a reasonable means for individuals to contact the covered entities regarding their handing of covered/sensitive information
- the process by which the covered entity notifies individuals of material changes to its practices or policies
- a hyperlink to the FTC Commissioner’s online consumer complaint form or the FTC’s toll-free number for the Commissions Consumer Response Center
- the effective date of the privacy notice.
Observations: While much of the notice requirements of the Act parallel the Fair Information Privacy Principles, one could argue that the Act also includes notice elements that appear to go beyond such principles. These additional elements also appear to address current issues that some believe may pose privacy problems. For example, it is interesting that notice is required concerning where/how information will be merged or combined with other data. The retention schedule requirement is also interesting as it may address concerns that some have about some companies retaining data too long.
How must the notice required under the Act be provided?
Under section 102 of the Act, the notices described in the prior FAQ must be “concise, meaningful, timely, prominent, and easy-to-understand” in accordance with FTC regulations authorized under the Act that will be published later. Notices must be retained for six years from the later of the date the notice was issued or the date it was last in effect.
Is notice required for “in-person transactions”?
Under section 103 of the Act, it appears that the notice and information referenced above is not necessary for “in-person transactions” but only if the covered information is collected for an “operational purpose” (e.g.for the purpose of providing goods or services, managing operations, compliance with legal obligations or protection against risks and threats ) or if the covered entity is only collecting name, address, email or phone/fax and does not share the information or use that information to acquire additional information about the individual from third parties.
Observations: Notably, the Act does not indicate that covered information needs to be collected solely for operational purposes. Based on the current wording, one could argue that if covered information was covered for both operational purposes and marketing purposes, it could fall under the “operational purposes” exception.
Are covered entities required to get consent from individuals for the collection and use of covered information?
Yes, under section 103 of the Act covered entities must provide “opt-out” consent in order to collect or use covered information (except for the collection or use of covered information for operational purposes). The Act indicates that a covered entity shall be considered to have obtained proper consent if it has provided the notice required under the Act, provides a reasonable means to exercise an opt-out right and decline consent; and the individual either affirmatively grants consent or does not decline consent.
The consent shall be considered permanent unless directed by the individual. However, the covered entity must provide an individual with a reasonable means to decline or revoke previously granted consent at any time.
A covered entity may also provide individuals with the ability to decline consent for specific uses of his or her personal information, but only if the individual has been given an opportunity to broadly opt-out of all collection and use of covered information.
May covered entities collection or use covered information as a condition of an individual’s receipt of a service or other benefit?
Yes, but only if: the covered entity has a direct relationship with the individual; the information is not shared with any third party without the express affirmative consent of the individual; the covered entity provides a clear, prominent and specific statement of the specific purposes for which covered information will be used; the individual provides consent by acknowledging such uses; and the individual is able to later withdraw consent.
Are covered entities required to get consent from individuals for the disclosure of covered information to third parties?
Yes. In general, a covered entity may not disclose information to a third party unless it has received express affirmative consent from the individual prior to disclosure. However, some exceptions apply. For example, no such consent is necessary for joint marketing activities as long as the covered entity has entered into a contract with the third party that prohibits the disclosure of the information except as necessary to carry out the joint marketing relationship.
Are covered entities required to get consent from individuals for the collection, use or disclosure of sensitive information?
Yes. In general, under section 104 of the Act, a covered entity may not collect, use or disclose sensitive information to a third party unless it has received express affirmative consent from the individual.
Does the Act put any limitations or restrictions on behavioral advertising or tracking an individual’s Internet browsing activities?
Yes. Under section 104 of the Act, covered entities may not use software or hardware to monitor all or substantially all (a.k.a. “comprehensive online data collection”) of an individual’s browsing activity (or other significant Internet or computer activity), and may not collect, use or disclose information concerning that activity unless certain conditions are met.
Covered entities may engage in comprehensive online data collection if: they receive the express written consent of the individual or for the purpose of making such information accessible to the individual for the use by the individual.
Are there any exceptions to the consent requirements of the Act?
Yes, exceptions exist under section 106 of the Act.
Covered entities may disclose information to a service provider as long as it has obtained the initial consent to collect information and contractually prohibits the service provider from disclosing the information other than for purposes of carrying out the purpose for which the information was disclosed. However, the Act indicates that the covered entity remains responsible and liable for the protection of the information transferred to a service provider for processing.
Consent is also not required for collection, use or disclosure necessary for fraud detection, imminent danger or compliance with law.
In addition, consent under the Act is not necessary for the collection, use or disclosure of publicly available information. However, even publicly available information cannot be used by a covered entity for marketing purposes if the individual has opted out of such use.
Do covered entities have any obligation concerning the accuracy of information they collect, assemble or maintain?
Yes, section 201 of the Act requires covered entities to establish reasonable procedures to assure the accuracy of covered information or sensitive information they collect, assemble or maintain. This duty may be further fleshed out as section 201 requires the FTC to promulgate regulations to implement this section. Limited exceptions exist with respect to fraud databases and publicly available information.
Does the Act require the covered entity to provide individuals with access to covered information or sensitive information?
Yes, under section 202, covered entities are required to provide access to such information if such information may be used for purposes that could result in an adverse decision against the individual, including the denial of a right, benefit, or privilege. If the information could not reasonably result in an adverse decision, the covered entity is only required to provide a notice to the individual of the type of information the covered entity typically collects.
In addition, covered entities, upon request, must provide individuals with access to their personal files, but only if the entity stores such file in a manner that makes it accessible in the normal course of business.
However, none of the foregoing obligations apply to information retained for under 30 days.
Is there any time frame by which a covered entity must respond to a permitted access, correction or amendment request?
Yes, in general, under section 202(f), covered entities have thirty days from the receipt of such request to respond.
Does the Act impose any data security requirements with respect to covered information or sensitive information?
Yes, under section 302 of the Act each covered entity and service provider must establish, implement and maintain “reasonable and appropriate” administrative, technical and physical safeguards to:
- ensure the security, integrity, and confidentiality of the covered information or sensitive information it collects, assembles, or maintains
- protect against any anticipated threats, reasonably foreseeable vulnerabilities, or hazards to the security or integrity of such information; and
- protect against unauthorized access to or use of such information and loss, misuse, alteration, or destruction of such information.
The Act requires the FTC to promulgate regulations to implement this section.
Does the Act require covered entities to conduct any risk assessment with respect to its information handling practices?
Yes, under section 302 of the Act covered entities are required to conduct an assessment of the risks to individuals raised by its collection, use and disclosure of covered information or sensitive information prior to engaging in such activities (or if it believes there is a reasonable likelihood that it will engage in such activities), but only if such activities will involve more than 1 million individuals.
Does the Act require any audits or assessments?
Yes, covered entities must conduct periodic assessments to evaluate whether the covered/sensitive information it has collected remains necessary for the purposes described at the time of collection, and whether the covered entities’ ongoing collection practices remain necessary for legitimate business purposes.
Does the Act limit how long a covered entity can retain covered/sensitive information?
Yes, under section 303 of the Act covered entities may retain covered/sensitive information for only as long as necessary to fulfill a legitimate business purpose or comply with a legal requirement.
Coming up next in Part Two: the “Safe Harbor” outlined in the Act, various exemptions for de-identified information and application and enforcement of the Act.
InfoLaw Alert: HHS Issues Proposed Mofications to HIPAA Security and Privacy Rules
The Department of Health and Human Services released proposed modifications to the privacy and security rules related to HIPAA. We are still reading through the 234 page document, but it appears that the new rules expand HIPAA responsibilities for business associates. In addition, HHS has set up a web portal that provides a summary of the breaches reported to HHS. There is a 60 day comment period on this proposed rule change. More to come from the Information Law Group in the coming days.
Quickhits: Dog Days of Summer Edition
The heat is on as we enter the dog days of summer. The same is true at the intersection of law, technology, privacy and security where tricky issues continue to heat up. Things are moving so fast now it is a challenge to keep track of all the developments. Here are a few "quickhits" to help keep you up-to-date . . .
- Another interesting online banking security breach recently occurred. This time the bad guys scored $465,000. If a lawsuit is filed this one may again test the issue of “commercially reasonable security” and the responsibility of the small business customer whose account was compromised. In this case (unlike for instance Shames-Yaekel or EMI ) a login by two separate individuals was required before a wire transfer could go out. It appears that the customer opened an unknown attachment to an email, which launched a Trojan horse that allowed the thieves to obtain the login credentials of BOTH people needed for a wire transfer. The sophistication of the attack was impressive, involving a fake email based on a real UPS delivery and the use of multiple “mule” companies (unwitting individuals trying to start a “get rich quick business from your own home”) to transfer funds to the criminals’ accounts.
- Healthnet settled with the Connecticut AG over its security breach and alleged violations of HIPAA. The fine was $250,000, but rumors have it that Healthnet spent in the vicinity of $7 million handling the breach, providing notice and responding to the investigation.
- Mexico’s data protection law recently went into effect. If you want to read a really bad English translation (created using Google Translate), click here (DISCLAIMER: do not rely on this translation it is full of errors, but will give an idea of what this law entails; the Mexican government will eventually release an official English translation).
- Germany launches legal proceedings against Facebook for allegedly illegally accessing and saving personal information of people that do not use Facebook.
- The 2010 Betterley Report on the "cyber insurance" market was recently released. Cyber insurance is being sold by more and more insurers at all levels of the economy. Will it become a standard purchase as information security and privacy legal risks increase? You can read an excerpt of the report HERE.
Thanks for reading us, and enjoy your summer!
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
California Department of Public Health Breach Fines and Legally Defensible Security
The California Department of Public Health (“CDPH”) recently announced its imposition of $675,000 in fines to six hospitals that had reported security breaches involving medical records (since January 1, 2009, the CDPH has issued fines totaling $1.1 million). The story has been extensively reported on in the media . You can listen to the CDPH’s press conference here. The total number of records exposed was only 244, for an average fine of around $2,766 per record. To put that in perspective, if a California hospital suffered a breach involving 100,000 medical records, using the average stated here, their potential fines could be $276 million (assuming no cap for fines and penalties -- the relevant laws do have a cap of $250,000 per incident).
In this post we take a deeper look at the CDPH fines and the legal framework that gave rise to them, and explore the concept of legally defensible security in this context.
Legal Framework and Basis for these Fines and Penalties
It is best to start at the beginning and take a quick look at the legal framework for the fines and penalties imposed on the hospitals. In this case it was a potent combination of California laws involving:
(1) a breach notice law that requiring hospitals to provide notice to the CDPH of unlawful or unauthorized access to, and use or disclosure of medical information with 5 days after detection;
(2) a duty to prevent unlawful or unauthorized access to, and use or disclosure of medical information; and
(3) an obligation to establish and implement appropriate administrative, technical, and physical safeguards to protect the privacy of a patient’s medical information and reasonably safeguard confidential medical information from any unauthorized access or unlawful access, use, or disclosure; and
(4) potential fines of $25,000 per patient ($17,500 per subsequent breach per patient) capped at $250,000 per event.
These legal requirements are all contained in two bills that amended California law in 2008: AB 211 and SB 541 (you can find the final amendments incorporated into the actual statutes here and here). Also referenced by the CDPH is Title 22, Section 70707(b)(8) of California's Code of Regulations, which lists the following as a mandatory "patient right" under the law:
Confidential treatment of all communications and records pertaining to the care and the stay in the hospital. Written permission shall be obtained before the medical records can be made available to anyone not directly concerned with the care.
Legal Defensibility
To refresh, the following summarizes a legally defensible security approach:
The focus of legal defensibility is understanding how a plaintiff ’s attorney, judge, jury, or regulator will view an organization’s security posture in light of applicable legal requirements. Under a legal defensibility analysis security choices become legal positions or arguments to be used to persuade legal decision-makers that an organization’s security was legally sound, and increase the likelihood that a judge, jury, or regulator will find a company legally compliant. Ultimately, there may not be a clear “right” or “wrong” answer, but rather a more or less persuasive legal argument/position on security.
In the case of the California laws outlined in this post, hospitals should be asking themselves as they develop their security programs, how will the CDPH interpret the security obligations contained in those laws, and in the event (or the inevitability as the case may be) of a security breach, what legal arguments does the hospital have to persuade regulators to refrain from issuing a fine?
A full blown analysis of the key security-related legal issues is well beyond the scope of this blogpost. However, there are some key issues posed by these laws that would be addressed under a legal defensibility approach.
Relationship between AB 211 and SB 541.
The obligations set forth in AB 211 and SB 541 appear to overlap and impact the development of an information security program. The relevant amendment set forth in SB 541 reads as follows:
1280.15. (a) A clinic, health facility, home health agency, or hospice licensed pursuant to Section 1204, 1250, 1725, or 1745 shall prevent unlawful or unauthorized access to, and use or disclosure of, patients’ medical information, as defined in subdivision (g) of Section 56.05 of the Civil Code and consistent with Section 130203.
(emphasis supplied). Section 130203 was actually added by AB 211, and provides in relevant part:
Every provider of health care shall establish and implement appropriate administrative, technical, and physical safeguards to protect the privacy of a patient’s medical information. Every provider of health care shall reasonably safeguard confidential medical information from any unauthorized access or unlawful access, use, or disclosure.
One reading of SB 541 is that no violation would exist due to a failure to prevent unauthorized access as long as the hospital could establish that it had “appropriate administrative, technical and physical safeguards” and reasonably safeguarded medical information (see AB 211). Another might read this part of SB 541 as creating regulatory liability if a hospital fails to prevent unauthorized access to medical records regardless of the hospital's security stance. Listening to the press conference put on by the CDPH it is not clear whether (or to what extent) they took the hospitals' security into account (and the CDPH indicated that it had not issued any "best practices" in this regard).
From a legal defensibility standpoint, legal analysis should be performed to determine arguments for and against each position. This analysis might look deeper into the legislative history behind these laws as wells as prior decisions and documents issued by the CDPH (e.g. the survey findings reports issued by the CDPH). That legal analysis will help to inform the hospital’s security team as to what actions to take and where to focus its efforts.
Appropriate Controls
Assuming that establishing and implementing appropriate/reasonable safeguards would provide a hospital with the means to escape regulatory fines, a legal defensibility approach would require research and analysis as to the meaning of “appropriate” and “reasonable” in this context. This meaning might be derived from legislative history, case law, other statutes using analogous language or decisions or documents issued by the CDPH concerning security measures (or the lack thereof).
Hospitals lawyers that perform this analysis while they are building their security program can help to guide their security teams to address crucial areas and reduce liability. Would compliance with particular standards improve their legal position? Would a evidence of a comprehensive security risk assessment persuade regulators that the hospital had done the right thing despite the breach? What security measures has the CDPH stressed or scrutinized in prior investigations? Employing a legal defensibility strategy would allow the hospitals to have established legal positions concerning their security in order persuade regulators not to impose fines and penalties
Risk Factors to Mitigate Potential for Fines
Both SB 541 and AB 211 set forth specific factors that regulators may take into account when deciding whether a security breach involving medical information is worthy of a fine and how much the fine should be. For instance, SB 541 provides:
For purposes of the investigation, the department shall consider the clinic’s, health facility’s, agency’s, or hospice’s history of compliance with this section and other related state and federal statutes and regulations, the extent to which the facility detected violations and took preventative action to immediately correct and prevent past violations from recurring, and factors outside its control that restricted the facility’s ability to comply with this section. The department shall have full discretion to consider all factors when determining the amount of an administrative penalty pursuant to this section.
Again, the key issue here is when developing the information security program, in light of these factors, what security should be implemented to reduce legal risk. More to the point, based on these factors, what arguments exist for the hospital to claim that they should not be fined. For example, based on references to detection, prevention and “immediate correct[ion],” a hospital that established a security program with strong intrusion detection and prevention controls might persuade regulators to refrain from imposing fines. Moreover, if the security program’s incident response procedures stressed rapid correction of breaches, and such correction took place, this fact may mitigate against the imposition of fees.
There are many other legal issues presented by this language that could impact how a security program is implemented so that it is legally defensible. For example, which of these factors do the legislators or regulators weigh more heavily (or are they all treated the same)? Is there any evidence (perhaps past regulatory actions and documents related thereto) that indicate other factors regulators may take into account when deciding whether to impose fees (at the CDPH press conference the spokesperson indicated that it had taken the "rural" nature of two hospitals into account in assessing penalties). Answering these questions requires careful legal analysis and coordination between a hospital's legal and security teams.
Preferably all of these legal defense considerations are proactively baked into a security program when it is built (instead of having to construct arguments reactively in the wake of a security breach). Preferably these legal positions are documented and preserved for use in case something goes wrong (instead of having to create them ad hoc in the heat of a breach situation). Having established positions is even more important for these California laws since hospitals only have five days before they are required to provide notice to the CDPH. Five days is likely not enough time to conduct a full investigation and analysis, and construct complex legal arguments.
Conclusion
It remains to be seen whether these fines are a one-time warning shot for deterrence purposes, or potentially the beginning of significant series of fines for California healthcare entiteis that have reported more than 3,400 patient confidentiality breaches since January 1, 2009. Either way these fines highlight the need for a legal defensibility approach when developing an information security program.
This is the reality in California for hospitals: you will need to report breaches to the CDPH within five days of detection, the CDPH has the potential to impose stiff fines if they believe you have violated various laws, and the hospital with have to establish that despite the breach it was doing the right thing and should not be fined. Hospitals that have not considered how to build security programs that provide solid legal arguments in favor of compliance with these laws may find themselves unable to dissuade regulators from imposing fines. They will be in a defensive and reactive posture under extreme time pressure instead of a proactive and prepared posture. Considering security and patient confidentiality for a legal defensibility standpoint may help to mitigate some of this risk.
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.
Observations on the Dept. of Commerce's Privacy Inquiry
Earlier in the week, I referenced the U.S. Department of Commerce’s Notice of Inquiry concerning “Information Privacy and Innovation in the Internet Economy” (the “Inquiry”). DataGuidance.com recently did a short article on the Inquiry in which I am quoted. I have now had a chance to review the document in more detail and believe that this Inquiry and the report that it generates has the potential to usher in a paradigm shift and reshape the privacy environment as it relates to commerce. Unfortunately, it also has the potential to be a frustrating exercise involving entrenched special interests banging their heads against a wall in a political forum. Nonetheless, whether the Inquiry ends up yielding any legislation, industry standards, best practices or a strategic frame work for privacy, the document itself reflects some of key challenges faced at the intersection of privacy and commerce. This post outlines some of my observations after reading the Inquiry.
Some thoughts and observations in no particular order:
- The Hard Questions. This Inquiry seeks to tackle practically all of the “hard questions” in privacy as it relates to commerce. Its breadth is impressive.
- Balance Between Commerce and Privacy. Based on how it is written, the topics discussed and the framing of the questions, it is clear that the DOC seeks to find the proper balance between commercial innovation/burden and individual privacy. It is interesting that these questions are being considered in a commercial context rather than from a “civil rights” point of view. This is consistent, of course, with the U.S. approach. However, considering that one of the issues it addresses is international privacy laws and regulations, it begs the question of whether the lack of consistency in privacy regulations globally (and difficulties related thereto) is “baked into the cake.”
- The Multiplicity of Privacy Laws. One of the key business problems the Inquiry seeks to explore is compliance with privacy laws and jurisdictional conflicts. The Inquiry ask questions about the multi-jurisdictional nature of handling person information, both on a national and state level within the United States, and on an international level with the rest of the world. It also provides a series of questions that seek to explore the effectiveness of the U.S. sectoral approach to privacy regulation. The compliance burden arising out of multiple (and sometimes conflicting) privacy regulatory regimes has vexed and continues to vex multinational corporations that handle personal information.
From a commercial and compliance point of view this issue is extremely important. The reality is that for multinational companies (which these days can be very large and very small -- a website that is accessible by foreign data subjects could put a company in the "multinational" category), because of transborder data flow, it is extremely difficult, if not impossible (when actual cost is taken into account), to even know what laws apply to the organization. In fact, the legal environment is constantly changing due to new laws at multiple jurisdictional levels, and due to organizational changes concerning the type, handling and location of personal data interacting with a company. Even if companies have the ability to ascertain what laws apply to them, compliance is also very difficult and expensive (and some would maintain again that it is impossible to achieve 100% compliance).
Based on the questions posed the Inquiry seems to recognize the disconnect between applicable privacy laws based on arbitrary and imaginary borders, and the completely borderless environment in which information exists in commerce. Will Commerce conclude that the multiplicity of privacy and security laws is an impediment or obstacle to the growth of the global economy? It will be interesting to see if the coming report will have recommendations on how to harmonize existing regulatory regimes while still addressing privacy issues important to particular countries.
- Cloud Computing and Borderless Data. Speaking of ethereal data processing-related concepts, the Inquiry specifically references cloud computing and web-based services, and appears to address the reality that in the 21st century data is borderless, but laws based on arbitrary location-based jurisdictional triggers are not.
- Notice & Consent Model Outdated? The Inquiry also appears to recognize concerns about the weaknesses of the current notice and consent privacy regime, and inquires about a “use-based” consumer privacy model. A used-based model recognizes the view that privacy is context-based rather than static. A use of information in one context may be consistent with the data subject’s expectation of privacy, but the same information may violate privacy in another context. Putting up pictures on Facebook of a late night out with friends and sharing with those friends does not violate privacy principles, but allowing the data subject’s employer to see those photos might. It is not clear, however, whether a “use-based” system would provide more effective protection or whether it could be done cost-effectively without massive standardization and cooperation between a multiplicity of entities that might handle personal information in the midst of a transaction. To achieve this type of regime, which effectively gives the data subject more control over its data, technology solutions may be necessary. Coincidentally, as discussed below, the Inquiry also asks questions concerning the role of technology in protecting privacy.
- The Role of Technology in Managing and Protecting Privacy. The Inquiry asks questions about “privacy-enhancing technologies” that would allow data subjects to manage the information they are sharing, allow for the auditing of compliance with privacy policies and expressed user preferences, and provide privacy notices to individuals concerning the use or disclosure of their personal information. To the extent that PETs empower individual data subjects, the challenge of course is getting data subjects to understand how they can use these technologies, and providing notice of what will happen to their personal information if they fail to do so. One interesting question in the Inquiry relates to whether technology designers are proper incentivized to build privacy-related functionality into the design of their technology. I think this question gets to the crux of one of the key problems with PETs: if the technologies are not already built into the business processes from the start, is it feasible and cost-effective to implement efficacious PETs.
- Recognition of the Small-Medium Business Challenges. The Inquiry poses a series of questions concerning the impact of privacy and compliance on small/medium businesses and start-ups. I think this issue is often overlooked in terms of how commercial innovation might be stifled by privacy requirements that are too costly. Much of the innovation over the past 20 years has come from start-up companies utilizing the efficiencies of information technology and the Internet. Do strict privacy requirements dissuade entrepreneurs from starting their companies or pose insurmountable obstacles due to compliance expenses? Some would argue that innovation has not been stifled by pointing to the existence of Facebook, Twitter, MySpace, all of which are pushing the boundaries of privacy. However, this begs the question because the existence of these companies is, in part, why the Inquiry is necessary. Beyond start-ups, the reality is most small businesses (even your local laundry mat) store, process and transmit personal information of some sort. Can laws and standards be created that are "one-size-fits all?" If not, considering the volume of small businesses in the U.S. (compared to large companies), if you exempt or limit the obligations of small businesses, are you leaving a massive privacy consumer privacy gap?
Overall, the ultimate impact of the Inquiry is unclear. The Inquiry specifically indicates that it is not being circulated for the specific purpose of creating legislation. However, it is possible that useful recommendations or guidance could come out of the DOC’s eventual report that could serve as the basis of future regulation, best practices or standards that relate to privacy in the context of modern commerce. It also must be recognized that this Inquiry is happening right in the middle of the political area. There will be entrenched and wealthy special interests on both the commerce and consumer side that will seek to influence the DOC and its report. The report will be less useful if it simply yields the same positions that have been espoused by various interests on either side of the spectrum. The hope is that the DOC report will get beyond the status quo and offer guidance and the foundations for public policy (and law) that actually move the ball forward and serve to address the significant privacy challenges the consumers and the commercial community face.
FAQ on Washington State's PCI Law
On March 22, 2010, Washington state became the third state to incorporate the Payment Card Industry Data Security Standard ("PCI") into law (the other two are Nevada and Minnesota). The Washington House and Senate have passed HB 1149 by substantial margins, and it has now been signed into law by the governor. HB 1149 amends Washington’s breach notice law (and borrows some of its definitions). Similar to Minnesota’s Plastic Card Security Act, HB 1149 provides issuing banks a legal mechanism to collect the costs to reissue payment cards after a payment card security breach. This blogpost summarizes HB 1149 in "FAQ" format and looks at its potential impact.
What is the overall stated purpose of HB 1149?
The introduction paragraph frames the purpose of the law in terms of protection consumers from identity theft due and fraud to data breaches of credit card data. To achieve this lofty goal, the law provides issuing banks the ability to seek reimbursement of reissuance costs in the wake of payment card data security breach. By providing this remedy, the drafters of the bill hope to encourage issuing banks to reissue cards, thereby reducing the incidence of identity theft and associated costs to consumers.
What organizations does HB 1149 apply to?
Moving past the introduction, the law provides a series of definitions related to payment card processing and data breaches. The law applies to “business(es),” “processors” and “vendors” (herein referred to as “Regulated Entities”). Businesses essentially refer to merchants that process more than six million payment cards annually, and who provide, offer or sell goods or services to residents of Washington. Processors are companies that process or transmit “account information” on behalf of another. Vendors are entities that manufacture and sell software or equipment designed to process, transmit or store account information that the vendor does not own.
Analysis: For each of these categories it is not necessary for the organization to physically reside in Washington state. To qualify as a “business “ the organization must merely offer or sell goods or services to Washington residents. Companies with an Internet website would arguably fall into that category. The definitions of “processor” or “vendor” do not even mention Washington residency as a limitation. As such, HB 1149 is likely to have reach beyond the borders of Washington State.
What kind of information does HB 1149 regulate?
HB 1149 imposes certain obligations with respect to “account information,” which is defined as follows:
Account information" means: (i) The full, unencrypted 2 magnetic stripe of a credit card or debit card; (ii) the full, unencrypted account information contained on an identification device as defined under RCW 19.300.010; or (iii) the unencrypted primary account number on a credit card or debit card or identification device, plus any of the following if not encrypted: Cardholder name, expiration date, or service code.
Analysis: Subsections (i) and (iii) mainly deal with various unencrypted cardholder data. Subsection (ii) however refers to unencrypted account information on “identification devices”, defined as "an item that uses radio frequency identification technology or facial recognition technology". An example might include a RFID tag. Identification devices are not obviously related to PCI and do not quite seem to fit into the overall theme of the law..
What data security obligations does HB 1149 impose on Regulated Entities?
Technically HB 1149 does not impose any obligations on Regulated Entities. Rather, the law works as a mechanism to transfer risk of loss between Regulated Entities and issuing banks in the event of a payment card breach involving Washington residents. Think of it as "sword and shield law": it gives issuing banks a sword to collect reissuance costs they otherwise might not be able to collect and provides companies a shield to avoid liability for such costs.
Section 2., paragraph (3)(a) indicates that if a processor or business fails to take reasonable care to guard against unauthorized access to account information, and that failure is the proximate cause of a breach, then the processor can be liable to issuing banks for costs to reissuing impacted payment cards. Section 2., paragraph (b) indicates that Vendors can be liable for damages caused by their negligence, but only if the claim is not limited or foreclosed by another provision of law or by contract to which the financial institution is party. However, as discussed further below, organizations that fall into HB 1149’s “safe harbor” will not be liable for reissuance costs (even if they did fail to take reasonable care or acted negligently).
Analysis: While there is no explicit/positive requirement for organizations to take reasonable care, companies that fail to do so may be liable to pay for reissuance costs after a breach. Contrast this against Nevada’s PCI law which imposed an affirmative obligation to be compliant with PCI for companies that accept payment cards.
What constitutes a “breach” under HB 1149?
HB 1149 borrows the definition for breach from Washington state’s breach notice law. As such breach has the same definition as “breach of the security of the system,” which is defined as follows:
unauthorized acquisition of computerized data that compromises the security, confidentiality, or integrity of personal information maintained by the person or business. Good faith acquisition of personal information by an employee or agent of the person or business for the purposes of the person or business is not a breach of the security of the system when the personal information is not used or subject to further unauthorized disclosure.
As you can see this definition references the term “personal information,” which is also a defined term under Washington’s breach notice law. Without repeating the entire definition, for information to be considered “personal information” it must include the first name/first initial and last name in combination with other data such as social security number or Washington driver’s license number. In addition, personal information includes first name/first initial and last name in combination with “account number or credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual's financial account.”
Analysis. There may be a lack of consistency between the definition of “account information” and “personal information” such that it may be possible to have a compromise of “account information” without there being any "personal information" compromised. If that were the case then there would be no “breach” under HB 1149 and its provisions would not appear to apply. For example, the unencrypted PAN of a payment card plus an expiration date would constitute “account information” under HB 1149, but is not “personal information” as defined under Washington's breach notice law. As such, if there was unauthorized access to such account information it would not constitute a “breach” since no personal information was implicated, and therefore HB 1149 would not apply (even if card reissuance was necessary).
How does PCI come into play under HB 1149?
Under HB 1149 the certification of PCI compliance is part of HB 1149’s “safe harbor.” In other words, under certain circumstances, even if a company failed to take reasonable care or acted negligently in protecting “account information” (as referenced in Section 3. of HB 1149) issuing banks will not be able to recover their reissuance costs.
How does the HB 1149 “Safe Harbor” work?
It appears that if a Regulated Entity satisfies the requirements of Section 2.(2) it will not be liable if it runs afoul of the reasonable care/negligence aspects of Section 2.(3). There are two ways to achieve safe harbor. First, Regulated Entities shall not be liable under HB 1149 if the account information at issue was encrypted at the time of the breach. Second, a Regulated Entity shall not be liable if it was certified as PCI complaint at the time of the breach. Under HB 1149, a Regulated Entity is considered compliant if it was validated by an annual security assessment as long as an assessment took place no more than one year prior to the time of the breach.
Analysis of Encryption Safe Harbor: The encryption safe harbor option seems odd in light of the definition of “account information.” Account information as defined under HB 1149 is by definition “unencrypted.” Thus, if the information described in the definition of account information was encrypted at the time of the breach, it would not constiute “account information” as defined. In other words, this safe harbor is completely circular and redundant.
Analysis of the PCI Safe Harbor: The PCI Safe Harbor is very interesting because it plays into and recognizes the difference between “PCI compliance” and PCI validation/certification. To make a long story short, a company can certify or validate that it is PCI compliant simply by filling out some paperwork. However, that company could be completely wrong and not actually compliant with the PCI standard. The PCI Safe Harbor in HB 1149 does not appear to care whether a Regulated Entity is actually PCI compliant. It appears that the paperwork will do. In fact, Section 2.(2) specifically indicates the following:
For the purposes of this subsection (2), a processor, business, or vendor's security assessment of compliance is nonrevocable. The nonrevocability of a processor, business, or vendor's security assessment of compliance is only for the purpose of determining a processor, business, or vendor's liability under this subsection (2).
What this appears to state is that, as long as the Regulated Entity has done a security assessment and certified/validated it (e.g. filled out and turned in required PCI paperwork in the form of a self-assessment questionnaire or report on compliance), its assessment is “nonrevocable” even if it was incorrect. At least this is one reading of this language (and I would love to hear other theories on this reference).
What kind of encryption is required for the encryption safe harbor?
HB 1149 defines “encrypted” as follows:
(f) "Encrypted" means enciphered or encoded using standards reasonable for the breached business or processor taking into account the business or processor's size and the number of transactions processed annually.
Analysis: The “taking into account” language is extremely odd in the context of describing encryption. It is unclear how a processor’s size or transaction volume would impact its encryption requirements. Typically the key factors for encryption are the key length (e.g. number of bits), encryption algorithm and key management. What is unclear is whether companies of smaller size and lower transactions are allowed to use “weak encryption,” and if so, that would seem to undermine the purpose of the statute (again, I would love to hear from readers on what they think the “taking into account” qualification might mean to them).
When would this law come into effect?
HB 1149 takes effect on July 1, 2010. It would only apply to breaches taking place on or after July 1, 2010.
What happens if more than one entity was at fault for a breach?
According to Section 2.(6), the trier of fact (a judge or a jury) is responsible for determining the percentage of total fault that is attributable to every entity that was the proximate cause of a claimant’s damages.
Analysis: Again a strange provision. One wonders what percentage of fault would be applied to the person/entity that actually stole the payment card data (or whether that would even be part of the analysis).
SearchSecurity.com Interview on the Data Accountabilituy and Trust Act
For those interested, I was recently interviewed by SearchSecurity.com concerning the Data Accountability and Trust Act ("DATA") passed in the House in December 2009. While I might not be cut out for a career in broadcasting, hopefully the information I provided is useful. If you would like more information, the Information Law Group has written several times on DATA and similar legislation pending in the Senate.
The Breach Notification Obligations in the Data Accountability and Trust Act
The Information Law Group has been following various Federal data security bills as they wind their way through the House and Senate. In December 2009, the Information Law Group commented on the passage of the Data Accountability and Trust Act ("DATA") by the House. I was recently asked by Data Protection Law and Policy (an excellent publication out of the UK focusing on data security and privacy issues) to take a closer look at the data breach obligations of the current version of DATA. The end result was my article entitled: "Potential changes to the US breach notice risk landscape".
In summary, my article discusses some of the similarities and differences between the current state-created breach notice regime and the system set forth under the proposed DATA law. DATA is interesting because it appears to create counter-opposing breach notice incentives. On the one had, there are mechanisms that could lead to less breach reporting, including:
- a "risk of harm" standard that is likely higher than many existing State laws;
- preemption of existing state law, which eliminates the "least common denominator" approach taken with respect to existing state law; and
- mandating call center and credit monitoring costs (e.g. these costs may be significant, and therefore encourage non-compliance, especially if enforcement is lax)
On the other hand, DATA allows for the imposition of civil penalties of up $11,000 per violation (capped at $5 million). Each failure to send the required notification to an affected individual is treated as a separate violation. Depending on how vigorously the law is enforced, the risk of significant civil penalties is likely to encourage compliance.
How these factors would play out is unclear and up for debate. However, what is even more unclear is whether DATA will ever be made into a law. The Senate is working on a similar bill, and assuming it passes the Senate it would still have to be reconciled with the House version. Consumer advocates will likely have concerns about the higher risk of harm threshold in the law. On the business side, I anticipate great resistance to call center and credit monitoring as mandatory costs. Moreover, the penalties for non-compliance may be problematic, especially for smaller and medium organizations. As such, should DATA become a law, it is likely to differ from this version.
