Third-Party Risk Management: 5 Characteristics of an Inefficient Program

Prepared By

Chris Gida, Risk Management and Governance, NCC Group

The rise of specialized services has brought about an explosion of external suppliers and vendors brought in to help organizations improve productivity and meet their business needs. For a company focused on core operations, it makes financial sense to handover non-core functions to third parties. Unfortunately, this introduces a whole new element of risk in the company's ecosystem. 

Even as organizations recognize the ever-evolving threats to their immediate operating environment, they often ignore the protection of data or access to internal systems provided to vendors. While some organizations do specify cyber security requirements as part of their vendor evaluation process, there's often internal and external pushback on what can or cannot be imposed on vendors.

1. Lack of Stakeholder Support.

Oftentimes, we see that departments are not working together to gain support and buy-in to the program. Without this support, the team executing the program will have a difficult time achieving success.

For example, support from the Legal team is needed to enforce contracts with sufficient language to detail the obligatory vendor requirements. Support from business leadership is critical, especially because of how the business is impacted when decisions are made to no longer do business with a vendor.

2. Not asking the appropriate questions.

In many cases, a large voluminous questionnaire is being used to perform a wide sweeping assessment of vendors. However, the staffing required to review these questionnaires is not considered. The questionnaire must be tailored to the function performed by the vendor. The vendor should only be asked to demonstrate adherence to applicable controls, which are not supported by contract terms. 

3. Internal departments working disparately.

We've seen several cases where the vendor review process is split into parts. For example, vendor selection may sit with procurement; departments within the business are onboarding vendors independently; the Information Security team is assessing vendors post-signature; and the accounts payable team is not integrated with anyone. 

An end-to-end vendor risk management program should be designed as an enterprise-wide solution to seamlessly integrate individual departments to collectively manage vendor risks.

4. Purchased tools are "force-fit"

There are a number of tools that can be purchased to support a vendor risk management program. These tools are designed to reduce manual efforts and provide visibility into progress.

We frequently observe one of the following two scenarios, where the tools selected selected are causing further resource consumption than intended

5. Lack of transparency.

For some reason, the assessing organization will often neglect to communicate with vendors about the required controls. For example, the organization will notify the vendor that they need to respond in full to the attached questionnaire (containing 500 questions) in the next two weeks. The time and effort to complete this task can be significant, and that doesn't take into account the other three questionnaires the vendor received from other customers that week.

Transparency and communication with the vendor can significantly assist in streamlining the entire process. The relationship should be treated as a partnership rather than a jail cell toss for paraphernalia. 

Many organizations like to focus on efficiency for resource demanding programs like vendor risk management, but a solid well-functioning program is the key first step. Addressing your program's core issue will set it up to more efficiently reduce risk while maximizing the resources allocated to the program.

Many organizations widely accept SOC 2 reports in lieu of completing security assessments of their third parties. SOC 2 reports can often be complicated and difficult to align to the products and services provided by third parties so it's important for organizations to ensure they have the appropriate personnel in security and/or risk management have specific domain expertise in SOC 2 reports. SOC 2 audits are not all equal and in reality, they have become an unchecked commodity market.

Having a SOC 2 does not mean the organization or product is without risk. For example, a validation process is not in place to ensure SOC 2 audits are completed in alignment with AICPA (American Institute of Certified Public Accountants) requirements. Therefore, the breadth and detail of assessments completed for a SOC 2 audit range significantly. Even the cost for a SOC 2 audit can differ by more than $100,000 for the same assessment and there is not always a correlation between cost and quality.

A SOC 2 based third-party risk assessment process may be easy to deploy, however, organizations rarely take the time to fully read and understand the report. Not to mention consider its validity and ensure there was not a conflict of interest involved during the audit process.

For these reasons, use the SOC 2 report as a supplement to a comprehensive security assessment questionnaire when assessing your third parties. This dual approach allows you to see a full picture of their technical and policy-driven security controls in addition to the results in the audit report. Leverage the questionnaire to ask specific pointed questions on controls and then expand the questions to ask for details on the SOC 2 report as well. A comprehensive risk assessment program should use multiple elements to build and assess the risk posed by each third party.