FAQ on Nevada's Security of Personal Information Law (NRS 603A)
InfoSecCompliance ("ISC") was recently asked by a prospective client to provide a summary of Nevada's Security of Personal Information law (NRS 603A) and a recent amendment to the Security Law that incorporated the Payment Card Industry Data Security Standard ("PCI"). ISC decided to try something new and create a Frequently Asked Questions document around the PCI requirements contained in the Security Law. For better or worse (after sinking in 15 - 20 hours) ISC ended up doing FAQs for the entireNevada Security Law. This turned out to be a much bigger work than originally anticipated, so ISC is going to do a five-part blog post series breaking down the Nevada Security Law into (hopefully) digestible parts.
This FAQ is broken down into six sections that will be posted over five posts over the next week or so. The postings will be broken down as follows:
Post One: The Basics of Nevada's Security Law and Destruction of Records
Post Two: Security Breach Notice
Post Three: Required Security Measures
Post Four: Encryption and PCI Compliance
Post Five: Remedies, Penalties and Enforcement
I will update this page with new links to each post as the post is made. This is the first time I have tried to convert a complex law into an FAQ format and I am not certain how it turned out. The goal was to make the law digestable by not only lawyers, but also security and privacy professionals. If you have the time, please leave a comment or send me an email and let me know if it worked for you or what could be improved. If this format is effective, ISC may do it for other laws as well (where possible).
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. This law is complex and additional research is necessary. If you are interested in a full legal analysis please contact me directly at djn@davidnavetta.com.
PCI DSS Incident Response: The Legal Perspective
The SANS Institute InfoSec Reading Room recently published an article by Christian J. Moldes entitled PCI DSS and Incident Handling: What is required before, during and after an incident. Moldes' whitepaper is a good starting point for developing an incident response plan to address payment card security breaches. The paper hits upon the key aspects of payment card security breach handling from an information security professional's point of view. The paper, however, speaks little of the legal implications of a payment card security breach, and the incident response considerations that arise out of those implications.
In today's environment, one of the most significant risks associated with a payment card breach is legal liability (whether it be contractual, regulatory or via class action lawsuits). The following legal risks may present themselves in the wake of a payment card security breach suffered by a merchant: (1) consumer class action lawsuits; (2) issuing bank class action lawsuits; (3) merchant bank lawsuits against the merchant; (4) payment card recovery processes (such as VISA Account Data Compromise Recovery process); (5) payment card fines and penalties; (6) federal regulatory actions; (7) state AG regulatory actions; and (8) shareholder lawsuits (based on misrepresentations/omissions concerning data security).
This post borrows in part from the relevant sections of Mr. Moldes framework and interjects some legal considerations and incident response planning into the fray. This article views incident response from the merchant's point of view (as opposed to a service provider's POV). Please note, as discussed further below, if there is one thing to take away from this article it is that merchants should consider hiring their own independent forensic assessor if they are forced by VISA to hire one of Visa's "Qualified Incident Response Assessors."
(1) Preparation Phase
-- Contractual Obligations. As the whitepaper indicates, the PCI Standard itself does not have many requirements concerning payment card security breach incident response. Rather the card brands themselves dictate response requirements through their various information security programs. In reality, however, a merchant's true obligations in a security breach situation are dictated by the merchant agreement it has with a payment processor or acquiring bank. Most modern merchant agreements will require the merchant to comply with the operating regulations and security programs of the relevant card brands. However, these contracts may also have additional duties relating to incident response, including different reporting requirements, audit rights and indemnification obligations. In fact, older contracts may actually pose less legal obligations on merchants (I have seen contracts that were not specific about compliance with payment card company security programs, and have even dealt with merchants that never received a contract -- they only filled out an application for payment card processing services).
In terms of preparation both the legal and security teams must review and understand their actual legal obligations in the event of a security breach. This includes not only the contract itself but all of the requirements of the payment card security programs, but also the specific mandates of the payment card operating regulations (which the merchant agrees to). An example raised in the whitepaper was Visa's Account Data Compromise Process. The ADCR only applies in certain contexts, and other dispute resolutions processes may apply depending on the circumstances. In order to manage business and legal risk, all of these obligations need to be taken into account well before an incident occurs. Since it is not unusual for these breaches to lead to litigation, and (as discussed below) it is possible that actual incident response can influence the outcome of litigation, this first line of contractual obligations needs to be well understood, and incident response plans built around those obligations.
-- Non-Contractual Legal Obligations. Organizations also face legal risk outside of their merchant agreements, including regulatory actions, issuing bank lawsuits and and consumer class action lawsuits. In addition, a payment card breach can trigger breach notice laws and may amount to violations of other data security and privacy regulations such as GLB, HIPAA, State security laws and international laws. Again, in developing an incident response plan the true consequences of the breach must be taken into account and planned for. Since a payment card breach may trigger overlapping legal obligations incident reponse should take that into account (especially with respect to breach notice laws).
-- PCI Compliance Positions -- Anticipate Compliance/"Reasonable Security" Arguments
As discussed in more detail below, one of the key factors in determining whether a merchant will ultimately be liable or fined/penalized for a payment card security breach is their PCI compliance status at the time of the breach. Some merchants may have made some interpretative judgment calls on specific PCI controls. Others may have initiated compensating controls to address certain sections of PCI that they could not strictly comply with. If such is the case, the lawyers and security professionals of such organizations must clearly understand how they reached their decisions, and anticipate what it will take to justify and defend those positions in a post-security incident environment which may include lawsuits, regulatory actions and allegations of breach of contract. The organization may consider utilizing attorney-client privilege (to the extent applicable) to shield their legal positions on whether the organization has established "reasonable security" (with PCI being one of the key factors in that analysis). In the event of a breach and/or lawsuit or regulatory action, the organization will be prepared to argue and establish its compliance with PCI. This preparation is especially important for organizations that may have had turn-over in their security department -- when security pros fail to document their rationale the institution can lose crucial knowledge needed to defend itself from accusations of PCI non-compliance at the time of a security breach.
-- Electronic Evidence Preservation
Moldes does a good job explaining the necessary task of inventorying cardholder data and those parts of the network environment storing, transmitting and processing cardholder data. From a legal standpoint, organizations should also determine the information it will need to support a payment card breach incident in terms of electronic discovery and electronic evidence. For example, throughout the paper Moldes references various types of logs used in different contexts. These logs obviously may have evidentiary value. A merchant's legal team needs to identify the information it will need to both help establish the cause of security breach, PCI compliance (e.g. evidence that the merchant is not in breach of it merchant agreement), the existence of reasonable security and due diligence, and other relevant defenses against potential lawsuits. In addition to identification, the merchant's IT team, security pros and lawyers should develop a plan and implement the necessary infrastructure to allow for the safe preservation and extraction of potential evidence in the midst of a security breach. All of this should be documented in the merchant's incident response plan.
(2) Identification and Containment
-- Attorney-Client Privilege/ Work Product Privilege and Communication Strategy. As part of a merchant's incident response plan, upon the discovery of a payment card security breach or even the suspicion of a payment card security breach (and these events can be defined in a more granular fashion in the incident response plan), the company's internal legal counsel should be contacted immediately. In addition, all communications, except those necessary to mitigate harm or contain the breach should be halted until general counsel establishes (or decides not to establish) the breach as a potential legal matter and implement a communication plan. To further the matter as a legal issue, organizations may retain outside counsel who also may work to establish a communication protocol concerning the incident.
The key concern here is attorney client privilege and work product privilege. Privilege protects communications between an attorney and its client from scrutiny in court. In some cases, security pros and IT professionals may engage in conversations that could have a impact on legal proceedings and may be protected by privilege. If these conversations occur without an attorney being involved, the organization may lose its right to assert privilege and all documents and convesations may be admitted in a court of law. The merchant's attorneys should assemble its incident response team and be at the center of all communications with respect to that team (to provide the best opportunity to preserve attorney-client privilege).
-- Electronic Evidence Preservation Part II.
This is where the actual preservation of evidence begins to happen. In addition to establishing attorney client privilege, internal legal counsel should be alterted immediately in order to help implement the merchant's data perservation plan (and to allow for general collaboration concerning the collection of evidence). At this point, it is possible that general counsel will implement a document preservation order/litigation control which mandates the retention of certain relevant information in case of legal proceedings. This process must be carefully coordinated to avoid spoiliation and provide the best opportunity to retain evidence that might help the merchant handle its case. Please note that in general, preservation duties arise during and "in anticipation of litigation," and not every breach may trigger these obligations (or they may be triggered at points after the initial identification/discovery of the breach).
(3) Eradication and Recovery Phases
-- Retain an Independent Forensic Assessor (in addition to the Qualified Incident Response Assessors). Moldes' whitepaper first references forensic investigations and audits in the the "eradication and recovery" phases, but in reality merchants should identify forensic auditors and begin their analysis in the identification phase (e.g. shortly after the breach/suspected breach is first discovered). In fact, merchants should have contacted potential forensic auditors well before an incident, and should write those auditors (and the procedrues around them) right into their incident response plan. In this context the forensic auditor should be thought of not simply as a security pro, but rather an individual essentially acting as the lawyers' "expert" assisting in the possible defense of the merchant.
A significant problem arises in those cases where a payment card brand insists that the merchant retain one of its own auditors. For example, VISA may require the merchant to retain one of eight "qualified incident response assessors" ("QIRAs"). This select group of assessors essentially has a monopoly on VISA's very lucrative post-incident forensic assessment services. Some of these assessors are viewed as very closely tied and aligned with the card brands and card brand interests. The main purpose of a QIRA in doing an assessment is to determine whether the merchant was compliant with PCI at the time it suffered a compromise. As mentioned above, PCI compliance is the key factor impacting liability/fines and penalites risk.
From a legal perspective the use of QIRAs may be very dangerous. First off, their close relationship with the card brands and the fact they make good money acting being part of this very select group of QIRAs calls into question their impartiality. The card brands have an incentive to support and defend the PCI standard, and the question is whether QIRAs may intentionally or "subliminally" have a tendency to see things in a way that favors the card brands goals over the merchant's. Note that I am not stating that this definitively happens (in fact I have many friends who work for QIRAs who endeavor mightily to always remain objective), but it is certainly not a stretch to say it is a risk that merchants must take into account. In fact, I have seen post-incident audit reports where a QIRA made conclusions that appeared to be pure speculation, yet those conclusions ultimately portrayed the merchant in the worst light.
Beyond potential conflicts of interest, the problem with QIRAs is that their work and communications get sent to third parties and therefore cannot be protected by attorney-client or work product privileges. In other words their reports are completely discoverable in a court of law, and if they reveal a lack of PCI compliance those reports can be damning to a merchant (see the expert report filed in the TJX case). In cases where non-compliance is obvious this may not be as big of an issue (e.g. if a merchant does not have anti-virus protection that fact cannot be protected by privilege). However, in cases where PCI compliance is a matter of interpretation and judgment, where reasonable minds may differ on close calls, a report by QIRA coming down on the side of non-compliance can be extremely damaging.
From an incident response perspective what should merchants do with respect to QIRAs. As a preliminary matter a decision needs to be made as to whether to even allow a QIRA to conduct an assessment. Again, the merchant's attorneys must carefully review the merchant agreement to determine exactly what contractual obligations a merchant has with respect to a QIRA assessment. If they chose to disallow access to the QIRA, obviously breach of contract (e.g. the merchant agreement) is a concern as well as potential loss of payment card processing, but those consequences should be weighed against the potential result of letting a QIRA in to produce a report that will be viewed by multiple third parties (and eventually plaintiffs counsel).
If a decision is made to allow a QIRA assess the merchant's PCI compliance, in all events the merchant should consider retaining its own forensic assessor to act as the expert for the merchant's legal team. While potentially more expensive (the merchant has to pay for two assessors; VISA makes the merchant pay for the QIRA), this provides some advantages for the merchant. First, communications between the merchant's forensic assessor and the attorneys should be cloaked attorney-client privilege and work product doctrine. If these privileges apply, those communications will not be discoverable or admissible in a court of law should lawsuits commence. Second, the merchant's independent forensic assessor acts as a counter-balance to the potential conflict of interest posed by the QIRA. In other words, if a QIRA knows that it has another reputable assessor "looking over its shoulder," it will tend to keep the QIRA "honest." Without a watchdog, the merchant is at the mercy of the QIRA's analysis, opinions and conclusions. Third, the independent forensic auditor can help the merchant develop and support is arguments as to why it was PCI compliant, especially where there is room for reasonable interpretation. In this context the forensic auditor supports the lawyers' role as advocates for the merchant. As such, potential forensic auditors should be reputable, have experience with interpreting PCI (preferably a QSA), and preferably be comfortable testifying in court and working with lawyers.
Conclusion
There are surely more legal aspects to incident response that I have not addressed (and hopefully will in a future whitepaper or more in depth post). Nonetheless the items discussed in this blog post, if initiated will lead to the proper conversations and planning, and will hopefully result in a well-conceived, multi-disciplinary payment card breach incident response plan. One last item, with the increasing legal risk posed by payment card security breaches, now more than ever lawyers and security pros need to work together to address these issues. As evidenced by Moldes' otherwise excellent whitepaper, it appears that security and legal still act laregly in seperate silos with little understanding of how their worlds are colliding and impacting each other.
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.
Ruiz v. Gap: Increased Risk of ID Theft Not Damages
In a previous post this blog noted that a California Federal District Court denied a motion to dismiss a data breach negligence claim based on a lack of "damages." Despite the partial "victory," the Court had also suggested that the damages issue might not survive a motion for summary judgment. Well, the Court made its own prediction come true in a recent ruling.
On April 4, 2009, the court issued a decision indicating that an increased risk of identity theft did not rise to the level of harm necessary to maintain a negligence claim. This was true despite evidence from experts indicating an increase risk that the plaintiff's personal information was exposed. Without evidence of actual significant exposure of the plaintiff's personal information, the Court indicated that analogies to "medical monitoring" damages were not supported.
This case is another in a line of case establishing that, absent identity theft, it is uncertain whether a consumer plaintiff of a data breach can win in court.
Who is Minding the Legal Risk Around PCI?
An article I did for the ISSA Journal: Who is Minding the Legal Risk Around PCI?
FACTA Class Action Certified (N.D. Illinois)
All, a link to a recent case that certified a class action under FACTA based on credit card receipts with more than the last five digits and expiration date: (Meehan v. Buffalo Wild Wings Inc., N.D. Ill., No. 07 C 4562)
Interestingly this case goes against rulings in the 9th, 10th and 11th Circuits, which ruled that the "superiority" requirement of Rule 23(b) had not been met because of the potentially staggering statutory damages available under FACTA ($100 to $1000 per violation).
In this case, the court followed 7th Circuit precedent that held that classes could be certified despite staggering damage potential. In this Circuit the issue of staggering damages, however, can still be challenged as a violation of due process rights after the certification.
In short, the certification provides the plaintiffs with more leverage because the class has been established and plaintiff's attorneys will have a large economic incentive to argue all the way through the due process arguments. Companies operating in the jurisdiction of the 7th Circuit should be very careful with their credit card receipts.
Minnesota's "Plastic Card Security Act"
A Direct Path to Merchant Liability for Payment Card Security Breaches
As reported in ISC's March 2007 Newsletter, States like Massachusetts and a handful of others (five in total, including: MA, IL, CT, TX and MN) are considering bills that provide financial institutions (e.g. banks and credit unions) with the ability to sue organizations that expose payment card data due to a security breach ("Payment Card Breach Laws"). These proposed Payment Card Breach Laws provide banks with the right to reimbursement from merchants for costs associated with payment card security breaches, including for the cost to reissue credit cards (allegedly $20 - $50 per card). In short, under Payment Card Breach Laws, when a merchant suffers a breach it could be liable for thousands or even millions of dollars. Taking an extreme example, in the TJX matter, 45 million cards where allegedly exposed - the cost to reissue assuming $20 per card is $900 million. For smaller or medium companies that lose thousands or tens of thousands of card numbers, the impact could jeopardize their solvency.
On May 21, 2007, Minnesota became the first State to pass such a law -- Minnesota's Plastic Card Security Act (H.F. 1758 -- the "Act") is a landmark statute that may radically increase the risk of liability and alter the security practices of retailers and service providers handling payment card data. In this issue, ISC summarizes the Act and outlines some of the issues and challenges arising out of it.
1. The Plastic Card Security Act
Subdivisions 1 and 2 of the Act, which prohibit the retention of certain payment card data for more than forty-eight (48) hours, first take effect on August 1, 2007. Subdivisions 3 and 4 of the law, which provides the right to reimbursement and allow financial institutions to file lawsuits to recover costs associated with a payment card security breach do not apply until August 1, 2008, and only apply to security breaches occurring after that date.
A. "The 48-hour Rule" -- Payment Card Retention Limitations (Subdivisions 1 and 2)
Subdivisions 1 and 2 of the Act attempt to address the problem of payment card security breaches by prohibiting companies that accept payment cards from retaining card security code data, PIN verification code numbers or the full contents of any track of magnetic stripe data ("Sensitive Authentication Data"), subsequent to forty-eight (48) hours after authorization of a transaction. Stated more simply, to comply with the Act, companies accepting payment cards must destroy or delete Sensitive Authentication Data within 48 hours of authorizing a transaction with such data (the "48-hour rule").
This Act also applies to entities using service providers that store, process or transmit payment card data - a merchant that provides Sensitive Authentication Data to a service provider will be in violation of the Act if its service provider does not comply with the 48-hour rule.
Coincidentally (or perhaps not so coincidentally) the Payment Card Industry Data Security Standard, v. 1.1 ("PCI Standard") also references and has rules surrounding Sensitive Authentication Data. Section 3.2 of the PCI Standard (as well as the Preface) prohibits the storage of Sensitive Authentication Data subsequent to authorization (even if encrypted). Unlike the Act, the PCI Standard does not specify a timeframe during which the merchant may retain Sensitive Authentication Data - by its silence, the PCI Standard arguably appears to require the destruction or deletion of Sensitive Authentication "immediately" after authentication. Therefore, as discussed below, PCI compliance (where there has been a tight interpretation of the section 3.2 requirements) may effectively act as a "quasi-safe harbor" from liability under the Act.
B. Financial Institution's Right to Reimbursement
The Act uses violation of the 48-hour rule as the trigger for financial institutions to recover when there is a security breach exposing payment card data. Subdivision 3 provides that when an entity that has violated the 48-hour rule suffers a security breach (or its service provider suffers a breach), any financial institution that issued payment cards affected by such breach is entitled to reimbursement of the costs of "reasonable actions undertaken by the financial institution as a result of the breach in order to protect the information of its cardholders or to continue to provide services to cardholders."
Stated more simply, merchants holding Sensitive Authentication Data for more than 48 hours that suffer a security breach must reimburse "issuing banks" reasonable costs to protect cardholder information and continue servicing cardholders. Such costs could include (but are not limited to) costs in connection with:
- cancellation or reissuance of payment cards affected by the breach;
- closure of accounts affected by the breach;
- opening or reopening of accounts affected by the breach;
- refunds or credits to cardholders to cover the costs of unauthorized transactions; and
- notification of cardholders affected by the breach.
In addition, such financial institutions are entitled to recover costs for damages paid by them to cardholders injured by the breach (e.g. essentially an indemnification right in the event the financial institution is sued or settles with a cardholder).
Subdivision 4. of the Act (Remedies) provides financial institutions with a private right of under section 8.31 subdivision 3a. of Minnesota's laws (basically a consumer protection statute). In addition to a right to bring a suit to recover damages and equitable relief, subdivision 3a provides the financial institution with the right to seek costs of investigation and attorney fees. The Act states that the financial institution's private right of action is in the public interest and indicates that the remedies are cumulative and do not restrict any other rights or remedies available.
2. Analysis
This law presents some very interesting issues and challenges for companies accepting payment cards.
A. Direct Path to Liability -- Low Harm Threshold - "Costs of Reasonable Actions"
Where the worlds of data security and the law meet, to date and despite many lawsuits, there have been very few instances of courts finding legal liability for security breaches. In fact, issuing banks have previously tried to sue retailers for payment card data breaches, but the courts presiding over those cases rejected the banks' third party beneficiary, negligence, promissory estoppel and breach of fiduciary duty claims, and dismissed the cases (see e.g. B.J. Wholesaler Summary Judgment Ruling, PSECU Motion to Dismiss). In short, there was no legal theory that clearly provided a right for issuing banks to recover - that hurdle has been jumped by the passage of the Act.
Now issuing banks have specific statutory rights to reimbursement and indemnity, as well as a private right of action to enforce those rights. The only requirements are as follows: (1) the entity is in violation of the 48-hour rule; (2) it suffers a breach of personal information affecting payment cards; and (3) the issuing financial institution incurs costs of reasonable actions to protect or continue servicing cardholders. There is no requirement that the merchant have acted intentionally, willfully, recklessly or negligently.In fact, it does not appear that the financial institution even has to establish that Sensitive Authentication Data was exposed.
As far as reimbursable costs are concerned, the issuing financial institution need not establish that the costs it incurs are necessary, just that the costs arise out of "reasonable" actions. The issuing financial institutions are not explicitly required to show that they will suffer harm or fraud if they do not take the actions (although this would factor into what constitutes "reasonable actions"). Their actions can be completely precautionary in nature so long as they are reasonable. In addition, there is a high likelihood that a court would view the list of example provided in the statute as representing examples of "reasonable actions" and perhaps a minimum list of what financial institutions are entitled reimbursement for. With the costs to reissue cards allegedly ranging from $20-50 per card, the costs of reissuance alone could be substantial (e.g. banks, including Chase, Citibank, the Maine Credit Union and TD Bank North, have already reportedly reissued millions of payment cards based on the TJX breach).
B. Nationwide Applicability -- Scope Beyond Minnesota?
Does the Minnesota law have a nationwide applicability? The answer is "maybe" for persons or entities doing business in Minnesota and elsewhere in the United States. Unlike Minnesota's consumer-oriented breach notice law, which requires notice to Minnesota residents whose personal information may have been acquired by an unauthorized person (See H.F. 2121), the Act is not limited to Minnesota residents. Rather, it applies to "persons or entit[ies] conducting business in Minnesota" and unauthorized acquisition of computerized personal information (regardless of the residency associated with that information). Therefore, by the plain words of the statute, it may be possible that a company simply doing business in Minnesota, which suffers a breach in California, could trigger duties under the Act.Of course there may be jurisdictional issues that preclude suit in Minnesota or application of Minnesota law, but the issue is complex and far from clear.
C. Service Provider Liability
Unfortunately for merchants that use service providers to handle payment card data, the Act still applies if their service provider suffers a breach. What this means for practical purposes is that merchants must ensure that their service providers have processes in place to comply with the 48-hour retention rule. This may be problematic: if the service provider does not have those processes in place it may charge merchants to comply. Moreover, despite the August 1, 2007 start date for the Act, it may take some time to modify systems and processes to achieve compliance.
Finally, the Act will require merchants to add new contractual duties to their service provider contracts that mandate compliance with the Act and most importantly, provide for indemnification. Significantly the Act makes the merchant responsible for the breach, and does not provide a direct route for banks to go after service providers unless "accepting an access device [payment card] in connection with a transaction." Merchants will have to add indemnification language to shift the risk of loss for breaches that are the service provider's fault. For existing relationships, merchants may have to reopen contract negotiations.
D. Personal Information Requirement
One potential limitation of the Act is the definition of "personal information." The Act requires the acquisition of personal information by an unauthorized person to be triggered. In this context, personal information includes an individual's first (or first initial) and last name, in combination with account number or credit or debit card numbers, in combination with any required security code, access code or password that would permit access to an individual's financial account. Therefore, if a breach occurs that only exposes payment card data, but does not expose the combination of data listed in the definition of "personal information," the Act may not apply. It is unclear whether companies can segregate this data to avoid the combination that triggers the Act - merchants should confer with their internal or external security professionals to further explore this and other risk-reducing measures.
E. No Encryption "Safe Harbor"
Unlike Minnesota's breach notice law applying to consumers (see H.F. 2121) which only applies to breaches of "unencrypted" personal information, the Act does not provide an "encryption" safe harbor. In other words, the Act applies even if Sensitive Authentication Data stored more than 48-hours is encrypted. It appears that the drafters have decided that the only way to avoid applicability of the law is to destroy or erase Sensitive Authentication Data. Significantly, section 3.2 of the PCI Standard also discounts encryption of this data.
F. Relationship to the PCI Standard - PCI "Quasi-Safe Harbor?"
Is compliance with the Act impacted in any way if a merchant or service provider is compliant with the PCI Standard. Strict compliance with the PCI Standard may effectively create a quasi safe-harbor to avoid liability under the Act. Both the Act and the PCI Standard prohibit the retention of Sensitive Authentication Data, however the Act allows retention of such data for 48 hours, while section 3.2 of the PCI Standard prohibits storage of such data completely after authentication (some qualified security assessors have said that VISA's time limit is 24 hours - however this is not explicitly stated anywhere). Therefore, if an entity is compliant with the PCI Standard, so long as section 3.2 of the PCI Standard has been strictly interpreted and followed (e.g. immediate deletion or destruction), they should also be in compliance with the Act's 48-hour retention rule.
The problem of course is that it is possible that some entities (or their qualified security assessors) may have interpreted section 3.2 more loosely, potentially allowing Sensitive Authentication Data to be retained beyond 48 hours. Therefore, entities that are PCI Compliant should not automatically conclude that they are compliant with the Act. They should check with their internal or external security assessors to determine how long Sensitive Authentication Data is stored and how strictly they interpret rule 3.2. Moreover, for future PCI security assessments, entities should at least consider imposing a 48-hour retention limitation on Sensitive Authentication Data retention if they want to be aligned with the Act.<
3. Conclusion
The Plastic Card Security Act and similar Payment Card Breach laws are likely to significantly impact the data security risks and liability associated with handling payment card data. For one of the first times in U.S. history, a direct liability path exists for a large segment of U.S. businesses that suffer security breaches involving payment card data. The true impact will not be known until these laws are used, but, especially for small or medium companies heavily reliant on payment card transactions, a careful examination of security practices and service provider contracts is recommended to achieve compliance with the Act. In addition, for those merchants that have not yet complied with the PCI Standard, now is the time to get serious.
As with many data security-related laws and regimes, compliance and risk management is a multi-disciplinary exercise. Entities should retain an attorney to assist with interpreting the Act and modifying service provider contracts to align with the Acts 48-hour rule. Security professionals should be asked to assist with achieving the data retention requirements, as well as working toward PCI compliance (and strict compliance with section 3.2). Finally, this is an area where information security and privacy liability insurance has clear and direct value. Companies should look at their current policies to determine whether coverage exists, and should consider security and privacy policies available in the market that are directly geared toward covering such liability. Taking these steps will provide a solid foundation to begin addressing the risk associated with the Act and other Payment Card Breach Laws that get passed.
Proposed Massachusetts Security Breach Notice Law Creates Additional Liability for Companies Accepting Credit Cards.
For companies that store or process credit card data, the legal landscape may be getting a little more risky.
Similar to breach notice laws passed in thirty-five other States, a proposed Massachusetts bill (H. 213) requires notice to residents of the State if, as the result of a breach of system security, "misuse of information about a Massachusetts resident has occurred or is reasonably likely to occur." The bill also requires entities that do not own or license personal information (which appears to include service providers working on behalf of the company that originally collected the information) to report to the owner or licensee of the personal information.
However, the bill goes a step further and requires organizations to reimburse banks for banks' "reasonable actions" in response to a data security breach where notice is required. Reimbursable costs include:
- the cancellation or reissuance of any credit card issued by any bank or access device;
- the closure of any deposit, transaction, share draft or other account and any action to stop payments or block transactions with respect to any such account;
- the opening or reopening of any deposit, transaction, share draft, or other account for any customer of the bank; and
- any refund or credit made to any customer of the bank as a result of unauthorized transactions.
This new remedy may be related to recent unsuccessful lawsuits by banks seeking to recover the costs of reissuing credit cards exposed as the result of a security breach.
In 2005 B.J. Wholesalers suffered a security breach and was sued by several "issuing banks" to recover costs to reissue credit cards (B.J. Wholesalers faced suits by four banks alleging millions of dollars in losses). However, the courts presiding over those cases rejected the banks' third party beneficiary, negligence, promissory estoppel and breach of fiduciary duty claims, and dismissed the cases (see e.g. B.J. Wholesaler Summary Judgment Ruling, PSECU Motion to Dismiss)
More recently, TJX Companies (holding company of such retailers as TJ Maxx, Homegoods and Marshalls and headquartered in Massachusetts) was sued by an Alabama-based AmeriFirstBank Inc. bank in the wake of a security breach. AmeriFirstBank alleges that it costs the bank approximately $20 to reissue a single card. News reports indicate that the breach may have exposed more than 40 million credit cards and approximately 60 banks have been notified of potential exposure. Some of these banks, including Chase, Citibank, the Maine Credit Union and TD Bank North, have already reportedly reissued millions of credit cards based on the TJX breach.
This Massachusett's bill may not be an isolated event -- other States and the Federal government are reportedly considering similar legislation according to this credit union source.
What might this mean in terms of managing information security risk?
For companies handling credit card information it means a fairly direct path to legal liability if a breach exposes credit card information. The legislation is not limited to a narrow definition of retailer, but applies to the "commercial entities" (broadly defined). Assuming damages of $20 for each card reissued, if a breach involves several thousands or millions of cards, the potential damages could be staggering. For smaller organizations a potential security breach could result in bankruptcy. For larger retailers with millions of credit cards stored, it could result in tens of millions of dollars in damages.
Moreover, the standard of proof for banks is arguably not very high. First, there must have been a security breach that resulted in the misuse of information about a Massachusetts resident, or such a misuse is reasonably likely to occur. Second, the banks actions must have been "reasonable actions," which includes those broad actions listed above. Therefore, a decision to report arguably guarantees that the organization will have to reimburse some bank costs. Ironically, since consumers do not have a direct remedy in the statute, the law may produce a strong incentive to avoid reporting to consumers if there is uncertainty as to whether misuse has occurred.
What should companies do to if a law like this is passed?
From a risk management perspective, organizations should conduct a risk analysis to determine how much credit card information they are handling, and whether it is subject to being stolen in large quantities. Since the potential liability for a breach could be enormous, the justification for enhanced security should be present. Regardless, companies should work hard toward at least achieving PCI compliance if handling credit card data. Since companies may be liable if their service provider suffers a breach, they should work to assess the controls of those service providers (or only work with those that are certified as PCI compliant.)
In addition, the existence of a law like this creates a very strong argument for insurance to transfer the risk of loss. Risk managers should check their insurance policies to determine if any coverage exists under their current forms, and should consider the purchase of information security and privacy policies. Some policies now provide coverage for liability arising out of a security breach and with respect to the costs of providing notice of a security breach.
From a legal perspective, it appears that legal liability could arise out of a breach related to a third party service provider. Therefore, attorneys for companies collecting credit card information and passing it on to service providers for processing must make sure that there are contractual duties to maintain adequate security, report security breaches and potentially indemnify for losses (in fact the PCI Standard actually requires the development of contract terms that mandate compliance with the PCI Standard). In addition, attorneys need to be versed in the details of such laws so they can provide good counseling when a suspected security incident occurs.
Conclusion.
It is very interesting that the liability potential for security breaches is now being pushed from the commercial side (while being pushed more slowly from the consumer side). If a bill such as H. 213 is passed it has the potential to radically change the information security risk management dynamic for companies handling credit cards. There will be strong interests on both sides (banks versus retailers) that will push for and against a scheme like this, so it is unlikely that it will be passed in its current form. Nonetheless, it will be very interesting to see if and how these laws develop further, and it is important for risk managers to pay close attention to the progress of bills of this type.
