Corporate Governance (Vendor Risk Management – VRM)

 

• Vendor risk management (VRM) is the ongoing management (or attempted management) by the enterprise of any form of risk to the enterprise that may be caused by some action or failure to act of a second-party supplier or vendor to the enterprise, with which the enterprise has a direct contract; VRM involves the enterprise in constantly assessing, managing and monitoring all second-parties to the enterprise, with which the enterprise has direct contracts, to ensure that such second-parties are constantly assessing, managing and monitoring their own behaviors, so as not to add their risk to any risk of the enterprise itself.

​​

• Although VRM may sound very similar to third-party risk management (TPRM), there is a nuanced-distinction between VRM and TPRM; VRM involves any risk to the enterprise caused by a second-party supplier or vendor to the enterprise, with which the enterprise has a direct contract, whereas TPRM involves any risk to the enterprise caused by a third-party supplier or vendor to the enterprise (meaning one which is a second-party to the supplier or vendor with the actual direct contract with the enterprise), with which the enterprise has no a direct contract.

​​

• There are numerous advantages to an enterprise for expending the massive amount of capital and personnel time required for the enterprise to implement and continuously-maintain a VRM program, such as, for example:

  • abilities for the enterprise to quickly-identify any risky behavior by one or more of the suppliers and vendors already in the enterprise VRM program, so any correction required by the enterprise could be sent to all suppliers and vendors immediately;

  • controlling the access of all suppliers and vendors already in the system to sensitive enterprise data, and limiting such access severely to only a restricted number of supplier and vendor personnel who must have such access in order to perform their work, thus perhaps reducing the number of possible data breaches and leaks (and in the event there was ever such a data breach or leak, the logging capabilities of the VRM program will make it simple for the enterprise to track backwards, to find the exact point of origin of such breach or leak);

  • easier offboarding for suppliers and vendors, since the complete history of their contracts would already be contained in the VRM program archives;

  • enterprise-wide monitoring of all internal controls (both within the enterprise and within each supplier and vendor already in the system) for greater security control;

  • faster dissemination of information, both within the enterprise, and to the suppliers and vendors already in the enterprise VRM program;

  • holding such suppliers and vendors accountable for their contract failures or causing risk to the enterprise, because the VRM program provides transparency and visibility into the contracts lifecycle management (CLM) of such suppliers and vendors, so the logging capabilities of the VRM program will make it simple for the enterprise to track their errors or omissions;

  • improved new supplier or vendor onboarding process, due to the greater accuracy of information resulting from the fully-functioning VRM program;

  • monitoring the second-party suppliers and vendors, the enterprise is hopefully able to preemptively-warn such second-party suppliers or vendors to eliminate, mitigate, or remediate any threat to the enterprise originating from such second-party supplier or vendor, before such threat affects the enterprise;

  • reducing enterprise spend through identifying and eliminating redundancies in contracts within both the enterprise CLM and enterprise supply chain;

  • remote monitoring of supplier or vendor performance on any contracts with the enterprise through key performance indicators (KPIs) and service-level agreements (SLAs) that are components of such existing supplier and vendor contracts with the enterprise;

  • tracking the compliance of all suppliers and vendors already in the system against numerous domestic and international laws, thus reducing the potential for fines and investigations by governments in numerous jurisdictions against both the enterprise itself and also against such suppliers and vendors.

​​

