Info Law Group

Privacy's Trajectory

Tanya Forsheit — Sun, 14 Mar 2010 11:12:35 -0700

As many of our readers know, the International Association of Privacy Professionals (IAPP) will celebrate 10 years this Tuesday, March 16. In connection with that anniversary, the IAPP is releasing a whitepaper, "A Call For Agility: The Next-Generation Privacy Professional," tomorrow, March 15. Monday morning you can find the whitepaper here. I am honored that the IAPP has given me the opportunity to read and blog about the whitepaper in advance of its official release. Where exactly is privacy going in today's environment? What is the role of the privacy professional over the next 10 years? And, a lot of people I know and love (you know who you are) would ask, what in the world is a privacy professional anyway?

Of late, I have found myself reiterating, and getting a lot of positive feedback for, the following proposition: with data (massive amounts of it) as the new currency, the explosion in outsourcing to "trusted partners," and the growth of legal risks associated with an ever-expanding body of privacy and data security regulation, the role for professionals who understand privacy is becoming increasingly important. Further, such professionals are uniquely positioned to bring together various key stakeholders in an organization, including Information Security, Legal, IT, and various business units. Why? Because privacy professionals are, by virtue of what they do, multidisciplinary. And the growing opportunities for such professionals are inextricably intertwined with that quality. The IAPP has summed this up succinctly, and eloquently in its whitepaper, as follows:

The next 10 years will see more types of data collected from more people, and more privacy laws in more places. A deepening and broadening of data protection regulations in the industrialized world will spread to emerging markets and place a higher premium on legal and compliance acumen. In addition, an expansion of health information networks, smart grid networks and cloud computing platforms will make industry and technology expertise a more indispensable part of practicing privacy.

. . . the privacy professional’s success in the next decade will demand greater adaptability and most importantly, agility. The agile privacy professional is the next-generation privacy professional: an expert practitioner who is keenly attuned to cultural and regional distinctions as these continue to grow in an increasingly interconnected data economy; who can migrate and adapt to different roles within an organization and offer value at each; who exhibits both comfort and grasp of legal/compliance and technical disciplines; and who instills direction and leadership of privacy management within the organization.

The following analysis and discussion of the IAPP's whitepaper is completely my own. I think that the paper raises some incredibly important points about the need for privacy professionals to lead the way for more effective information governance. As an outside lawyer (with my own unique perspective), my key takeaway is the following -- privacy professionals must understand law AND technology, and must facilitate dialogue between those two disciplines and as between those disciplines, on the one hand, and the business side, on the other.

The importance of a "privacy professional" understanding both legal and technical disciplines cannot be overstated:

The central role of regulatory and IT drivers shaping the privacy profession almost ensures an ongoing need for privacy professionals to be conversant in not one, but both of these disciplines.

Regulation and "Reasonable Security"

I believe this is largely due to what the IAPP describes in the whitepaper as the "Second Wave of Regulation," which began in approximately 2003 with California's landmark data breach notification legislation, Civil Code section 1798.82 (for private entities), often called SB 1386. On the heels of that came 44 additional such state laws, DC, Puerto Rico, the Virgin Islands, and now some similar European legislation, as discussed in the whitepaper. And, with the light now shining on security risks and failures within private organizations, additional security standards and legislation began to emerge - most notably, as highlighted by the IAPP, the Payment Card Industry (PCI) Data Security Standard (DSS) and laws such as Nevada's (SB 227) that incorporate that Standard. For more on that, see Dave's posts here, here and here. Further, as noted in the whitepaper,

A number of factors have spurred North American (and particularly American) organizations to dedicate more resources to privacy process improvement: most notably, PCI DSS enforcement, FTC enforcement, and data breach notification.

Not discussed in the IAPP whitepaper in depth, but just as important, a number of states have crafted legislation designed to require "reasonable" security or safeguards to address security risks in a more proactive fashion, as opposed to the traditional reactive breach notification approach. Massachusetts, Massachusetts M.G.L. c. 93H and 201 CMR §§ 17.00-17.05, is of course the most recent, most detailed, and most well known, but many states require the same "reasonable security" (sometimes for all personal information, sometimes for just Social Security numbers), including, but not limited to, California (Civ. Code §§ 1798.81, 1798.81.5, and 1798.85), Arkansas (Code Ann. §4-110-104(b)), Colorado (Rev. Stat. Ann. §6-1-713), Connecticut (HB 5658), Maryland (Com. Law Code Ann. § 14-3503), Nevada, as mentioned above (Rev. Stat. § 603A.210 and SB 227), Oregon (Rev. Stat. § 646A.622), Rhode Island (Stat. § 11-49.2-2), Texas (Bus. & Com. Code Ann §§ 48.102(a) and 521.001, .052, .151) Utah (Code Ann. § 13-44-201), and Washington (Rev. Code Ann. §19.215.020 to .030). There are more, I could go on.

What in the world is "reasonable security"? A privacy professional who understands the law and traditional notions of negligence, various concepts of privacy (Fair Information Practice Principles, etc.) as embodied in different standards and legislation around the world (from EU to Australia), and the evolution of information security (as a technical matter) is ideally positioned to help assess what "reasonable security" means and determine what will be compliant, what will be legally defensible, what will be best practice, and what will be just good business. And such a privacy professional can facilitate discussions among stakeholders that speak somewhat different languages in this regard to reach solutions that are acceptable to all involved.

From Privacy to Information Governance

As a lawyer, I am also extraordinarily pleased to see, in the IAPP's whitepaper, a reference to the new ediscovery rules that came into play in the latter half of the 2000s, most notably the amendments to the Federal Rules of Civil Procedure in 2006. What does privacy have to do with ediscovery? Everything. As noted in the IAPP's whitepaper, the amended rules "increased the need for organizations to conduct data inventories and implement data-retention policies." How do you protect sensitive data (personally identifiable information, trade secrets, IP, etc.)? You figure out where it is first. And thus, as the IAPP points out, we start to see the "privacy" role evolve into an information governance role.

Speaking of information governance, let's return to technology. States the IAPP: cloud computing will set the pace for the next decade:

One of the clear directions of technology in the past 10 years as it pertains to personal data has been more—more types of data collected from more people in more ways, and shared with more entities. The emergence of cloud computing—essentially a new computing paradigm in which data is stored off-premises and by a range of third parties—sets the pace for the next decade. Short of a wholesale social movement to opt out of information technology and “go dark,” the conveniences and commercial benefits of more data collection and sharing seem to point in the direction of more. People will not 'go dark,' we estimate, because the utility of sharing information will continue to well exceed the risks of doing so.

Thus, the IAPP stresses the need for agility and identifies five strategies for action:

(1) Redefine the privacy role [information governance]; (2) Rotate through departments/business units; (3) Develop multi-cultural literacy; (4) Understand legal and technical disciplines; and, (5) Instill direction and leadership.

Bottom line? Proactive, multidisciplinary solutions to information governance that incorporate information technology savvy and that address compliance, legal defensibility, and best practices, are now and will become increasingly crucial to any organization that handles sensitive data. Privacy professionals are well positioned to lead those efforts. Congratulations to the IAPP on its 10th anniversary! I look forward to the next 10 years.

Quickhits: Federal Judge Dismiss Aetna Data Breach Case Due to Lack of "Injury-in-fact"

David Navetta — Fri, 12 Mar 2010 14:23:14 -0700

A Federal judge in the U.S. District Court for the Eastern District of Pennsylvania dismissed a class action lawsuit arising out of a data security breach involving Aetna, Inc. (original compliant found here). The basis of the dismissal was the plaintiff's lack of standing due to its failure to allege an "injury in fact" (the dismissal was under section 12(b)(1) of the Federal Rules of Civil Procedure). In particular the court held that the plaintiff's alleged injury in the form of an increased risk of identity theft is far too speculative based on the factual allegations.

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.

A Closer Look at the PCI Compliance and Encryption Requirements of Nevada's Security of Personal Information Law

David Navetta — Wed, 10 Mar 2010 10:51:35 -0700

Since approximately 2005, the state of Nevada has had a fairly comprehensive data privacy law on its books: the Nevada Security of Personal Information Law (the “Law”). Prior to 2009, the Law imposed various requirements concerning the protection of personal information of Nevada residents, including requirements concerning security breach notice, the implementation of reasonable security measures and the destruction of records containing personal information. In 2009, the Nevada legislature materially amended the law by passing Nevada Senate Bill 227 (“SB 227” or “SB 227 Amendment”). The SB 227 Amendment added two significant (but mutually exclusive) data security obligations: (1) a requirement to comply with the Payment Card Industry Data Security Standard (“PCI”); and (2) requirements to encrypt personal information in certain contexts. The SB 227 Amendment became effective on January 1, 2010. This article summarizes the requirements of the SB 227 Amendment, addresses various compliance issues posed by it, and discusses its “safe harbor.”

The Interplay Between the Law’s PCI Compliance and Encryption Obligations

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.

Thoughts from the RSA Conference

Tanya Forsheit — Wed, 03 Mar 2010 17:51:54 -0700

As the partners of InfoLawGroup make our way through the sensory overload of the RSA Conference this week, I am reminded (and feel guilty) that it has been a while since I posted here. I have good excuses - have simply been too busy with work - but after spending several days in the thought-provoking environment that is RSA, I had to break down and write something. A few observations, from a lawyer's perspective, based on some pervasive themes:

We all need to work together, and we can. Legal, Information Security, Privacy, Compliance, IT, and the affected business units. Now more than ever, it is essential that ALL the stakeholders join forces, as early as possible, to address security and privacy risks, assess and vet business deals, and put in place appropriate procedures - RFPs, due diligence, contract negotiation - to address the risks.
Cloud, cloud, cloud, yada, yada, yada. Hold up - the technology is not new - but usage and the business model have changed dramatically. I have been having this argument with my information security and technology friends for months. OK, I get it. "Cloud" technology in some form or another has been around for 30 or 40 years. What is new is the massive scale, availability and changes in usage and the business model - in part driven by the economics. Guess what? Those business model changes make the legal risks even more pervasive. Going back to (1) above, all of the stakeholders need to be in the room (or on the phone or videoconference) discussing the issues BEFORE the decision is made to enter into a cloud arrangement. ANY cloud arrangement. Not after the RFP is issued. Not after IS does its due diligence. Not after the contract negotiations have begun. And not after the contract is inked. The same due diligence and attention to risks that would apply in a traditional outsourcing/offshoring relationship must be applied here, too. The cost savings are illusory if the short-term and/or long-term risks are significant. Think about the kind of data at issue. What are the risks? Evidence preservation, data security, breach response, enforcement rights, indemnification. And before we even get to those - can the data be transferred across borders in the first place? Think about it early. And then talk about it before decisions are made.

