Inherent Risk Tiering for Third-Party Vendor Assessments
It can be a challenging and overwhelming task to adequately manage the risk associated with outsourcing technology or business processes, no matter the size or sector of the organization. This is supported by a study sponsored by the Ponemon Institute, which gathered responses from hundreds of respondents across both public and private sectors to present a view of the state of Data Risk in the Third-Party Ecosystem. Though the study presents several interesting findings, two are of particular concern: 1) 56% of the respondents indicated that they had experienced a data breach or cyber-attack caused by a third party, and 2) 57% responded that their company did not have a comprehensive inventory of all third parties with whom they share sensitive and confidential information.
It is often enticing to contract a vendor for assistance instead of spending the time and effort to devote internal resources to its development, implementation and maintenance. It could be preferable to contract a vendor due to a few reasons including being the first to market, a lack of in-house expertise, or the vendor solution may be tied to a broader sourcing strategy that will be more cost-effective in the long run. No matter what the underlying reason, outsourcing to third-party vendors poses a unique set of risks that must be diligently governed through risk identification, assessment, treatment, and monitoring. For the purpose of this blog, I will focus on the first element, risk identification.
A vendor who is accessing, transmitting, storing non-sensitive data solely within your environment may not pose the same level of risk as a vendor who is accessing, processing, transmitting and storing personal health information (PHI) for all of your employees in their data center. In order to appropriately identify risk, organizations must cleanly separate those third-party risks into tiers through a determination process utilizing a set of well-defined criteria. At a high level, you should seek to determine:
- What type of information will the vendor have access to?
- What is the risk associated with the information the vendor will access?
- How is the vendor accessing and transmitting the information?
- Where is the information being accessed by the vendor being stored?
These tiers will ultimately assist in determining the level and frequency of due diligence required while directing stakeholders to an appropriate set of supporting risk practices and procedures. For example, there may be a scoring model that yields three third-party vendor risk tiers:
Assessment type and frequency is merely one decision that could be made with the tiers – other options might be escalation paths and the level of seniority required to accept a risk related to a third-party vendor.
Third-party risk management could be integrated closely with all other aspects of Enterprise Risk Management (ERM), which may isolate a key business process and then enumerate the risk elements of each separate domain (i.e., operational, regulatory, business continuity, and third-party). Another common approach is to operate an Enterprise Third-Party Management (ETPM) program as a standalone risk and compliance program that incorporates the needs of those risk domains into the assessment cycle. In either case, there must be a means of tiering third-party vendors into meaningful groups so that risk identification, assessment, treatment, and monitoring are all proportionate to the risk at hand. If this is not done effectively, then an organization is likely to be performing far too many or too few risk activities.
Let’s take an example – consider the following third-party vendor relationships for a financial institution and rank them from highest to lowest inherent risk (i.e., risk posed before the consideration or application of controls):
If you were hoping that your ranking was the correct one, think again – there’s no right answer. In the example of Company C, one may assume the guards “only” have physical access, but that may be more than enough to cause a damaging risk event to be realized if one does not determine what is stored in the physical location and the guards’ access level to said items/information.
On the other hand, one might gravitate to the mobile application being highest risk (Tier 1) because money transfer is involved, but after completing your determination process, you may find that the purpose of the software does not add any additional inherent risk than any other third-party software development effort. The correct response would be that you need some common and consistent way of gathering inherent risk attributes across each of these third-party vendors to be able to accurately rank them.
The above scenario may have been simplistic and specific to one industry, and one in which third-party risk management practices are heavily scrutinized, but the principles typically apply to any industry or enterprise. Below we’ll review three considerations that organizations should be using to assist in the development of a set of inherent risk attributes to consistently score and rank third-party vendors.
Data, Data, Data…
A third-party vendor’s access to an enterprise’s internal documents or consumer data should be the key attribute contributing to inherent risk calculation. Even if the final risk scoring model doesn’t weigh the confidentiality of said data as high as the availability of that product or service, the value of the data quite simply cannot be ignored or understated. The nearly constant drumbeat of Information Security news featuring companies and their inadvertent and often negligent data handling transgressions seems to show at least the value the public places on the protection of that data. Important details such as data classification, volume of records, type of access (read only, modify, execute), fourth-party access, etc., should be carefully considered, but each of those should begin with the context of the data in question.
Inherent Risk Should Not Be Confused with Scoping of Controls
When developing a set of inherent risk attributes, certain questions, such as those described above relating to the type and quantity of data, would almost always be included in a calculation of inherent risk and subsequent tiering. Other questions, however, may be asked as a means of routine data collection and/or assessment scoping. In many cases, the separate goals may be easily conflated. For example, a question may be asked as followed: Does any part of this third-party relationship pertain to Payment Card Information (PCI)? In many cases, an affirmative answer would simply result in a set of control/compliance questions asked during an assessment to ascertain whether or not the Payment Card Industry Data Security Standard (PCI-DSS) is being followed. A rational argument could be made, however, that payment card information being involved implies a level of inherent risk, and the control assessment questions would then be used to identify compliance and derive a level of residual risk that must be addressed. Regardless of whether it is for inherent risk or another purpose, ensure that the rationale behind each question in a third-party vendor questionnaire is clearly understood. The best way to approach this is to tie each and every question to a clear set of outcomes with a stakeholder identified. If a question is being asked that does not contribute to the inherent risk score or scoping of controls, ensure that there is value in asking the question or evaluating the response. If concrete decisions are being made or escalation required for a response, that should be clearly documented and communicated.
Ensure these attributes are accurately entered and easily updated
Inherent risk questionnaires are nearly always “snapshots in time.” At best, they capture accurate responses upon completion, but may be inaccurate in short order. At worst, the questionnaire starts out as inaccurate because the questions may be misunderstood, skipped over too quickly, or purposely answered to understate the risk. As such, there must be some level of governance over inherent risk questionnaires to ensure their accuracy. There also should be a mechanism to ensure that updates and changes to the questionnaire are prompted based on a change in status and done so promptly.
Who is Reviewing Your Questionnaires?
Once an inherent risk questionnaire has been developed, a scoring model is created, and outcomes are documented, the work has only just begun. The most important part remains to evaluate the responses, ensure quality control, and validate that appropriate decision making is taking place as a result. If a question owner creates a question, but never bothers to evaluate the responses, it may not be gathering the correct information or contributing to the scoring model the way it was initially designed. For example, perhaps the sourcing department writes a question that intends to track offshore business processes or technology elements to ensure appropriate governance and compliance. Further, presume that the question only asks about involvement and adds to the inherent risk score whether or not offshore data access is involved. At some point, an engagement owner or a stakeholder from sourcing would need to evaluate those individual or aggregate responses to verify that the question and responses are in fact gathering accurate data resulting in risk-based and appropriate decisions. The department responsible for evaluating these responses and making corrections as needed is not important – rather, it’s more important to ensure the right personnel are doing it at the most appropriate time interval.
Effective third-party vendor management can be a challenging and overwhelming task, as an organization has outsourced the technology or process, but they still retain all the risk. Several components would go into a successful program, but an organization must start with asking a set of clear and consistent questions to relationship owners or project managers that derives the inherent risk. Not doing so puts them at peril of lumping too many third-party vendors into the same risk group, which translates to doing too much or little to ensure risks are being identified, treated and monitored appropriately. Instead, define the inherent risk data points that are most important to your organization, collect accurate responses for those data points, and be more at ease with the knowledge that you’re addressing third-party risk in a clear manner.
Want to be part of what we do next? Join our Team.
Additional Blog Posts: https://www.mindpointgroup.com/blog/your-datas-your-data-managing-third-party-risk/
 Data Risk in the Third-Party Ecosystem, Second Annual Study, Ponemon Institute, 2017.