News

Compliance issues should be spelled out in vendor contracts

Richard Menta says the speed with which new technology products appear and new enhancements to existing products are applied make evaluating and monitoring risk a daunting task -- but one that financial institutions must not neglect.

May 24, 2004

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 contracts' 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. The speed with which new products appear and new enhancements to existing products are applied make 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?

All of these products were developed with expediency to capitalize on the new market the act 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? 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 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 regard 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.

Most vendors enter into these contracts with the best of intentions. It is only good business for them to help their clients 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 adding clauses and addendums in contracts to either limit accountability or sidestep participation altogether. This is a warning to banks not to shirk their due diligence on contracts.

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 in which a small software vendor, who was about to extend the terms 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 phrase alone should set off alarm bells to any upper bank manager reviewing this contract.

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 to rewrite the code and correct the flaw? Here, the vendor states that it's not its problem. Furthermore, it states it feels no obligation to take future steps 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. The vendor has bared itself as an unwilling -- maybe even unqualified -- partner with regard to the security of its own product. This means the product itself not only carries increased risk, but the capability of the vendor's management is in question.

This vendor's product was created to serve only banks; so 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.

Walking away is not always a solution. The bank has invested 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 switch. The bank needs to reevaluate 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.

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 the requirements and intentions.

This way there is no doubt the vendor is aware of its importance and why, and both sides can make their commitments fully informed. Vendor expectations can be better managed, especially from those who serve several vertical markets and are only superficially versed in bank regulations.

Financial institutions 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 DR 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 Web sites.

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 financial service firms can use to streamline the risk process evaluation of vendors.  The informative and comprehensive form can be downloaded at http://www.bitsinfo.org/bitsxmatrix2004.xls

The author, Richard Menta, has developed information security programs for banking clients ofIcons Inc,an information security consulting firm. He has performed risk assessments of the information security infrastructures of financial organizations, with emphasis on compliance with the requirements of the Gramm-Leach-Bliley Act regarding protection of customer data. An MBA from Rutgers University, he serves as the director of marketing for the company as well as editor ofBankInfoSecurity.com. He can be reached atrmenta@iconsinc.com.