The Merchants Strike Back?
With the recent news of several restaurants teaming up to sue point-of-sale system provider Radiant Systems (a copy of the complaint can be found here) for failing to comply with the PCI Standard, it appears that some merchants may be in a mood to strike back in the aftermath of a payment card security breach. This lawsuit comes in the wake of a couple lawsuits against payment card security assessor Savvis for allegedly failing to properly validate a processors' Visa CISP compliance (admittedly in this case it is the merchant bank suing the assessor, but a similar cause of action could exist for a merchant if its assessor makes a mistake in verifying PCI compliance). While two instances certainly don’t indicate a trend, they do indicate a potential route that merchants may consider to deflect liability arsing out of a payment card security breach.
It is possible that we will see more lawsuits by merchants against service providers, payment processors, and application/point-of-sale system providers in the coming months and years. Part of the reason is that the PCI regulatory system imposes a form of “strict liability” on merchants that suffer a security breach. Fines, penalties and the availability of recovery processes are contingent (in part) on whether or not a merchant was PCI-compliant at the time of the breach (see e.g. Visa’s ADCR). Thus, when a Qualified Incident Response Assessor ("QIRA") comes in after a credit card breach to do an audit one of its main tasks (if not its primary goal) is to ascertain whether the merchant was PCI-compliant.
Lost in the shuffle sometimes, however, is the issue of “causation.” The question that is not being asked is whether or not PCI compliance would have prevented the breach, or whether the lack of PCI-compliance was the cause of the breach. In other words would PCI-compliance have made a difference. In some cases the answer is obvious. For example, if a merchant is holding onto sensitive authentication information, clearly PCI compliance (which requires the deletion of such data after a transaction) would have precluded a payment card breach. In other situations, however, the answer might not be as clear cut.
Moreover, even where a merchant is found not PCI compliant, the question still remains whether any other party was fully or partially responsible for the breach itself. Was the merchant’s payment application the source of the breach? Was the merchant working with a service provider, gateway or processor that could have been the source of a virus or attack by a hacker? Unfortunately, with their focus on PCI compliance, a QIRA may not have cause to investigate further into these possibilities (and a separate forensic assessment by an independent forensic firm may be necessary). In fact, I have seen an audit report where the auditor literally indicated that it could not determine how malware got onto a merchant’s system or whether cardholder data ever left (and in the report decided to speculate that it may have been porn or file sharing sites).
Beyond the entities involved in storing, processing or transmitting payment cards, merchants may also begin to target companies assisting their efforts to achieve and validate compliance with PCI. Consultants that help merchants become PCI compliant or remediate PCI violations may be targets if they make a mistake. Moreover, as Savvis shows, qualified security assessors that make mistakes in their validation of PCI compliance are also potential defendants.
Despite sometimes having a variety potential targets to recover from, merchants still face obstacles to actual recovery post-security breach. The biggest obstacles are the contracts that merchants enter into with the entities mentioned above. In most cases these contracts contain terms that effectively limit the liability of these entities and make it very difficult to recover under any theory of recovery.
So is there an answer for merchants to these contract clauses? Thinking ahead might make all the difference in this case. When entering into a contract with any of the various entities described above, at the Request for Proposal phase, merchants should make indemnification and other favorable contract terms (e.g. no limit of liability/disclaimer of consequential damages for security breaches) part of the bidding process. Merchants' propsective service providers, assessors and application providers should be forced to compete on the issue of taking responsibility when they are fully or partially at fault for a security breach or inaccurate/improper PCI validation. Proper levels of cyber insurance should be in place to allow merchants to recover if there is a breach. If merchants don’t take these steps early on and in a disciplined fashion they may find themselves holding the bag even in situations where others may have contributed to their security breach.