By Adam Atlas
Attorney at Law
As with most businesses today, technology is a cornerstone for contemporary ISOs. This article considers some legal issues that are specifically relevant to technology contracts for ISOs.
Payment Card Industry (PCI) Data Security Standard (DSS) compliance means different things to different people. To a small merchant, it might mean an annual self-assessment questionnaire coupled with a compliance or non-compliance fee.
An ISO that has a technical understanding of PCI compliance is at an advantage, because it can source and supply merchant-appropriate solutions. For example, a merchant who needs to collect and store cardholder data, but does not have PCI-compliant systems, will need to procure access to such systems. The ISO is perfectly situated to be the intermediary between the merchant and possible suppliers.
Once an ISO fully understands the cardholder data processing needs, and the corresponding PCI implications, it is in a position to select and procure the right solution. That said, not all suppliers are aware of the specific level of their own PCI compliance, and some do not even know why they need to be compliant. The ISO can therefore fulfill an educational function not only for the merchant – but also for suppliers – to make the best fit between them.
When a draft IT services agreement is finally put together in support of a PCI-regulated project, the ISO should review it to see what kinds of representations are made as to the PCI compliance of the provider and its services. It might also help to have the merchant or ISO's own PCI assessor look at those representations to see if they satisfy the needs of the merchant or the ISO.
The point here is that some IT services agreements are simply inadequate as to the PCI needs of ISOs and merchants, and they should be tested for that requirement before signing.
Disaster recovery, backup, source code escrow, service level commitments and access to information are but a few themes to address in common-sense policies that ISOs should expect from IT suppliers.
This does not mean that the ISO needs to read all of the policies. Under the agreement between the ISO and its IT provider, it makes sense to have the IT provider represent that it has these policies in place and that it meets whatever standard the ISO requires of them.
The PCI DSS is convenient, because it allows the parties to point to an objective set of standards that are not only identifiable but also subject to certification from a small army of PCI certification services. Outside of the PCI standard, IT suppliers are expected to implement measures to ensure that their data is not compromised or corrupted. ISOs should consider representations by IT suppliers as to the security measures they take to ensure that the ISOs can expect performance that is commensurate with their needs.
When there is a security breach involving consumer data, a whole suite of federal and state laws can apply to the parties. When parties are at the contract-negotiation phase, it is helpful to consider how they will each allocate their respective responsibilities in the event of a security breach. It's also worth asking the IT company to inform the ISO of a breach in its systems that has nothing to do with the ISO – but that could nonetheless be informative as to the solidity of the IT provider.
In a perfect world, ISOs would obtain indemnification for all breaches or other wrongdoing by their IT suppliers. In the real world, IT suppliers will try to limit their obligation to indemnify to a few big-ticket items including:
An IT supplier should be able to promise that it is using only its own intellectual property (i.e. software and systems) or intellectual property rights that it has licensed for use in conjunction with serving the ISO.
When an IT supplier uses content in which it does not own the necessary intellectual property rights, the ISO business can become collateral damage in a claim by the rightful owner against the IT company. For example, suppose the IT company is providing a gateway system – that it stole from another party. The aggrieved party then sues the IT company, the ISO and all of the ISO's merchants for intellectual property infringement. This kind of claim is one for which an ISO can likely specify indemnification at the negotiation stage of the IT services agreement.
Where there is a breach in the security of the IT provider, the ISO will likely wish to have indemnification by the IT provider.
Intentional wrongdoing is easy to define: it's the common sense definition of someone doing something intentionally wrong. Gross negligence (as distinct from negligence) is a bit trickier. Definitions of this term will vary from state to state and also in accordance with the specific circumstances of the case.
That said, if negligence is not doing what a reasonable person in the circumstances would normally do (that is, turn the engine off after parking a car in a closed garage), then gross negligence is a conscious and voluntary disregard for the need to use reasonable care, which is likely to cause foreseeable grave injury or harm to persons, property or both. It is conduct that is extreme compared with ordinary negligence, (such as not even knowing an engine was on).
ISOs will likely wish to negotiate for indemnification by the IT provider for harm done as a result of intentional wrongdoing or gross negligence.
I have saved the best for the last. Limitation of liability means what it says – it means that the IT provider's liability will not exceed the amount indicated. This is a very important clause because it renders all other rights (such as indemnification) useless if the cap on liability is too low.
ISOs should pay close attention to limitation of liability clauses in IT supply contracts to see if they meet with their commercial needs.
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