Tip

Vendor contract management: Regulatory guidance is risk-based

Andrew M. Baer, Esq., Contributor

While various sources of regulatory guidance address contractual information security requirements for financial institutions, the characteristic feature of these requirements is that they are flexible and risk-based. That is to say, the guidance avoids prescribing specific language that must appear in every contract or a contractual requirement that certain technologies be used, such as a particular encryption standard. Often the guidance does not even use the word "must" at all, instead reminding financial institutions that they "should" consider various recommended types of contractual protections (of course, those of us used to dealing with bank regulators know that "should" does not necessarily mean optional).

The overall thrust is that while some sort of written contract is required to hold the vendor responsible for the security of customer information, regulators are primarily concerned with informed risk assessments, i.e., making sure the financial institution has evaluated the level of risk as part of a systematic vendor due diligence process and that the contract requires reasonable or appropriate security measures, with reasonableness depending on identified risk factors such as the nature and amount of the information shared with the vendor. The classic expression of the risk-based framework appears in the

    Requires Free Membership to View

Interagency Guidelines Establishing Standards for Safeguarding Customer Information, jointly issued by the federal banking agencies and the Federal Trade Commission in 2001 to implement the security requirements of the Gramm-Leach-Bliley Act. With respect to contracting, the guidelines require a financial institution simply "require its service providers by contract to implement appropriate measures designed to meet the objectives of these Guidelines …" (i.e., implementation of safeguards designed to mitigate the assessed risks).

Other federal guidance adds a few specific information security requirements, but these are minimal. For example, OCC Bulletin 2001-47, which addresses third-party risk management for national banks, provides a detailed summary of contractual provisions that banks should consider. On the specific topic of information security, however, beyond customary confidentiality language and a requirement to implement appropriate security measures, the bulletin indicates only that the bank should require vendors to provide disclosure of security breaches resulting in unauthorized intrusions that may materially affect the bank or its customers, as well as reporting on the effects of such breaches and any corrective action taken. The Outsourcing Technology Services IT Examination Handbook, issued by the Federal Financial Institutions Examination Council (FFIEC) in 2004, repeats this directive.

The FDIC's Guidance for Managing Third-Party Risk, issued in June 2008, sounds the same note: "Any nonpublic personal information on the institution's customers must be handled in a manner consistent with the institution's own privacy policy and in accordance with applicable privacy laws and regulations. Any breaches in the security and confidentiality of information, including a potential breach resulting from an unauthorized intrusion, should be required to be fully and promptly disclosed to the financial institution."

In addition to guidance issued by their supervising regulators, financial institutions may also be subject to state data security laws and the Payment Card Industry Data Security Standard (PCI DSS). The contracting requirements specified in these sources are also minimal. For example, the August 2009 amendments to Massachusetts' regulation, 201 CMR §17.00, align it with the Interagency Guidelines discussed above; organizations that own or license personal information about Massachusetts residents must require third-party vendors by contract to implement and maintain appropriate protective security measures that are consistent with the regulation and with federal regulations. (However, any contract entered into prior to March 1, 2010 will not be considered non-compliant even if it lacks these provisions.)

PCI DSS Requirement 12.8 provides that if cardholder data is shared with a service provider, an organization must implement and maintain policies and procedures to manage the relationship. With respect to contracting, these policies and procedures must include maintaining a written agreement to acknowledge that the service provider is responsible for the security of cardholder data in its possession.

A brief survey of the guidance, therefore, suggests that information security requirements for financial institution vendor contracts are not onerous: "reasonable" or "appropriate" security measures plus disclosure and reporting on data breach incidents. However, a broader reading of the guidance and sound risk management principles behoove us to go little further.

These protections need not add pages of verbiage, and while the legalese will inevitably be negotiated, vendors used to dealing with financial institutions or personal information, particularly in the age of PCI DSS compliance, should be familiar with these requests and have standardized responses to them.

About the author:
Andrew M. Baer is an attorney with long experience in technology, e-commerce and information security matters relating to the financial industry. He is the founder of Baer Business Law, LLC (www.baerbizlaw.com), a Philadelphia firm focused on providing clients with cost-efficient business counseling and transactional assistance, particularly in the areas of technology and intellectual property law. He can be contacted at andrew@baerbizlaw.com.


HOW TO MANAGE SECURITY RISKS IN VENDOR CONTRACTS

  Introduction
  Vendor contract management: Regulatory guidance is risk-based
  Vendor audit and monitoring contractual rights
  Data breach protection: Implementing vendor breach safeguards
  Vendor risk management: process and documentation

This was first published in September 2009

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.