<div dir="ltr"><a href="http://www.bankingexchange.com/news-feed/item/7239-data-breaches-good-reminders-of-vendor-risks" target="_blank">http://www.bankingexchange.<wbr>com/news-feed/item/7239-data-<wbr>breaches-good-reminders-of-<wbr>vendor-risks</a><br><br>Data breaches involving billion-dollar companies ranging from Deloitte, Yahoo!, and, of course, Equifax have forced bankers and regulators alike to place increased scrutiny on vendor risk management practices.<br><br>Data liquidity will be a key focus for efforts towards mitigating future reputational, operational, and legal risks.<br><br>Compared to other businesses, banks have a higher bar to reach when developing risk management programs. Federal regulators are constantly monitoring for potential missteps and there is an increasing level of expectation from customers to improve security.<br><br>Following the recent Equifax breach, bankers must ensure that their vendors are putting the proper controls in place to mitigate all potential threats.<br><br>Prioritizing and stratifying vendor risk<br><br>Risk management is intended to be a process of identifying the biggest threats to your organization. The first step towards creating a proper program is to stratify risks categorically. Some banks apply the same risk rating to each of their vendor relationships, regardless of the service provided; the level of access they have to bank data; or the types of data shared.<br><br>This, frankly, is a recipe for disaster. Some vendors pose a larger, more catastrophic risk to your bank than others. For example, most financial intuitions are leveraging one vendor for branch automation technology while using another for their loan origination system (LOS). While both vendors have access to the institution’s network (which must be accounted for), the LOS is potentially pulling much more sensitive data from the bank into their own system. This flow could be easily compromised if the vendor is lax in managing its own safeguards.<br><br>This brings up the key issue of managing exactly how data moves through an organization. Some vendors require data to be transferred between the bank’s server and their own, while others process data within the institution’s servers.<br><br>Some banks might consider getting into this a trivial nuisance, but it’s of critical importance to a robust risk management program.<br><br>It’s true that internal intrusions are a key risk for financial institutions, but what could be more risky than allowing data to leave an organization? Once data is outside of a bank’s network, bankers have little to no control over it, and it’s up to the vendor to hold up their end of data security.<br><br>Safeguards and due diligence<br><br>After evaluating, categorizing, and tracking the various risks posed by an institution’s vendor relationships (technology or otherwise), the bank must conduct its due diligence and ensure the vendor is upholding its end. This typically equates to a requirement on the vendor’s part to provide documentation that demonstrates the company’s security arrangements and controls.<br><br>Such analysis can be critical to any vendor-bank relationship. Yet frequently this is only done at the onset of a relationship— once a program is up-and-running conducting any further analysis is too often treated as an unnecessary, time-consuming expense.<br><br>Due diligence, in reality, should be an ongoing effort and one that never takes a backseat to the operation itself.<br><br>Even if a vendor has the proper safeguards in place at the beginning of a relationship, that does not mean those controls will remain up-to-date or effective over time.<br><br>Consider the Equifax breach, where not updating the Apache Struts web-application enabled hackers to gain access to more than 145 million Americans’ personal identification information, including Social Security numbers. Based on percentages alone, that means that half of any given bank’s customers may be impacted.<br><br>This underscores an important point: What’s true the moment a contract is signed may not be the case months, or even years, down the road.<br><br>This is particularly the case for technology vendors who have specialized access to a bank customer’s data. Physical threats have always been ubiquitous for banks. Bankers understand that branches and ATMs can be targets for criminals, and they have put protections in place to limit those risks, but technology and software threats are always evolving.<br><br>Hackers constantly discover workarounds to what was once perfectly secure technology. It’s their livelihood to do so. It’s a banker’s job on the other hand, to limit the number of potential backdoors and routes a hacker can use to commit criminal acts.  <br><br>Response tactics when inevitable happens<br><br>Once a financial institution has a strategic, robust risk management program in place, and has conducted proper due diligence on all of its vendors, it’s up to the controls in place and the institution’s regular audits to ensure that no issues occur.<br><br>Risks are always there. A bank can take all the precautions in the world and hire the best people available however, and a disaster can still occur. A patch can be missed, an employee will click a malicious email link, or a hacker will simply find a new and innovative way of accessing data that no one could have predicted, other than the hackers themselves.<br><br>When infiltration occurs, the approach shifts towards mitigating the opportunity for a disaster to ever occur again. To do this, banks must identify where any missteps occurred within the program, whether or not there was a fundamental flaw in the initial risk assessment or if the vulnerability was previously unknown. This way, bank management can better identify where to implement new and more robust controls.<br><br></div>