August 1, 2019

Covering Your Assets:  Protect Your Bank in TSP Contracts – WST

Let’s face it.  Reading through contracts is boring, if not downright painful.  But the angel is in the details.  Often, banks sign contracts with Technical Service Providers (TSP) that are boilerplate legal documents provided by the TSP.  However, is the contract that they are providing mutually beneficial to the bank and the TSP?  Frequently, TSP contracts are very specific in protections for the TSP with broad categories of exclusions, while failing to specify important details concerning the services they are providing.  Increasingly this lack of contractual protection for the bank is coming under examiner scrutiny.

There are many areas where standard TSP contracts commonly fail to adequately provide for the bank’s need for clarity.  The first of these is in patch management.  If the TSP is responsible for applying patches to operating systems, third-party software, or proprietary software then it is critical that several specifics are spelled out in the contract.  Who will be installing the patch?  The TSP, the bank’s IT team, or bank staff?  How will patches be installed?  Using an automated patching solution or installing patches manually?  What is the maximum time between the patch release date and successful patch installation?  Also, make sure to factor in the criticality of the patch for this time calculation.

The second area where TSP contracts fall short is in the arena of incident response.  Contract language surrounding this topic is sometimes vague if it’s mentioned at all.  Your contract should specify what is considered a cybersecurity incident.  How much time may elapse between a confirmed cybersecurity incident and TSP notification to the bank?  To whom will the notification be routed and by what method (email, telephone call, registered mail, etc.)?  Will the bank be notified of a cybersecurity incident at the TSP which did not affect the bank’s data?  This list of contract specifications for incident response is long.  The point being, that while it is not possible to foresee all contingencies, details not specified in the contract are optional for the TSP.

The last area where TSP contracts come up lacking is in specifications around business continuity and disaster recovery.  Does the contract specify the recovery time object (RTO) and recovery point objective (RPO)?  Do these objectives match the bank’s stated RTO and RPO?  Are there remedies stated in the contract if the TSP fails to meet the RTO and/or RPO?  What is the disaster recovery notification time period?  Who is notified and by what method?  Again, this list of contract specifications is longer.

Now that you’ve determined what gaps exist in the TSP contract, how does the bank go about getting these contract specifications added?  The best time for this is when selecting a new TSP.  Writing the contract specifications into the RFP ensure the TSP knows up front what is expected.  Another opportunity is during an agreement renewal or renegotiation.  Take the time to confirm that the TSP understands what is expected and why.  At this stage having legal counsel participate may be warranted.  Finally, leverage user groups or forums to lobby other TSP clients to demand the same contractual modifications, especially if other banks are clients of the TSP.

The time has come for banks to become more diligent in the contract review and more purposeful in their contract negotiating.  If the bank doesn’t protect its best interests, who will?

Past Weekly Security Tips – WST