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.

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.

The general thrust of the class action compliant is that the merchant banks should be liable for the acts and errors of the payment processor they contracted with to process payments on their behalf. The complaint set forth a series of complex legal theories (3rd party beneficiary theory, negligence), some of which had been attempted in other litigation, and some new theories of liability such as breach of fiduciary duty and vicarious liability. 

Each merchant bank has now filed a motion to dismiss the issuing banks' complaint.  We have obtained copies of the motion and corresponding briefs.

• Keybank's Motion to Dismiss

• Heartland Bank's Motion to Dismiss

• Issuing Bank's Response to Keybank's and Heartland Bank's Motions to Dismiss

• Keybank's Reply Brief (in support of its motion)

• Heartland Bank's Reply Brief (in support of its motion).

As you can see (if you click on the links above) the motions and briefs are quite voluminous and complex.  We will pass on trying to summarize all these arguments and instead will keep you posted on the Court's ruling when it comes out.  All the briefs appear to be filed (the last one was filed on June 7th), so it is probable that an oral argument will be scheduled (if it has not been already) and we should get an opinion shortly after that argument.  Stay tuned.

• 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!

P.S. I have linked to some of the key documents and have not included all of the supporting exhibits. I have all of the exhibits supporting all of these briefs, including relevant contracts and guides. If you want them all, please contact me at dnavetta@infolawgroup.com and we can arrange something.

This matter revolves around a couple sections of Michigan’s version of the Uniform Commercial Code, in particular MCLA 440.4702(2), which provides in relevant part:

(2) If a bank and its customer have agreed that the authenticity of payment orders issued to the bank in the name of the customer as sender will be verified pursuant to a security procedure, a payment order received by the receiving bank is effective as the order of the customer, whether or not authorized, if (i) the security procedure is a commercially reasonable method of providing security against unauthorized payment orders, and (ii) the bank proves that it accepted the payment order in good faith and in compliance with the security procedure and any written agreement or instruction of the customer restricting acceptance of payment orders issued in the name of the customer. The bank is not required to follow an instruction that violates a written agreement with the customer or notice of which is not received at a time and in a manner affording the bank a reasonable opportunity to act on it before the payment order is accepted. (emphasis supplied)

MCLA 440.4702(3) explains how “commercial reasonableness” is to be determined under MCLA 440.4702(2):

(3) Commercial reasonableness of a security procedure is a question of law to be determined by considering the wishes of the customer expressed to the bank, the circumstances of the customer known to the bank, including the size, type, and frequency of payment orders normally issued by the customer to the bank, alternative security procedures offered to the customer, and security procedures in general use by customers and receiving banks similarly situated. A security procedure is deemed to be commercially reasonable if (i) the security procedure was chosen by the customer after the bank offered, and the customer refused, a security procedure that was commercially reasonable for that customer, and (ii) the customer expressly agreed in writing to be bound by any payment order, whether or not authorized, issued in its name and accepted by the bank in compliance with the security procedure chosen by the customer. (emphasis supplied).

Finally, the definition of “security procedure” under MCLA 440.4701 is relevant in this context:

“Security procedure” means a procedure established by agreement of a customer and a receiving bank for the purpose of: (i) verifying that a payment order or communication amending or cancelling a payment order is that of the customer, or (ii) detecting error in the transmission of a the content of the payment order or communication. (emphasis supplied)

In short, what these laws do is assign the risk of loss with respect to payment orders that may not have been actually initiated by the customer. Even if a payment order is initiated by a criminal that payment order will be deemed effective under the law as long as the requirements of MCLA 440.4702(2) are satisfied. If those requirements are satisfied, the losses may fall on the banking customer rather than the bank (at least with respect to this particular law – there may be other theories of liability that could apply).

Comerica’s Motion for Summary Judgment

The following summarizes the main arguments put forth by Comerica in its motion for summary judgment ("MSJ").

• Comerica’s security procedure was commercially reasonable as a matter of law.

Comerica had established two-factor authentication using RSA secure token technology for its online banking. In order to access its online banking account EMI was required to input a user ID, password and PIN number generated from the RSA token(s) posesed by EMI (the PIN is randomly generated and changed every sixty seconds). Comerica maintains that EMI agreed that this security scheme was commercially reasonable. Support for this contention is found in the NetVision Wire Transfer Agreement entered into by EMI, which provided:

Customer [EMI] agrees that the selected Security Procedures are commercially reasonable for the type of entries which Customer may transmit to Bank, and Customer shall hold Bank harmless for any action taken in reliance upon the use of the Security Procedures.

Comerica also argues that 2-factor authentication is the same security it uses for its high volume wire transfer customers (i.e suggesting that it was providing more security than would normally be afforded to a low volume customer like EMI).

Key to its argument is the language of MCLA 440.4702(3)(i) italicized and bolded above. Comerica argues that it offered EMI the ability to require up to two users to confirm every wire transfer payment order made by an EMI employee (the evidence for this offer is an affidavit from a Comerica VP indicating that she told EMI’s online account administrator about this security option). Following the relevant language in MCLA 440.4702(3), Comerica argues that EMI was offered this security option, but refused it, and therefore the two-factor authentication that EMI used is automatically “deemed” commercially reasonable.

• Comerica followed the security procedure EMI agreed to use and acted in good faith

Comerica argues that there is no evidence suggesting that it failed to follow its security procedures consistent with MCLA 440.4702(3)(ii), and it maintains that it acted in good faith accepting the fraudulent payment orders. Specifically, Comerica indicates it followed the two-factor authentic procedure that had been established. It also uses this argument to support its position that it acted in good faith. In addition, Comerica points to the assistance it provided EMI in recovering a large portion of the transferred funds as evidence of its good faith.

• EMI admitted it was the source of the security breach

Comerica also argues that EMI was responsible for keeping passwords and PINs confidential, and that its actions resulted in the breach when it provided the information to the phishing attacker. To support this argument, Comerica sites a comment to UCC section 4A-203 which states:

The burden on the customer is to supervise its employees to assure compliance with the security procedure and to safeguard confidential security information and access to transmitting facilities so the security procedure cannot be breached.

EMI’s Response to Comerica’s Motion for Summary Judgment

EMI sets forth several arguments as to why it believes that summary judgment is unwarranted. As a reminder, the general rule is that motion for summary judgments should be granted only if there is no genuine issue as to any material fact (such that judgment is appropriate as a matter of law). Focusing on MCLA 440.4702(2) and the definition of “security procedure” under MCLA 440.4701, EMI sets forth four arguments contending that genuine issues of material fact do exist (making summary judgment inappropriate).

• EMI never agreed to the RSA Token security procedures, therefore they are not “security procedures” as defined under MCLA 440.4701

