Over the past year, the OCC, the FRB, and the FDIC have all released updated guidance on managing third-party risk. One focus of this guidance is the identification of “critical” vendors and board-level approval, which highlights the importance of understanding how third parties expose the banks they serve to privacy concerns and operational risk. The question isn’t, “What happens to the third party if there’s an incident?” Rather, it’s, “What happens to the bank(s) served if there’s an incident at the third party?” The importance of this distinction is obvious, but too often overlooked by those tasked with managing third-party risk.
As an assessor, it’s easy to focus on the third party under review while ignoring the dynamics of the relationship between that third party and the business process they serve within your organization. Outside of an organization’s senior ranks, it’s rare to find individuals who understand key processes from end-to-end, including the roles played by vendors and other third parties. In this light, the recent theme in regulatory guidance is both strategic and timely. In addition to prescribing expectations for vendor due diligence, the new guidance should have the positive effect of influencing banks to put their vendor risk management programs into better context within their own business risk.
Nevertheless, many banks still act tactically when it comes to assessing and monitoring how third parties manage risk. As an example, our organization was recently asked to provide an official response describing how it dealt with the Shellshock vulnerability. Frankly, this isn’t the right question.
Heartbleed, Shellshock, and POODLE have gotten more than their fair share of press over recent months. But if an organization only addresses the vulnerabilities that are featured by the mainstream press, it’s doomed. The Common Vulnerability Exposure (CVE) database, operated by MITRE Corporation (a federally funded, nonprofit organization), aggregates and standardizes reporting on vulnerabilities. The CVE database recorded over 7,200 vulnerabilities during 2013, and as of October 15 has recorded over 6,000 new vulnerabilities already for 2014. With a tempo of approximately 20 new vulnerabilities every day to consider and, if applicable, mitigate, IT organizations have to treat vulnerability management as a short cycle control or even a continuous control if they’re going to adequately protect the systems, data, and business processes they support. The question isn’t, “What did you do about Shellshock?” Instead, the correct question is, "How do you manage vulnerability reports by the thousands each quarter – and do so without disrupting business operations?”
The Gramm Leach Bliley Act (GLBA) of 1999, section 501 (b) Safeguards Rule that went into effect during 2003, kicked off the current third-party risk management frenzy by requiring banks to not only implement a security plan for protecting customer information, but also flow that plan down to their third parties by way of contractual obligation and assessment. Since that time, regulatory guidance has continually increased the scope of these programs to include broader topics of risk, in particular drawing attention to operational risks that threaten the resiliency of the banking system itself.
Perhaps more valuable than the guidance is the example set by the seemingly organic maturation of that guidance over the past decade. The regulatory mission in this case is one of "public health" and its objective is to drive a minimum standard of risk management capabilities across a wide community. Being examined by a regulator can be disruptive and bothersome, but the strategic dialogue driven by these interactions is a positive and important outcome. To the degree that third party risk management programs essentially place banks into the role of "regulator" of their vendors, there’s an opportunity to not only specify and assess controls, but also inspire a strategic and operationally robust approach to risk management.
Sean Cronin is responsible for leading all aspects of ProcessUnity's Risk Suite line of business including strategy, marketing, sales, client services, and strategic partnerships. He brings over 12 years of Governance, Risk and Compliance (GRC) experience to the company. Sean ... View Full Bio