Third-Party Risk Management – 4 Steps for a Successful Program

Technology has greatly enhanced the ability to connect with clients, prospects and partners. It has also significantly increased the threat landscape organizations face. In this post we’ll focus on the last of these three, the expanding partnerships we work with daily and the sharing of information between organizations, and how to ensure the third parties work with are properly protecting our data.

The four key steps for maintaining a successful third-party risk management (TPRM) program include:

1 - Information Collection

Once a program is in place, organizations should be able to maintain information collection. Automated scans or self-attested internal or external questionnaires can both achieve this. If possible, it is best to capture this information in a single source, so you can determine where the third-parties fit in your organization’s risk-tiers (Ex. Tier: 1: High, 2: Medium, 3: Low). Manual collection of information can become a quick bottle-neck to the process. Automation or simplicity is key to alleviating this so third-parties who are beyond the threshold (High Impact) can be quickly identified and escalated for analysis.

Risk tiers and thresholds are generally aligned around shared information related to regulatory and compliance statutes (GDPR, GLBA, PCI-DSS, HIPAA, etc.) and potential business-impact (Data Centers, Cloud services, service-delivery, etc.).

2 - Analysis and Risk Management

The analysis of a third-party can be done using many tools (both automated and manual), which can leave many wondering: “Where do I look for answers?” While the collection of information is best automated, the analysis portion is best done in a manual, human fashion, as today’s technological solutions cannot match a human’s ability to understand the context of a third-parties use by the organization (Qualitative analysis).

Depending on the organization’s tolerance for third-party risk, a limited capacity to perform analysis across all high impact third-parties may be an issue. This can often be addressed by revising thresholds to give adequate attention to only the highest impacting third-parties. If this is not an acceptable solution, bringing in a service provider to augment the TPRM program and provide the needed level of analysis should be considered. The temptation to dial-down the time spent on analyzing, or the depth of analysis, is often met with leaving questions unanswered and risks not being mitigated across all of the third-parties. Unfortunately, this is a common occurrence in the face of staff shortages.

3 - Reporting

Operational reporting is the keystone to any successful program. Gaining quick insights on what has been completed, and what still needs to be addressed can save hours each day in remediating issues and keeping the program on track. Unfortunately, most tools in the TPRM space are just not equipped to provide custom operational reports that reflect the steps and stakeholders in the process. Those that do can take months if not longer, to implement, run and tune the process. Solve this gap through a combination of, APIs, Business Intelligence Tools, Task/Issue tracking platforms, etc. This step is critical and should not be overlooked or thought of as an unnecessary part of the program.

Executive buy-in for the TPRM program can be won through effective reporting of identified risks (“What we didn’t know.”) and mitigated risks, which may be associated with a monetary number (Annual/Single Loss Expectancy). These amounts should be aggregated and compared to the annual budget for the TPRM program to give a clear indication of ROI. This action provides the program with the attention and support needed to mature and become an integral part of the organization.

4 - Monitoring and Reassessment

Because business relationships can change suddenly, more often than not, scheduling third-party periodic reviews and reassessments is not enough. It is essential to have excellent communication between the TPRM and Legal teams so that any contractual changes can be reviewed to determine if the alterations are significant enough to justify a reassessment of the third-party based on a new threshold. For example, going from medium or low risk to high risk. Not only can the relationship change, but so can the third party’s control environment and vulnerabilities around the technologies utilized. The proactive solution to this is to use automated scans (preferably compatible with CVSS/CVEs) that can continuously identify new vulnerabilities and issues with patching and DNS health. The gap here is that these scans are often equipped with summarized alerts and not “specific” alerts. So although they monitor and alert for changes, the alerts can be more general and not instantly-informative of the issue and the remediation steps for the third-party. This limitation requires some digging and analysis once alerts are received via email and can be easily missed when tackling the day-to-day issues and could even go completely unattended.

To bridge the gap, assigning a single person to be responsible for these alerts and related follow-on steps may be considered. Vulnerabilities though, are often unexpected and likened to “unanticipated hours” in the assignee’s day. This can conflict with other projects they are involved in and balancing duties should be taken into account when assigning this “Fire Patrol” like role.

When implementing a third-party risk management program, identifying how to handle these four areas is key. When including these aspects, programs will likely keep traction, identify key risks to reduce risk and exposure of critical information assets, and achieve compliance with the ever-growing regulatory landscape.