MCLA 440.4702(2) only applies to “security procedures” as defined under MCLA 440.4701. EMI contends that it never agreed to the RSA token security procedures, and therefore MCLA 440.4702(2) is not applicable.

This argument rests on the allegation by EMI that Comerica switched wire transfer services, and EMI never agreed to the security procedures for the new services. EMI argues that it had entered into an agreement for NetVision Wire Transfer Services in November 2003. As mentioned in Comerica’s MSJ, EMI signed the agreement for NetVision services that included a specific agreement by EMI that Comerica was using commercially reasonable security. The authentication security for NetVision was a “digital certificate” process.

However, in May 2008 Comerica apparently changed to “TMC Web wire transfer services,” which used the RSA token security. EMI contends that it never entered into a written agreement for the new TMC Web services, never agreed to the RSA token security, and never agreed that such security was commercially reasonable. EMI also argues that it was not a signatory to various other documents referenced by Comerica, including an online banking user guide and Comerica’s Treasury Management Services Master Agreement (both of which provided more information concerning Comerica's security procedures).

Finally, EMI disputes Comerica’s contention that EMI’s use of wire transfer services constitutes acceptance of the RSA token security procedures. According to EMI, it actually never sent a wire transfer using the TMC Web wire service that utilized the RSA token security, and therefore it never accepted this security procedure. Since the RSA token security was never “agreed to” by EMI, it contends that MCLA 440.4702(2) does not apply or shift the risk of loss to EMI, and that Comerica is responsible.

• Genuine issues of material fact exist as to whether Comerica’s RSA token security was “commercially reasonable”

EMI disputes Comerica’s contention that the RSA token security should be deemed reasonable under MCLA 440.4702(3). As summarized above, under that section if a customer refuses a security procedure that was commercially reasonable, but the customer agrees to another security procedure, the latter procedure is deemed commercially reasonable. This is basically a timing argument supported by dueling affidavits.

EMI claims that, at the time the TMC Web wire service was initiated, it was never advised that it could require approval from two authorized users prior to wire transfer, nor did Comerica offer additional security procedure options in connection with TMC Web services. This argument also rests on the prior EMI argument that it never entered into an agreement concerning the security of the TMC Web wire services in the first instance.

EMI then takes on the substance of "commercially reasonable security" using expert witness testimony. EMI’s expert contends that secure token technology was known to be lacking in any reasonable defense to a “man-in-the-middle” phishing attack. EMI’s expert opines that secure token technology has been unacceptable for banking logins since 2003. EMI’s expert also argues that Comerica’s particular implementation of this security was flawed based on prior practices of Comerica. In particular, with respect to the Netvision wire services that predated the TMC web wire services, Comerica allegedly regularly sent EMI unsolicited emails that lead to links requesting confidential login information. Essentially Comerica's prior practice caused EMI personnel to be off guard when the phishing attack came in.

EMI also takes issues with the warnings that Comerica sent out concerning phishing attacks. It points to Comerica’s April 28, 2008 communication in which Comerica indicated that it would never ask for confidential information in an email. EMI contends that the very next day it received an email from Comerica asking EMI to provide confidential login information.

Finally, EMI argues that the RSA token based security used by Comerica was not commercially reasonable because Comerica did not also implement security protection related to transaction verification and verifying wire transfers initiated after the initial login. In other words, EMI contends that an online banking system that allows unfettered wire transfers after a single successful login is not commercially reasonable. Had the token generated PIN been required for each wire transfer (e.g. the RSA token generates a new random number every sixty seconds), then the bad guys would have been stopped after the first fraudulent wire transfer (instead of being able to do 93 separate wire transfers for a total of $1.9 million).

• Genuine issues of material fact exist as to whether Comerica accepted payment orders in good faith and in compliance with the security procedures

EMI first argues that Comerica failed to accept the payment orders in good faith because it allowed 47 wire transfers to happen within a few hours even though EMI had only made two wire transfers in the prior two years. Moreover, EMI argues that Comerica’s lack of good faith is evidenced because it allowed 46 wire transfers to go through after EMI notified Comerica that EMI had not initiated the transfers. EMI also maintains that the failure to implement a simple fraud scoring system or fraud monitoring program to stop these types of wire transfers was evidence of a lack of good faith.

Comerica’s Reply to EMI’s Response

Comerica also filed a reply brief to address the arguments set forth in EMI’s response to the MSJ. This section summarizes Comerica’s arguments.

• The NetVision and TM Connect Web wire services were the same service governed by the 2003 NetVision contract

Comerica attempts to nullify EMI’s argument that it never entered into an agreement for security procedures related to TM Connect Web wire services. It contends that NetVision and TM Connect are the same systems. Comerica argues it simply changed the name of its online banking system. Comerica argues that the “Services” governed by the 2003 NetVision contract were the same and that all of EMI’s online transactions were subject to that contract. Comerica notes that the NetVision contract incorporates Comerica’s Treasury Management Services Master Agreement and a related user guide which Comerica uses to buttress its MSJ.

The NetVision contract also allows Comerica to update its security procedures, and indicates that after notice is provided by Comerica to EMI, EMI’s use of the services constitutes acceptance of the new security procedure. While EMI did not use wire transfer services until after NetVision changed its name to TM Connect Web, it had received wires from outside parties. Comerica contends that EMI’s continued receipt of wire transfers it its account constitutes use of the services and acceptance of the RSA token based security procedures for outgoing wire transfers. Of course EMI's acceptance is crucial if Comerica wants to rely on the risk-transfer mechanism set forth in MCLA 440.4702(2).

• Under MCLA 440.4702(3) the issue of the “commercial reasonableness” of a security procedure is a question of law, not fact

On this issue, Comerica points to the explicit language of MCLA 440.4702(3) which indicates that “commercial reasonableness of a security procedure is a question of law.” As such the court can decide that issue on a motion for summary judgment. Comerica contends that EMI acknowledged that Comerica’s security procedures were commercially reasonable in the NetVision agreement, making appropriate summary judgment in Comerica's favor.

• Comerica followed its procedures and acted in good faith

Comerica contends that it followed the procedures in place for online banking and denies that other procedures, such as requiring the initiation of wire transfers by phone call, were relevant. It attempts to counter EMI’s arguments concerning good faith by noting that it was not physically possible to stop some of the wire transfers after EMI informed Comerica that those transfers were not authorized. Moreover, Comerica argues that when it was able to stop or recall wire transfers it did so despite not being bound to do so, and ultimately decreased the loss from $1.9 million to $560,000.

Finally Comerica addressed EMI arguments concerning prior Comerica requests for confidential information via email. It argues that those emails did not send the user back to a Comerica website, but rather to a website hosted by their security vendor, Verisign. Secondly, the information that was requested was not online banking login credentials, but rather an ID/PIN sent each year for the sole purpose of renewing EMI’s digital certificate. As such, Comerica’s warning that it would never ask for online banking credentials via email was not untrue as EMI suggested.

Conclusion

These cases always get interesting when a little discovery ensues and the litigants begin digging into the relevant documents and contracts. As you can see, there is a lot going on here that has little do with actual security, and more to do with procedural issues around security acceptance, contracting and the UCC. Nonetheless, on some level the issue of commercially reasonable security will have to be addressed (either by the court on this motion for summary judgment) or later in proceedings by the ultimate trier of fact.

What can be gathered from this case and this MSJ is the importance of contracts in this context, and apparently the importance of contract timing issues and clear indications of “accepting” security procedures related to online banking. While there is a paper trail here with some favorable contract language, the record does look muddied, and this can make it more difficult to win at this stage of litigation.  Had the bank thought it through in more detail it probably could have created a more solid record to back its arguments. For instance, while contracts incorporating other documents that are constantly changing may be efficient, they may lack the same degree of acceptance as compared to requiring a new contract or other document certifying acceptance. Based on the dueling arguments, it is difficult to determine exactly where the court will come down on this motion for summary judgment. I believe that oral arguments are scheduled and thereafter we will get a written opinion from the court. Until then, have fun breaking these documents down and feel free to ask any questions you may have in the comments.

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.

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

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.

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.

The parenthetical in the title of this blogpost may seem counter-intuitive perhaps, but it appears that this controversy and the pleadings that have been filed paint a picture of what can potentially go wrong when proper cyber or technology errors and omissions coverage is not in place. It will be interesting to see how this case shakes out (and I make no predictions on what will happen because I lack too much information to analyze the issue), but I guarantee that the players involved are probably wishing they purchased explicit cyber or technology errors and omissions coverage (again, it appears that they may not have, but I don’t have all the information to state that definitively). Instead, they will have to litigate with no guarantees of success (and large hurdles for the University). Ironically, the University may ultimately recover from insurance proceeds, but those proceeds may come from the insurer that provides errors and omissions coverage to Perpetual Storage's insurance broker.**

The following background allegations were taken from the original compliant and the University’s complaint.

It appears that Perpetual Storage contracted with the University to provide data storage services. In June 2008, back-up tapes containing personal information of 1.7 million patients were stolen from a Perpetual Storage employee’s car. 1.1 million of the records included social security numbers. This employee allegedly parked his car while working at a second job, and later in his driveway at home overnight. The tapes were allegedly taken in the middle of the night approximately 8 to 12 hours after they had been picked up.

In response to this incident, as of May 25, 2010 the University had incurred about $3.35 million in costs broken down as follows: $2,483,057 related to credit monitoring expenses (one year for each impacted individual whose social security number had been exposed); $646,149 related to printing and mailing costs for notice to each of the 1.7 million impacted individuals; $81,389 related to phone bank costs (to field more than 11,000 phone calls); and an additional $144,158 in miscellaneous costs. In addition, the University allegedly expended 6,232 personnel hours responding to and mitigating the security breach (and it seeks compensation for that lost time as well).

Colorado Casualty appears to have issued two insurance policies to Perpetual Storage, one described as a “commercial package policy” and the other a “commercial liability umbrella policy.” None of the pleadings mention Perpetual Storage or the University having purchased cyber coverage (i.e. data security or privacy coverage) or errors or omissions coverage.

Procedurally, there is a fair amount going on with this case, including a motion to dismiss by Perpetual Motion. Most relevant, however is the University’s activity. It filed an answer and several claims against various players. First, it filed against Colorado Casualty and attempts to assert that coverage is available. It also filed against Perpetual Storage directly for its acts and errors, including allegations that Perpetual breached its contract with the University. Finally, it filed a claim against Perpetual Storage’s insurance broker, United Insurance Services, alleging that United failed to procure the insurance coverage needed by Perpetual.

Observations

This case is interesting for many reasons, some of them outlined below.

Do not rely on a commercial general liability policy or traditional property policy to get coverage for security or privacy breaches.

From experience, unless an endorsement was purchased, it would be unusual for a general commercial liability policy to provide first party coverage for breach notice costs (mailings, call center, credit monitoring) or professional liability coverage (coverage for liability due to an act, error or omission of a professional service provider like Perpetual). In fact, there are several cases that have found that commercial general liability policies and property policies do not cover certain data security and privacy risks. Of course, there may be arguments in favor of coverage under certain general commercial policies or property policies, but it may not be clear cut and it may require expensive litigation to obtain that coverage. It is also possible that these policies had endorsements providing more than the traditional coverage (and ultimately the specific wording is what will matter; for purposes of this blogpost I am assuming that the language is fairly similar to traditional policies I have worked with).

The moral of this story is that there is insurance out there, provided by many carriers (and more and more are providing it) that is specifically intended to provide coverage for information security and privacy breaches and technology professional liability. This insurance is specifically designed to provide coverage for damages and defense costs arising out of a data security breach or an act, error or omission in the rendering of professional technology services (like data storage services). Moreover, coverage now exists for direct costs incurred by an insured to provide notice to individuals in the event of a security breach, as well as expenses to set up a call center and provide credit monitoring. Having purchased coverage for this specific purpose, companies can have a much much higher level of certainty that the type of data breach described in this case will be covered.

Insure your own company directly.

The University in this case does not appear to have its own cyber insurance coverage (if they did, I am assuming they would have tendered their expenses to their own carrier and this controversy would most likely not exist). Instead they are making the difficult argument that they should be the beneficiaries of insurance purchased by their service provider. All of this could have been avoided if the University had purchased a cyber policy directly insuring the University.

Most cyber insurance companies provide coverage for “breach notice costs,” including mailing costs, credit monitoring and call center expenses. In addition, most cyber policies provide coverage if the security breach happens to one of the insured’s service providers. That coverage would have addressed the vast majority of the expenses incurred by the University (most cyber policies, however, probably would not provide any coverage for the personnel hours expended internally to address the breach). The moral of this story is if you are an organization that handles a lot of personal information (or other sensitive information), regardless of how secure you think you are (and by now everybody knows that there is no such thing as perfect security; breaches are a matter of when and how bad at this point), you should seriously consider cyber insurance in your risk management mix.

Brokers beware.

It looks as if the University is exercising all its options to try to get reimbursed for the expenses it incurred to address this security breach – it even sued Perpetual Storage’s insurance broker. However, considering there is no direct contract between the University and that broker it may be difficult to recover. Rather, Perpetual Storage is likely in a better position to sue its own broker for breach of contract and/or negligence.

Nonetheless, there is also a moral here for brokers. Here is the reality in 2010: most companies of all shapes, sizes and wealth profiles use information technology and handle sensitive information including personal information and credit card numbers. That means they face potential direct losses due to a data breach (the biggest risk being having to provide notice under breach notice laws and provide credit monitoring/call centers). It also means that most organizations face potential lawsuits and liability arising out of data security and privacy breaches (e.g. consumer lawsuits, employee lawsuits, lawsuits by banks if credit cards are lost, and regulatory actions). 

As such, brokers should be aware of the data security and privacy risk their clients face, understand where and how that risk might be covered.  Where appropriate brokers should approach the market to obtain cyber insurance for their customers.  Unfortunately, cyber policies (due to their technological nature) are often very complex and brokers dealing with general liability insurance may not have the training or expertise to understand where cyber insurance fits in and how it provides coverage.  This problem needs to be overcome or we will see a lot more lawsuits against brokers after security breaches.

Last point to make, assuming the University does not have its own policy, I am wondering whether (or when) the University decides to name its own insurance broker as a defendant.  I suppose it will depend on whether that broker raised the issue of cyber insurance, and whether the University turned it down or was unable to obtain coverage.

Conclusion

The bottom line is that practically every company in our modern economy has information security and privacy risk. There is no way to completely eliminate it (and it is not cost-effective in most cases to even try). That leaves residual risk that can either be internalized (like the University did) or transferred. Companies that want to transfer that risk would be well-served to get piece of mind and relative predictability by purchasing a cyber policy actually designed to address the risk. Relying on a general liability or property policy to provide the coverage is no longer a wise choice (if it ever was). Of course this does not mean that cyber insurance is the proper decision for every company, cost is always a factor. Nonetheless, with dozens of carriers now offering the coverage on some level competition is fierce both on price and coverage scope, so now is the right time to explore the market.

Final note, many of my observations and much of my analysis above is based on assumptions I am making concerning the nature of the policy and the facts of this case.  Depending on what is in that policy, and what really happened in this matter, some of my predictions could be off or not applicable.  If the policies are filed in court, we will revisit this matter and dig a little deeper.

**DISCLOSURE: I have several cyber insurance company clients and have assisted with drafting some of the top-selling forms in the marketplace; independent of those relationships, however, I am a huge proponent of risk transfer when it comes to security, privacy and technology risk, and believe that no data security and privacy risk management process is complete without considering cyber insurance.

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.

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.
 

This multi-part blog series looks at the terms of the Google contract and the corresponding CSC contract, including how the contracts work and the concessions Google and CSC made.  Part one of this series focuses on the information security, privacy and confidentiality obligations Google and CSC agreed to. Subsequent parts will review contract provisions related to due diligence, auditing and enforcement, incident response, compliance with privacy and security legal obligations, termination rights, and risk of loss terms (e.g. limits of liability, consequential damages disclaimers, indemnification).   Hopefully this post will prove useful for those entering into the Cloud and negotiating contract terms.

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

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

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

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

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

• unlimited damages for a data breach

• provisions allowing audits

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

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

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

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

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

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

Analysis of the Contracts

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

Security Control Requirements

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

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

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

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

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

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

Confidentiality/Data Privacy Obligations

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

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

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

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

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

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

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

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

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

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

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

All data and information provided by End Users via the sign up process for the Services, as well as data, including email, documents, spreadsheets, presentations, and videos, provided, generated, transmitted or displayed via the Services by Customer, or Reseller on behalf of Customer.

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

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

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

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

Conclusion

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

It will be interesting to see whether the Alberta law ushers in the passage of additional provincial laws similar to way California's SB 1386 lead to breach notice laws in over forty U.S. states. There appear to be several breach notice initiatives at the provincial and federal level in Canada, some of which may be on the verge of passing. If a wave of breach notice laws do pass throughout Canada, it will be interesting to see if it will have the same impact as in the United States (e.g. frequent reporting of breaches, lawsuits, etc.). It will also be interesting to see whether the Canadian approach differs from the U.S. approach.

This blog post breaks down Alberta’s breach notice provisions in a “Frequently Asked Questions” format, and includes commentary and comparisons to existing U.S. law.  Note that the Act also now includes obligations concerning collecting and transferring of personal information outside of Canada.  That is also discussed briefly in this blog post.

First, before diving into the FAQ on the breach notice provisions of Bill 54, let’s take a quick look an amendment in Bill 54 that addresses the use of service providers outside of Canada for purposes of collecting or transferring personal information. Bill 54 added the following provision to the Act:

13.1(1) Subject to the regulations, an organization that uses a service provider outside Canada to collect personal information about an individual for or on behalf of the organization with the consent of the individual must notify the individual in accordance with subsection (3).

(2) Subject to the regulations, an organization that, directly or indirectly, transfers to a service provider outside Canada personal information about an individual that was collected with the individual’s consent must notify the individual in accordance with subsection (3).

(3) An organization referred to in subsection (1) or (2) must, before or at the time of collecting or transferring the information, notify the individual in writing or orally of (a) the way in which the individual may obtain access to written information about the organization’s policies and practices with respect to service providers outside Canada, and (b) the name or position name or title of a person who is able to answer on behalf of the organization the individual’s questions about the collection, use, disclosure or storage of personal information by service providers outside Canada for or on behalf of the organization.

While this provision does not require an individual’s consent to use a service provider outside of Canada, it does require certain notice of certain information to the individual prior to collecting or transferring personal information to such service providers. This specific information referenced in the Act can probably be put into an organization’s privacy policy. However, for organizations that have existing  non-Canadian service provider relationships, a process must be put in place to provide notice to individuals. This provision may also have implications with respect to Cloud computing. Some organizations in Canada using the Cloud may not know whether personal information is being transferred outside of the United States. As such, these organizations may have to examine their existing service provider relationships, including identifying subcontractors outside of Canada that service providers may be using.

FAQ on the Personal Information Protection Act’s Breach Notice Obligations.

What breach notification obligations are set forth in Alberta’s breach notice law?

There are actually two potential notification obligations in Alberta’s breach notice law. The primary obligation requires organizations to provide notice to Alberta’s Information and Privacy Commissioner (the “Commissioner”):

34.1(1) An organization having personal information under its control must, without unreasonable delay, provide notice to the Commissioner of any incident involving the loss of or unauthorized access to or disclosure of the personal information where a reasonable person would consider that there exists a real risk of significant harm to an individual as a result of the loss or unauthorized access or disclosure.

(emphasis supplied). In addition, organizations that suffer a breach may also have to provide notice to the impacted individuals:

37.1(1) Where an organization suffers a loss of or unauthorized access to or disclosure of personal information that the organization is required to provide notice of under section 34.1, the Commissioner may require the organization to notify individuals to whom there is a real risk of significant harm as a result of the loss or unauthorized access or disclosure (a) in a form and manner prescribed by the regulations, and (b) within a time period determined by the Commissioner.

(emphasis supplied). Two points jump out based on these duties. First, it appears that any notice obligation for individuals applies only to those individuals as to whom there is a “real risk of significant harm.” So with respect to a particular breach, this may involve only a subset of those individuals whose personal information was subject to loss or unauthorized access. Second, even if a real risk of significant harm does exist, there is no automatic mandatory reporting obligation to the impacted individuals. Rather, there is only a reporting obligation if the Commissioner requires reporting. At the end of the day however, depending on the regulations and procedures created by the Commissioner, this notification obligation may effectively become “mandatory.” In fact, subsection 37.1(3) requires the Commissioner to establish an “expedited process” for determining whether to require notification where the harm to the individual is “obvious and immediate.”

Differences against U.S. State breach notice laws:

• Regulator Involvement. The obvious difference between Alberta and most U.S. breach notice laws is that the primary notification obligation is to the regulators. In the U.S. the breach notice laws require notification to the impacted individuals, and some also require concurrent notification to the state regulators (e.g. state attorneys general). In addition, the U.S. breach notice laws typically do not give the regulators discretion as to whether to require notice to individuals.

• Harm Threshold. Like some state breach notice laws, Alberta’s law has a “harm” threshold built into it. While no U.S. breach notice law uses the “real risk of significant harm” terminology, some states do require a material risk of harm,  a material compromise, a material risk of identity theft, or similar. While it is difficult to compare harm standards, and more research would be necessary to get a clearer picture, it appears that the real risk of significant harm threshold is relatively high. The term does not appear to be defined in the Act itself, but perhaps the Commissioner will get an opportunity to clarify its meaning as it develops regulations and processes for managing the notifications it receives.

What kind of information does the Alberta breach notice law apply to?

It applies to “personal information”, which is defined as follows:

“personal information” means information about an identifiable individual.

Differences against U.S. State breach notice laws:

• No residency requirement.  Unlike U.S. state laws, the residency of the individual does not matter. Personal information could relate to any individual whether a resident of Alberta or not. This could serve to limit the Commissioner’s jurisdiction to some degree. In the U.S. states, a state breach notice law could apply to a company with little to no “presence” in that state simply if they held personal information of a resident. Under Alberta’s law, there may need to be more traditional “doing business” jurisdiction for this law to apply. However, this jurisdictional issue is outside of the scope of this article (Michael Power, please weigh in if you would like/have the time).

• Less precise definition than U.S. breach notice laws.  In U.S. breach notice laws the definition of “personal information” or “personally identifiable information” is more precise: typically requiring first name/first initial and last name, in combination with some kind of a account number. The concept of “identifiable individual” is arguably a broader concept than PI or PII in the United States, and therefore there may be instances of reporting required under Alberta’s law that may not be required under U.S. law (on the argument that PI or PII was not at issue as defined under the U.S. breach notice law[s]).

How is a “security breach” defined that would trigger Alberta's breach notice law?

There is no formal definition for “security breach” or “breach of the security of the system.” Nonetheless, a security breach trigger is described in Alberta law as follows: “any incident involving the loss of or unauthorized access to or disclosure of the personal information.” However, a breach by itself does not trigger a reporting obligation unless “there [also] exists a real risk of significant harm to an individual.”

Differences against U.S. State breach notice laws:

• Actual Loss/Unauthorized Access/Disclosure. Under Alberta's law it appears that there must be an actual loss or unauthorized access to or disclosure of the personal information to activate the trigger. Many U.S. breach notice laws are triggered if there is a reasonable belief or suspicion of unauthorized access or acquisition. As anybody knows who has handled a breach, it is not entirely clear in some cases whether actual unauthorized access occurred (often there is circumstantial or tangential evidence of unauthorized access). If construed in this matter, the Alberta law may result in some breaches not being reported.

• Alberta's Loss Trigger.  Second, the Alberta law includes “loss” as a trigger. The classic example is a lost laptop. Under many/most U.S. statutes, loss of personal information is not a explicit trigger. Depending on the circumstances, under U.S. state breach notice laws, some organizations may argue that a lost laptop with personal information does not amount to a reasonable belief of unauthorized access. Alberta’s law takes that argument away (however, the harm threshold must still be met).

What is the risk of harm threshold under Alberta’s breach notice law, and how does it operate in terms of the individuals who must be notified?

As discussed above the risk of harm threshold for notification is a “real risk of significant harm.” This harm threshold appears to apply in two different ways under the Alberta law. Under section 34.1 if there is a security breach where a reasonable person would consider that there exists a real risk of significant harm to an individual, the organization must report to the Commissioner. Notice of the entire security incident to the Commissioner is required if a real risk of significant harm exists for a single individual impacted by the incident.

However, under section 37.1, notification is required only to those individuals to whom there is a real risk of significant harm as a result of the loss or unauthorized access or disclosure. This standard takes out the “reasonable person” test and appears to require actual an actual risk of harm. Moreover, notice is only required to those individuals as to whom a real risk of harm exists. So, if the organization reports a breach involving 1 million people and one may have reasonable suffered significant harm, it must report the entire breach to the Commissioner. However, it appears that the only individual that the organization must provide notice to is the individual as to whom an actual real risk of significant harm exists.

What notification obligations does an organization have if its service provider suffers a breach involving personal information?

The Alberta law applies to an organization that has personal information “under its control.” On its face, this control standard appears ambiguous when a service provider breach has occurred. If personal information is stored offsite on a service provider’s computer, but is accessible to an organization, is it under the “control” of the organization or the service provider (or both)? Unlike U.S. breach notice laws, Alberta’s law does not distinguish between the “owner” or “licensee” of personal information and the “service provider” (whose typical breach notice obligation under U.S. laws is to report the breach to the owner/licensee). This of course begs the next question.

What notification obligations does a service provider have if it suffers a breach involving personal information of its customers?

This is the flip-side of the question posed above. Service providers may be hard pressed to argue that they were not in “control” of personal information provided by their customers, and therefore may have an independent duty to notify under the Commissioner and possibly the impacted data subjects. Again, this is less clear than U.S. laws that only require service providers to report the breaches to their customers (a.k.a data owners/licensees;  although some have argued that ambiguity exists as to the meaning of data "licensee" under U.S. laws).

Under Alberta’s breach notice law, do the notification obligations apply to personal information that is encrypted?

Unlike most U.S. laws there is no specific reference to encryption under Alberta’s breach notice law, and therefore no explicit encryption safe harbor. However, practically speaking, the definitions and triggers in Alberta’s law may preclude notice obligations with respect to encrypted personal information. For example, organizations may argue that, with respect to encrypted personal information, a reasonable person would NOT consider that there exists a real risk of significant harm to an individual whose personal information was lost or subject to unauthorized access.

Conclusion

Alberta's breach notice provisions are very interesting, especially when compared and contrasted against the approach of U.S. states.  It will be even more interesting to see if Alberta's law becomes the model for other provinces, and whether it will have a similar impact on Canadian organizations as it did in the United States.
 

The era of legal defensibility is upon us. The legal risk associated with information security is significant and will only increase over time. Security professionals will have to defend their security decisions in a foreign realm: the legal world. This article discusses implementing security that is both secure and legally defensible, which is key for managing information security legal risk.

So, what does "legal defensibility" mean in the security context? 

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.

Employing a legal defensibility strategy goes beyond superficial "checklist-oriented" compliance and recognizes that ambiguities exist in the law, that if not properly addressed could adversely impact a company.  It recognizes the need for a close working relationship between legal and security that allows both roles to understand how the other operates.  It requires changing the security team's frame of reference slightly so enable them to understand how their decisions will be scrutinized in a legal realm.  Under a legal defensibility model, security decisions become legal positions to address issues like "reasonable security," risk and compliance with specific regulatory mandates. 

Even the communication mode is altered -- best practice is to establish attorney-client privilege to attempt to shield the "sausage making" (and related paper trail) that sometimes goes into developing a security program.  Documentation of decisions and rationales for decisions become important to create a historical artifact to be unearthed in the event of legal action.  This documentation will allow the organization to justify its processes and put itself in the best light in front of a legal decision maker.

For legally defensible security a key consideration is the process for making security decisions.  A an established decision-making process that takes into account accepted and relevant security standards, risk management and legal requirements is better than an ad hoc approach.  It provides for consistency across an organization and over time,  provides a basis for courts to analyze the adequacy of a company's security program, and is easier to defend if reasonable and followed.  Coupled with documentation, having a well-conceived and consistent process can assist an organization's position in a legal context and reduce risk.

Final thoughts.  As legal risk increases a legal defensibility approach will become more important and eventually commonplace.  Our data driven society, and the legal risks arising out of it, dictate that we work together.  Now is the time for legal, privacy and security professionals to break down arbitrary and antiquated walls that separate their professions.  The distinctions between security, privacy and compliance are becoming so blurred as to ultimately be meaningless.  Like it or not, it all must be dealt with holistically, at the same time, and with expertise from multiple fronts.  In this regard we must all develop thick skins and be not afraid to stop zealously guarding turf.  The reality is, the legal and security worlds have collided, and most lawyers don't know enough about security, and most security professionals don't know enough about the law.  Let's change that.  With the era of legal defensibility upon us, it is past time that this conversation went to the next level.  So please take a look at my article.   I sincerely look forward to your comments and constructive criticism on my thoughts. 

• 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.

• Last week the U.S. Commerce Department launched an initiative to examine how the privacy of individuals is impacted in the Internet economy, with the goal of producing a report in the early fall and advising the White House. The Commerce Department is seeking public comment from the commercial sector, the academic world, all other organizations with interest in the issue, as well as individual citizens with views on the current privacy laws in the U.S. and around the world as they apply and influence the information economy.

• The headline says it all:  Apple iPhone Leak: Crime, Marketing Ploy or First Amendment Issue?

• Kroll has released its 2010 HIMSS Analytics Report: Security of Patient Data (registration required to obtain a copy of the report)

• Sen. Chuck Schumer and other Senators are not happy about Facebook's "instant personalization" functionality.  They think "opt-in" is more appropriate in this context.

However, interesting from a legal and business point of view is the apparent importance of Google's contract terms in the City's decision to choose Google's Cloud over Microsoft's Office.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Conclusion

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

UPDATE:  Note, this law only applies to governmental entities, or other orgnizations "supported wholly or principally by public funds."   The version we previously linked to was an older version of the Virginia House's bill and had a broader definition of "entity."

"Entity" means any authority, board, bureau, commission, district or agency of the Commonwealth or of any political subdivision of the Commonwealth, including cities, towns and counties, municipal councils, governing bodies of counties, school boards and planning commissions; boards of visitors of public institutions of higher education; and other organizations, corporations, or agencies in the Commonwealth supported wholly or principally by public funds.

"Medical information" means the first name or first initial and last name in combination with and linked to any one or more of the following data elements that relate to a resident of the Commonwealth, when the data elements are neither encrypted nor redacted:

1. Any information regarding an individual's medical history, mental or physical condition, or medical treatment or diagnosis by a health care professional; or

2. An individual's health insurance policy number or subscriber identification number, any unique identifier used by a health insurer to identify the individual, or any information in an individual's application and claims history, including any appeals records.

The term does not include information that is lawfully obtained from publicly available information, or from federal, state, or local government records lawfully made available to the general public."Breach of the security of the system" means unauthorized access and acquisition of unencrypted and unredacted computerized data that compromises the security, confidentiality, or integrity of medical information maintained by an individual or entity. Good faith acquisition of medical information by an employee or agent of an individual or entity for the purposes of the individual or entity is not a breach of the security of the system, provided that the medical information is not used for a purpose other than a lawful purpose of the individual or entity or subject to further unauthorized disclosure.

Breaches that trigger the notice obligations are defined as follows:

"Breach of the security of the system" means unauthorized access and acquisition of unencrypted and unredacted computerized data that compromises the security, confidentiality, or integrity of medical information maintained by an individual or entity. Good faith acquisition of medical information by an employee or agent of an individual or entity for the purposes of the individual or entity is not a breach of the security of the system, provided that the medical information is not used for a purpose other than a lawful purpose of the individual or entity or subject to further unauthorized disclosure.

Even if the data is encrypted, the law requires notice if the breach involved a person with access to the encryption key.  The law requires notice to affected individuals (residents of Virginia) as well as Virginia's Office of Attorney General.  The Attorney General can bring an action for violations of the law and impose civil penalties up to $150,000 per breach (or a series of similar breaches of a similar nature that are discovered in a single investigation).  The law does not apply to persons or entities that must report the breach under the HITech Act.

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).
 

