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.