• Before selecting a VRM software platform, it may be prudent for the enterprise to consider the framework design (meaning how the potential VRM software platform will interact with enterprise users and with the enterprise itself) used by the VRM software platform vendor in the design of the potential VRM software platform; since such design follows generally three (3) basic business models, the enterprise may wish to choose a VRM software platform with a framework similar to the basic business model on which the enterprise is based – centralized (all interactions between users and the VRM software platform are controlled though one or just a few access points (the possible advantage of this design is have better tracking of incoming queries and outgoing responses, but the disadvantage is a potential bottleneck situation if too many queries are received simultaneously, thus slowing down the VRM software platform); decentralized (there are unlimited access points, so any user may interact with the VRM software platform from anywhere (the possible advantage of this design is quick access, but the disadvantage is the potential difficulty in tracking queries and responses); hybrid (some combination of centralized and decentralized, allowing each business unit within the enterprise easy access to its own relevant information within the VRM software platform); the information about the particular framework design of a potential VRM software platform may be obtained from the vendor; recently, some vendors are offering universal designs, which allow the enterprise a measure of customization capabilities.

​​

• Prior to implementing a VRM program, the enterprise must establish an internal governing body of enthusiastic personnel, who will first perform all the tasks necessary to implement the VRM program, and once the enterprise implements the VRM program, who will then manage the VRM program for the enterprise; such governing body may have any name the enterprise management may assign, bust is generally called something very appropriate, such as the “vendor risk management committee” or the like; the Board of Directors, C-Suite and enterprise senior management will designate (through Board resolutions and corporate policies) an executive to manage that vendor risk management committee, perhaps with a tile such as chief risk officer (CRO), or whatever title the enterprise may wish.

​​

• Once the enterprise has established the vendor risk management committee, there is much due diligence the members of such committee must perform in order to fully-implement the VRM program itself, such as for example (in no particular order of precedence):

  • collecting a supplier and vendor inventory, with all available attributes and information about each, including the classification of each (generally based on the criticality of whatever good or service such supplier may eventually provide to the enterprise, and the level of risk that the operations of each may generate), such as for example – Tier 1: highest criticality, highest risk; Tier 2: moderate criticality, moderate risk; Tier 3: lowest criticality, lowest risk; and whatever further Tiers the enterprise may wish to create;

  • identifying all goods and services the enterprise produces, and exactly which suppliers or vendors may provide goods or services of their own that would eventually become components of of such enterprise goods or services;

  • analyzing all such goods and services, and all such suppliers and vendors, to determining what risks may be inherent in each individual good or service, and in each such vendor or supplier, so that the vendor risk management committee may be able to catalogue and understand the universe of risks that must be managed in the VRM program, at the individual good or service level, and at the supplier or vendor level, and at the enterprise level, to reduce the aggregate threat of all such risks to the enterprise;

  • prioritizing the risk types that may be most-concerning to the enterprise, from the plethora of potential risks, such as for example: board-approval risk; business continuity risk; business management risk; child labor and exploitation; climate change; compliance with numerous applicable laws in numerous jurisdictions; concentration risk; corporate social responsibility (CSR)-related; credit risk; criminal prosecutions; critical enterprise risk; cyberattacks; delivery failure; downstream risk; emerging risk; environmental social governance (ESG)-related; erratic human behavior; event risk; foreign ownership, control, and influence (FOCI); fourth-party risk; fraud; geopolitical; inter-country and inter-hemisphere trade wars; global and regional shortages of food, water and critical materials; governance risk; government investigations; human rights violations; human trafficking; increased competition; labor actions; lack of an educated workforce; lack of a skilled labor force; liquidity risk; market risk; natural resources shortages; new business models; operational risk; pandemics; population migrations; price increases; privacy risk; regulatory; regulatory enforcement actions; replacement risk; schedule changes; shipping container shortages; staffing shortages; sociopolitical instability; strategic risk; supplier financial distress; supply shortages; systematic risk; third-party complications; unanticipated sudden demand; upstream risk; unsystematic risk; weather catastrophes; worker strikes.

  • determining the “risk appetite” of the enterprise (an odd phrase, meaning basically the level of risk that the enterprise is willing to accept when trying to achieve its strategic goals, before such risk becomes too great for the enterprise to tolerate, thus causing the enterprise to take some form of action to either eliminate, mitigate, remediate or transfer such risk, to clear the way for the enterprise to return to attempting to achieve its strategic goals), which would be embodied formally in a risk appetite statement issued by the enterprise through the vendor risk management committee, for the benefit of management, stakeholders and potential investors, defining clearly what risks the enterprise has identified as being impediments to the achievement of the enterprise strategic goals (which should also be defined clearly in the risk appetite statement), and just how the enterprise has planned to eliminate, mitigate, remediate or transfer such risks, so the enterprise can return to attempting to achieve its strategic goals;

  • choosing an appropriate risk control framework (meaning, a set of risk assessment rules) by which to asses each such risk, such as those available from the Consensus Assessments Working Group (CSA), International Organization for Standardization (ISO), National Institute of Standards and Technology (NIST), Shared Assessments Standardized Information Gathering (SIG), or the like; and employ a risk matrix model as one of the risk assessment tools;

  • choosing a VRM program software platform itself, perhaps through the various enterprise procurement and sourcing protocols of requests for information (RFIs), requests for proposals (RFPs), requests for qualifications (RFQs), requests for quotes (RFQs), and requests for solicitations (RFSs); and once the award of a contract to the winning VRM program supplier or vendor occurs, ensure that such supplier or vendor performs extensive training for the vendor risk management committee, and all enterprise support personnel who will assist the vendor risk management committee; one critical requirement that must be strictly-enforced by the enterprise is that all potential vendors must continuously-maintain all the insurance types and limits required by the enterprise risk management department, and must include ACORD-type certificates with the responses such potential vendors provide during the vetting process, as evidence that they maintain such required insurance types and limits.

  • conducting supplier and vendor risk assessments, either online or onsite, using the guidance and templates provided through the VRM program; it may be beneficial for the enterprise to choose a VRM program platform that may have the capabilities to integrate with many third-party risk exchanges (third-party providers of information, risk scores and risk assessments about a myriad of suppliers and vendors);

  • inputting all supplier and vendor contracts into the VRM program platform, and enabling optical character recognition (OCR) capabilities, for enhanced search functions;

  • enabling all monitoring functions of the VRM program platform; commence generating reports about the contractual and external functioning of such suppliers and vendors; enable all alerts (particularly for when it might be necessary to reassess a particular supplier or vendor, for whatever reason), logging, notifications and updates functions; automate as many workflows as the VRM program may allow; continuously monitor the VRM program itself to identify areas of improvement.

​​

• One of the most-common self-assessment evaluation tools for VRM software platforms recommended to enterprises by security subject matter experts (SMEs) is the vendor risk management maturity model (VRMMM) software platform, which the enterprise will use to evaluate the different phases of VRM software platform implementation, with a focus on the information technology (IT) aspects – such as for example: business resiliency controls; cybersecurity; data privacy; data security; and the like – of the particular VRM software platform utilized by the enterprise; all VRMMM platforms must have several components – a clearly-defined methodology to identify the perceived vulnerabilities of an enterprise; a clearly-defined methodology to identify the perceived risks to the enterprise enterprise; and, a clearly-defined methodology to measure how efficient the utilized VRM software platform is at identifying such vulnerabilities and risks, and then how efficient the utilized VRP software platform is at combatting all such risks to all such vulnerabilities; one of the main values of a VRMMM software platform to the enterprise is to find ways to improve the efficiency of the enterprise VRM software platform, thus making it easier for the enterprise to identify potential high-risk suppliers and vendors more quickly.

​​

• Each VRMMM software platform will have its own proprietary maturity ranking model, consisting of various maturity levels (proceeding up from total immaturity – meaning little or no VRMM software platform operations – through full maturity – meaning a fully-functioning VRMMM software platform, operating at a high level of efficiency), and there are assessment forms and questionnaires that must be completed by the appropriate enterprise personnel at the achievement of each possible maturity level, which will then be evaluated by both enterprise senior management and the VRMMM software platform vendor, to reach alignment about the progress of the VRMMM software platform in achieving the clearly-defined goals for that particular maturity level.

​​

• A general example of possible VRMMM software platform maturity levels may be, for example:

  • installation (little or no VRMMM software platform operations because the VRMMM software platform was just installed, and the appropriate enterprise personnel are being trained in its functions and use);

  • initial operations (the appropriate enterprise personnel have been trained, and are now beginning to operate the VRMMM software platform);

  • efficacy (the appropriate enterprise personnel are now reasonably-adept in the use of the VRMMM software platform);

  • sophistication (the appropriate enterprise personnel are now able to operate the VRMMM software platform basic alerts, analytics, measurement tools, notifications, reporting, and the like);

  • proficiency (the appropriate enterprise personnel are now able to customize, manipulate and understand all the capabilities of the VRMMM software platform);

  • collaboration (the appropriate enterprise personnel have become so familiar with the VRMMM software platform  that they are able to suggest potential operating improvements to the VRMMM software platform vendor, and then to work directly with such vendor to test and implement such improvements).

​​

• Once the VRM software platform is up and running, one of the most important questions that must be addressed is the risk scores to be assigned to each vendor; the VRM software platform should have built-in capabilities to do this, supported by a repository of numerous risk assessment questionnaires that every potential vendor must complete; in order to assign a risk score to a particular vendor, the VM software platform will analyze all the answers provided by the potential vendor to the numerous questions on the  the numerous questionnaires, and then run all that resulting data through a vendor risk matrix tool to generate a risk score for each potential vendor; the entire process can be summarized by the basic formula, likelihood of a threat to the enterprise x impact of such threat to the enterprise = vendor risk score (the risk posed by that potential vendor to the enterprise); this is a quick metric to justify senior management accepting or rejecting potential vendors), and should be employed during the potential vendor selection process, to avoid pre-qualifying potential vendors which may pose great risks to the enterprise at some future point; the enterprise should also establish a yearly schedule for regular reviews of vendors, based on their risk scores, perhaps as follows – high-risk vendors quarterly; moderate-risk vendors semi-annually; low-risk vendors annually, and the VRM software platform can be configured to generate alerts for reviews, based upon a pre-defined list of triggering risk events by a vendor, such as – bankruptcy, decrease of credit rating, excessive layoffs, excessive lawsuits, and the like; the enterprise may also base the frequency of reviews on the type of work the vendor may perform for the enterprise, such as – critical goods or services (most-frequent review period); customer support; data processing; back office; non-essential goods or services (least-frequent review period).

​​

• In keeping with with the current enthusiasm for cloud-based solutions to every conceivable business need, there are now a growing number of vendors offering cloud-based vendor-risk-management-as-a service (VRM-a-a-S or VRMaaS) solutions; as with most cloud-based solutions, they may be based in some remote location or foreign country beyond the jurisdiction in which the enterprise may be located; thus, the enterprise must pay particular attention to – the security measures the VRM-a-a-S vendor will offer, to protect sensitive enterprise data; the laws of the jurisdiction in which the VRM-a-a-S itself is located (in the event of litigation); the type of data that will be sending to location in which the servers for the VRM-a-a-S vendor are located (the EU General Data Protection Regulation – GDPR – requires an enterprise to identify the particular types of data that may flow in and out of any EU member jurisdiction, and if any sensitive personal information is included, the entire GDPR may become applicable to the entire such data flow).

​​

• A very interesting development related-tangentially to VRM is the recent use of virtual credit cards to manage vendors when making business-to-business (B2B) payments from the enterprise to vendors; a virtual credit card is akin to an intranet, which is under the control of the enterprise, open to only a select few, and closed to the vast majority (whereas a regular credit card would be akin to the internet, which is controlled by forces external to the enterprise, but is open to all); the advantages of this arrangement to the enterprise are that the enterprise can – limit spending for vendors; set an overall spending limit, or multiple one-time limits; track all payments to vendors with greater ease, since all payment information is under the direct control of the enterprise (rather than under the control of external credit card issuers), since such payment information is already in the VRM software platform; cancel such virtual credit card with ease; pay vendors immediately, with no lag time for payment settlement processing, as happens at financial institutions; control the security issues inherent in electronic payments, since no sensitive personal information is exchanged in a virtual credit card transaction.

​​

• Drafting and negotiating all VRM-related documents, and legal support for all VRM-related tasks.

​​

• Progress_Page_Last_Updated_221105_1814