The following quote cited by the court (from another case), is indicative of the court's reasoning:

[f]or plaintiff to suffer the injury and harm he alleges, many ‘if’s’ would have to come to pass. Assuming plaintiff’s allegation of security breach to be true, plaintiff alleges that he would be injured ‘if’ his personal information was compromised, and ‘if’ such information was obtained by an unauthorized third party, and ‘if’ his identity was stolen as a result, and ‘if’ the use of his stolen identity caused him harm. These multiple ‘if’s’ squarely place plaintiff’s claimed injury in the realm of the hypothetical. If a party were allowed to assert such remote and speculative claims to obtain federal court jurisdiction, the Supreme Court’s standing doctrine would be meaningless.

Note that the basis of this dismissal was not a "failure to state a claim" under 12(b)(6).  Rather this decision basically held that the plaintiffs could not even get a hearing in court on a 12(b)(6) motion because the court lacked subject matter jurisdiction to hear the case at all.  Also note that other courts have found standing for data breach cases, including the Seventh Circuit in Pisciotta.  However, those that have proceeded past the 12(b)(2) motion have often been dismissed under 12(b)(6).  In all, no matter how it happened, it appears that plaintiffs still have significant challenges moving consumer data breach cases further toward trial.

More commentary can be found here.

To understand the requirements of SB 227, it is important to first understand the interplay between the PCI obligations set forth in subsection 1. and the encryption requirements of subsection 2. Significantly, it appears that a data collector that complies with PCI (as required under subsection 1. of SB 227) need not comply with the personal information encryption requirements of subsection 2. This “either/or” dynamic creates a strange compliance situation.

