Code or Clear? Encryption Requirements (Part 2)
In the last post, I talked about the role of encryption in fashioning a “reasonable” security plan for sensitive personal information and other protected data routinely collected, stored, and used by an enterprise. But lawmakers and regulators are getting more specific about using encryption and managing data that is risky from an ID-theft perspective. Here are some leading examples of this trend.
State Security and Breach Notification Laws
Since California adopted SB 1386, which went into effect in 2003, nearly all US states have enacted security breach notice laws that require notice to affected individuals, and in some cases to public authorities, when a party has reason to believe that the security of protected categories of personal data has been compromised. The protected categories are typically SSN (Social Security Number), driver’s license, financial account or payment card details (usually only if the password or access code is also compromised), and, increasingly, medical data not covered by federal HIPAA privacy protections.
All of these laws make an exemption from the notice obligation if the data were encrypted (some add that this is true only if there is no reason to believe that the decryption key was also compromised). The laws, and regulations adopted under the laws, typically do not specify the level or kind of encryption. For example, California’s Office of Privacy Protection published guidance specifically on the subject of “Recommended Practices on Protecting the Confidentiality of Social Security Numbers” in April 2007, which has only this to say about encryption, on page 11:
“Protect records containing SSNs, including back-ups, during storage by encrypting the numbers in electronic records or storing records in other media in locked cabinets.”
Partly as a consequence of these security and breach notice laws, organizations should limit their use and storage of these categories of personal data to the extent they are really necessary for business operations. Storage on servers or on archived media, and transmission over internal networks and VPN connections, may or may not be sufficiently secure without encryption, depending on the company’s risk assessment and IT security practices. Organizations should encrypt such data when it is resident on laptops or other portable devices and when it is in transit over the public Internet.
Massachusetts and Nevada have recently adopted stricter and more specific rules, however, that may become a model for other states. These increase the regulatory pressure for encrypting protected categories of personal data.
Massachusetts
The Massachusetts Personal Information Security Regulation (201 CMR 17.00) is now scheduled to take effect on March 1, 2010. The Regulation was promulgated by the Office of Consumer Affairs and Business Regulation (OCABR) under the authority of the Massachusetts personal information security law.
The Regulation will require all parties that “own or license” any of the protected categories of personal data concerning Massachusetts residents to encrypt the data in laptops or other portable devices, as well as in wireless transmissions and in transmission over public networks.
Note that the Regulation does not limit its coverage of financial account data to cases where the access code or PIN is compromised, as do most security and breach notice laws. The Regulation extends to any nonpublic financial account or payment card data, as well as to SSNs and driver’s license numbers. The Regulation does not cover medical information, however.
The Regulation mandates a number of “Computer System Security Requirements” (201 CMR sec. 17.04) for businesses that handle the protected categories of personal data. These expressly include the following:
“(3) Encryption of all transmitted records and files containing personal information that will travel across public networks, and encryption of all data containing personal information to be transmitted wirelessly . . .
(5) Encryption of all personal information stored on laptops or other portable devices . . .”
The level and type of encryption are not specified.
Nevada
Nevada recently amended its personal information security law, which already required “reasonable” security measures as well as breach notice (Nevada Rev. Stats. secs. 603A.010 et seq.). The amendments take effect on January 1, 2010.
The law covers SSNs, driver’s license numbers, and payment card or financial account data in combination with an access code or PIN. Medical information is not covered.
Under the amended law, businesses that accept payment cards (credit cards and debit cards) must comply with the Payment Card Industry Digital Security Standard (PCI DSS). In addition, a party handling any of the protected categories of information must encrypt the data if it transfers the data electronically “outside of the secure system of the data collector” or if the data is stored on a device (laptop, USB drive, etc.) that is moved “beyond the logical or physical controls of the data collector or its data storage contractor.”
“Encryption” is defined in the amendments with reference to “established standards,” specifically including FIPS and mentioning the need for standards-based key management as well as encryption protocols:
‘Encryption’ means the protection of data in electronic or optical form, in storage or in transit, using:
(1) An encryption technology that has been adopted by an established standards setting body, including, but not limited to, the Federal Information Processing Standards issued by the National Institute of Standards and Technology, which renders such data indecipherable in the absence of associated cryptographic keys necessary to enable decryption of such data; and
(2) Appropriate management and safeguards of cryptographic keys to protect the integrity of the encryption using guidelines promulgated by an established standards setting body, including, but not limited to, the National Institute of Standards and Technology.”
Thus, while the law itself does not specify the form of encryption, it puts the burden on the user to choose an appropriate and standards-based method.
HITECH
Title XIII of ARRA, the federal economic recovery legislation adopted early in 2009, is labeled the Health Information Technology for Economic and Clinical Health Act (HITECH). It amends the HIPAA medical privacy provisions by adding a federal security breach notice requirement for nonpublic, personally identifiable health information. While HIPAA applies only to certain covered entities (healthcare providers and insurance companies and clearinghouses), HITECH also applies to “business associates” that provide services to those entities. HITECH reaches as well any employers that are covered by HIPAA because, for example, they operate company clinics or manage their own health plans.
HITECH requires notice to affected individuals when there has been a security breach exposing personally identifiable health data. HIPAA already lists 18 identifiers (names, addresses, SSNs, health plan ID numbers, etc.) that must be removed to establish that health records have been “de-identified.” Where compromised records have not been fully de-identified by removing these data fields, HITECH sec. 132400 also recognizes that the information may not be personally identifiable if it is effectively encrypted:
“(b) Implementation specifications: Requirements for de-identification of protected health information. A covered entity may determine that health information is not individually identifiable health information only if:
(1) A person with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods for rendering information not individually identifiable:
(i) Applying such principles and methods, determines that the risk is very small that the information could be used, alone or in combination with other reasonably available information, by an anticipated recipient to identify an individual who is a subject of the information; and (ii) Documents the methods and results of the analysis that justify such determination; . . . .”
Thus, HITECH does not specify a particular form of encryption but leaves it to IT security experts to decide whether the data are effectively unidentifiable in the hands of an unauthorized user. Note that the statute requires covered entities to maintain documentation of this professional analysis, and that the analysis must be based on “generally accepted” principles and methods – which means that professional opinions are likely to refer to published specifications and industry standards.
Red Flags
The 2007 Identity Theft Red Flags Rule (promulgated under the 2003 FACTA amendments to the federal Fair Credit Reporting Act) went into effect in November 2008, although the FTC suspended enforcement until November 1, 2009. (Similar rules were issued by the federal financial regulatory agencies, for the institutions they supervise.) The Rule requires covered entities to develop and implement written policies to prevent identity theft, including recognition of warning signs or “red flags” of suspected ID theft.
The Rule applies not only to traditional financial institutions but to “creditors,” defined as companies that “regularly defer payment for goods or services,” whether or not charging interest or finance charges, and therefore store personal information about individual debtors. Some employers, for example, sell goods or services to employees on deferred payment terms and may be treated as covered entities for that reason. (However, the Red Flag FAQs written by FTC staff take the view that an employer is not a covered entity simply because it sponsors a 401k or other qualified retirement plan that allows participants to borrow from their retirement funds.)
For covered entities, the mandatory policy to prevent ID theft must identify signs of possible security breaches involving certain data, as well as appropriate responses to those alerts. The covered data are SSNs and tax identification numbers, healthcare IDs, financial account and credit/debit card details, personally identifiable medical information, and identifying data from consumer reports (which are often used for employee background checks as well as for credit applications).
The Rule itself does not mandate encryption measures. However, most covered entities will necessarily address encryption in their written anti-ID theft policies. Their “red flags” should also include an alert if there is evidence that encryption keys have been misused, stolen, or hacked.
Merrick Bank v. Savvis Update: Savvis Files Motion to Dismiss
As reported previously, the CardSystems security breach has resulted in a lawsuit brought by a merchant bank (Merrick Bank) against CardSystem's security assessment company (Savvis). The suit alleges that Savvis negligently certified CardSystem's security as compliant with Visa's Card Information Security Program ("CISP"), and negligently represented that CardSystems was compliant. Earlier this month Savvis filed a motion to dismiss this case. This post summarizes and explores that motion.
Choice of Law
The threshold issue addressed by Savvis is which States' law applies to this case (the choices appear to be Utah, Missouri or Arizona). This question is extremely important with respect to Savvis' statute of limitations argument. Under Arizona law, the time limit for filing negligence and negligent misrepresentation claims is two years. It may be longer for other States, such as Utah and Missouri which will be Merrick's counter-argument (note, Savvis contends that Merrick Bank's filing of this lawsuit originally in Missouri was a blatant attempt to avoid Arizona's two year statute of limitation). While this post will not go into the intricacies of the choice of law analysis, it will point out one fact that could hurt Merrick Bank. Both Merrick Bank and Savvis were sued previously by Cumis Insurance Society because of the CardSystem's breach (Cumis represents credit unions acting as issuing banks that allegedly incurred expenses because of the breach -- the Cumis case is still pending and the subject of a future post). In the Cumis case Merrick Bank previously took the position that Arizona law applied to the CardSystem's breach, and a Federal court in California agreed with Merrick. While this circumstance is not the ultimate determining factor on this issue, it will make it more difficult for Merrick Bank to avoid the imposition of Arizona law. It will be interesting to see what Merrick Bank comes back with in its reply brief.
Statute of Limitations
Savvis' first argument for dismissal is procedural in nature. It argues that Merrick Bank failed to file its lawsuit within Arizona's two year statute of limitations ("SOL"). The SOL analysis involves determining when the causes of action "accrued" and calculating how much time elapsed since the accrual date. In Arizona, the SOL begins to run when the plaintiff knew or by reasonable diligence should have known of the defendant's alleged tortious conduct. In this case, Savvis has on its face what appears to be a very favorable timeline: Savvis argues that Merrick Bank's claims accrued no later than July 2005, and its filing of suit on May 12, 2008 was more than three years after that date.
Savvis' contention is based on Merrick's allegation that it knew that CardSystems was not CISP compliant "immediately" after CardSystem's May 2005 breach. In addition, the post-incident forensic report allegedly indicated that CardSystems was not CISP compliant at the time Savvis issued its June 2004 Report on Compliance. Savvis also points to Merrick Bank's January 20, 2006 lawsuit against CardSystems as evidence that it should have known by reasonable diligence that it had a potential claim against Savvis. In other words, if Merrick Bank knew it had a claim against CardSystems in January 2006 why didn't it reasonably know of Savvis' alleged tortious conduct at that time? Note, that even if the January 2006 date it the accrual date, Merrick Bank still would not make the two year SOL.
In addition to its SOL argument, in the alternative, Savvis claims that Merrick's complaint failed to adequately allege negligence and negligent misrepresentation.
Dismissal of Negligence and Negligent Misrepresentation
Savvis argues, that even if its position on the SOL is wrong, Merrick Bank's negligence and negligent misrepresentation allegations are flawed and should be dismissed. Savvis first addressed the negligent misrepresentation claim, citing Restatement section 552(2) which limits negligent misrepresentation liability to loss suffered:
(a) by the person or one of a limited group of persons for whose benefit and guidance he intends to supply the information or knows that the recipient intends to supply it; and(b) through reliance upon it in a transaction that he intends the information to influence or knows the recipient so intends or in a substantially similar transaction.
Based on the comments associated with section 552(2) and Arizona caselaw, Savvis maintains that it can only be liable where the maker of the representation intends to reach a particular person or group known to Savvis, and distinct from the larger class who might reasonably be expected to have access to, and take action in reliance upon, such information. Savvis maintains that Merrick was not part of a defined group for whose benefit Savvis provided its representation of CardSystem's CISP compliance. Savvis argues that Merrick's claim should be dismissed because Savvis did not make any representation directly to Merrick intending to influence its behavior "distinct from the much larger class" of acquiring banks involved with the Visa and Mastercard systems. Rather, Savvis made its representation directly to CardSystems and the card brands. Savvis also pointed to the Court's prior decision in the lawsuit filed by Cumis against Savvis. In that case the same Court dismissed a negligent representation claim because no representations where made to Cumis or its insureds (issuing banks) distinct from the larger class of participants in the Visa and Mastercard systems (as stated above, this blog will have more on that decision soon). Finally, from a public policy perspective, Savvis indicated that interpreting section 552 more broadly would expose it to limitless potential exposure.
In addition, Savvis made quick work of Merrick's negligence claim. According to Savvis, under Arizona law "providers of professional information" such as Savvis may be sued only for negligent misrepresentation. Savvis contends that plaintiffs are not permitted to avoid the limitations set forth in section 552 simply by alleging a general negligence claim. Signficantly, Savvis did not directly attack the merit of negligence claims on the basis of whether it owed any duty to Merrick Bank. (UPDATE -- 062409: as one reader points out, by claiming that the negligence claim is subsumed into the negligent misrepresentation claim, one could say that Savvis is indicating that they owe no duty under a pure negligence theory. I have not read the citations within the case so I don't know if that is the case).
Conclusion
The procedural aspects of this case, including the previous transfer of this matter from a Missouri court, as well as the choice of law, will have a significant impact on the case moving forward. Considering Merrick Bank's prior indication that Arizona law applies, it appears that Savvis has a solid statue of limitations argument that could kick the case out before any hearing on the merits occurs (which will keep the rest of the world in the dark on the substantive merits of this case). On this issue it will basically come down to when Merrick Bank knew, or reasonably should have known, it had a case against Savvis. Obviously Savvis is going to argue for the earliest date possible. Expect Merrick to come back with its own analysis on how it took longer for it to "discover" a valid claim against Savvis (e.g. perhaps the "necessary" facts of Savvis' alleged culpability only came out after depositions or other discovery in the CUMIS case). To the extent there are any factual issues wrapped into this analysis the Court might passe on a motion to dismiss an allow the litigants to engage in some discovery (at least limited to this issue).
On the merits, as previously predicted, the main issue is whether Merrick Bank is a "person" or a "one of a limited group" for whose benefit Savvis supplied the CISP certification information. This is going to be a close question. Unlike issuing banks or their insurers (as referred to by Savvis in relation to the Cumis lawsuit), processors like CardSystems have a direct contractual relationship with acquiring banks. That relationship requires processors, before acquiring banks can retain them, to certify compliance with payment card standards such as CISP. It is difficult to argue that security assessors in this space do not know this. In addition, it can be argued that these assessments are intended for the direct benefit of acquirers. Not only does it give acquiring banks and indication that the risk of credit card fraud is decreased, it also allows them to avoid contractually mandated. fines, penalties and recovery costs in the event of a security breach or otherwise.
It will be interesting to see Merrick's response on this matter. Note that even if this lawsuit does survive a motion for summary judgment there are other fact-based arguments that may allow this case to be dismissed on a different motion (e.g. motion for summary judgment). Not only will the issue of intended class of persons be attacked by Savvis, but also the matter of whether Merrick Bank relied on Savvis' assessment (and not some other factor) will be tested. More to come in the next few weeks. Stay tuned.
PCI Service Provider Contracting
(NOTE: cross-posted at Branden Williams' Security Convergence Blog)
As an attorney focusing on information security and privacy issues, I often get called in to assist companies to understand their legal liability risk around the PCI (self) regulatory system. One of the key areas I get involved in is service provider relationships, and in particular section 12.8 of PCI and service provider contracts. There are many aspects of 12.8 (and its subsections) that are potentially ambiguous and open to interpretation, but this particular article is not going to focus on those. This post concerns the "written agreement" referenced in 12.8.2, which provides in full:
12.8.2. Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.
We could debate whether a "written agreement" is the same of as a "contract" as referenced in version PCI v. 1.1 (under the law there is not much difference between a "contract" and an "agreement"). However, rather than concentrating on mere PCI technical compliance, this blog post will discuss the contract terms merchants should consider in their service provider agreements to actually manage their security risk. Of course service provider agreements should address the PCI requirements, but for merchants concerned about truly mitigating their risk, much more is involved. Coincidentally, I am in the middle of writing a book on payment card contracting that will be released through the American Bar Association, this post summarizes some of the ideas/concepts that will be in that book.
Pre-Contracting Activities
In general, as most understand, organizations cannot "outsource" compliance with PCI. That is to say, while merchants work with service providers that do some or all of the merchant's storing, processing or transmission of cardholder data, interested parties will still attempt to hold the merchant responsible for the service provider's non-compliance with PCI, and the impact of a service provider's payment card security breaches. The service provider contract is one of the key places where this risk can and must be dealt with (the other mechanism for managing service provider risk is insurance, but that is another topic for another day).
The first step in the process is understanding what the merchant has legally obligated itself to. This requires an analysis of the merchant's "upstream" contracts: the various "merchant agreements" it has in place with payment processors and/or merchant banks. If a merchant deals with more than one card brand there could be multiple contracts. In essence, the goal here is to identify the merchant's upstream obligations and transfer those obligations down to any service providers utilized by the merchant. For example, if the merchant agreement requires the merchant to indemnify the payment processor for fines and penalties imposed by card brands, the service provider agreement should require the service provider to do the same. One thing to note. Most modern merchant agreements require merchants to adhere to the relevant payment card brands' operating regulations. As such, merchants should understand those obligations (e.g. Visa's Account Data Compromise Recovery process) as well in order to transfer risk to their service providers.
The second step is attempting to understand the risk posed by the particular service provider the merchant is dealing with. What is the transaction volume the service provider is handling? What controls does the service provider have in place or not have in place? Has the service provider's security been independently assessed (e.g. by a QSA)? What would happen to the merchant's business if the service provider went down (e.g. not all the risk is liability risk)? If the service provider suffers a breach, does it have an incident response plan to mitigate harm and provide notice to the merchant? In addition to general security requirements, depending on the nature of the transaction, this risk assessment may result in specific service provider contractual obligations.
Security Contract Terms
So what security-related terms should be in service provider contracts? This answer to this question will vary depending on many factors (e.g. the type/purpose of the transaction, the data at issue, the laws that apply, the upstream contractual obligations of the merchant, etc.), but the following should be considered:•
(1) Definitions. The payment card world relies on particular definitions and terminology. To avoid confusion, where warranted, some definitions should be incorporated into the contract (e.g. PAN, sensitive authentication information, etc.). This can be achieved in part for some key terms by referencing the PCI standard and/or the PCI glossary.
(2) "Preventative" Contract Terms -- Compliance and Controls. The overall purpose of these terms is to contractually obligate the service provider to certain controls and practices with the hope of preventing non-compliance and/or a security breach (or at least to decrease the risk of those events). In these sections the service provider should be required to comply with the requirements of the PCI regulatory system. This includes, but goes beyond, the PCI standard itself. Other elements of the PCI regulatory system include card brand security programs, FAQs, Guidance papers and other documents issued by the PCI Council, and the card brand operating regulations themselves.
In addition, if there any specific controls or security measures that the merchant wants the service provider to implement and maintain, that should be indicated. Merchants can also draft other standards into the contact, such as ISO 27001, if desired. Last, regardless of the specifics, the service provider should have an obligation to maintain "reasonable security" to protect the sensitive data that is the subject of the agreement. By broadening the duty to "reasonable security" the hope is to avoid cases where technical compliance with PCI was achieved, but the service provider's systems were not actually secure. The reference to "reasonable" establishes an "objective" standard under the law that allows for scrutiny in a litigation context. Note that all duties in this section should be made ongoing and continuous (none of this PCI compliance only matters on the day the contract is signed), and the service provider should be required to comply with changes to the PCI Standard.
(3) Monitoring and Reporting. These contract terms should provide the merchant with the right to monitor and enforce compliance with the service provider agreement, the PCI standard, payment card company security programs, etc. There are many ways this can be achieved, including imposing reporting requirements on the service provider, providing the merchant with security assessment rights or actually requiring a periodic third party audit. With respect to PCI, the agreement should require the service provider to allow the merchant (or third parties selected by the merchant) to conduct quarterly network scans, as well as QSA assessments.
What are the consequences of non-compliance with the agreement or PCI? Monitoring is good, but if non-compliance is found the merchant must also have enforcement rights. Without enforcement mechanisms the service provider's promises may be hallow. Contractual penalties may be put into the contract, indemnification rights (discussed below), termination rights and other remedies may be considered. The key here is to have some leverage to get the service provider to actually comply instead of having to abandon the relationship and find a new service provider. .
(4) Security Incident Response. Service providers and outsourcers act as an extension of the merchant's operations. However, if their incident response procedures are out of sync it could be problematic. Merchants need to understand their service provider's internal incident response procedure and then build contractual obligations that allow the merchant's incident response procedure to seamlessly meld with the service provider's. This section may require service provider to identify a response coordinator to act as a liaison and cooperate fully with the merchant. In addition, it may require an investigation, remedial action, notice and reporting to the merchant and payment card network, collection of evidence, documenting incident response and access to service provider systems, logs and data.
One of the key considerations here is identifying the party responsible for complying with breach notice laws. Arguably, based on the statutes themselves, the primary duty would rest with the merchant, and the merchant would have to pass it on contractually to the service provider (note the primary duty would still reside with the merchant, so if the service provider refused, the statutes still require the merchant to comply).
(5) Rights, Remedies & Indemnification. These terms transfers risk of loss between the merchant and service provider and provide other rights for breach of the service agreement or in the event the service provider suffers a security breach. These terms are amongst the most important in the agreement, and are also the most contentious to negotiate. However, they are also the most important and truly establish the baseline for the merchant's liability in the event the service provider makes a mistake. The following should be considered. Indemnification rights should require the service provider to pay for/reimburse the merchant for claims, attorney fees, lawsuits, fines, penalties and other costs associated with the service provider's non-compliance with the agreement and other requirements of the PCI regulatory system, as well as security breaches (whether compliant or not). If there is a limitation of liability clause, exceptions should be considered for security breaches, fines and penalties due to non-compliance and other issues. The same holds true for any consequential damages limitation clause that finds its way into the contract. Additionally, termination rights should be built into the contract based on service provider non-compliance or security breaches.
(6) Insurance Clause. An insurance clause requiring the service provide to purchase insurance covering security breach notice law compliance, liability arising out of security breaches and other professional errors or omissions should be considered (especially when utilizing smaller vendors). If possible, the merchant should be named as an additional insured on the policy so that it can tap directly into the policy proceeds. This clause should specify required limits and should require the insurance to be primary. In addition, the contract should note that insurance proceeds are not intended to limit the amount of the service provider's liability.
To implement these terms, what I often do is create a security schedule or exhibit that contains all/most of the security-related obligations of the contract. Oftentimes a merchant will be forced to work with the service provider's contract. If the security terms are in a pre-established exhibit, that exhibit can be incorporated into the contract (with some careful drafting of course). On a final note, please understand that while this post has focused on PCI, a framework similar to that described above could be used for other statutory or security requirements, including GLB, HIPAA, EU Data Protection Directive and others. In fact, for organizations with multiple security standards or laws to comply with, a security exhibit or schedule can be an efficient way for addressing all of the requirements at one time and in one place.
Conclusion
At this point in time when reliance on service providers and outsourcers to handle payment card information is high, while the legal liability risk associated with payment card security breaches is significantly growing, the security terms in a service provider contract have increasing importance.
In fact, I counsel my clients to raise some of the terms they want (especially indemnification) at the RFP phase instead of waiting until later. The key here is to create competition between potential service providers not only on price and scope of services, but also acceptance of risk and contract terms (those willing to accept more risk being potentially better candidates than those not so willing). Organizations that wait to request protective contract terms until after they have selected a vendor may find those terms watered down during negotiations, and may be stuck holding all the risk of a service provider mistake (and you know that for most service providers the default is contract terms that completely insulate them from risk - don't settle for that!). As it currently stands the focus of risk mitigation with respect to security are technical controls and other security measures, and the importance of the contract as a risk mitigating tool is overlooked. As litigation increases in this area, for risk-conscious organization, the protections (or lack of protections) in the service provider contracts are going to become very important.
Merrick Bank v. Savvis: Analysis of the Merrick Bank Complaint
The Merrick Bank v. Savvis lawsuit has the potential to change the liability dynamic of the PCI regulatory system. The Savvis case is one of the first known instances of a payment card security assessor being sued by a merchant bank ( the merchant bank is a third party relative to the Savvis-CardSystems relationship). The Merrick Bank compliant alleges that it relied on Savvis' certification of CardSystems as Visa CISP compliant (this matter pre-dated the PCI standard), and that certification was false. After CardSystems suffered a breach exposing up to 40 million payment card records, Merrick allegedly incurred $16 million in payments to the card brands (which was ultimately transferred to issuing banks who suffered losses arising out of the CardSystem breach).
If Savvis is held liable (or even if this case makes it past motion to dismiss or a motion for summary judgment) it has the potential to significantly modify the relative risk of PCI qualified security assessors, and in turn modify the PCI regulatory scheme. This post discusses the two theories of liability alleged by Merrick: (1) negligence; and (2) negligent misrepresentation.
Please note, while I am an attorney this post does not in any way constitute legal advice or a legal opinion, and should not be relied upon to take any action or be the basis for any inaction. The law related to this case is complex and varies from jurisdiction to jurisdiction, and over time. If you are interested in a full legal analysis of potential security assessor liability in a particular jurisdiction, please contact me directly at djn@davidnavetta.com
One further note, the basic rules and general information in this document was derived from various legal research sources. However, one book in particular provided excellent information on the liability of service providers to third parties. Please check it out, and purchase it: Professional Liability to Third Parties (Jay M. Feinman).
UPDATE: Other bloggers/mags are putting together some nice analysis of this case as well: here, here
Relevant Allegations
In order to understand the theories of liability alleged by Merrick, it is important to spot the specific allegations that will ultimately support those allegations. The key allegations, which are repeated throughout the complaint, include:
- Merrick would not allow CardSystems to process Card Transactions until it was certified as CISP compliant
- Savvis was specifically retained to certify CardSystems as CISP compliant, and did so pursuant to a Report on Compliance issued to VISA
- Upon learning of the results of Savvis's Report on Compliance (after CardSystems was listed by Visa as CISP compliant) Merrick allowed CardSystems to serve as its processor
- According to a post-incident forensic analysis, at the time Savvis issued the ROC, CardSystems had been improperly and continuously storing unencrypted cardholder data
- Savvis provided the ROC to VISA for the express purpose and with knowledge that Visa would publish the ROC, and that merchant banks would rely on it to determine whether CardSystems met the CISP standard
- It was reasonably foreseeable to Savvis that merchant banks would rely on its report
- Savvis knew or should have reasonably known that its certification of CardSystems was directly for the benefit and guidance of merchant banks
Analysis
The key threshold issue in this case is whether Savvis owed any duty of care to Merrick with respect to the security assessment it provided to CardSystems, and if so the extent of those duties. Note that the typical method for establishing a duty in a professional services context is via a contract (and when two parties are bound contractually they are said to be in "contractual privity"). In this case, Savvis likely had a contract with CardSystems to perform an assessment, but did not have a direct contractual relationship with Merrick. The lack of contractual privity is main legal obstacle faced by Merrick. Are there other non-contractual theories of liability that apply to Savvis in this context? Merrick Bank has alleged negligence and negligent misrepresentation against Savvis.
Negligence
In the professional service provider/client relationship, negligence is typically a valid theory of liability. For example, it is the basis for many malpractice claims against lawyers, doctors, accountants and architects. The validity of a negligence claim is trickier when it is a third party alleges it. The key analysis is whether the service provider owed any duty to a third party to perform its services in a reasonable and competent manner. Unfortunately, this is not an easy question to answer under the law. There are several different tests courts consider to make this determination, and different jurisdictions may apply different tests or apply the same test in a divergent manner. In addition, whether a duty exists will also rest heavily on the particular facts of the case at hand. That said, in general, some Courts are wary of circumstances that will result in unlimited liability down the line for service providers. The following represents a brief description of some of two of the main tests:
- Foreseeability. In the most basic approach to determining whether a duty exists, the Court asks whether the defendant's actions create a foreseeable risk of harm to the third party plaintiff. Typically both the plaintiff and the risk of harm must be foreseeable. This approach is criticized by some on the basis that the concept of "forseeability" is unbounded and can extend extremely far.
- Balance of Factors Test. This test considers foreseeabilty of harm to the plaintiff as only one of several factors to determine whether a duty exists. Other potential factors include: the extent to which the transaction was intended to affect the plaintiff; the degree of certainty that the plaintiff suffered injury; the closeness of the connection between the defendant's conduct and the injury suffered; the moral blame attached to the defendant's conduct; and the policy of preventing future harm. After argument by the parties, all of these factors are weighed by the Court which then determines whether a duty exists.
Other jurisdictions employ variations of these tests. In Wisconsin state courts, for example, if it is foreseeable that the service provider's actions could harm a third party, then a duty will not exist only if there are overriding public policy considerations. Some courts employing the balance of factor test focus on the relationship between the parties, and specifically if there was any indication that a third party was the intended beneficiary of the professional services rendered.
One more important factor with respect to negligence: even if a duty is found to exist as to a third party, the "economic loss doctrine" may bar recovery of any "economic loss" (loss that is not a personal injury or property damage). This doctrine is also complex and applied differently depending on the jurisdiction. In some jurisdictions it does not apply when services are at issue (as opposed to products). In other jurisdictions, "professional services" such as those provided by lawyers or accountants are not protected by the rule. However, if the rule does apply, it can wholly eliminate the type of damages being claimed by banks like Merrick (and in fact has been used to dismiss negligence claims by issuing banks for security breaches in the TJX case and BJ Wholesalers cases).
Negligent Misrepresentation
Similar to the accountancy field, the payment card security assessment field involves an act of attestation. That is, an opinion/representation as to the status of a company's financial statements (for accountants) or security status against a particular standard (for security assessors). If these "representations" are purposely false or simply incorrect because of mistakes, plaintiffs may have an action for fraud or "negligent misrepresentation." Merrick alleged in this case that Savvis's certification of CardSystems was a negligent misrepresentation because in reality CardSystems was not CISP compliant. Similar to negligence claims (which often overlap with negligent misrepresentation claims because they require proof of a failure to meet the standard of due care), the approaches employed with respect to this theory varies by jurisdiction.
The original position adopted by most courts concerning negligent misrepresentation was that third parties not in privity of contract (or "near privity") could not utilize this theory of liability (see Ultramares v. Touche, 1931). The sixty year reign of the Ultramares case began to erode in the 1960s based on new case law and the eventual adoption of Section 552 of the Restatement (Second) of Torts, which represents the modern approach to service provider negligent misrepresentations to third parties. Section 552 states in relevant part:
(1) One who, in the course of his business, profession, or employment, or in any other transaction in which he has a pecuniary interest, supplies false information for the guidance of others in their business transactions, is subject to liability for pecuniary loss caused to them by their justifiable reliance upon the information, if he fails to exercise reasonable care or confidence in obtaining or communicating the information.(2) * * * liability in Subsection (1) is limited to loss suffered (a) by the person or one of a limited group of persons for whose benefit and guidance he intends to supply the information or knows that the recipient intends to supply it; and (b) through reliance upon it in a transaction that he intends the information to influence or knows the recipient so intends or in a substantially similar transaction.
Interestingly, if you read the Merrick complaint (or the relevant facts laid out above) you will see that many of the words used in section 552 are copied verbatim.
In the typical situation, many of elements in subsection (1) are satisfied in a typical attestation situation. In this case it is not a stretch to say that security assessors supply information that is relied upon by third parties. However, plaintiffs may have to establish that their reliance was justified - the more direct the reliance the better their chances. So if there were other factors that impacted Merrick's decision to hire CardSystems and CISP certification was secondary, the issue of reliance may be more difficult to establish.
In addition, in some cases it may be difficult to establish that the information was "false" (especially when there are gray interpretative areas involved). Likewise, in some cases it may be a challenge to establish that the security assessor violated his or her duty of care. If a security assessor's opinion was reasonable the plaintiff may not be able to establish this element. Of course, if there are obvious ("black and white") mistakes, such as the failure to encrypt cardholder data or the storage of track data, this element will be less difficult to establish.
The elements in subsection (2) of section 552 require both that the service provider have knowledge of the person or group of persons that will be receiving benefit or guidance from the opinion, and that the service provider (or recipient of the information, e.g. CardSystems of VISA) intends the information to influence the plaintiff with respect to a transaction. These knowledge and intent issues often ultimately impact the failure or success of plaintiff's case.
The application of these knowledge and intent requirements may vary by jurisdiction. Some may take a narrow view and require that the service provider specifically intended to induce the plaintiff's reliance for a particular transaction (e.g. the service provider would have had to have known of the transaction, and known that their opinion was the key information that was inducing the plaintiff to go through with the transaction). In some cases, the plaintiff may only need to know of the potential users of the information and the potential use of the information. In addition, some courts may require actual knowledge of the potential users of the information, while others may allow this element to be satisfied if the service provider has reason to know of potential users/uses of the information.
One item to note again with respect to the economic loss doctrine. While it often blocks plaintiffs from recovering under negligence theories, in some jurisdictions the doctrine is inapplicable to fraud and negligent misrepresentation claims. So if plaintiff can establish a negligent misrepresentation claim, it may have a good route to recovery.
Lastly, it must be noted that the negligent misrepresentation claim, in general, has been utilized by issuing banks against merchants already in the TJX case. Although the context is different (TJX involves a merchant's misrepresentation as opposed to a security assessor's misrepresentation), an appellate court refused to dismiss a negligent misrepresentation claim based on indirect representations of CISP compliance. Thus, it may be that the negligent misrepresentation claim against Savvis could have some legs.
Conclusion - Observations of the Merrick Case
The Merrick case represents a potential watershed moment for the payment card security assessor industry (and security auditors in general). If liability is found in this case, and especially if case law is created that goes against Savvis, security assessors will be entering the world of lawyers, doctors, accountants and architects. This world will involve much higher potential for liability, more need to purchase professional liability insurance, increased costs for merchants employee assessors, more rigorous ethical obligations and potentially a higher level of skill and scrutiny applied to security assessment engagements. Over time, this world could start to look more like the world of accountants.
Unfortunately for security assessors, since there is no ability to gain contractual protection through limitations of liability or consequential damages disclaimers, it may be difficult to deflect liability. Significantly, as one can ascertain above, whether plaintiff's claims are valid in this context may involve a fairly fact intensive inquiry. In many instances, legal matters that are highly fact intensive are allowed to proceed past a motion to dismiss or motion for summary judgment -- factual disputes are for juries to decide typically. What this means is litigation leverage for the plaintiffs - with good fact patterns the pressure to settle these cases may be great since victory may come down to who has the better facts and who can argue those facts the best. Moreover, regardless of the facts, arguing in front of a jury always poses a risk.
Based on the foregoing it is very difficult to make any predictions concerning the Merrick Bank case. However, the fact pattern in this case appears favorable to Merrick based on alleged severe violations of CISP and the magnitude of the breach. Merrick has gone out of its way to tailor its allegations to match the legal elements discussed above. Whether those allegations are substantially true remains to be seen. For instance, was the CISP compliance truly the make or break factor that Merrick relied on to enter into a transaction with CardSystems? The complaint mentions MasterCard's security program. Was it justifiable and reasonable for Merrick to rely on CardSystems CISP certification as a proxy for compliance with Mastercard's security rules? Will the court require that Savvis have actual knowledge and intent to induce the particular transaction at issue?
Please note that a potential analogue for security assessors are lawsuits by investors against accountants. Both engage in attestation services that are known to some degree to be relied upon by third parties. There are numerous cases going both ways (some finding liability/some not) with respect to accountant liability to investors who relied on inaccurate financial statements.
Finally, one thing to be aware of with respect to negligent misrepresentation. If a security assessor is made aware that its assessment will be relied upon by a particular third party as the key factor in it deciding to engage in a transaction, the more likely a negligent misrepresentation claim will be valid. QSAs brought into an engagement for this purpose should pause and consider the implications of making a mistake.
Regardless of the outcome, this case will be very interesting to watch and it will surely wake the QSA community up. Once we have more information we will put it up on the blog. In the meantime, feel free to contact me with any questions on this matter.
The TJX Case: It Lives! With a New Theory of Liability: "Unfairness"
However, two financial institutions (Amerifirst Bank and SELCO Community Credit Union - hereinafter "Issuing Banks" or plaintiffs) have pressed forward with an appeal of various dismissals and class certification motions to the U.S Court of Appeals for the First Circuit (the "Appellate Court"). The 1st Circuit's opinion sheds some more (high level) light on the liability risk of payment card data breach security cases. Ultimately, the Appellate Court allowed three theories of liability to proceed, including a previously dismissed theory alleging that TJX's inadequate security amounted to an unfair business practices under Massachusetts's unfair and deceptive business practices law.
The main issue on appeal was the ruling on a motion to dismiss by the U.S District Court for the District of Massachusetts (the "District Court"). TJX and Fifth Third Bank (TJX's merchant bank; collectively referred to as "defendants") had asked the District Court to dismiss all of the counts alleged in the Issuing Bank's complaint, including: (1) negligence; (2) breach of contract; (3) negligent misrepresentation; and (4) unfair or deceptive business practices under chapter 93A (Massachusetts's consumer fraud statute). The District Court dismissed the negligence and breach of contract claim, but allowed the negligent misrepresentation claim and the 93A claim (which was based on negligent misrepresentation) to proceed.
Negligent Misrepresentation
The Appellate Court ultimately refused to dismiss the plaintiff's negligent misrepresentation claim. However, the Court took a different path than the District Court. First, the court noted that the plaintiffs were not alleging any actual misrepresentation, but rather the plaintiff's "negligent misrepresentation" was based purely on the defendants' conduct in performing credit card transactions (in fact, the Appellate Court also referenced the defendants' conduct in the form of entering contracts requiring certain credit card security measures). While conduct can be part of a misrepresentation, the link between the conduct and the implication must be "tight." This link may be established by a combination of words and conduct concerning the alleged misrepresentation.
The Court then pointed to another Massachusetts's State credit card breach lawsuit (Cumis Ins. Soc. Inc. v. BJ Wholesale Club, Inc. 23 Mass. L. Rep. 550 [Mass Super. 2005]) that granted a defendant a motion for summary judgment on the issue of negligent misrepresentation. In that case, the motion was granted because the implied misrepresentation was based purely on conduct.
Based on this the Appellate Court refused to dismiss the negligent misrepresentation count on a motion to dismiss. In its view, the claim was properly pleaded in the complaint, and the proper method for dismissal of the case would be a motion for summary judgment (assuming the plaintiffs could not provide evidence to support their allegations). In its parting words, the Appellate Court ultimately indicated that the claim was "on life support." (e.g. likely to be dismissed on motion for summary judgment).
The Appellate Court also considered the District Court's denial of class certification with respect to the negligent misrepresentation claim, and ultimately upheld the District Court's denial. As such, even if the plaintiffs can establish negligent misrepresentation it appears they will have to do so for each individual plaintiff (rather than a class of plaintiffs).
Chapter 93A "Unfair" or "Deceptive" Trade Practices
The Appellate Court's ruling on the Issuing Banks' 93A claim was actually a bit surprising. The non-surprising aspect was the court's decision to uphold the plaintiff's 93A claim based on negligent misrepresentation. Since the base negligent misrepresentation claim was allowed to stand, the 93A claim based on the misrepresentation also stood, albeit with the same defects according to the Court.
The surprise was the Appellate Court's reversal of the dismissal of the plaintiff's other 93A claim. 93A provides a claim for "unfair" or "deceptive" trade practices as between businesses, and "unfairness" can be established by reference to other appropriate sources of law The plaintiffs had alleged that the defendant's lack of security measures, based on various consent decrees issued by the FTC, amount to a violation of the Federal Trade Commission Act, and therefore an "unfair" practice under 93A. The District Court disagreed and held that consent decrees are not appropriate sources of law for purposes of 93A.
In reversing the dismissal, the Appellate Court recognized that the plaintiffs allegations went beyond consent decrees and relied on an actual FTC complaint against TJX for the very breach at issue, as well as two other security breach complaints alleging that the lack of appropriate security measures equated to an unfair act or practice. The court noted that use of FTC precedent was directly referenced in 93A itself, and that at least one other Massachusetts court had allowed FTC complaints to serve as the basis of 93A actions. The court also noted that "adjudicated" FTC cases were even more potent (although did not clarify whether a "consent decree" amount to an adjudicated FTC case).
Moreover, the Appellate Court rejected TJX's argument that it did not have a close enough business relationship to the Issuing Banks. The Court also refused to limit a 93A actions to "egregious conduct" or "deliberate wrongdoing" at this stage. Rather, this issue was one that would have to be resolved after discovery in the District Court.
Negligence
The District Court dismissed the plaintiffs' negligence claim based on the "economic loss doctrine", which holds that "purely economic losses are unrecoverable in tort and strict liability actions in the absence of personal injury or property damage." On this claim the plaintiffs argued that they had suffered property damage because they had a property interest in the payment card information which the breach rendered worthless. The Appellate Court disagreed. It recognized that electronic data can have value and that value can be lost, but the loss must be as a result of the physical destruction of property. That was not the case for this security breach, and the District Court's dismissal was upheld.
Breach of Contract - Third Party Beneficiary Theory
The Appellate Court upheld the District Court's dismissal of the plaintiff's breach of contract claim. Under this theory, the Issuing Banks argued that they were the intended beneficiary of the contract between Fifth Third and TJX. That contract, however, contained the following express provision disclaiming third party beneficiaries:
This Agreement is for the benefit of, and may be enforced only by, Bank [Fifth Third] and Merchant [TJX] . . . and is not for the benefit of, and may not be enforced by any third party.
The plaintiffs argued that this provision was superseded by the Visa and Mastercard Operating Regulations. The court noted that those regulations do indicate that they prevail in any conflict with the provisions of a merchant account, but in this case the court noted, those provisions did not conflict with the third party beneficiary disclaimer in the TJX merchant agreement. The Appellate Court construed the following language in the Mastercard agreement as disclaiming third party beneficiary rights: [Mastercard] "shall have the sole right to interpret and enforce" [its operating regulations]. The Visa Operating Regulations were more explicit, indicating that those regulations "do not constitute a third-party beneficiary contract as to any entity or person . . . or confer any rights, privileges, or claims of any kind as to any third parties." Note that it does not appear that this type of disclaimer existed in early versions of the Visa Operating Regulations (see the use of third party beneficiary theory in the B.J. Wholesaler's case)
Class Certification
One of the biggest risks for defendants, even where weak theories of liability exist that are likely to yield small recoveries, is the prospect of certification of large plaintiff classes. The District Court held that class certification was not appropriate for the surviving negligent misrepresentation claim and 93A claim (based on negligent misrepresentation). The District Court reasoned that class certification was inappropriate because negligent misrepresentation requires proof that each individual plaintiff relied on the misrepresentation.
The Appellate Court, however, questioned whether the newly revived 93A "unfairness" cause of action would require an individual finding with respect to each plaintiff. The Appellate Court noted that the unfairness theory appears to consider what the defendants did (or failed to do) rather than the Issuing Bank's reliance on any misrepresentation. Ultimately, the Appellate Court did not issue an opinion on the certification of the 93A unfairness claim, and instead remanded the question back to the District Court.
Conclusion
For the most part the Appellate Court's decision represents a victory for TJX, but does open the door to some uncertainty. While the negligent misrepresentation claims (common law and the 93A claim) is viable, class certification has been denied. The plaintiffs have indicated that they will attempt to better define the classes to remedy this defect, but at this point it appears they would have a very difficult road.
The "unfairness" theory under 93A, however, presents a wild card. The "unfairness" doctrine has been used by the FTC to allege that a company's security itself was inherently unreasonable and therefore "unfair." Those FTC cases resulted in consent decrees and therefore the unfairness theory has never been truly tested (one commentator believes it was improperly employed by the FTC). Yet it provides a potential hook, especially in this case where TJX was found to have been in non-compliance with 9 of the 12 PCI requirements. Even so, the question remains whether the Issuing Banks will be able to establish damages under 93A. Notably, considering that most States have a similar deceptive practices laws on the books (although not all of them with private causes of action), this "unfairness" theory could have wider application in the security breach context.
Credit Card Theives So Good They Have Too Much Data...
Some interesting statistics from a new report from Verizon Business. The Washington Post security writer sums it up nicely in terms of the payment card data market:
[Verizon] said it responded to at least 90 confirmed data breaches last year involving roughly 285 million consumer records, a number that exceeded the combined total number of breached records from cases the company investigated from 2004 to 2007. Breaches at banks and financial institutions were responsible for 93 percent of all such records compromised last year, Verizon found.
This has resulted in a huge decrease in the price per credit card in the black market:
As a result, the stolen identities and credit and debit cards for sale in the underground markets is outpacing demand for the product, said Bryan Sartin, director of investigative response at Verizon Business. Verizon found that profit margins associated with selling stolen credit card data have dropped from $10 to $16 per record in mid-2007 to less than $0.50 per record today.
Another Processor Breach?
Rumors abound that another big processor (not Heartland), may have recently suffered a security breach.
Stay tuned.
Is Something Wrong With PCI?
A question being asked in various circles in the wake of the Heartland breach. An interesting post by Michael Dahn over at the Aegenis Group. I started to respond and kept going and going and going. Read his post first and my (somewhat rambling/unpolished ) response is below.
A couple points.
(1) Faulty Logic. You claim that it is faulty logic to conclude after one company getting hacked that the entire PCI program ineffective. On the flip side, it is also faulty logic to conclude that the mere existence of a standard means better security. It really depends on what the standard says, its scope/rigor and how it is applied. Even for seatbelts, some studies have suggested that the existence of seatbelts may increase the likelihood of reckless driving. It is possible to implement a standard simply to give the impression that something is being done...
(2) It's the Risk, Stupid. As you site in your post many individuals considering PCI compliance are only interested in doing "the minimum" to allow them to validate compliance for the year. The problem is that there is no requirement under PCI that the level of risk posed by a given merchant or processor's operation dictate compliance. How can the requirements of PCI be the same for a merchant that does 1000 cards a month and a payment processor that does 100 million cards per month? It only can if the depth/rigor of compliance is higher for the 100 million processor. You are right, there is a difference between having a firewall (check box!) and having a properly configured firewall and having a program in place to ensure/check that firewalls are properly configured. Yet, some view the PCI Standard as not making a distinction between these situations - all are "compliant." And, I contend that that is a problem with the Standard - that concept should be explicitly stated in and made part of PCI. Not that GLB itself is a great standard, but at least it captures the idea of risk:
(a) Information security program. You shall develop, implement, and maintain a comprehensive information security program that is written in one or more readily accessible parts and contains administrative, technical, and physical safeguards that are appropriate to your size and complexity, the nature and scope of your activities, and the sensitivity of any customer information at issue.
(3) The Incentives Are All Wrong. Let me partially take back some of what I said about not taking risk into account. Merchants and service providers are taking risk into account, the risk that they will lose their ability to process credit cards if they are not PCI compliant. That is the motivating factor in the PCI game. With no other real carrot or sticks implemented within the system. Thus the name of the game is getting an ROC as cheaply as possible.
As long as you can find a QSA to validate, or one of your own IT employees for SAQs, you can continue doing business. And of course, since there are hundreds of QSAs, meaning tons of competition, companies can leverage that competition to get an easy pass. QSAs that want to do the right thing get marginalized. In fact, since the QSAs get critiqued by their customers, those that play ball end up rising to the top of the ladder (another flaw in the system). But isnt' the QSA assuming the risk if they rubber stamp, you ask? Go read your contract with the QSA and see how much risk they are actually taking (look at the limitation of liability clause, disclaimer of consequential damages clause and indemnification clauses). Meanwhile the ROC that is submitted is accepted without question. We won't even get into the incentives around an in-house security or IT professional (with perhaps no security training) who is completing a merchant or service provider's SAQ.
So what could change the incentives/motivating factors: carrots and sticks. There is no enforcement unless you are not validated. Nobody checks if you REALLY ARE PCI compliant or whether you ACTUALLY have reduced any risk. There is no penalty if you are validated unless you suffer a security breach (discussed more below).
What about carrots? The benefit of validating PCI compliance is the ability to accept payment cards. That benefit accrues to any company that has validated, whether or not they actually have reduced risk to a reasonable level. What about "Safe Harbor"? I don't think it exists. Many companies I have spoken to are under the impression that if they are PCI compliant they will be immune from fines/penalties and liability. I challenge anybody to identify a LEGAL RIGHT to immunity or a LEGAL OBLIGATION on anybody to provide a Safe Harbor. In fact, Safe Harbor is no longer even identified on Visa's website: VISA Merchant Page. You have to use the Internet Way Back machine to find information on what they used to call "safe harbor": Old Safe Harbor Reference.
Note the even under the old description of safe harbor, it only excused PCI-complaint merchants from fines. It did not prevent an Issuing bank from suing a merchant for the cost to replace cards. So clearly, for merchants that engage in rigorous PCI-compliance there is no carrot that comes their way if they happen to suffer a breach.
Frankly, the lack of proper incentives and motivation around PCI compliance make me wonder about my last sentence in (1) above.
(4) The Ultimate Stick - Getting Your Pants Sued Off. Yes, high profile breaches and lawsuits can deter bad behavior in the PCI realm. However, there are a couple issues here as well. As set forth below it appears that some companies believe that if they validate PCI compliance they are in a Safe Harbor that protects them. Therefore they (wrongly) may not fear lawsuits. Secondly, for those that use QSAs, there is a belief that if they are validated PCI compliant and they really aren't, that it will be on the QSA. Again read your contract with your QSA to see how much liability they are actually taking. Perhaps more high profile incidents like Hannaford and Heartland will act as a deterrent, but I question how much it is now. This is especially true because lawyers are often not involved in the PCI compliance process and those security pros that are do not have the experience pr expertise to gauge actual legal risk (unless they have law degrees and have practiced - which is a whole other post). Therefore, it may not be fully taken into account.
Thoughts?
More Companies Validated as PCI Compliant Breached
Despite the changes to PCI that went into effect in October 2008, more PCI-compliant entities are suffering security breaches. Added to the list of Hannaford, Best Western and Forever 21 are Heartland Payment Systems and RBS Worldpay.
The Heartland Payment Systems breach was reported on January 20, 2009 in the midst of President Obama's inauguration. While the extent of the breach is unknown, some commentators are speculating that it could be the biggest breach in history. Heartland reportedly processes 100 million transactions a month, but is not certain how many payment cards were exposed. More information here.
RBS Worldpay suffered a breach that reportedly exposed 1.5 million cardholders, and resulted in 100 instances of fraud. The breach included not only cardholder data, but also involved the Social Security numbers of about 1.1 million account holders. More information here.
These incidents again raise the question as to the efficacy of PCI. Of course it is possible that these processors made a mistake in validating their PCI compliance. Nonetheless, premilimary reports indicate that the Heartland breach was caused by malware installed behind Heartland's firewall on its internal network. Assuming PCI was complied with, the issue becomes whether or not encryption during transmission over Heartland's network would have prevented the exposure, and the further question will be whether failing to encrypt internally is "unreasonable" as a matter of law (getting to a T.J. Hooper rationale).
More to come I am sure. Lawsuits? Regulatory scrutiny? Will this be a Card Systems or TJX situation, or something less severe? ISC will keep you posted.
The New Path to PCI Liability: 3rd Party Beneficiary Theory
Merchants face a potentially huge liability if they suffer a security breach exposing payment card data. Issuing banks (those banks that issue credit cards to consumers) have filed lawsuits to recover reissuiance costs allegedly ranging from $20-$50 per card (multiplied by thousands or millions of cards depending on the magnitude of the breach). A recent decision from the U.S. Court of Appeals for the Third Circuit ("3rd Circuit" or "Appellate Court") appears to have expanded the potential liability merchants face for payment card security breaches.
In Sovereign Bank v. B.J. Wholesale Club & Fifth Third Bank, No. 06-3392/3405 (3rd Circuit, July 13, 2008)(hereinafter the "BJW Decision"), while the Appellate Court affirmed the lower court's dismissal of most of the claims against B.J. Wholesale Club, it reversed the lower court's dismissal of Sovereign Bank's breach of contract action that was based on a third party beneficiary theory. This article explores how the Appellate Court reached its decision, how the decision could increase the legal risk faced by merchants that suffer security breaches and potential actions merchants can take to better understand and mitigate their legal risk.
Background
The BJW Decision arose out of a payment card security breach suffered by B.J. Wholesale Club ("BJW") that was first reported in March 2004. Criminals were able to steal (and commit crimes using) the magnetic stripe information from payment cards stored by BJW. In reaction to this security breach, Sovereign Bank and the Pennsylvania State Employee's Credit Union (hereinafter "Issuing Banks") incurred costs to reissue the payment cards that were the subject of the BJW breach. Litigation ensued in 2005 when the Issuing Banks separately sued BJW and BJW's merchant bank (Fifth Third Bank) to recover their reissuance costs. The federal lawsuits were eventually consolidated in the U.S. District court for the Middle District of Pennsylvania (the "Lower Court") and alleged the following causes of action: (i) negligence; (ii) breach of contract (Third Party Beneficiary Theory) and (iii) equitable indemnification; (iv) breach of fiduciary duty and (v) promissory estoppel. The Lower Court fully granted the defendants' motion to dismiss and motion for summary judgment, which lead to the plaintiff's to appeal (see Sovereign Bank v. B.J. Wholesale Club, 385 F.Supp.2nd 183 [M.D. Pa. 2005] and Sovereign Bank v. B.J. Wholesale Club, 427 F.Supp.2d 256 [M.D. Pa. 2006]).
Relationship Between the Players in the Payment Card System
In order to understand the Appellate Court's ruling one must first be aware of the relationships (contractual or otherwise) between the players in the payment card system.
In this case, BJW was the merchant that accepted payment cards from consumers (some of whom were issued their cards by the Issuing Banks). In order to accept credit cards and become part of payment card networks such as Visa or Mastercard, merchants must work through and contract with an acquiring bank (a.k.a. "acquirer" or "merchant bank"). In this case Fifth Third acted as BJW's merchant bank and had a "Merchant Agreement" in place with BJW. In turn, moving upstream, Fifth Third had a "Member Agreement" in place with VISA. Pursuant to the Member Agreement, Fifth Third became a "member" of the VISA network and agreed that it would comply with VISA's Cardholder Information Security Program ("CISP") and VISA's Operating Regulations (note that at the time of the breach the PCI Standard was not in effect and each card brand had its own security standard).
Sovereign Bank, was one of the Issuing Banks that had issued payment cards to various consumers that were impacted by the BJW security breach. Sovereign Bank is also a member of the VISA network by virtue of its own Membership Agreement with VISA. However, the Issuing Banks had no direct contractual relationship with Fifth Third or BJW. A graphic representation of the contract chains can be found at this link: BJW Contract Relationship Chart.
Sovereign Bank's Breach of Contract Allegations
Despite not having a direct contractual relationship with Fifth Third, Sovereign Bank alleged a breach of contract claim based on Fifth Third's breach of the Membership Agreement between Fifth Third and VISA. Although it was not a party to the Membership Agreement, Sovereign alleged that it was an intended third party beneficiary of the agreement (see BJW Contract Relationship Chart).
Pursuant to the Membership Agreement, Fifth Third agreed comply with VISA's Operating Regulations (which included VISA's Cardholder Information Security Program). The version of the Operating Regulations applicable to this case provided the following:
- Fifth Third agreed to ensure that its merchants (BJW in this case) complied with the Operating Regulations
- Fifth Third agreed to enter into a Merchant Agreement with each of its merchants requiring each merchant to comply with VISA's Operating Regulations
- A prohibition against retaining or storing the data encoded on the magnetic stripe on the back of payment cards after a transaction is authorized (this is essentially the same prohibition set forth now in section 3.2 of the PCI Standard), and a duty for Fifth Third to impose this obligation on merchants like BJW
- Provisions concerning dispute resolution between members, including chargeback and representment procedures, and arbitration provisions.
Significantly the Operating Regulations in place at that time did not eliminate any other rights an issuing bank may have to pursue any legal remedy that may otherwise be available. As discussed further below, unless Visa's Operating Regulations have changed, this suggests that there is no real "safe harbor" for PCI compliance.
Sovereign Bank alleged that both BJW's failure to delete the magnetic stripe data, and Fifth Third's failure to ensure BJW's compliance with the deletion requirement constituted a breach of the Operating Regulations by Fifth Third. Sovereign Bank further contended that these contract breaches allowed the unauthorized access to, and use of, payment card data at BJW, and that Sovereign Bank was legally obligated to reimburse cardholders for fraudulent charges that resulted. Moreover, the resulting unauthorized access to payment card data also required Sovereign Bank to incur the expense to reissue the compromised payment cards. Finally, the Issuing Banks alleged that their customer goodwill was adversely impacted by the BJW breach. The Appellate Court was called upon to rule on these issues in a motion to dismiss/summary judgment context.
The Issue to Resolve: 3rd Party Beneficiary Theory.
The Appellate Court considered the following issue:
Was Sovereign Bank an intended third party beneficiary of the Member Agreement between Fifth Third and VISA?
Although Sovereign Bank conceded that it is not an express third party beneficiary of the Member Agreement between Visa and Fifth Third, it based its argument on § 302 of the Restatement (Second) of Contracts (which had been adopted under Pennsylvania law, which governed this case):
Intended and Incidental Beneficiaries
(1) Unless otherwise agreed between promisor and promisee, a beneficiary of a promise is an intended beneficiary if recognition of a right to performance in the beneficiary is appropriate to effectuate the intentions of the parties and either:
(a) the performance of the promise will satisfy an obligation of the promisee to pay money to the beneficiary; or
(b) the circumstances indicate that the promise intends to give the beneficiary the benefit of the promised performance.
(2) An incidental beneficiary is a beneficiary who is not an intended beneficiary.
In the context of § 302, the court framed the issue as follows:
Under § 302, Sovereign's contract claim depends on whether "the recognition of a right to performance" in Sovereign is "appropriate to effectuate the rights of" both Visa and Fifth Third in entering into their Member Agreement and whether "the circumstances indicate that" Visa (the promisee) "intended to give Sovereign the benefit of the promised performance."
To establish whether Visa intended to give issuing banks like Sovereign the ability to rely on Fifth Third's promises in the Member Agreement, Sovereign relied on the deposition testimony of Visa's representative, Alex Miller. Miller testified that he was not aware of any intent on Visa's behalf to create a direct right to benefit third parties, and that no documents existed that allowed issuing banks to "step into [Visa's] shoes" to enforce the Membership Agreement with Fifth Third.
However, Miller also stated:
It's fair to say that the core purposes of the operating regulations is to set up the conditions for participation in the system, to set up rules and standards that apply to that ultimately for the benefit of the Visa payment system, the members that participate in it and other stakeholders such as cardholders, merchants and others who may participate in the system as well.
Miller further testified that the purpose of Visa Operating Rules (including CISP in this case) was to maximize the value of the Visa system as a whole, including "to protect issuers." Fifth Third argued that Miller's statements evidenced that Visa's Operating Regulations were intended not to benefit any individual member or class of members, but the Visa system as a whole.
Sovereign argued that Visa's Operating Rules were specifically intended to benefit issuers. In addition to Miller's testimony, it pointed to an August 1993 memo sent by Visa to its members that specifically alerted members of the (then) new requirements to delete magnetic stripe data (hereinafter referred to as "August 1993 Memo").
That memo started off with the following:
To protect the Visa system and Issuers from potential fraud exposure created by databases of magnetic-stripe information, Section 6.21 has been revised. Effective September 1, 1993, the retention or storage of magnetic stripe data subsequent to the authorization of a transaction is prohibited. Acquirers are obligated to ensure that their merchants do not store the magnetic-stripe information from Visa Cards for any subsequent use.
Sovereign also relied on a May 2003 article printed online by Visa entitled "Issuers and Acquirers Are At Risk When Magnetic-Stripe Data Is Stored," which indicated that magnetic stripe data compromises "impact[] Issuers" (hereinafter referred to as "May 1993 Memo).
The Appellate Court's Decision and Reasoning
The Appellate Court considered the arguments by both sides and ultimately held that genuine issues of material fact did exist as to whether Sovereign was an intended beneficiary of the Member Agreement between Fifth Third and Visa, and therefore the case should be remanded for further proceedings (e.g. trial) rather than decided on a summary judgment motion.
The Appellate Court rejected Sovereign's reliance on the May 2003 Memo, indicating that it simply stated the reason for the prohibition against retention of magnetic stripe data. However, the Appellate Court agreed that the August 1993 Memo and Miller's "core purpose" testimony (referenced above), raised genuine issues of fact.
The court noted that Sovereign is a Visa member and that the core purpose the Operating Regulations according to Miller was to benefit members that participate in the Visa system. Just because Miller also indicated the Operating Rules were to benefit other stakeholders (such as cardholders, merchants and others who may participate in the system), the possibility that Visa intended to benefit individual users such as Sovereign was not negated.
Moreover, the Appellate Court held that the August 1993 Memo clearly stated that acquirers (such as Fifth Third) must act to protect Issuing Banks (like Sovereign) by ensuring that merchants (like BJW) do not retain magnetic stripe data. The Appellate Court held that this piece of evidence alone was sufficient to get Sovereign past summary judgment. Based on the foregoing, the Appellate Court remanded Sovereign's breach of contract claim for further proceedings (e.g. trial in front of a judge or jury).
Analysis -- Increased Merchant PCI Liability
Similar to Minnesota's Plastic Card Protection Act (discussed at this LINK), this decision has the potential to significantly increase the liability risk faced by merchants that are not compliant with PCI and that suffer a security breach.
First, although the Appellate Court's breach of contract decision only involved the acquirer and the issuing bank, merchants such as BJW may ultimately be liable for the issuing bank's costs. The source of this liability will also be contractual. However the contract at issue in this case is the direct contract between the merchant bank and the merchant (hereinafter "Merchant Agreement" -- see BJW Contract Relationship Chart). As the court ruled, this case will now be remanded to the lower court. A judge or jury could find Fifth Third liable to Sovereign for reissuance costs, or Fifth Third and Sovereign may settle the case based on the strength of Sovereign's breach of contract claim. If Fifth Third wanted to recover the damages it paid to Sovereign, it may be able to rely on language in the Merchant Agreement between it and BJW to recover directly from BJW.
It is not atypical for a merchant to enter into a very one-sided Merchant Agreement with an acquiring bank (or the acquiring bank's processor). Such Merchant Agreements often require the merchant to comply with the card association's operating rules, security program and/or PCI. A sample of how such language may read is as follows:
Merchant agrees to comply with all security standards and guidelines that may be published from time to time by Visa or MasterCard and any other applicable industry security standards, including, without limitation, the Visa U.S.A. Cardholder Information Security Program ("CISP"), the MasterCard Site Data Protection ("SDP"), and the Payment Card Industry Data Security Standard (the "Security Requirements").
If BJW agreed to comply with Visa's Operating Rules and/or CISP, Fifth Third may have a right to recover any damages paid to Sovereign under a breach of contract theory (BJW having breached the Merchant Agreement).
In fact, merchant banks may have an explicitly contractual right to recover reissuance costs they are forced to pay issuing banks. It is likely that the Merchant Agreement requires the merchant to indemnify the merchant bank for liability it incurs because the merchant allowed a security breach. A sample of how such language might read is as follows:
Merchant agrees to indemnify Acquiring Bank, Member, the Associations, affiliates, officers, directors, employees, agents and issuing banks from any losses, expenses, costs, liabilities, and damages of any and every kind (including, without limitation, our costs, expenses, and reasonable legal fees) arising out of any claim, complaint, or chargeback caused by the merchant's noncompliance with this Agreement, any Security Requirements or the Association Rules.
If similar language exists in the Merchant Agreement between BJW and Fifth Third, Fifth Third may demand that BJW indemnify it for any issuing costs that Fifth Third is required to pay to Sovereign. Of course, if BJW refuses, Fifth Third will again need to file a claim against BJW for breach of the Merchant Agreement. In short, by allowing an issuing bank to use the Visa Member Agreement to go after the merchant bank, the Appellate Court opened a path to merchant liability for the costs incurred by the issuing bank to reissue credit cards. The path starts with the Member Agreement, goes through the Merchant Agreement and ends up at the merchant.
PCI Compliance as a Defense - Existence of "Safe Harbor?"
Despite the existence of this contractual path to liability, the question arises whether a merchant's compliance with the PCI and card association operating regulations will insulate the merchant from liability if it suffers a payment card security breach. Unfortunately, from the issuing bank's point of view the merchant's PCI compliance status is irrelevant - the issuing bank still must pay to reissue payment cards after a security breach of a PCI-compliant merchant. There are several points which may illuminate whether PCI compliance provides an automatic "safe harbor" from liability.
First, at least under the version in effect during the BJW case, according to the Appellate Court, issuing banks were not precluded by Visa Operating Rules from pursuing any available remedies at law. Thus, even if a merchant had fully complied with PCI and the applicable operating rules, an issuing bank's status as a member of Visa or Mastercard does not block it from going after merchants. In fact, even if an issuing bank had agreed with Visa to refrain from pursuing merchants that were PCI compliant, the only party that could enforce that agreement would be Visa (unless, ironically, the merchant could be argued to be a third party beneficiary of the Member Agreement between Visa and the Issuing bank). Significantly, while compliance with the industry standard for protecting cardholder information will offer merchants a strong defense, it is still possible that a merchant could be liable under other theories of liability (e.g. negligence) if a court finds that the PCI standard itself is inadequate (see e.g. T.J. Hooper case).
Second, a PCI-compliant merchant's liability will be largely contingent on the language set forth in the Member Agreement between the acquiring bank and the card association, and the Merchant Agreement between the acquiring bank and the merchant itself. If the Member Agreement makes the acquiring bank responsible for merchants' security breaches in general (regardless of PCI compliance) and the Merchant Agreement requires the merchant to indemnify the acquiring bank for any losses, then the path to liability described above could apply. In such a case, in order to "block" the path from issuing bank through the Member Agreement, the Member Agreement would have to contain specific language providing a PCI "safe harbor" (alternatively, as discussed further below, the merchant may be able to negotiate a "safe harbor" in the Merchant Agreement to block the liability path).
Significantly, gaining access to the card associations' operating rules and Membership Agreements has been notoriously difficult. Without the ability to read to those documents it may be hard to ascertain the scope of the liability risk under this theory since the merchant will not be aware of the merchant bank's obligations to the card association in the event of a merchant security breach.
Limited Applicability?
Variations in the terms and conditions of Member Agreements and card association operating rules may also impact the path to merchant liability. As such, the holding in the BJW may not apply if there have been changes in subsequent versions of these documents. For example, if the current versions of Visa's Member Agreement specifically precludes enforcement of the Merchant Agreement by third parties, then the issuing banks would not be able to use employ the 3rd party beneficiary theory used by Sovereign. However, if the Member Agreement between the card association and acquirer bank remains silent, then the same rationale in the BJW decision could apply.
With respect to Visa's Member Agreements, where intent is unclear, issuing banks may be able to rely on Mr. Miller's deposition testimony in the BJW decision. As such, cases brought in jurisdictions that follow section 302 of the Restatement (Second) of Contracts may be prone to agree with the Appellate Court's decision. Again, unfortunately, merchants will not be able to ascertain the full extent of their risk unless they can get access to the acquiring bank's Member Agreement or be informed of whether it prohibits third party beneficiaries.
Merchant Actions to Potentially Reduce the Risk of Liability
There may be some steps that merchants can take to reduce their risk of liability for a payment card security breach. The BJW path to liability is a two step process. First the issuing bank must successfully sue the acquirer for breach of the Member Agreement between the card association and the acquirer, then the acquirer must pursue the merchant under the Merchant Agreement. Thus, merchants should consider both steps to determine the extent of their potential liability and for purposes of cutting off the path.
- Attempt to Determine Existence of 3rd Party Beneficiary Prohibition in Member Agreement
The first step on the path to liability under the 3rd party beneficiary theory is whether the Member Agreement between the card association and acquirer bank precludes third party enforcement of the Member Agreement. Merchants should ask their acquirer banks if they can examine their Member Agreement. It is likely, however, that the acquirer bank will be unwilling to provide the agreement itself. If not, the merchant should at least attempt seek assurances that there is a prohibition against third party beneficiaries. If the Merchant Agreement does not contain such a prohibition, then it is possible that the first step on the BJW liability path is open. Therefore, the merchant should seek to cut off the second step on the path, the Merchant Agreement.
- Negotiate a "Safe Harbor" in the Merchant Agreement
Obviously, the merchant has little control over what third party beneficiary terms its acquirer may have agreed to in the Member Agreement. However, a merchant does have some control over the terms it agrees to in its Merchant Agreement with its acquirer. It may be possible for a merchant to cut-off liability even if the issuing bank has been successful as a third party beneficiary of the Member Agreement. When entering into negotiations with acquirers (or their payment processors) merchants should attempt to negotiate a "safe harbor" into their Merchant Agreement. In essence, the safe harbor language would indicate that in the event of a security breach involving payment card information, if at the time of the breach the merchant was compliant with PCI and/or the card association's operating rules, the acquirer would have no right to indemnification or any other recourse against the merchant. Rather than relying on (mostly likely) illusory safe harbors identified by the card associations, this would provide a direct right to avoid contractual liability if the merchant has done everything it promised with respect to PCI.
The parameters of the safe harbor should be defined to protect the merchant. First, the merchant agreement should identify a truly independent third party responsible for performing a post-breach PCI/operating rules audit, and set-up a process for the audit itself (note that one issue to consider is that the auditors findings will not be protected by attorney-client privilege, so caution is warranted). This third party would be the last word on whether the merchant was PCI-compliant at the time of the breach. Currently this post-incident response is performed by auditors hand-picked by the card associations, and some believe, because of close relationships these auditors have with the card associations, they could be less than "neutral" when performing these audits. Second, the standard for compliance should not be strict compliance. Rather, the merchant should be deemed to be compliant unless it is in material non-compliance with PCI. Finding technical non-compliance with some section of PCI or card association rules, as any security expert can tell you, is not difficult. Even better would be language requiring the non-compliance with PCI to be the actual cause of the security breach at issue - if the non-compliance was not in anyway relevant to the breach the merchant would not be liable. Last, if possible, the Safe Harbor should include indemnification from the acquiring bank if the merchant is PCI-compliant at the time of the breach. This would allow the merchant to cut off direct suits from other stakeholders (consumers, issuing banks, card associations). Admittedly, however, it will likely be difficult to convince an acquiring bank to go this far.
Whether a merchant will be able to negotiation a safe harbor or any other term of the Merchant Agreement will depend a large part on negotiating leverage. Larger merchants with clout, or any merchant willing to "shop around" between multiple acquiring banks, will be in the best position to negotiate favorable terms. Some of the same negotiating leverage issues apply for this route as well.
- Limitation of Liability
In addition, merchants should consider a limitation of liability that caps the merchant's potential liability in the event of a security breach exposing credit card data. Merchants that have expended significant resources in becoming PCI compliant may be able to justify the cap more easily.
- Insure Against Payment Card Security Breaches
The insurance market has created information security and privacy liability policies which may cover liability arising out of a payment card breach. Since the risk of a security breach can never be 100% eliminated, insurance may be a good risk management tool to transfer unwanted risk. The key for utilizing insurance is to make sure the risk the merchant desires to transfer is actually transferred in light of the terms, conditions and exclusions in the insurance policy.
Conclusion
Merchants can no longer afford to treat PCI compliance as a pure security issue. Merchants should carefully analyze their PCI liability risk and determine ways to mitigate that risk. Laws like Minnesota's Plastic Card Protection Act and the BJW decision have likely increased the risk significantly. The potential for huge damage is great - issuing banks have alleged that the costs of reissuing payment cards range from $20-$50 per card (multiplied by thousands or even millions of cards). For smaller and medium companies highly reliant on payment cards, the failure to address this risk ahead of time can mean bankruptcy. For larger retailers, the prospect of spending tens of millions of dollars defending and settling lawsuits against issuing banks and merchants should spur on a careful examination of all merchant agreements, and the possible shopping around for merchant banks and payment processors that provide reasonable terms.
As such, more than ever, merchants must work with their legal counsel and risk managers to understand and mitigate the risk. Merchant lawyers must analyze their clients' current contractual relationships with acquiring banks and assist in negotiating favorable terms with payment processors and merchant banks. Since the risk is somewhat unpredictable and may be difficult to eliminate, information security and privacy risk insurance should also be considered. Lawyers should carefully analyze the scope of information security liability coverage to make sure their PCI risk is being transferred to the insurers. If the proper steps are taken, merchants may be able to avoid or mitigate significant losses in the event of a security breach.
New Jersey Security Requirements (including encryption of personal information)
A proposed New Jersey regulation that may be come law in 2008. It has very specific requirements around encryption of personal information at rest and in transit. In particular, if these rules pass organizations would be required to encrypt according to the Federal Information Processing Standard (FIPS) recommended standard, which is the Advanced Encryption Standard (AES) 128-bit to 256-bit. This law also has 20 other fairly specific security requirements.
How will these specific requirements related to other State, Federal, International security requirements? Do the specifics in this regulation harken a movement away from a "technology neutral" approach to information security regulation?
TJX -- Banks' Motion for Class Certification Denied
This is the court's decision denying class certification by the banks suing TJX. Have not fully read through it, but interestingly it appears that the nature of the negligent misrepresentation claim (e.g. the reliance requirement) is one of the reasons that class cert. was ruled inappropriate.