More after the jump.

Privacy is the next frontier in Information Security. Wait, what? I have to admit that my initial reaction to this was - seriously? Privacy regulations have been here for some time. That's true, and the privacy profession has been growing for the last 10-15 years. But the privacy profession is in its infancy as compared to information security and IT. Why is the privacy profession growing? In part because the regulatory environment has exploded. But Information Security and Privacy care about the same thing -- data management and governance. We can help each other find creative solutions to mitigate risk.
The regulatory scheme is becoming more complex, at breakneck speed. What regulations do information security professionals and the businesses they serve need to understand and address? Many - international, federal, state, and local. And things are changing constantly. Just this week the Massachusetts data security regulations became effective. And last week the FTC filed its notice of appeal of the District Court's ruling that the FTC cannot apply the Red Flags Rule to attorneys.

Information Security and Privacy, together with Legal, should consider all potentially applicable laws in evaluating security risks. What are those laws? Well, depending on your industry, and where your customers and employees reside, a few, but not all, might include FTCA, GLBA, HIPAA (including the HITECH Act), state data security laws (such as the new Massachusetts data security regulations and Nevada's encryption and PCI law), Sarbanes-Oxley, Red Flags Rule, FACTA Disposal Rule, ECPA, E-Sign, FERPA, the Federal Rules of Civil Procedure and Evidence, the PATRIOT Act, PIPEDA, the EU Data Protection Directive, EU member country laws, other foreign laws across the globe, state breach notification laws, and Social Security number protection statutes. But there are many more. And that's not even getting into contractual standards such as PCI-DSS.
Lawyers need to embrace technology. I was fortunate enough to attend a CLE last week, pre-RSA, hosted by the Entertainment Law and Intellectual Property Section of the Los Angeles County Bar Association. Roland Trope, who moderated the panel on social networking issues, raised a tremendously important question: Are lawyers "competent" if they do not keep track of, and understand, changes in technology? The ABA is considering changes to the Model Rules of Professional Conduct to address this question. Some take the position that no changes are necessary and that the requirement can be read into the existing Rules. In any event, what better place than RSA to reflect on that question and the future of the legal profession and its relationship with technology.

That's it for now - back to work, and preparing for my next cloud presentation tomorrow. In the meantime, I encourage our readers - the lawyers, the information security professionals, and the privacy professionals - to weigh in.

The Curious Case of EMI v. Comerica: A Bellwether on the Issue of "Reasonable Security"?

David Navetta — Wed, 24 Feb 2010 16:39:00 -0700

Security breaches in the online banking world continue to yield interesting lawsuits (you can read about three others in this post). The latest online banking lawsuit filed by Experi-Metal Inc. (“EMI”) against Comerica (the “EMI Lawsuit”) provides some new wrinkles that could further illuminate the boundaries of “reasonable security” under the law. Brian Krebs has a good article summarizing the case. In addition, bankinfosecurity.com has a recent article on this matter (in which yours truly was quoted). In this post we take a look at the EMI Lawsuit, consider some legal questions that the case raises, and analyze how it might impact the question of what constitutes “reasonable security” under the law.

The Allegations

On a general level the EMI Lawsuit involves a basic fact pattern that is similar to several online banking security breach cases: criminals were able to obtain the login credentials of a bank’s business customer and wire transfer large sums of money from the customer’s account (in the EMI lawsuit approximately $560,000 was allegedly wired). Like other online banking cases, the bank in this case (Comerica) did not reimburse EMI for the unauthorized wire transfers, and this lawsuit was eventually filed.

However, the EMI Lawsuit differs in two substantial ways from the online banking cases InfoLawGroup previously reported on. First, unlike the other online banking breach suits, in the EMI Lawsuit, Comerica had implemented (and EMI was using) 2-factor authentication. In particular, Comerica had implemented a token-based 2-factor system. It appears that Comerica online banking customers where provided with a physical token that generated random numbers at various regular time intervals (e.g. the token number was always changing at regular interval). To utilize online banking, Comerica customers would have to input their username and password as well as the random number showing on their token. Without all three pieces of information, logging into Comerica's online banking would not be possible.

Second, in other the lawsuits, it was not known (or at least unclear from the compliant) how the criminals obtained the banking customer’s online banking credentials. In the EMI Lawsuit, however, the bad guys allegedly obtained EMI’s login credentials through a “phishing attack.” EMI alleges that one of its employees was tricked into giving those login credentials to the criminals via a spoofed email that purported to be from Comerica. This fake email was allegedly similar to those sent by Comerica to EMI in the past. Apparently the EMI employee would have provided not only user name and password, but also the random number from the token. The complaint alleges that the thieves were able to conduct about 97 money transfers over a period of approximately 6 ½ hours.

Analysis

This case raises several interesting legal issues. In fact, this case could ultimately illuminate how courts view the scope of a “reasonable security” duty.

Existence and Scope of a “Reasonable Security” Duty.

One of the issues that will be key in this case is whether the bank has a legal duty to prevent these types of phishing attacks. The Shames-Yaekel case has recognized a general duty to protect a customer's online banking accounts. In that case, however, it is unclear how the bad guys obtained the banking customer's online credentials. This case is a little different because phishers were able to trick the customer into volunteering its online banking credentials. Assuming a general duty exists, the question is whether that duty extends to preventing (or reducing the risk of) its customers from being duped by social engineering attacks like phishing.

On that issue, In the EMI Lawsuit (like many of the other online banking lawsuits) the plaintiffs allege that Comerica failed to comply with the “commercially reasonable” security procedure requirement under Michigan’s version of UCC 4A202 (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.

Subsection (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.

Significantly, the existence of a duty and whether Comerica's security procedures were commercially reasonable under MCLA 440.4702(2)) are questions of law, and will be decided by the Court, not a jury. Also of note, some of the plaintiffs’ allegations track to the factors laid out in MCLA 440.4702(3), including allegations that EMI had only performed two wire transfers in the two years prior to the attack. From a legal standpoint, assuming this case does not settle, since this is a question of law, we could see some actual briefings and a court decision on the issue of reasonable security.

One of the factors that courts look to in order to determine whether a duty exists and its scope is forseeability -- was this attack and/or the resulting harm foreseeable by the bank? In fact, EMI alleges that the secure token technology was one that was already known to fail. On this issue, in general, we know that phishing attacks have been around for awhile. We also know that banks and other organizations have developed approaches to try to prevent these types of attacks. Finally, security professionals tell me that use of phishing to foil two-factor authentication is also a risk that has been discussed in the past. In fact, a similar phishing attempt spoofing a Citibank online banking portal was reported back in 2006. As such, we will likely see significant arguments from both sides on this issue.

“Reasonableness,” Industry Standards and Tug Boats

This case is interesting because Comerica was actually using 2-factor authentication. In the Shames-Yeakel matter, the court ruled that the failure of the bank to use two-factor authentication as suggested by FFIEC guidance created a question of fact appropriate for a jury. Thus, unlike Shames-Yeakel and other online banking cases, at least with respect to authentication, it appears that Comerica was meeting what some would call the "industry standard.”

However, at this point in time it is possible that a court could rule that 2-factor authentication only serves as a floor, and industry standards for online banking security may have evolved further. In other words, to the extent this “man in the middle” type of attack was known and there are methods for addressing it (especially in the phishing context), the “industry standard” for online banking may be 2-factor authentication PLUS other security measures. Again, plaintiffs allege several other measures they believe should have been in place, including verifying the computer sending the wire transfer instructions, security testing and fraud monitoring programs. The key issue here will be determining what other similar banks are doing to address this risk.

Moreover, even if 2-factor authentication is considered the “industry standard,” under the law an entire industry may not be implementing reasonable security. The rationale for this was explained by Judge Learned Hand in the famous (for first year law students at least) T.J. Hooper case. In T.J. Hooper, the plaintiffs were shipping two barges full of cargo when the ships encountered a storm. The barges were accompanied by two tugboats owned by the defendants. Unfortunately the tugs were unable to safely pull the barges from the storm and the cargo they carried was lost. The plaintiffs asserted that the defendants were negligent because their tugboats were not equipped with effective radio sets capable of receiving warning of the storm. The defendants argued that they did not owe the plaintiffs a duty to carry such a radio because they were a new technology and it was not a common practice in the tugboat industry to carry such radios. Judge Learned Hand disagreed:

Indeed in most cases reasonable prudence is in fact common prudence, but strictly it is never its measure. A whole calling may have unduly lagged in the adoption of new and available devices. . . . Courts must in the end say what is required. There are precautions so imperative that even their universal disregard will not excuse their omission.

What is the import of this? Under the law for purposes of negligence, a defendant can avoid liability even if a plaintiff suffered harm as long as the defendant did not breach its duty of care. In this context if the bank's security measures where "reasonable" under the law it would not be liable. I think the fact that the bank used 2-factor authentication and can point to the FFIEC guidance will help its cause in this respect. Nonetheless, it is possible the court will rule either that industry standards have evolved further or that the entire online banking industry was “lagging” behind in its reliance on 2-factor authentication. From a legal perspective it will be very interesting to watch the court’s analysis on the issue of reasonableness as it relates to industry standards (and hopefully it will provide more guidance for lawyers and banks going forward).

What about EMI’s fault?

There is a concept in the law called contributory negligence (or comparative negligence). You can read more about it here. Essentially this concept recognizes that a plaintiff (the bank customer in this case) may have also been negligent and may have contributed to the harm it allegedly suffered. In some States if the plaintiff was more than 50% responsible, it would be barred from any recovery. Other states, including Michigan (where the EMI Lawsuit was filed) employ a “modified comparative negligence” approach. Using this approach, if the plaintiff was 60% negligent and the bank 40%, the bank would be responsible for only 40% of the plaintiff's loss. I think there is likely a good argument to be made that EMI should bear some of the responsibility for the unauthorized use of their online banking accounts. In fact, if you read Comerica’s answer to EMI’s complaint you will see that Comerica appears to be taking that position:

16. Denied that the alleged website “appeared to be a Comerica website” to any reasonably alert person who was responsible for safeguarding EMI’s financial records and digital credentials.

26. Denied that any perpetrators infiltrated EMI’s bank accounts. Valid credentials assigned to an EMI employee were used to authenticate a logon for purposes of online banking transactions. If some unknown criminals used those credentials, rather than the EMI employee to whom they had been entrusted, this was caused solely by the actions of that EMI employees.

Whether EMI bears some responsibility will be a very fact-intensive inquiry that will include an analysis of the spoofed email, Comercia's previous practices concerning requests for login-credentials and the actions and decision-making process of the employee that provided the credentials to the criminals.

Conclusion

In general, I believe that these online banking cases have more legs than other types of security breach lawsuits because the plaintiffs have suffered actual damages/harm. Evidence of this is the Shames-Yeakel case, which proceeded past a motion for summary judgment. Contrast this with the numerous security breach cases brought by consumers that have been dismissed relatively early in litigation. In those cases, the plaintiffs whose information was stolen have argued that they suffered harm because they had to pay for credit monitoring. Courts have more or less consistently rejected this argument. For online banking cases, plaintiffs don’t have that problem. In this case the plaintiff is out hundreds of thousands of dollars, so damages are clear.

So if a plaintiff can get past the motion to dismiss phase on the issue of damages, do the defendants have an opportunity to get a summary judgment (rather than risk having to present their case to a judge and jury – something every company likes to avoid, if possible). The problem for banks is that the issue of whether a bank’s security measures were “reasonable” is likely a “question of fact.” Courts are typically not willing to grant summary judgment where questions of fact exist for a jury to decide.

That said, this case is a little different than those in my other blog post because of the phishing issue and because the issue of commercial reasonableness is a question of law under MCLA 440.4702(2). Whether a duty exists under the law is typically a question of law that Courts (as opposed to juries) typically decide. I think there will be a battle at both the pleading and summary judgment phase with the banks trying to argue that they have no duty under the law to prevent their customers from being duped and that their practices were commercially reasonable 440.4702(2). If Comerica does not win these argumenst then this case could go to a jury, which poses legal risk.

The Breach Notification Obligations in the Data Accountability and Trust Act

David Navetta — Mon, 22 Feb 2010 11:43:08 -0700

The Information Law Group has been following various Federal data security bills as they wind their way through the House and Senate. In December 2009, the Information Law Group commented on the passage of the Data Accountability and Trust Act ("DATA") by the House. I was recently asked by Data Protection Law and Policy (an excellent publication out of the UK focusing on data security and privacy issues) to take a closer look at the data breach obligations of the current version of DATA. The end result was my article entitled: "Potential changes to the US breach notice risk landscape".

In summary, my article discusses some of the similarities and differences between the current state-created breach notice regime and the system set forth under the proposed DATA law. DATA is interesting because it appears to create counter-opposing breach notice incentives. On the one had, there are mechanisms that could lead to less breach reporting, including:

a "risk of harm" standard that is likely higher than many existing State laws;

preemption of existing state law, which eliminates the "least common denominator" approach taken with respect to existing state law; and

mandating call center and credit monitoring costs (e.g. these costs may be significant, and therefore encourage non-compliance, especially if enforcement is lax)

On the other hand, DATA allows for the imposition of civil penalties of up $11,000 per violation (capped at $5 million). Each failure to send the required notification to an affected individual is treated as a separate violation. Depending on how vigorously the law is enforced, the risk of significant civil penalties is likely to encourage compliance.

How these factors would play out is unclear and up for debate. However, what is even more unclear is whether DATA will ever be made into a law. The Senate is working on a similar bill, and assuming it passes the Senate it would still have to be reconciled with the House version. Consumer advocates will likely have concerns about the higher risk of harm threshold in the law. On the business side, I anticipate great resistance to call center and credit monitoring as mandatory costs. Moreover, the penalties for non-compliance may be problematic, especially for smaller and medium organizations. As such, should DATA become a law, it is likely to differ from this version.

Developing an Information Security and Privacy Schedule for Service Provider Transactions (Part Two)

David Navetta — Thu, 18 Feb 2010 16:39:36 -0700

In Part One of this blog series, we looked at the proactive nature of a data security and privacy schedule ("Schedule"), and considered the compliance function of a Schedule. Part Two of this series discusses security incident response contract terms that should be considered for a Schedule. In addition, we look at more traditional "risk of loss" contract terms and how data security and privacy risks impact those terms.

Security Incident Response Planning

As mentioned above, a Customer should think of a Service Provider’s security as an extension of its own internal security. This applies not only to the controls the Service Provider maintains, but also how a Service Provider responds to a security incident. The key here is to impose obligations on the Service Provider that provide the Customer with the most control possible in responding to, and mitigating the impact of, a security incident. In addition, in the event litigation or a regulatory action is a possibility, Customers should attempt to secure rights that allow them to collect and preserve evidence relevant to their defense (or in some cases a suit against the Service Provider).

On the front end, Customer should investigate the Service Provider’s security incident response procedures. In particular, the Customer should ask:

Does the Service Provider have controls and policies in place to detect an incident?

Once detected is there a chain of communication that escalates the incident to appropriate personnel?

Are there procedures for ascertaining the risk and potential impact posed by a security incident?

What processes exist to allow for the quick remediation of a security breach?

Moreover, since a forensic analysis or security assessment will often be necessary post-breach, the Customer should investigate what information is retained by Service Provider, and the Schedule should obligate the Service Provider to retain certain information that may be relevant to a breach (e.g. logs, error reports, planning documents, security policies, etc.)

Beyond that the Customer should consider how the Service Provider and Customer will interact in the event the Service Provider suffers a security breach impacting the Customer’s information, systems or ability to conduct business. The Schedule should require the Service Provider to identify an incident response coordinator to serve as the communication point for the Customer. Communication obligations can also include a point of contact within Customer’s organization, including in some instances a security breach emergency "hotline" phone number. The Schedule may include “deadlines” for providing notice of security breaches to the Customer (e.g. “immediately” or “within twenty-four hours” of discovery, etc.). The Schedule should include a general cooperation clause, and where appropriate specific incident response procedures between the Service Provider and Customer.

In addition, the Schedule should require the Service Provider to provide reports and information concerning the security incident, including information concerning what went wrong, what information or systems were impacted, and the remediation taken and planned by the Service Provider. The Schedule should also provide the Customer with the ability to conduct its own independent forensic analysis and security assessment after a breach. Since litigation or regulatory action is possible after a breach, the Schedule should include mechanisms for initiating a litigation hold and preserving information that may be relevant in a litigation context, as well as procedures for responding to information requests by regulators or litigants.

Risk of Loss

While most of the items discussed above are rather unique to the information security and privacy realm, risk of loss provisions are common to most contracts. These terms include warranty disclaimers, consequential damages disclaimers, limitation of liability clauses and indemnification clauses. Risk of loss terms should also address information security and privacy risk.

First, it is not unusual for a security incident to yield “consequential damages” in addition to “direct damages," including loss of profits, lost customers, attorney fees, breach notice costs and other similar costs. If the overall contract contains a consequential damages disclaimer, the Customer should endeavor to get an exception for consequential damages arising out of a security incident and/or breach of the Schedule.

Second, the Customer’s damages arising out of security incident can be enormous. They can include loss of profits, expenses to defend litigation (often multiple lawsuits for large breaches), regulatory defenses, damages, fines and penalties arising out of litigation, costs to provide notice to individuals whose personal information was breached, credit monitoring expenses, call center expenses and third party forensic analysis expenses. If a limitation of liability clause is in the contract, Customers should consider whether the liability cap would be sufficient to make them whole in the event of a security breach. If not, Customers should attempt to negotiate an exception to the limitation of liability (or perhaps a different limit of liability) for loss arising out of security incidents or breaches of the Schedule.

Last, enhanced indemnification/reimbursement language should be considered. As discussed throughout, it is not unusual for litigation or a regulatory action to arise out of a security incident. In the event the a breach of the Service Provider leads to litigation a regulatory action, the Schedule should include an indemnification or reimbursement clause that pays for the defense of these actions and indemnifies Customer for all damages, fines, penalties and other costs arising out of such actions.

In addition, the Schedule should also include a duty for the Service Provider to indemnify (or pay for) certain breach notice-related expenses. To date approximately 45 states have passed breach notice laws that require companies to provide notice to individuals whose person information may have been compromised. There are many expenses that arise out of the legal requirement to provide notice, including forensic expenses, attorney fees and mailing costs. In addition, some Customers may also want to provide affected individuals with a call center and credit monitoring. Many of these expenses have a “multiplier” component that can result in enormous damages. For example, one year of credit monitoring could cost anywhere from $10 to $360 per year per individual. If credit monitoring is provided to 1 million affected individuals a low-end estimate of the cost would be about $10 million. Therefore, the Customer should attempt to include language in the Schedule that requires the Service Provider to pay for or indemnify the Customer for these costs as well. If possible, all such indemnification costs should be outside the limit of liability.

Finally, organizations should consider another method for transferring risk of loss: insurance. “Cyber” insurance is available that can cover many of the types of loss that arise out a security or privacy breach, including loss of income, remediation expenses, data restoration, attorney fees, damages, fines and penalties, forensic expenses, breach notice expenses, credit monitoring expenses and call center expenses. The Schedule should require the Service Provider to carry both errors and omissions and “cyber” risk coverage with appropriate limits of liability. The Customer should attempt to mandate that it be named as an additional insured under the Service Provider’s policy (this option, however, may not be available as it will depend on whether the insurer is willing to provide “additional insured” coverage). In addition, Customers should consider purchasing their own cyber policy to provide direct coverage. Many carriers will provide coverage to the Customer for security and privacy breaches arising from a Service Provider security incident.

Conclusion

An information security and privacy schedule that sets forth Service Provider security and privacy obligations, and Customer rights with respect to the same, is an increasingly important and necessary part of an information technology, outsourcing or cloud computing transaction. Lawyers charged with developing such terms should be aware that Schedules serve several simultaneous purposes that are specific to the compliance and liability risk associated with data security and privacy. As a final point, the Schedule is a classic example of where “hybrid” knowledge of the law and security is required. A large part of the Schedule involves “translating” legal compliance and risk issues in a manner that can be understood by security and privacy professionals (and vice versa). As such lawyers should work closely with their client’s information security and privacy teams to develop security assessment processes, draft the terms of a Schedule, and negotiate Schedule terms with Service Providers.

Developing an Information Security and Privacy Schedule for Service Provider Transactions

David Navetta — Mon, 15 Feb 2010 23:09:28 -0700

It is a very interesting time for information security and privacy lawyers. Information technology and the processing, storage and transmitting of sensitive and personal information is ubiquitous. At the same time (and likely as a result of this ubiquity) the legal risk and regulatory compliance environment poses increased threats and potential for significant liability. Finally, whether through cloud computing providers or traditional outsourcing of information technology functions (e.g. ASP, hosting and storage), to stay competitive and efficient, companies of all shapes and sizes are outsourcing their information technology functions to third party service providers. It is likely that adoption of these practices will increase at an increasingly faster rate.

This reality poses significant information security, privacy and legal challenges. Internal security and privacy professionals find themselves ceding control of significant decisions to third parties (“Service Providers”) concerning the implementation, maintenance, enhancement and enforcement of information security and privacy measures. Unfortunately, an organization’s legal risk and compliance obligations do not follow – in most cases they remain with the organization that chooses to outsource (the “Customer”). Of course on the Service Provider side, the main motivation is as follows: (1) secure revenue; and (2) void liability. These motivations often counter-oppose the goals of the company seeking to outsource.

These tensions play themselves out during the contract negotiations with Service Providers. It is at this juncture that the role of the Customer’s information security and privacy attorney, working closely with the Customer’s internal security and privacy professions, becomes increasingly important. To navigate these waters legal experience in the areas of data security and privacy law, contract drafting, litigation risk and negotiation tactics is crucial. However, as important, is a solid understanding of technology and substantive security and privacy matters, and how they relate to and interplay with the law. The net result is intense negotiations around the data security and privacy contract terms, which are often in the form of an information security and privacy schedule or exhibit (“InfoSec-Privacy Schedule” or “Schedule”).

In this two-part post, we explore the function and purpose of these Schedules and discuss how they might be drafted and used. Part One discusses the proactive nature of a Schedule and how it should be viewed as compliance document. Part Two details security incident response provisions that should be considered in a Schedule, and contract terms allocating risk of loss between the Customer and Service Provider.

The Multiple Functions of a Data Security and Privacy Schedule

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

Proactive Nature of an Info-Sec Privacy Schedule

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

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

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

The Infosec-Privacy Schedule as a Compliance Document

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

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

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

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

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

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

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

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

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

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

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

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

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

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

EU Adopts New Standard Contract Clauses for Foreign Processors

W. Scott Blackmer — Tue, 09 Feb 2010 12:31:17 -0700

Last Friday, the European Commission adopted new "controller-processor" standard contractual clauses ("SCCs" or "model contract") to protect personal data transferred from Europe to a data processor located outside the EU/ EEA. Existing contractual arrangements are grandfathered, but any new contracts with data processors must include the new version of the SCCs.

The principal change from the 2002 controller-processor SCCs is that processing contractors are now obliged to obtain prior written consent from the customer before subcontracting any of the processing, and the subcontractor must be contractually bound to the same obligations that apply to the contractor.

Article 25 of the EU Data Protection Directive directs member states to prohibit the transfer of personal data to countries lacking similar legal protections, unless one of several limited exceptions applies or approved safeguards are in place. EU-approved standard contract clauses between the data "exporter" and data "importer" are a common means of legitimizing data transfers to locations outside the European Economic Area -- the European Union plus Iceland, Liechtenstein, and Norway. (SCCs are not used where the transfers are to a US company that participates in the international Safe Harbor program, or to a company relying on informed consent, nationally approved Binding Corporate Rules, or one of the other "derogations" under Article 26 of the Directive.)

The European Commission has approved two alternative sets of SCCs for use in transferring personal data to a data "controller" outside the EEA, and in 2002 the Commission approved a set of SCCs to be used when transferring data to a "processor." The distinction between controllers and processors is not always clear in practice, but the basic concept is that a controller makes decisions about what data to collect and how to use it, while a processor merely performs operations on data only on behalf of the controller and according to its instructions. Business process outsourcing in a non-EEA country such as the United States or India is a common context for using SCCs to protect employee and customer information or other personal data furnished by a European company.

The concern addressed in the new controller-processor SCCs is that processors today often subcontract some processing, storage, and technical support functions to third parties. This is particulary common in cloud computing, where several entities might be involved in handling and storing the data. The new SCCs are designed to ensure that the company that remains responsible as the data controller in Europe is informed about any proposed subcontracting, and that all parties handling the data are subject to the same obligations of confidentiality and security.

The full text of the decision and the new SCCs are not yet posted on the Commission's website. (They will ultimately appear on the "Model Contracts" page.) A Commission spokesman described the decision on Friday, however, as follows:

"According to the newly adopted Decision, where a data importer (processor) intends to subcontract any of its processing operations performed on behalf of the EU data exporter (controller), it must first obtain the prior written consent of the data exporter. The written contract will impose the same obligations on the sub-processor as those imposed on the data importer under the standard contractual clauses."

The Commission reportedly will not require companies with existing controller-processor SCCs to replace those agreements with the new SCCs. New processing agreements, however, must use the new set of controller-processor SCCs if they are to serve as a legal basis for data transfers outside the EEA.

Data Integrity and Evidence in the Cloud

W. Scott Blackmer — Fri, 29 Jan 2010 11:09:09 -0700

How does cloud computing affect the risks of lost, incomplete, or altered data? Often, the discussion of this question focuses on the security risks in transmitting data over public networks and storing it in dispersed facilities, sometimes in the control of diverse entities. Less often recognized is the fact that cloud computing, if not properly implemented, may jeopardize data integrity simply in the way that transactions are entered and recorded. Questionable data integrity has legal as well as operational consequences, and it should be taken into account in due diligence, contracting, and reference to standards in cloud computing solutions.

Consider a traditional business data transaction such as recording a customer order or a new hire. Sales or human resources staff, or possibly data entry clerks, type required information into an application hosted on premises. The data may be stored in multiple local databases. For example, the customer screen presented by an ERP (enterprise resource planning) system may automatically populate fields in separate order fulfillment, accounting, and customer relationship management systems, and perhaps in a marketing database as well. The new hire screen may feed relevant data to human resources, accounting, and payroll systems or modules.

The interaction between the data entry system and the multiple databases is normally effected through database APIs (application programming interfaces) designed or tested by the database vendors. The input is also typically monitored on the fly by a database “transactions manager” function designed to ensure, for example, that all required data elements are entered and are within prescribed parameters, and that they are all received by the respective database management systems.

Cloud computing solutions, by contrast, are often based on data entry via web applications. The HTTP Internet protocol was not designed to support transactions management or monitor complete delivery of upstream data. Some cloud computing vendors essentially ignore this issue, while others offer solutions such as application APIs on one end or the other, or XML-based APIs that can monitor the integrity of data input over HTTP.

Since the 1980s, database management systems routinely have been designed to incorporate the properties of “ACID” (atomicity, consistency, isolation, and durability). The question for the customer is whether a particular cloud computing solution offers similar fail-safe controls against dangerously incomplete transactions and records.

With apologies to IT professionals who understand this subject much better than I do as a lawyer, here is what is entailed in ensuring data integrity in a database management system:

Atomicity means that the transaction is aborted unless all required data elements are successfully recorded in all required systems. The transaction must entirely succeed or entirely fail. As a consequence, no payment will be sent without an associated taxpayer identification number, and HR records will not miss any personnel that show up in the payroll system. Human error, device failure, software bugs, communications or power outages – whatever the source of a failure, if all the required data are not recorded by all of the systems for which it is intended, then none of them are; the transaction fails and must be restarted. This is relatively easy to control when all of the input comes through a single data entry system with defined APIs and is distributed simultaneously to the relevant on-premises database applications. But in cloud computing, the data are typically entered via web browser and may go to separate vendors – for outsourced HR information management and payroll services, for instance – and there may be no immediate cross-check between them. Data successfully recorded on one of the systems may nevertheless fail to be recorded on the other, and the error may not be discovered immediately.

This may be a good reason to use a single cloud service provider for related applications, or to employ a cloud services aggregator that offers some intermediate transaction management functions.

Consistency means that a database remains in a consistent state before and after the transaction. If a data field (say, Social Security Number) requires nine digits, the database must contain only nine-digit numbers in that field before and after the transaction. If other data records refer to that field, it cannot be deleted without deleting those records or taking some other action that maintains the consistency of the database schema.

Using separate vendors in the cloud to manage different but related databases may result in inconsistencies, particularly where one data record necessarily refers to another.

Isolation is the principle that one operation in a database system should not affect others until the transaction is complete, so that one function is not confused by an intermediate step in another function. This is why database management systems use scheduling algorithms to isolate functions and process them in the proper sequence.

Cloud computing should not threaten this principle so long as a complete transaction is processed on the same device or array, or at least subject to the same scheduling algorithm.

Durability means that the transaction record will persist once it is successfully created and the user is so notified. A common way of ensuring this result is to create a transactions log, which allows the database manager to return the database to a pre-failure state.

A cloud solution should similarly offer the capability of logging user transactions, even if the transaction data are then sent on to different locations or vendors.

Cloud computing is new enough that not all vendors have satisfactorily incorporated these data integrity principles in their solutions. Moreover, customers sometimes use such a variety of service providers that no single one of them takes responsibility for ensuring data integrity at the level of data entry and transaction management.

Over time, more cloud service providers may refer to developing standards such as the SNIA Cloud Data Management Interface (CDMI) specification and other SNIA cloud storage standards, the Data Integrity Field (DIF) standard (which, among other things, verifies input-output addresses to avoid misplacing data entered in the cloud), WS-Reliability (an OASIS standard for reliable message delivery in web services) and WS-Transaction (OASIS protocols for coordinating distributed applications), as well as XML-based solutions that add some transaction management functionality to web applications. As these standards and solutions mature, it may be appropriate to make them contractual.

These approaches would help the customer feel more confident that good data gets into cloud databases, stays there, and comes out of the cloud in the same shape.

The lawyer in me recognizes that this sort of confidence must also be communicated to government agencies, courts, and juries. Records processed and stored in the cloud may become evidence, and the strength of evidence depends largely on its reliability. I was involved once in litigation over a web marketing campaign, where the website transaction logs were so badly maintained and so insecure that it was nearly impossible to ascertain what the customer really owed the marketing company under the contract.

Reliable business records are necessary to collect a bill, prove an obligation, comply with government requirements, or establish a sequence of disputed events. If there are serious questions about data integrity in the systems routinely used by the business, the company may find its position badly undermined.

Once litigation is launched or threatened, the cloud customer will need to put a “litigation hold” on relevant data, even if it is in the hands of an outsourced service provider, and the customer will typically need the service provider’s assistance in locating and producing electronically stored information (ESI) stored outside the party’s premises. (See my colleague Tanya Forsheit’s recent discussion on preserving and retrieving ESI in the cloud.) But the service provider may be needed not only to help find, preserve, and deliver relevant records as ESI but also to establish their bona fides.

Parties presenting claims or defenses in court have long relied on the “business records exception” to the hearsay rule, a descendant of the English common law “shop book rule,” to present records of transactions in court. The principle is reflected in Rule 803(6) of the US Federal Rules of Evidence and in similar state provisions. Rather than bringing witnesses into court to testify from direct experience and memory about every material aspect of a disputed transaction, a party can produce the records that it routinely keeps in its business, and these are presumed to be reliable. The presumption can be rebutted with evidence to the contrary -- which conceivably could occur in the case of a badly executed cloud computing strategy with poor assurances of data integrity.

Business records are not entirely self-authenticating, and there are sometimes disputes over their source and custody, or whether they have been altered. Typically, business records must be introduced from the party’s custody along with testimony that identifies the records and authenticates them as records regularly made and kept in the course of the party’s business.

Thus, it could become necessary in some cases to call for testimony from an employee of the cloud services provider to authenticate data produced from an outsourced application and a shared data storage facility, and to counter any challenges about the possibility of lost or altered data. The cloud computing service provider should be able to demonstrate that its procedures for recording transactions, associating them accurately with the author, date, and time, and storing the data securely, are consistent and effective, and that they comport with industry standards or common industry practices.

These issues are not entirely new or restricted to cloud computing, of course. To take an example, email has been central to business communications for more than twenty years, and emails are often used as evidence of transactions, conduct, and intentions in a wide variety of civil and criminal legal proceedings. Yet emails are not always reliably sourced or date-stamped, and they often reside in multiple locations, including individual’s laptops, desktops, and phones, servers on the premises of the sender’s and receiver’s organizations, and the facilities of third-party service providers, ISPs, and webmail operators. In each case, the messages may or may not be backed up or archived onto other computers or storage media. As a result, investigators and lawyers are often in the position of searching out and comparing multiple instances of what appears to be the same email, and courts sometimes have to rule on the likelihood that a critical message was in fact sent by the purported author, received by the intended recipient, retained or deliberately deleted, or even altered in substance. (Celebrated cases involving Martha Stewart and the White House come to mind.) Lorraine v. Markel Am. Ins. Co., 241 F.R.D. 534 (D. Md. 2007) is an example of a court losing patience with parties that merely attached emails to court papers without authenticating testimony to establish their source and reliability.

As transactions databases and other kinds of business records follow email into the cloud, we are likely to see more disputes over records authentication and reliability. This suggests that customers should seek out cloud computing service providers that offer effective data integrity as well as security. Customers should also consider inserting a general contractual obligation for the service provider to cooperate as necessary in legal and regulatory proceedings -- because sometimes integrity must be proven.

Celebrating Data Privacy from A to Z

Tanya Forsheit — Thu, 28 Jan 2010 10:45:25 -0700

In honor of Data Privacy Day and its spirit of education, I thought it might be appropriate (and fun) to celebrate some (but certainly not all) of the A, B, Cs of Data Privacy. Would love to see your contributions, too!

A is for Advance Encryption Standard or AES, approved by NIST. Are you encrypting transmissions of sensitive data and portable storage devices? See more below.

B is for Breach Notification Laws, including the 45 state laws, District of Columbia, Puerto Rico, Virgin Islands, HITECH Act, and international regulations. (Also Behavioral Advertising.)

C is for . . . what to Choose? -- Contracts? Cloud Computing? How about California - the first state to enact a breach notification law, California Civil Code sections 1798.29, 1798.82 et seq. (SB 1386), and the first state Office of Privacy Protection

D is for Data Protection Authorities in the European Union

E is for the EU Data Protection Directive. Oh, and Encryption, of course. See above and below.

F is for Financial Institutions, regulated by (wait for it . . . after the jump . . .)

G is for the Gramm-Leach-Bliley Act and the new model privacy notice form

H is for HIPAA and the HITECH Act, which impose privacy and data security obligations on health care providers and their business associates

I is for the International Association of Privacy Professionals, IAPP

J is for John and Jane Doe, anonymity - is there any such thing?

K is for Kearney v. Salomon Smith Barney Inc, California Supreme Court (2006), requiring two-party consent for recording or eavesdropping on telephone conversations, even if only one of the participants is in a two-party consent state

L is for Legislation -- will there be a federal breach notification law in 2010 (other than HITECH) that will preempt the state data breach notification laws?

M is for Massachusetts and its new data security regulations, 201 CMR 17.00 et seq., effective March 1, 2010

N is for Nevada and its new encryption law, SB 227, effective January 1, 2010

O is for Outsourcing, and the need for due diligence and contractual provisions to safeguard personally identifiable information (and other kinds of sensitive information) shared with third parties. See, e.g., Massachusetts 201 CMR 17.00 et seq. and California Civil Code section 1798.81.5. Oh yes, and don't forget the Cloud in this context - are you putting data in the cloud? Have you done your due diligence?

P is Personally Identifiable Information or PII -- what IS it anyway? Depends where you live.

Q is for Questions, Q & A, and the Q in FAQ: ASK QUESTIONS early and often about how your organization will use personal information of customers and/or employees in its business operations.

R is for Radio Frequency Identification or RFID and locational privacy issues - should organizations be able to use RFID to track customers/products?

S is for SO many things -- Social Networking, Social Security numbers, Surveillance, Spam, . . .

T is for Telemarketing, Text Messages, and the TCPA -- do you have opt-in for your mobile marketing campaigns?

U is for the UK ICO, which will order companies to pay up to £500,000 as a penalty for serious breaches of the Data Protection Act

V is for the Video Privacy Protection Act or VPPA, the basis for a recent privacy class action filed against Netflix in the Northern District of California

W is for Website Privacy Policies, required under California law for any website that collects information from California residents, Cal. Bus & Prof. Code section 22575 et seq. When was the last time you updated yours? Is it accurate?

X is for XXXXX -- Redact the information!

Y is for Yes, You can implement a successful data protection program in Your organization

Z is for Zango, the adware distributor that settled FTC charges that it used unfair and deceptive methods (FTC Act Section 5) to download adware and block consumer efforts to remove it

Happy Data Privacy Day!

Issuing Banks File Class Action Suit Against Acquiring Banks in Heartland Breach Matter

David Navetta — Thu, 21 Jan 2010 09:18:05 -0700

In an interesting development, a handful of issuing banks impacted by the Heartland breach have filed a class action lawsuit against two acquiring banks related to Heartland Payment Systems. According to this article, the issuing banks are unhappy with Heartland's proposed settlement with Visa. This appears and to be an attempted end-run around the proposed $60 million settlement with Visa. It also may demonstrate that issuing banks are not satisfied with the dispute resolution mechanisms under the Visa Operating Regulations (the Account Data Compromise Recovery process estimated the loss at $140 million, yet the settlement was for only $60 million), and their ability to be made whole under those mechanisms. We will have more analysis of the complaint at a later day. In light of the relative lack of success issuing banks have had in these types of cases, it will be very interesting to analyze the legal theories employed by the issuing banks and track the progress of this matter.

Is Your Organization's Red Flags Rule Identity Theft Prevention Program Ready for Primetime?

Tanya Forsheit — Tue, 19 Jan 2010 12:57:49 -0700

As our readers know, the FTC, after four extensions of the deadline, currently intends to begin enforcing the Red Flags Rule with respect to organizations subject to its jurisdiction on June 1, 2010. In the meantime, the Red Flags Rule remains in effect as to all financial institutions and creditors (and has been subject to enforcement by the banking regulators since November 1, 2008). Although a recent decision of the United States District Court for the District of Columbia, ABA v. FTC, brought lawyers outside the scope of the Rule, the Rule remains broad and covers a wide range of entities as "creditors." Creditors subject to the FTC's jurisdiction need to have their written Red Flags Rule Identity Theft Prevention Programs prepared, approved by the Board, and implemented by June 1. For more on the history and the requirements of the Rule, see my recent article, "The FACTA Red Flags Rule: A Primer," published in Bloomberg Law Reports – Risk & Compliance, reproduced here with the permission of Bloomberg. Read on . . .

Information Security Clauses and Certifications - Part 1

W. Scott Blackmer — Sun, 17 Jan 2010 20:30:02 -0700

Outsourcing business and IT functions often means outsourcing compliance and liability risks as well. When a service contract involves protected categories of personal information, both parties need to understand the security requirements and risks. The contract should allocate responsibilities to prevent and respond to security breaches. The contract may also set expectations more precisely by incorporating a written security policy or referring to a widely accepted information security standard, sometimes accompanied by a requirement for a third-party security audit or assessment.

What contractual information security provisions should you consider, as a customer or as a vendor or business partner, when the contract contemplates the exchange of protected information? What do security standards and audits entail for a vendor, and what do they offer for a customer?

With heightened liability and compliance risks associated with handling protected categories of data, it is becoming more common to see contractual requirements holding vendors accountable for information security or requiring them to conform to a specified information security standard. Formerly, certification requirements were largely confined to contracts procuring data processing services for government agencies, financial services firms, and healthcare providers. Now, such provisions are appearing in a wide variety of outsourcing, cloud computing, software as a service (SaaS), infrastructure as a service (IaaS), and consulting contracts where the vendor will be processing or storing Social Security Numbers (SSNs), payment card or bank account details, medical information, or virtually any personal data from Europe, Canada, or other jurisdictions with more comprehensive data protection laws.

Often, the contract requires a self-certification of conformance with a particular set of information security safeguards and control procedures, such as the Payment Card Industry Digital Security Standard (PCI DSS) for credit and debit card data, ISO 27001/27002 (formerly ISO 17799), or the US government’s NIST 800 series of Federal Information Processing Standards (FIPS). But many contracts go beyond representations, warranties, or conditions concerning information security and require the vendor to submit a third-party expert assessment or audit of the vendor’s security practices.

Security audits can be costly and time-consuming, and an audit requirement may or may not be reasonable given the type and amount of data at issue. On the other hand, a neglected or casually performed self-assessment can result in contract termination, denial of insurance claims, or the shifting of liability following a security breach incident.

How well do lawyers drafting or vetting contracts know what their clients need, or what they are committing to, when it comes to the clauses or annexes detailing the parties’ information security obligations? Despite the sometimes mind-numbing acronyms and technical content, lawyers and business managers need to have a basic understanding of what is entailed with the more common forms of information security clauses and certifications. This will also help them determine which are the most useful and appropriate standards, representations, and certifications for a particular services contract.

Common Information Security Clauses

Confidentiality and nondisclosure provisions typically include a definition of “Confidential Information” accompanied by nondisclosure obligations. The definition usually amounts to “proprietary,” nonpublic information that could be legally protected as trade secrets or confidential commercial information. Sometimes the definition specifically includes “personal information” shared between the parties, such as customer and employee data or marketing lists, which may be both proprietary and protected by privacy laws. Typically, the clause obliges the parties to protect each other’s Confidential Information in the same manner that they customarily protect their own Confidential Information (“the same care and discretion” is a common formulation).

A simple, reciprocal confidentiality obligation works well where the parties have similar interests and capabilities in information protection. However, if one of the parties is relatively inexperienced or lacks sufficient resources or motivation, it may not be satisfactory to rely on such a provision without naming (or attaching) any special security requirements that apply to some of the data, or referring contractually to a widely accepted security standard.

Personal Information Security Clauses

Many contracts involving the sharing of protected categories of nonpublic personal information now also include a Personal Information or Personal Data provision. This is typically designed to help ensure compliance with any applicable privacy laws or standards, such as the federal HIPAA and HITECH acts governing medical data in the US, state personal information security and breach notice laws, and data protection legislation outside the US. The clause will often require the parties to implement “reasonable and appropriate” security measures to protect either defined categories of personal data or, more broadly, any personally identified or identifiable information (“PII”) furnished in connection with contract fulfillment.

The clause may refer generally to compliance with “any applicable laws and standards,” but it is prudent to add a specific reference to any particular information security regimes that are known to apply, such as PCI DSS (payment cards), HIPAA and HITECH (medical records), GLBA (financial accounts), FCRA (consumer reports), national laws based on the EU Data Protection Directive, or the Massachusetts personal information security requirements contained in Massachusetts M.G.L. c. 93H and 201 CMR §§ 17.00-17.05. This helps ensure that the parties understand the operational security requirements and avoids disputes about precisely what was required of the vendor.

Related provisions that may appear in this clause or separately include those relating to indemnification in the event of a security breach or abuse of personal information, insurance to cover such events, notice obligations in the event of a suspected breach of security, and a duty to cooperate in the investigation and resolution of security incidents involving protected personal information. Depending on the sensitivity of their consumer, employee, or government relations, some customers insist on a provision that allows them, or their designated experts, to control the investigation and any notifications to affected individuals or to law enforcement or regulatory bodies, even if the vendor is responsible for some or all of the related costs. Occasionally, the personal information clause will expressly deny any intent to create third-party beneficiary rights for the individuals who are the subjects of the data. This is not possible, however, in the case of European personal data transferred abroad under EU-approved standard contract clauses, as mentioned below.

The personal information clause may also include reference to a specified information security standard and possibly to a required third-party certification. The more common forms of these will be discussed in the next posts in this series.

Clearly, the personal information provisions of the contract can involve substantial risks and costs. The vendor should be careful to understand the requirements and not commit to more than it can perform (or afford). The Customer needs to exercise due diligence in ascertaining that the vendor has the technical and financial capability to perform as required, since the customer may be held accountable in any event by courts, regulators, and the public.

Transborder Personal Data Transfer Agreements

Personal data from the European Union, European Economic Area (the EU plus Norway, Iceland, and Liechtenstein), and other jurisdictions (such as Switzerland and Russia) with laws based on the EU Data Protection Directive are usually covered as well by a transborder data transfer clause. This may refer to the receiving party’s obligations as a data “controller” under laws based on the EU Directive, including obligations to provide notice and access and to secure the data with appropriate “technical and organizational” measures proportionate to the privacy risks inherent in handling the data at issue. If the receiving party is a mere “processor” under EU law, it is mandatory for the contract to include an “Article 17” clause (usually under the heading “Personal Data” or “Data Protection”) to the effect that (a) the processor will handle the data only according to instructions from the data controller and (b) the processor will employ “technical and organizational” security measures equivalent to those required of controllers. (Note that Article 17 clauses are required in contracts between controllers and processors even if the personal data remain in the EU / EEA.)

Whether a party receiving European personal data outside the EU / EEA is a controller or a processor, it must have a legal basis for receiving the data. The data may be received in any of the handful of countries deemed by the EU to afford an “adequate” level of protection, such as Switzerland and Canada (to the extent that the data are protected by the Canadian federal PIPEDA act). Data from EU / EEA countries, Switzerland, and Israel may also be received lawfully in the United States by a company that participates in the International Safe Harbor program. Otherwise, the transfer of such data must be covered by informed consent or another of the accepted “derogations” under Article 26 of the EU Directive. The most common of these are EU-approved standard contract clauses (or “model contracts”) and, more recently, nationally approved binding corporate rules (BCRs).

The EU standard contract clauses typically appear in a separate document or annex, with mandatory terms and a description of the data transfers according to EU requirements. There are only a few approved options in the terms themselves, but the descriptive annex must be carefully drafted to cover all of the contemplated data categories, uses, and recipients. The current sets of EU-approved standard contract clauses do not require a detailed description of security measures, but they do require reference to any special measures that must be taken to safeguard “sensitive” data. (In the EU context, sensitive data refers to information concerning race or ethnicity, health or sex life, religious beliefs, political or trade union activity, and, depending on the country, criminal history, national ID numbers, civil judgments, and any other categories of data deemed especially risky under national law or regulations). In some countries, such as France and the Netherlands, the data transfer agreement and descriptive annex must be submitted for review by a national data protection authority (DPA). DPAs have been known in some instances to request more information about the security measures to be employed (such as encryption), particularly where sensitive data are involved, and they may require that these be included in the data transfer agreement. This information is not made public, however, lest it compromise the security measures.

Several other jurisdictions with comprehensive data protection laws (such as Argentina, Australia, Canada, Dubai, Israel, and Japan) require “reasonable” or “appropriate” security measures proportionate to the risks; they also require or recommend contractual safeguards when transferring personal data to the US, India, and other jurisdictions lacking similar data privacy laws. So far, these countries have not specified security standards or detailed requirements that must be reflected in the data transfer agreement.

***

In the following posts in this series, we will look at the more common information security standards and certifications that may be included in service contracts.

Online Banking and "Reasonable Security" Under the Law: Breaking New Ground?

David Navetta — Thu, 14 Jan 2010 00:24:02 -0700

With the report of another data security-related lawsuit involving online banking (another 2009 lawsuit referenced here involved an alleged loss of over $500,000), and a recent victory for a plaintiff on a summary judgment motion in a similar online banking data security breach case, the question arises whether online banking breaches will yield some substantive case law on the issue of “reasonable” security procedures as a matter of law. Ironically, this question may be answered by reference to a 20 year old model code (UCC 4A) originally drafted to address technological advances from that era. This post explores two complaints recently filed against banks for online banking (Patco Construction Co. v. People’s United Bank ("PATCO”) and JM Test Systems, Inc. v. Capital One Bank ("JMT")) and a court’s ruling on a motion for summary judgment in similar lawsuit (Shames-Yeakel v. Citizens Bank Memo and Memo Order on Motion for Summary Judgment – “Shames-Yeakel” case). In short, since the Shames-Yeakel case proceeded past the "damages" pleading phase, it (and possibly these other online breach suits) reveals how some courts view security "standards" and approach the question of whether a company has achieved "reasonable security." I also believe they demonstrate the difficulty defendants face if they have to defend their security measures in a litigation context after a security breach.

Plaintiffs’ Allegations

In general, these matters involve a fairly consistent general set of allegations:

the bank allowed a small business to utilize online banking, including ACH transfers;
nefarious third parties somehow gained access to the plaintiffs’ online banking account (e.g. login credentials such as username, password, “secret question”, etc.), which allowed them to use the online banking system to transfer (a.k.a. steal) funds out of the plaintiffs' bank account;
the bank failed to provide notice to the plaintiffs of unusual or suspicious activity; and
the bank’s security measures did not prevent the fraudulent transfers and were not commercially reasonable.

In addition, the following facts were alleged in one or more of the three cases:

the bank failed to block a transfer request from an IP address that was previously unused by the plaintiff (e.g. an IP address was different than typically used by the plaintiff);
the bank did not utilize multifactor-factor authentication (e.g. “token-based” authentication or fax confirmation);
the allowable daily transfer limit vastly exceeded the plaintiffs’ average/maximum daily transfers (e.g. in PATCO, the daily maximum limit was $750k, but the most PATCO ever needed to transfer was $36.6k);
the funds were transferred to individual accounts to which the plaintiffs had never transferred funds before; and
despite having been informed of unauthorized transactions by the plaintiff, the bank did not close the account in order to prevent more fraudulent transactions (JMT case only).

Alleged Legal Theories

Based on these facts the plaintiffs asserted various causes of action against the banks relating to security practices. In both PATCO and JMT, the plaintiffs referenced the bank’s failure to comply with section 4A-202 (ISSUE AND ACCEPTANCE OF PAYMENT ORDER) of the Uniform Commercial Code (in PATCO the plaintiffs cited MRSA 4-1202 and in JMT they cited RS 10:4A-202). Under 4A-202, as long as the bank and its customer have agreed that the customer will be verified pursuant to a “security procedure”, a payment order received from the customer will be considered an effective order by the customer, whether it was actually authorized by the customer, but only if the security procedure was “commercially reasonable” and followed by the bank. In PATCO, for example, the plaintiffs alleged that 4A-202 had been violated for the following reasons:

failure to offer/use multi-factor authentication to authenticate the plaintiffs’ identity for online transactions;
use of an unreasonably low trigger for “challenge question” authentication;
failure to provide and IP address block that would block orders originating from unapproved IP addresses;
failure to detect fraud because the amounts of the payments were the largest ever made under the account, were sent to accounts to which funds had never been transferred, originated from an IP address that had never previously been used and occurred on days that the plaintiff normally did not may payments;
failure to offer a dual control option requiring two people to log on in order to complete a payment transaction;
allowing a transfer limit that exceeded the needs of the plaintiff;
failure to manually review ACH payment batches prior to submission for payment; and
failure to provide email alerts concerning unusual transactions.

In addition to a UCC violation, all of the cases included allegations of negligent security and breach of contract. In Shames-Yeakel, the plaintiffs alleged that the bank’s failure to implement multi-factor authentication did not comply with a document put out by the Federal Financial Institutions Examination Council (“FFIEC”) entitled “Authentication in an Internet Banking Environment” (the FFIEC Report), and therefore presented questions of fact as to negligence. The JMT plaintiff, in support of its negligence claim, alleged a failure to meet the security standards of “similarly situated” national banks, a failure to implement security procedures that were “commercially reasonable,” and a failure of the bank to comply with its own existing security procedures.

The Judgment on the Shames-Yeakel Motion for Summary Judgment

While the PATCO and JMT complaints have not yet been tested on motion, the Shames-Yeakel plaintiffs have survived a summary judgment motion. In addition to other statutory claims that were particular to the fact pattern at hand, and relevant to this blogpost, the plaintiffs alleged that the bank was negligent in failing to protect the plaintiffs’ online account, and in particular breached its duty to sufficiently secure its online banking system.

As such, the threshold question the court addressed was whether a duty to “sufficiently secure” its online banking existed for the Bank. On that point, the court extrapolated a duty to secure based on a bank’s general duty to refrain from disclosing its customer’s information:

A number of courts have recognized that fiduciary institutions have a common law duty to protect their members’ or customers’ confidential information against identity theft. Although this court could not find an Indiana case addressing the matter, Indiana courts have held that a bank “has a duty not to disclose information concerning one of its customers unless it is to someone who has a legitimate public interest.” If this duty not to disclose customer information is to have any weight in the age of online banking, then banks must certainly employ sufficient security measures to protect their customers’ online accounts.

(citations omitted; emphasis added). Apparently, according to the court, the bank-defendant did not dispute the existence of a duty to protect the plaintiffs’ account from fraudulent access. However the bank did contest the plaintiffs’ allegations that the bank breached its duty and that the breach caused harm to the plaintiffs.

On that issue, the court focused on the FFIEC Report. According to the court, the FFIEC Report indicated that single-factor identification was “inadequate” for securing online transactions of financial institutions. Moreover, a vice president of the bank admitted that the bank did not implement additional security measures beyond single factor identification until after the breach at issue. Thus, the court held that a reasonable finder of fact could potentially conclude that the bank breached its duty. Moreover, since the bank had not reimbursed the plaintiffs for their economic loss, the court ruled that a jury could find that the bank’s failure to secure caused such economic loss (as well as mental and emotional anguish).

Analysis

The Shames-Yeakel case (as well as potentially the PATCO and JMT down the line) is very interesting from a data security breach liability perspective. First, most data breach cases (typically involving suits by consumers or banks issuing credit cards) are dismissed early on for lack of damages or based on the economic loss doctrine. With online banking the damage component is clear (e.g. lost money) and since the main loss of money arguably constitutes “direct damages” (rather than purely economic damages), the economic loss doctrine may not bar an action. As such the court must rule on substantive issues such as the existence a duty to provide “reasonable security” and whether that duty was breached and caused damages. This is what happened in Shames-Yeakel.

The approach taken by Shames-Yeakel was also very interesting. In essence, the Court took a non-binding, completely voluntary “guidance” document and allowed it to serve as the standard of care for “reasonable security” in this context. This FFIEC Report was not an official “standard” and did not reflect any statutory requirements (for purposes of establishing a negligence per se theory). I am sure that the FFIEC and other bodies have put out a lot of papers (formal and informal) on various security and privacy issues, and if other courts are willing to accept these guidance documents as establishing standards (or better stated creating a question of fact for juries) then defendants of data breach cases may face some significant liability in the future. While this particular FFIEC Report may be the appropriate benchmark in this case, I would have liked to see the court explain its rationale in more detail for converting this guidance document into the standard of care (e.g. Why this particular document? What other kinds of documents reports may establish the standard? If it was a report from a non-governmental body would it have the same weight? Must the standard reflect some sort of consensus? What opposing guidance or opinions exist, how much weight are they given in determining or discarding a particular alleged standard?, etc.)

Beyond the court’s decision to arguably elevate the importance of the FFIEC Report, it is not even clear that the report stands for the very broad proposition that single-factor authentication for online banking is inadequate. The following excerpt from the FFIEC Report summarizes the authors' views on the inadequacy of single-factor identification:

The agencies consider single-factor authentication, as the only control mechanism, to be inadequate for high-risk transactions involving access to customer information or the movement of funds to other parties. Financial institutions offering Internet-based products and services to their customers should use effective methods to authenticate the identity of customers using those products and services. The authentication techniques employed by the financial institution should be appropriate to the risks associated with those products and services. Account fraud and identity theft are frequently the result of single-factor (e.g., ID/password) authentication exploitation. Where risk assessments indicate that the use of single-factor authentication is inadequate, financial institutions should implement multifactor authentication, layered security, or other controls reasonably calculated to mitigate those risks.

Note that the FFIC Report indicates that single-factor authentication may be inadequate if it is the only control mechanism or where a risk assessment indicates that the use of single-factor authentication is inadequate. The FFEIC Report then lists layered security or multi-factor authentication as potentially compensating for single-factor authentication (while I will let my security friends weigh in on this issue, as well as identify other potential compensating controls). In short, the FFEIC Report on its face seems to indicate that it is possible to utilize single-factor authentication with other controls such that risk is adequately mitigated. In contrast, the court in Shames-Yeakel stated the following:

In [the FFEIC Report] the Council described single-factor identification (username/password) as “inadequate” to secure the online transactions of financial institutions.

Despite overstating the conclusion of the FFIEC report, however, overall the court’s decision to deny the motion for summary judgment may be okay. It is likely that both parties have contradictory expert testimony on the issue of reasonable security. Second, some testimony existed from the bank's vice president hat appears to establish that only single-factor authentication was used by the bank (although this seems contradicted by the banks’ expert testimony that the bank employed reasonable security measures). Moreover, in general, whether single-factor authentication plus additional security adequately reduced the risk appears to be a factual question. I think the court could have come out with the same ruling without overstating the conclusions of the FFIEC report simply by accurately citing the FFIEC report, the vice president’s testimony, and indicating that both sides had contradictory opinions on the overall issue of whether the bank’s security was reasonable.

Conclusion

The Shames-Yeakel ruling highlights potential significant difficulties for defendants if plaintiffs are able to proceed past the motion to dismiss phase in a data breach lawsuit. Despite the court’s inaccurate description of the FFIEC Report, when the question of whether security controls were adequate to reduce risk to an appropriate level is posed, it will be difficult for defendants to win on summary judgment. Like many other types of lawsuits, it will come down to a “battle of the experts”, and for these cases a “battle of the standards” (e.g. which standards should the defendant have complied with and did they comply with them). As such, for data breach defendants the pleadings phase will be where the street brawl will take place. Defendants will want to (and should) aggressively attack the early “questions of law” (e.g. does a duty exist at all, did the plaintiff suffer legally cognizable harm). If plaintiffs can get past this phase, it seems that it will be a challenge for defendants to win a motion for summary judgment and avoid the prospect of a jury trial (I think, for many data breaches, causation will be the most likely candidate for a defendant victory on summary judgment).

Are We Living in a Post-Disclosure, Opt-In World?

Tanya Forsheit — Mon, 11 Jan 2010 21:09:49 -0700

Today's New York Times Media Decoder Blog features an "on-the-record" discussion with Federal Trade Commission chairman Jon Leibowitz and Bureau of Consumer Protection chief David Vladeck. The question presented: "Has Internet Gone Beyond Privacy Policies?" The FTC (and Congress, for that matter) continue to signal that change may be imminent in the world of online privacy policies and traditional notions of opt-out consent.

The dilemma remains - if consumers don't want to read privacy policies, what would constitute true notice and consent? And, in the Web 2.0 world with consumers' insatiable appetite for on-demand, customized and interactive content, how can that process be handled in a manner that is both meaningful and consumer-friendly? What do consumers really want? And are their expectations regarding privacy simply inconsistent with the modern realities of social networking? Just yesterday, the blogosphere was abuzz with news of the Facebook CEO's comments at the Crunchies Awards that "[p]eople have really gotten comfortable sharing more information and different kinds but more openly and with more people."

At the end of the day, the real question (and answer) may have more to do with what constitutes "personal information," what consumers "reasonably" expect in today's world, and whether the sharing and use of certain kinds of information should be regulated.

In our current legal structure, even though such information flows around the world at breakneck speed, the definition of personal information ultimately depends on where you reside - and that, in turn, has grown out of social and cultural expectations. In the United States this has traditionally meant information that can be used to identify and victimize you (i.e., identity theft) - Social Security number, financial account number, and now, to a growing extent, medical information - although, in some new state statutes, the definition is much more broad. In Europe, the answer, for cultural and historical reasons, continues to be much more expansive, encompassing just about anything that can identify an individual.

So when an individual shares information on Facebook about his or her favorite music, or holiday plans, or the color of a piece of clothing, does that constitute "personal information"? What are consumers' reasonable expectations about how that information, if disclosed publicly -- or not so publicly (e.g., to one's "friends") -- should be used? And should the government regulate the sharing and use of such information by data brokers, social networks, cloud computing vendors, and advertisers?

Last year, the FTC introduced self-regulatory principles for behavioral advertising, but issued a warning that advertisers had one last chance before the FTC would take further steps to regulate. Has that time come? Mr. Vladeck told the New York Times today that the FTC will issue a report in June or July. Chairman Leibowitz said:

I have a sense, and it’s still amorphous, that we might head toward opt-in.

What would such opt-in look like and how would it operate? Is any opt-in solution manageable in the online world? Can any proposed model keep up with rapid changes in technology and consumer expectations? And will this focus on online privacy issues affect and/or eclipse the progress of the many pending federal data security and breach notification bills?

We shall see.

Quickhits: Heartland Settles With Visa for $60 Million

David Navetta — Fri, 08 Jan 2010 16:10:21 -0700

Read all about it here. Note, analyst Avivah Litan of Gartner indicated the "this seems like a very fair settlement, and it seems like Heartland escaped the tremendous costs that TJX incurred - $139 million plus - despite the fact that Heartland's breach was more extensive." In reality TJX settled with Visa for $41 million, and the $139 million figure (wherever she got it from -- this article from June 2009 claims TJX expended $320 million) likely includes both the Visa and Mastercard settlement amounts PLUS the costs and expenses to defend the numerous actions filed against TJX. At this point I doubt that Ms. Litan (or anybody else except Heartland) knows how much Heartland has incurred in expenses to defend the numerous lawsuits and regulatory actions it is facing.

Quickhits: Security in the Ether; Countrywide Settles Data Breach Case

David Navetta — Tue, 05 Jan 2010 11:20:36 -0700

Happy New Decade (2010)! Unbelievably another decade is gone. Information law developments continue to occur at an increasingly fast pace. The InfoLawGroup is catching up from a very busy December, so we will start out the 2010 blogging with a couple quick hits.

Security in the Ether. A very nice article by David Talbot on the security challenges, myths and misperceptions around Cloud computing. The challenge for security pros and lawyers: what is "reasonable security" in the Cloud, how do you perform your "due diligence," how do you document your due diligence process for use in the event of a breach, litigation or a regulatory action, and how do you draft and negotiate contracts for Cloud-based services?

Judge Preliminarily Approves Countrywide Data Breach Lawsuit Settlement. Faced with 35 lawsuits (many of them class actions) arising out of a security breach exposing the records of millions of customers, Countrywide Financial Corp. has chosen to settle. The settlement includes an offer of one year of credit monitoring for up to 17 million people. In addition, customers that suffered identity theft may recover up to $50,000, but only if they actually lost something of value, were not reimbursed and the theft stemmed from the Countrywide breach. Assuming a 20% redemption rate and a cost of $5-$15 per year for credit monitoring, the credit monitoring alone could cost from $17 million to $51 million (probably on the lower end of the scale -- Countrywide should be able to negotiate favorable credit monitoring rates considering the potential volume). Additional costs that Countrywide had to incur include legal fees and breach notice expenses (assuming breach notice laws were triggered). Does this settlement (and others I am aware of other settlements that have been less publicized) indicate a growing fear that the "damages" wall is weakening?

Massachusetts's Highest Court Delivers BJ Wholesalers (and other Retailers) a Data Breach Liability Gift

David Navetta — Wed, 23 Dec 2009 10:41:02 -0700

While the proverbial jury is still out concerning retailers’ sales success this 2009 holiday season, Massachusetts’s highest court (the Supreme Judicial Court or “Supreme Court” as referenced herein) delivered retailers a significant holiday gift in the form of an opinion slamming the door on some financial institutions seeking to recover reissuance costs arising out a retailer’s payment card data breach. The Cumis Insurance Society, Inc. v. B.J. Wholesale Club, Inc. decision (“Supreme Court Decision”) analyzed and ruled upon most of the mainstream legal theories issuing banks have used to attempt to recover card reissuance costs, including breach of contract under a third party beneficiary theory, fraud, negligence, negligent misrepresentation and breach of unfair/deceptive practices laws (in this case M.G.L. Chapter . 93A, section 11). We have previously commented on multiple decisions involving retailer payment card breaches similar to the BJ Wholesale breach and PCI liability in general, including a 3^rd Circuit federal appellate decision that allowed issuing banks to proceed forward with a third party beneficiary breach of contract theory. This blog post dives into and analyzes the Supreme Court Decision, and looks at it in context against similar decisions. Overall, in terms of issuing banks recovering for payment card breaches, the game does not appear to be litigation in the courts, but rather in the backroom contracts and recovery processes contained in the card brand operating regulations that most retailers agree to comply with.

Relevant Facts

The Supreme Court Decision arises out of a payment card breach of BJ’s Wholesale Club, Inc. (“BJs”) involving approximately 9.2 million payment cards and millions of dollars in fraud. The plaintiffs in this case are credit unions and their insurer who incurred costs to reissue the payment cards that were impacted by the breach (as well as costs for fraudulent charges that arose out of the breach). The plaintiffs allege that thieves were able to compromise BJ Wholesale Club’ s systems because BJs and their acquiring bank (Fifth Third Bank) breached two sets of contractual obligations. With respect to BJs, the plaintiffs alleged that BJs breached their contract with Fifth Third bank, which prohibited the storage of the magnetic stripe data after authorization of card transactions. In turn, the plaintiffs alleged that Fifth Third breached its Membership Agreement with Visa and Mastercard requiring Fifth Third to ensure that merchants like BJs did not store magnetic strip data post-authorization.

Alleged Claims and the Supreme Court’s Decision

The plaintiffs alleged several causes of action against BJs and Fifth Third, including breach of contract under a third party beneficiary theory, fraud, negligence, negligent misrepresentation and breach of unfair/deceptive practices laws (in this case M.G.L. Chapter . 93A, section 11). The lower court had granted the defendants a motion to dismiss all of the plaintiff’s causes of action, and the Supreme Court was asked to review the lower court’s decision. Ultimately, as described below, the Supreme Court agreed with the lower court’s decision and upheld it.

Breach of Contract – 3^rd Party Beneficiary Theory

The plaintiff’s alleged that they were the intended third party beneficiary of two separate contracts. First, the Merchant Agreement between BJs and Fifth Third prohibited the storage of magnetic card data, and the plaintiffs alleged they were the beneficiaries of, and should be able to enforce, the agreement against BJs. Second, the plaintiffs also alleged that they were the intended third party beneficiaries of the Membership Agreement between Fifth Third and Visa/Mastercard. Pursuant to the Membership Agreement, Fifth Third agreed to ensure that its merchants did not store magnetic stripe data.

Unfortunately for the plaintiffs, the Merchant Agreement contained the following language:

This Agreement is for the benefit of, and may be enforced only by [Fifth Third] and [BJ’s] and their respective successors and permitted transferees and assignees, and is not for the benefit of, and may not be enforced by, and third party.

Despite this language, the plaintiffs maintained that the prohibition against storing magnetic stripe data was intended to benefit them. Citing a lower court judge who had indicated that any benefits to the plaintiffs in the Merchant Agreement were incidental, and relying on the specific intent referenced in the disclaimer, the Supreme Court upheld the dismissal of the breach of contract claim based on BJs Merchant Agreement.

With respect to the Membership Agreements between Fifth Third and the card brands, the Supreme Court held that the plaintiffs’ third party beneficiaries allegations were conculsory in nature and not supported by any facts establishing Visa or Mastercard’s intent to have them as beneficiaries able to enforce the Membership Agreemwent. While Visa and Mastercard’s operating regulations did not have a specific third party beneficiary disclaimer, both Visa and Mastercard, reserved the right to interpret and enforce such regulations. The Supreme Court viewed this as indicating an intent to prohibit enforcement of the Membership Agreement by others like the plaintiff (the Supreme Court viewed that as consistent with the TJX decision). Interestingly, this case involved the same facts as another BJ Wholesale Club in federal court that allowed the plaintiff-banks to proceed with a third party beneficiary claim. In the Federal case, Visa and Mastercard representatives actually testified at deposition that operating regulations around magnetic stripe data were intended to protect the participants in the system, including issuers. However, the Supreme Court found that the plaintiffs failed to submit that deposition testimony into the court record so that testimony apparently was not considered by the Supreme Court.

Negligence – Economic Loss Doctrine

The Supreme Court did not address whether BJs or Fifth Third, for purposes of a negligence theory, had a duty to employ reasonable security with respect to cardholder data. Rather, the Supreme Court relied on the economic loss doctrine to dismiss the plaintiff’s negligence claim. Under the economic loss doctrine, plaintiffs cannot recover using a theory of negligence unless physical harm or harm to property exists (as opposed to pure “economic loss”). The plaintiffs argued that tangible harm did exist because the physical credit cards had to be reissued after the BJs breach. On this issue, the Supreme Court again followed the BJ Wholesaler’s decision rendered in Federal district court (see the 3^rd Circuit Appellate Decision upholding that rationale), which held that reissuance costs are economic in nature even if related to a physical card. In this case the cards themselves were not harmed since consumers could still use them after the breach. Rather, the Supreme Court found that the plaintiffs chose to cancel the cards for the purpose of avoiding future economic loss.

Fraud and Negligent Misrepresentation

The Supreme Court also rejected the plaintiff’s fraud and negligent misrepresentation claims. The basis for these claims was again tied to the defendant’s contractual promises to comply with the card brands’ operating regulations. In disposing of the fraud claim, the Supreme Court noted that the plaintiffs admitted neither BJs nor Fifth Third made any direct representations to the plaintiffs indicating that they were storing magnetic stripe data. Moreover, despite alleging that they would have changed their behavior had they known about the risk of magnetic stripe exposure, the reality was that the plaintiffs continued to participate in the Visa and Mastercard system. There was no evidence that the plaintiffs would have acted any differently had they been aware that BJs was storing magnetic stripe data.

With respect to the negligent misrepresentation claim, the Supreme Court cited case law indicating that failure to perform a contract does not equate to a negligent misrepresentation claim. Moreover, false statements of opinion or conditions to exist in the future cannot support a negligent misrepresentation claim. In this case, dismissal was warranted because there was no evidence that BJs never intended to comply with its Merchant Agreement at the time it entered into it.

In addition, the Supreme Court held that even if entering into an agreement constituted a representation of compliance with the magnetic stripe disposal requirements, there was no evidence that plaintiffs’ alleged reliance on that representation was justifiable. The Supreme Court essentially held that no reasonable person would rely on the regulations prohibiting the storage of magnetic stripe data. The court pointed to evidence indicating that the participants in the payment card system expected that the operating regulations would be breached because Visa and Mastercard instituted a system of fines and penalties for non-compliance. In addition, the plaintiffs’ purchase of insurance to cover credit card fraud was listed as evidence that plaintiffs anticipated this type of fraudulent activity. Finally, the plaintiffs had received numerous alerts from Visa and Mastercard concerning payment card breaches and fraud involving compromised magnetic stripe data (I find this reasoning very convoluted, at best. The existence of rules to deter certain behavior seems to create some certainty that such behavior should not be happening).

M.G.L. Chapter . 93A, section 11

Since the plaintiffs’ M.G.L. Chapter . 93A, section 11, equitable indemnification and subrogation claims were all based on the dismissed fraud and negligent misrepresentation claims, they were also dismissed. Interestingly, unlike the First Circuit Appellate court’s decision in the TJX matter, the Supreme Court did not consider whether the plaintiffs had a viable cause of action based on the “unfairness” prong of the Massachusetts’ law (e.g. whether BJs information security was so poor that it constituted an “unfair practices).

Conclusion

This case is yet another in the increasingly long series of cases that allow retailer plaintiffs to escape liability arising out of data breach litigation at the motion to dismiss phase. What lessons does it hold for the various payment card stakeholders?

On the merchant side, for any agreement where the merchant is making promises about data security or PCI compliance, make sure there is a strong disclaimer of third party beneficiaries. This will cut issuing banks off on that theory fairly early. Also on the merchant side, be careful of what you say about security and compliance with card brand rules and operating regulations. To the extent a merchant makes representations concerning security (especially direct representations), they may be opening themselves up to misrepresentation claims. The consequences could be serious since negligent misrepresentation and fraud claims are not barred by the economic loss doctrine (and at least one court has provided those theories some legs).

From the issuing banks’ point of view, the question becomes whether litigation is worth it in this context. This is especially true now that both VISA and Mastercard (*I believe, their regulations are not all public) have explicit recovery mechanisms within their systems that can allow an issuing bank to recover without going to court. VISA and Mastercard have both tightened up their contracts and operating regulations to disclaim third party beneficiary theories (although if an issuing bank is to pursue such a theory make sure to get the deposition testimony from the Visa and Mastercard officials referenced in the 3^rd Circuit’s BJs Wholesale case). One area for issuing banks to take a harder look at is State unfair/deceptive trade practice acts. As mentioned above at least one high court has indicated that inherently poor security may amount to an unfair practice. This line of thinking also happens to be consistent with several high profile FTC actions , including of course one involving BJ Wholesale Club.

Quickhits: AMEX settles with Heartland Payment Systems for $3.6 Million

David Navetta — Tue, 22 Dec 2009 16:25:04 -0700

Read all about it: HERE.