Subsection 1. of SB 227 provides:

1. If a data collector doing business in this State accepts a payment card in connection with a sale of goods or services, the data collector shall comply with the current version of the Payment Card Industry (PCI) Data Security Standard, as adopted by the PCI Security Standards Council or its successor organization, with respect to those transactions, not later than the date for compliance set forth in the Payment Card Industry (PCI) Data Security Standard or by the PCI Security Standards Council or its successor organization.

Subsection 2. of SB 227 provides:

2. A data collector doing business in this State to whom subsection 1 does not apply shall not:

(a) Transfer any personal information through an electronic, nonvoice transmission other than a facsimile to a person outside of the secure system of the data collector unless the data collector uses encryption to ensure the security of electronic transmission; or

(b) Move any data storage device containing personal information beyond the logical or physical controls of the data collector or its data storage contractor unless the data collector uses encryption to ensure the security of the information.
(emphasis supplied).

The current version of PCI (v 1.2.1 – July 2009 ) references encryption with respect to certain cardholder related data while stored and in transit. Section 3.4. of PCI requires companies to render a payment card’s PAN’(“Primary Account Number’”) unreadable, including through the use of strong encryption. Compliance under section 3.4 is also possible through other measures, including truncation, index tokens and pads, and “compensating controls.” Section 4.1. of PCI mandates the use of strong encryption of “cardholder data” during transmission over open or public networks. Cardholder data as defined under PCI includes PAN, Cardholder Name, Service Code, and Expiration Date as defined with respect to PCI.

