By Adam Atlas
Attorney at Law
Data breaches are a part of contemporary business. Despite substantial efforts by both industry and governments to limit the chances of a data breach and the negative repercussions associated with them, they continue to occur and cause significant harm.
As ISOs evolve from simple sales organizations to active participants in the flow of data related to merchant payment transactions, they are earning correspondingly greater liability for breaches that occur along the way. The purpose of this article is to highlight key considerations for ISOs, from a legal perspective, arising from a merchant data breach.
If there is no data being stored, the chances of a breach are much lower. For several reasons, it is essential for ISOs to know precisely where merchant data is stored. Specifically, ISOs should know where cardholder data is stored, given that cardholder data is the most sensitive data in the payment operations of merchants. Note that merchants are often ignorant of where their data is stored.
The process of finding out where data is stored starts at the POS. When cardholders (online or in person) enter their payment card information, that information goes somewhere. Usually, it is picked up by a secure element within the POS device or hosting platform and is transmitted by a secure gateway (for example, Authorize.net) to the merchant’s processor (for example, First Data) for presentment to payment networks (for example, Visa).
Sometimes merchants wish to retain a copy of cardholder data, but they rarely have their own secure storage facilities for cardholder numbers, so they use a third-party provider (such as TrustCommerce). In other cases, merchants are ignorant of the legal and commonsense security requirements, and they store cardholder data on their own unsecured computer systems.
It is a best practice for ISOs to go through this analysis with each merchant to learn precisely where cardholder state is stored and precisely who has promised to store or transmit that data for the merchant. When a breach occurs, both the ISO and the merchant will want to know where and why data was rendered vulnerable to prevent future breaches, as well as allocate liability for the ensuing losses.
The processing agreement between the merchant and the acquiring bank will leave all responsibility for security of cardholder data in the hands of the merchant. The ISO should help the merchant take that understanding one step further to see who really stores the data and what promises have been made about that storage.
For example, if a merchant has engaged a gateway to store its cardholder data, the merchant should look to that gateway for promises about the degree of security that will be used in storing the data.
The PCI Security Standards Council is an industry standards-setting organization that has established specific security standards related to the storage of cardholder data. The Payment Card Industry (PCI) security standards came into existence partly because of a fear that if the industry did not regulate itself, government would intervene and impose standards on the industry.
By contract, virtually every participant in the payments industry promises to comply with PCI standards. The standards dictate levels of compliance that are a function of the quantity and type of cardholder data being stored. The more you store, the more secure you have to be.
Back to the documents: the agreement between a gateway storing cardholder data and a merchant should contain promises by the gateway as to its level of PCI compliance. It is helpful for an ISO to know precisely who has made what promises with respect to cardholder data storage.
Before leaving the subject of promises made, it is important to touch on limitations of liability. When a security breach occurs, the merchant who collected the compromised cardholder data could be liable for substantial fines – even if the merchant did not store the data itself. The reason for this is that the merchant had the duty, under the merchant agreement, to select a vendor (that is, gateway) that had secure data collection and transmission capabilities. Where the gateway fails, the processor may look to the merchant for having made a bad choice of gateway.
Under the merchant agreement, the merchant’s liability for security breaches on its own system is usually unlimited. This topic gets interesting when we read contracts between merchants and gateways: we often find the gateway limiting its liability to a few months of fees, which is a relatively small amount compared to the liability that the merchant carries versus the acquirer.
In short, the merchant promises the acquirer that it will keep cardholder data secure, and the merchant more or less has unlimited liability under that promise. Then the merchant turns to a gateway to store its data; the gateway very often limits its own liability to a few months worth of fees, even if all of the data of the merchant is compromised. This glaring gap is likely to be the subject of litigation because the parties that hold the data (gateways) limit their liability for breaches, while parties that do not usually store data (merchants) carry unlimited liability for data breaches.
ISOs are caught in the middle, because they are often reselling both the processing services (that impose high liability on merchants for data breach) and gateway services (that limit their own liability while providing the necessary secure data storage).
If a breach does occur, waste no time. Identify the source of the breach promptly. Stop the harm.
Once the technical aspect of the emergency is under control, or while it is being brought under control, the merchant and other parties responsible should consider who has to be notified of the breach.
Merchants are often required to notify their processor, and state law may require notices of the breach to cardholders. ISOs should support merchants at these critical times with information and references to expert assistance – such as data breach audit services and guidance from the acquirer.
In publishing The Green Sheet, neither the author nor the publisher is engaged in rendering legal, accounting or other professional services. If you require legal advice or other expert assistance, seek the services of a competent professional. For further information on this article, email Adam Atlas, Attorney at Law, at firstname.lastname@example.org or call him at 514-842-0886.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.Prev Next