Organizations are becoming increasingly reliant on external parties to manage parts of their business. The centralized knowledge, expertise, and economies of scale that third parties provide enables organizations to focus internal resources on their core services and reduce effort to develop, implement and maintain technologies and processes. While a great deal of time and maintenance is transferred to these providers, there are remaining risks which are still the responsibility of the organization. These may be financial risks if a vendor goes out of business, experiences downtime, or loses key staff, which is an increasing concern during the current COVID business environment. There are extensive legal risks related to how the vendor may use or protect the data based on laws such as the General Data Protection Regulation (GDPR), California Consumer Privacy Act (CCPA), Health Insurance Portability and Accountability Act (HIPAA), New York Department of Financial Services (NYDFS) and many others. Cybersecurity risks if a vendor hosting information were to experience a breach can be particularly costly and damaging for an organization. Finally, reputational risks by simply being associated with a provider who experiences newsworthy negative events, even without direct violation of laws or contracts, can also impact organizations. Add to these additional industry and geographic laws related to trade compliance, anti-bribery and corruption, and public transparency and the risk environment quickly becomes complex.

Third party risk management and vendor due diligence processes are intended to help the organization proactively identify, remediate, and manage these risks. Despite policies with well-intended and thoughtful organizational goals for these program, they are often very difficult to operationalize and maintain. This is because they frequently rely on very manual, document-based, or disparate processes that lack objective procedures, transparency, and the ability to monitor risks over the long term. Based on experience working with organizations in across industries on their risk, compliance and legal processes, below are five best practices for developing and maintaining a third party risk management program.

1. Identify a Risk Framework: As a first step, organizations should define the problem they intend the process to address. This involves establishing a framework or set of frameworks which identify risk management and compliance obligations. These may include laws such as the CCPA, GDPR, NYDFS, HIPAA along with industry frameworks such as the National Institute of Standards and Technology’s (NIST) Cyber Security Framework, Supply Chain Security and universal screening tools such as the Standardized Information Gathering (SIG) questionnaire. This process helps the organization define their risks and ensure that they are gathering the necessary attributes to evaluate vendors. These frameworks, laws and questionnaires are unique in some ways but also have a great deal of overlap. I find it useful to map the obligations and outcomes to a singular framework. For example, I often recommend a version of the NIST framework to which we have mapped the various data protection laws and allows for integration of new laws which are more frequently becoming applicable.
2. Leverage Technology: As previously mentioned, these processes frequently involve very manual activities which include vendor risk teams exchanging emails and Excel files with vendors and then conducting a review and assessment which may not be memorialized. While these processes might be easier and less expensive to develop in the short term, they are often not maintainable in the longer term. They lack transparency, automation, and reporting which are necessary to demonstrate that procedures are being applied in a consistent manner. Additionally, they are difficult to review historically to evaluate where the risk profile of an existing vendor may change due to new services, new laws, or other changes to the business or regulatory environment. Leveraging a technology platform allows organizations to develop a standardized process which can be followed, scaled, and reported upon. Allowing for certain communications, workflows, and risk identification to be automated can help save time, cost, and drive consistency. Additionally, these platforms provide a greater level of transparency to review existing vendor rosters and attributes. If a particular software platform experiences a notable breach, having a central list of vendors allows an organization to query for any vendor who might use that software and remediate. These tools also make it easier to identify which vendors may require amendments to contracts, such as those required by the GDPR when personal data is being transferred or shared across borders. Another benefit is they give the organization the ability to track and hold internal or external parties accountable for remediating identified risks by providing automated reports and reminders when open issues persist. Finally, the platforms provide a greater level of reporting to understand key performance and risk indicators which are important to management stakeholders. These may include the average time to complete vendor reviews, trends in most common risk types, volumes and tiers of vendors, etc.
3. Formalize Responsibilities, Rules, and Decision Criteria: Many risk management programs are chartered by policies which describe the desired outcomes but lack more formal assignment of roles, responsibilities, and rules. It is critical for organizations to identify which parties are responsible and accountable for the process as well as those who should be consulted or informed of changes and ongoing results. Often times, the review and evaluation of vendors is more of an art than science. While there will always be a need to make risk-based decisions and willingness to accept risk based on the impact or likelihood, organizations need to define the default decision criteria that will be applied. This may involve an initial assignment of quantified risk to each attribute in a vendor questionnaire. The procedure should describe when certain scores or specific answers require escalation or the review of other individuals or teams and what are acceptable levels of likelihood of a risk event occurring in conjunction with the impact that would have on the organization. While this concept is generally accepted, the mechanics, rules and thresholds are often not well defined in a manner that would provide defensibility if reviewed by a regulator in events such as a vendor breach.
4. Communicate and Collaborate: Third party risk is constantly evolving and unpredictable. It is important that the results of the program be communicated to other parts of the business. For example, legal teams need to understand how evolving third party risk may impact their contracting and possible litigation response processes. Additionally, I often find with larger organizations or those who have gone through M&A processes that they have a great deal of duplication across their vendors and technologies. Having information in a central location which can be easily reviewed allows for teams to identify areas for efficiency and cost savings by consolidating processes with fewer vendors while also reducing risk. All these pieces of information should be communicated to help the vendor risk management team earn a seat at the table by communicating the value across the organization.
5. Do Not Skip Internal Software Development: Lastly, while we have focused on external parties here, I find that internal software development lifecycles continue to present a risk area that needs similar attention. Some organizations have a false impression that when software or processes are developed by internal teams that the risk may be less because they have greater control over the resources. While the organization does have greater insight, they still need to apply risk analyses to internal development as the teams may not fully appreciate the legal and compliance obligations that intersect with their work. The advent of low-code platforms and third-party software development kits (SDKs) have enabled internal development teams with less specialized knowledge to build more robust applications by click-and drag development and connection to external platforms which help enhance or enable to solution. Many of these are free or openly accessible solutions which can provide a new third party access to information without the organization realizing it. As an example, there several current and notable cases where internal teams used such third-party SDKs to enable customer sign-on to their tool through other social media platforms. The team was unaware that this would then trigger the personal data of their customers to be shared with those sites and other third parties. This has been cited in numerous class action lawsuits against the organizations for violation of cybersecurity, privacy and shareholder laws.

Outsourcing key parts of an organization's operations to third-parties provides a great benefit in allowing a company to have access to talent and technology that help drive greater results and manage costs. This also encourages greater economic innovation for new companies to build and commercialize services which did not exist in years past. As part of this shift, it is critical for companies to enhance their third party risk management processes by considering the practices above.