However, the definition of “personal information” under the Law is much broader than “PAN” or “cardholder data” under PCI. Personal information includes information that is wholly unrelated to credit cards, including social security numbers, driver’s license numbers, identification card numbers and bank account numbers. PCI does not require encryption of these elements while transmitted electronically. Moreover, PCI does not require any personal information to be encrypted while stored. Rather, it only requires that the PAN be encrypted in storage (and even here encryption is not an absolute requirement -- PCI allows for other methods to render PANs unreadable and allows for "compensating controls"). Finally, since the encryption that happens around PCI relates to payment processing only, it does not appear that PCI-compliant companies would have to address encryption in other contexts, including for example e-mails containing personal information.

In short, PCI compliance allows an entity to avoid the obligation to encrypt personal information (except for "Cardholder Data") on data storage devices or while in transit, as required under subsection 2. of SB 227, and would appear to undermine the broader purposes of the Law. Stated differently, companies that are already PCI compliant would appear to have diminished obligations when it comes to encrypting Personal Information than those companies that are not subject to PCI.

Issues Surrounding the Law’s PCI Compliance Obligations

Nevada is the first state to incorporate the entire PCI Standard into law. The PCI Standard is an industry standard contractually imposed by the payment card networks on merchants and service providers that store, process or transmit cardholder data. In essence, the Nevada legislature has ceded its legislative authority to a group of private companies whose interests and concerns in creating and updating the standard may not be aligned with the goals of the Law. It has given PCI the weight of law, backed by attorney general enforcement and potential statutory liability, despite the fact that PCI is typically imposed in a negotiated contractual setting. As such, tying PCI to the Law raises several interesting issues and poses additional challenges:

