Vendor Contracts Grow More Complex
By Richard Menta
Each year vendor contracts become ever more the minefield. New regulations can be attributed to this as they place deeper responsibilities on financial institutions to protect the information of their customers while continually validating their accuracy. Contracts must therefore become more detailed to reflect compliance obligations.
The rise of technology over the last decade has exacerbated this issue as each new or updated technology solution brings with it a new set of risks. This is the nature of technology as it serves an ever-fluid existence of rapidly maturing software and hardware remedies to challenging business requirements. The speed with which both new products appear and new enhancements to existing products are applied makes evaluating and monitoring technology risk a daunting task.
For example, the Sarbanes-Oxley Act is only a year old, yet already dozens of manufacturers have released software products to help bank management comply with it. Since such software has to deal with the vagaries of a young act that time has yet to clarify, is it reasonable to assume even a properly functioning product can have flawed interpretations?
Rush for Competitive Edge
All of these products were also developed with expediency to capitalize on the new market the act instantly created. Since the rush to achieve an early market entrance (and competitive advantage) means a short commercial deadline, is it reasonable to assume that this left less time to perform tasks such as identifying bugs and fixing code? How about security – was there time to incorporate an active security plan within the development process?
This is why technology partners need to be just that, partners. A vendor can't just sell a product or service and walk away. Many times only they can mitigate issues that arise under existing regulations (as well as new regulations that may appear during the term of the contract). Part of the contract phase needs to incorporate wording that assures the technology vendor will play an active role when needed.
Despite potential risks, vendor products and services provide high value to financial institutions. Banks just have to remain continually mindful that the current market rewards those third parties who react the fastest, not necessarily the best. Bank managers must also remind themselves that, under current law, outsourcing to vendors does not transfer the bank's responsibility to satisfy regulations. Ultimately, the bank is held accountable.
Section 501(b) of the Gramm-Leach-Bliley Act clearly states this with regards to third-party contracts and puts due diligence on banks to assure that the data that passes through outsourced hands is reasonably secured and protected. The act places the full burden on the bank to confirm that all third parties and vendors have proper protection mechanisms in place to protect the non-public personal information they or their products come in contact with.
For their part, most vendors enter into these contracts with the best of intentions. It is only good business for them to help their client stay compliant. In fact, it can be quite profitable. This does not mean all vendors are equally knowledgeable about the various regulations. Some vendors see regulations as only a nuisance and don't want to deal with them at all.
As more vendors become savvy to the implications of newer regulations, we are witnessing more of them add clauses and addendums in the contract to either limit accountability or sidestep participation altogether. This is a warning to banks not to shirk their due diligence on contracts.
Beware the Insanity Clause
Here is a perfect and very recent example, one that caught me by surprise when it first passed before my eyes. Below is an actual passage in a third party contract addendum where a small software vendor, who was about to extend the term of the original agreement with a bank, felt they needed to say a few things about security and their product. The passage indeed says quite a bit:
“The following shall be inserted at the conclusion of section 12 of the Agreement. Licensor shall NOT be responsible for taking any measures to safeguard the security of, or preventing access of a person or entity to, data or information of licensee and Licensor disclaims any liability for, and makes no representation, warranty, covenant or agreement with respect to, the security or integrity of the Software in connection with such data or information.”
“Shall not be responsible for taking any measures to safeguard security.” That line alone should set off alarm bells to any upper bank manager reviewing this contract.
Tell me, if there is a flaw in the code of this product that creates a vulnerability a hacker can exploit, who else but the vendor can reasonably be expected rewrite the code and correct the flaw? Here, the vendor just stated that it's not their problem. Furthermore, they are stating they feel no obligation to take steps in the future to make sure this product is made safe from unauthorized intrusion.
This addendum really serves as an announcement, one to this vendor's clients that security was never a consideration in the development of the product and will not be in the future. Signing this contract as is does more than violate the bank's due diligence responsibilities to section 501(b). It violates good business sense.
We told the bank to walk away. Yes, the bank can change the wording on the contract, but there is more here as the vendor has also bared themselves as unwilling – maybe even unqualified – partners with regards to the security of their own product. This means the product itself not only has increased risk, but the capability of the vendor's management is in question. As this product was created to serve only banks, that's a severe problem as all of the vendor's clients now have motivation to disengage service. Is it a stretch to say the viability of this company may now be in question? That's another risk.
But, walking away is not always a solution. The bank has made an investment of time and money into this product. It will take time and effort to find a suitable replacement, not to mention the added integration and training costs to change over. The bank needs to re-evaluate its risk exposure and either accept the additional risks or terminate and replace. That's assuming the bank can accept added risk. Any examiner who reads the above addendum will immediately ask the bank what action it will take beyond the vendor's role to mitigate problems. Since some problems like the example above cannot be fixed without the vendor, the relationship can never be in compliance.
Specific Details Do Matter
Today, contracts with vendors must be specific about the bank's regulatory obligations; they can no longer be left unmentioned or implied. These contracts must bring up each act that is applicable and spell out both their requirements and intentions. This way there is no doubt the vendor is aware of their importance and why, and both sides can make their commitments fully informed. Then expectations from vendors can be better managed, especially from those who serve several vertical markets and are only superficially versed in bank regulations.
Banks and credit unions must ask in detail what they need. Ultimately, this leads to the creation of an Information Security Audit Questionnaire, one that is presented to every vendor who might see a credit card number or customer statement. This device is usually several pages long, asking detailed questions on the vendor's information security state. It includes questions on employee background checks, physical security checks, the vendor's disaster recovery plan and the vendor's data security plan. It asks for the types of security technology employed including intrusion detection systems and application protection mechanisms for transactional websites.
To help financial institutions that have yet to develop such a questionnaire, the Banking Industry Technology Secretariat (BITS) in January 2004 released a standardized questionnaire that financial service firms can use to streamline the risk process evaluation of vendors. The questionnaire is very informative and comprehensive and is designed so a financial institution can present it to vendors as is for them to complete. The form can be downloaded from the BITS site at http://www.bitsinfo.org/bitsxmatrix2004.xls.
Richard Menta is an information security specialist in the finance industry for Icons Inc. A Master of Business Administration from Rutgers University, he has more than 10 years experience in information technology. Menta can be reached at firstname.lastname@example.org.