Categories
News

Developing a Successful Service Provider Oversight Program

By Kevin Tsuei, CISA and CISSP, and Vivian Wei, AuditOne LLC

Outsourcing certain technology operations can undoubtedly be a cost-effective means by which an institution meets its needs. However, reliance on a third-party provider is always accompanied by an unknown degree of risk. Not only are effective risk management practices imperative to protecting the security and interests of an institution, they are also an expectation, as the board of directors and senior management bear the full responsibility of the safety and soundness of all activities regardless of whether they are performed in-house or outside.

As an increasing number of community banks are upping their use of cloud computing (one of the many examples of increased reliance on third-party providers), regulators have become more stringent on how management evaluates and monitors outsourced vendors. In this article, we will explain how management can create and implement an effective service provider oversight program. We will also discuss an appropriate response plan for when a vendor is impacted by negative news or regulatory orders.

In 2012, the FFIEC issued a revised IT Examination Booklet on the Supervision of Technology Service Providers (TSP Booklet). A year later, the OCC issued Bulletin 2013-29 which detailed risk management guidance for third-party relationships. The general purpose of the OCC guidance is to help banks implement a proper risk management process to identify risks, conduct appropriate vendor due diligence, inspect written contracts, implement ongoing monitoring, ensure a contingency plan is in place if the relationship terminates, identify appropriate parties to oversee the vendor, retain proper documentation/reporting, and conduct independent reviews of this area.

As with any risk management process, a service provider oversight program should begin with a vendor risk assessment. There are many types of risks to consider when evaluating service providers. However, the risk assessment process need not be overly complex. For example, it can be a simple scoring system based on several inherent risk factors: GLBA, strategic, operational, reputational, compliance/regulatory, and transactional risks.

We will develop a robust methodology for GLBA risks as an example. A typical evaluation of GLBA risks includes the following: What types of sensitive information does the vendor store or have access to? Does the service provider transport the data? We generally recommend management evaluate GLBA risks by using a four-tier risk scoring system:

  • A score of 0 indicates the vendor does not store or have access to any sensitive customer information.
  • A score of 1 indicates the vendor has access to basic customer information such as names and contact information (e.g., marketing companies).
  • A score of 2 indicates the vendor has access to account specific information such as account balances and activities (e.g., statement printing vendor).
  • A score of 3 indicates the vendor has sensitive information such as customer Social Security numbers, birthdays, etc. (e.g., core processor).

The remaining risk factors should be given similar treatment, but due to space limitations, we will not be addressing them in detail.

After the risk scores have been tallied for all service providers, management can classify them into multiple categories (high, medium, or low risk). A risk management program or policy can then be created to minimize residual risk. This policy would address the initial due diligence and ongoing monitoring based on the risk of the vendors.

  • For example, for high-risk vendors, we typically observe that management reviews vendor due diligence materials such as SSAE16 or third-party audit reports, financials, BCP plans, penetration test results, insurance, references, etc.
  • Obtaining other documentation should be considered as well. For example, management should ask for a Red Flags policy from vendors that hold critical customer sensitive information (e.g., core processors). Also, a Certificate of ACH audit should be obtained from ACH service providers. The certificate will ensure the vendor has been audited against NACHA rules.
  • In addition to reviewing materials for initial due diligence and ongoing monitoring, management should review contracts thoroughly. At minimum, a contract should contain common clauses such as confidentiality, service level agreement (SLA), and termination.
  • However, if the service provider stores your data, it is important to search for clauses such as data ownership and security breach monitoring clauses. Data ownership defines who owns the data being stored by your vendor. It should also discuss what will be done with the data upon termination. That is, will the data be returned to its rightful owner? Will it be disposed of securely? Security breach reporting is crucial for vendors that possess your data (e.g., cloud computing provider). The clause should clearly state the timeframe in which the vendor must report the breach.
  • Another important clause to look for in a vendor contract is an auto renewal clause. Many technology vendors have auto renewal clauses, which commonly require a termination letter 90 days prior to contract expiration. Some vendors may even have automatic fee increase clauses: if termination is not sent 90 days prior to the contract renewal date, fees are automatically increased.
  • Lastly, it is important to determine whether the Bank has the right to obtain audit reports or inspect the service provider’s environment. This clause is often overlooked but can be important as part of your vendor due diligence.

In recent years, a few technology vendors have been faced with regulatory orders. A C&D order was issued against Fundtech Corporation and BServ, Inc. just in December. When responding to such an order, it is important for the Bank to document the process leading up to the decision of parting or remaining with the technology vendor. If management decides to stay with the vendor, document reasons and ways in which it will affect the Bank. It is recommended that the analysis be submitted to both the IT Steering Committee and the Board for review.

To decrease audit and regulatory risks, it is important for banks to document their initial due diligence and ongoing monitoring of vendors. For example, a contract clauses checklist can aid management in documenting the review to ensure the consistency of the process. When reviewing due diligence material, it is important to record the analysis and report it in your annual Information Security Report.

Sources:
http://www.occ.gov/news-issuances/bulletins/2013/bulletin-2013-29.html

https://www.fdic.gov/regulations/compliance/manual/pdf/VII-5.1.pdf
http://www.occ.gov/news-issuances/news-releases/2014/nr-occ-2014-6.html

Published in Western Independent Bankers Association’s Technology & Security Digest, Issue 21 – March 2014.