• PCI is always changing. One of the biggest problems with the PCI compliance requirement under SB 227 is that PCI is constantly being changed and updated. PCI is currently on version 1.2.1 (the fourth version in four years) and is currently soliciting comments concerning potential modifications in 2010. This makes the Law a moving target. On a certain level this makes sense – the PCI standard and good security evolves as the risks and technology changes. However, from a compliance standpoint constant vigilance is required to ensure compliance. Under the Nevada law this is especially true since non-compliance can result in an attorney general action.

• PCI is ambiguous. Unfortunately the PCI standard is ambiguous as written in many sections and as applied in many circumstances. This is due in part to the one-size-fits-all nature of the standard. The problem is exacerbated, however, because there are multiple sources of interpretation, including the PCI Council, merchant banks, the card brands and qualified security assessors. Even within the PCI Council itself multiple methods of interpretation exist, including guidelines, FAQs, prioritized approaches, and email answers provided by the PCI Council provided on an ad hoc basis. Moreover there is no set interpretative hierarchy between potentially competing interpretations. For example it is not clear whether PCI Council guidance document would trump an FAQ, or the interpretation of a merchant bank.

• PCI is contractual in nature. Typically a merchant will enter into a “merchant agreement” with a merchant bank or processor so it can accept credit cards. That merchant agreement will mandate that the merchant comply with PCI. If there is an ambiguity, since the merchant’s obligations are derived by contract, naturally the “best” source to resolve those ambiguities is with the merchant bank that is party to the agreement. If the merchant bank “gets it wrong” or agrees to a PCI interpretation that is not compliant, while it may have sufficed for the contractual relationship, under the Law it could result in a legal violation.

• PCI is one-size-fits-all. PCI is made up of over 200 individual requirements/sub-requirements. For small businesses it may be difficult, if not impossible, to comply with (from a resource standpoint). Yet the Law does not make any exception or allowance for this. As a result, on day one many businesses (especially smaller and medium companies) are likely to be non-compliant with the Nevada law.

• New independent and direct duty for service providers to comply with PCI? Typically, under the PCI regulatory scheme, service providers that store, handle or transmit cardholder only have a direct obligation to comply with PCI if they are contractually required to do so. They have no independent legal duty to comply with PCI under normal circumstances. SB 227, however, may provide a direct duty for service providers to comply with PCI. Service providers appear to fall into the definition of “data collectors” because they typically “handle, collects, disseminates or otherwise deals with nonpublic personal information.”  The issue becomes whether, under subsection 1. of SB 227, a service provider storing, processing or transmitting cardholder data for another “accepts a payment card in connection with a sale of goods or services.” If the language in subsection 1. read “accepts a payment card for a sale of its goods or services,” then it would appear to be limited to merchants. However, the “in connection” language arguably extends the duty to service providers. For example, some might argue that payment gateways directly “accept” payment card numbers from customers online on behalf of merchants in connection with the merchant’s sale of goods and services.

Issues Surrounding the Law’s Encryption Obligations

The Encryption Obligations: Electronic Transmission and Data Storage Devices.

If a data collector doing business in Nevada does not have an obligation under subsection 1., then it must comply with the encryption requirements of subsection 2. SB 227 requires encryption in two areas: personal information transmitted electronically (subsection 2.(a) of SB 227) and encryption of personal information stored on certain data storage devices (subsection 2.(b) of SB 227).

A data collector doing business in Nevada, subject to exceptions discussed below, may not transfer personal information outside of its secure systems through an electronic transmission, unless encrypted. Again, a drafting quirk may pose some interesting interpretations of this obligation. By using the term “secure system” (undefined), it appears that this encryption requirement does not apply to personal information transmitted from an “insecure system.” Note that the probable intent of the “secure system” language was to eliminate the need to encrypt personal information while in transit within the internal networks of an organization (or at least that is one interpretation).

Drafting mistakes aside, SB 227 sets forth some significant exceptions to this encryption requirement. The electronic transmission encryption requirement does not apply to:

• electronic voice transmissions or facsimile transmissions;

• telecommunication providers conveying communications of other people; or

• data transmissions over secure private communications channel for: (1) approval or processing of negotiable instruments, EFT transfers or similar payment methods; (2) issuance of reports regarding account closures due to fraud, substantial overdrafts; or (3) abuse of ATM machines or related information regarding a customer.

Data collectors must also encrypt data stored on a data storage device if the device goes beyond the logical or physical controls of the data collector or its data storage contractor. The concept of going beyond the physical controls (e.g. facilities of the data collector) is fairly clear. However, it is uncertain exactly what the intent is behind the “logical controls” reference. It could mean that if the data storage device is protected by the same “logical controls” as data storage devices that are part of the data collector’s internal networks, then encryption is not required.   Or it could be tying back into the concept of secure internal environments.  However, more research is necessary to ascertain how the “logical control” reference should be interpreted.

The Encryption Standard.

To comply with the Law, data collectors must use an encryption technology that renders such personal information indecipherable in the absence of associated cryptographic keys necessary to enable decryption of such data, which has been adopted by an established standards setting body, including for example, the Federal Information Process Standards published by the National Institute of Standards and Technology.

Encryption under the law also requires sound key management processes and safeguards. Specifically, data collectors must utilize appropriate management and safeguards with respect to cryptographic keys in order to protect the integrity of its encryption process. The data collector’s key management procedures and safeguards must be consistent with guidelines set forth by an established standards setting body, including for example, the National Institute of Standards and Technology.

While one might quibble with the requirement that the encryption technology render personal information indecipherable (all encryption is theoretically capable of being broken), the reference to FIPS and NIST standards provides solid guidance. However, the Law does not indicate what constitutes an “established standards setting bodies” in the event a data collector would like to use an encryption standard that is not based on FIPS or NIST.

The SB 227 Amendment’s “Safe Harbor”

While SB 227 arguably imposes significant encryption obligations on certain data collectors (at least those that are not already PCI-compliant), it also provides a “reward” for companies that meet its mandates. Subsection 3. of SB 227 provides a “safe harbor”:

3. A data collector shall not be liable for damages for a breach of the security of the system data if:
(a) The data collector is in compliance with this section; and
(b) The breach is not caused by the gross negligence or intentional misconduct of the data collector, its officers, employees or agents.

This “safe harbor” may provide significant protection to compliant companies that suffer a personal information breach, even beyond the Law itself. Some may argue that the safe harbor protects the organization from all damages no matter what context or theory of liability (e.g. common law negligence, contract, negligent misrepresentation, etc.). Support for this theory can be found where SB 227 references a very limited list of liabilities theories (“gross negligence and intentional misconduct”), which arguably implies that other theories of liability can be barred by the safe harbor. Moreover, since the Law itself does not explicitly provide any damage remedy against a data collector that suffers a security breach, it would appear to be referring to liability outside of the Law.

For example, assume the case of a merchant that suffered a payment card breach. It would typically have a contract in place whereby it agreed to indemnify its merchant bank in the event of a payment card breach. Under SB 227, as long as the merchant was PCI compliant at the time of the breach (and therefore compliant with subsection 1. of SB 227), it could argue that it should be immune from contractual liability. This is significant because there is no legal mechanism currently in place under PCI that provides this legal protection. Please note that this argument is far from settled and additional research and analysis is necessary in order to validate the intent of Nevada’s legislature.

Beyond its potential broad scope, the safe harbor language in SB 227 arguably creates some incongruities between SB 227 and the Law. For example, the Law requires data collectors to implement certain “reasonable” security measures around personal information, which typically include measures beyond encryption (e.g. background checks, firewalls, virus protection, security policies, etc.). However, the safe harbor applies to all security breaches as long as the data collector complied with SB 227, even if it implemented “unreasonable” (but not “grossly negligent”) security.

An illustration may assist here. Assume a data collector made a mistake in configuring its firewall, which allowed a hacker to steal one million unencrypted personal information records while in transit on the data collector’s internal systems. One might argue that this data collector violated the section of the Law requiring “reasonable security measures” by providing such access. Nonetheless, as long as the data collector complied with SB 227 by encrypting data in transit externally or in data storage devices taken off premises, and it was not grossly negligent, it appears it would not be liable for the security breach under the Law (and otherwise). In other words, with the safe harbor, the requirements of SB 227 could be argued to override more stringent requirements of the Law around security.

Conclusion

Nevada’s Security of Personal Information Law, including the SB 227 Amendment, may pose some challenges for organizations. Its scope is arguably wider than Nevada companies because it appears to apply to any business that stores or processes personal information of Nevada residents, even those without a physical presence in Nevada. It employs a one-size-fits all approach that requires either PCI compliance or encryption of data in transit or on data storage devices, regardless of feasibility, or the resources or sophistication of the company. Moreover, by incorporating the payment card industry’s data security standard directly into the law, it gives PCI “the force of law.” This may be problematic for several reasons, the least of which is that PCI is frequently amended and presents a “moving target,” and is often ambiguous as written and as applied.

However, in addition to the new obligations posed by SB 227, it may offer some benefits and protection to organizations. First, companies that are already PCI compliant do not need to go the extra step under SB 227 and encrypt personal information in transit or on data storage devices. This is true despite the fact that the encryption requirements of PCI are limited in scope. Second, SB 227 provides a safe harbor that arguably bars liability arising out personal information security breaches that were not intentional or grossly negligent. In all, it will be interesting how companies react to the Law, how it is enforced by regulators, used by litigants involved in security breach litigation, and interpreted by courts.