Background

Third-party risk management (TPRM) has its challenges. It is a relatively new area that has been developing rapidly, but many programs face significant issues as their companies grow. TPRM rarely scales linearly with the business or the number of applications in use. There are no easy fixes, but you can make steady improvements. I will share some practices I have used to improve programs over time, which you can take away and adapt to your situation.

Challenges and Solutions

TPRM programs have many challenges, and this list is by no means inclusive, but it’s what I would consider the top problems I see in many programs today.

Too Many Questionnaires

Yep, it’s a classic, so of course, it’s at the top of the list. If you want your vendors to hate working with you, ask them to do a full SIG or CAIQ questionnaire every year. The TPRM space is broken right now, with everyone requesting long questionnaires from everyone else. The hours spent filling in these things are absurd. Some vendors don’t respond to questionnaires, and honestly, I don’t blame them. What’s worse is when a significant security breach happens, everyone asks each other if they use the breached tool. It’s like a vast web of toil that cascades and does not contribute to tangible risk reduction.

This is the hardest one to fix, and I’ve yet to see a program which doesn’t use questionnaires at all, but here are a few recommendations to lessen the impact.

  • Make information as freely available as you can. Have a Trust site with everything a customer would need and provide freely available security questionnaires to customers. I strongly encourage you to make this available to anyone, including prospective customers. Still, if you must, you can take an approach similar to AWS Artifact and gate it behind agreements for more sensitive items such as SOC2. Some of the best trust sites I know include Atlassian and 1Password if you need inspiration.
  • Tailor questionnaires to the risk presented. Approach this however you like, but if, for example, you triage and have low and high-risk applications. Low-risk may only ask the most minimal questions, while the high-risk vendors get the complete due diligence. For some vendors, you may forgo the questionnaire and rely on the open resources entirely, as mentioned above.
  • Use more collaborative editing and automation. A tool such as Whistic can help make the back and forth easier is one approach you can take. This way, you keep context over the years and don’t need a whole new questionnaire to be provided each time. Alternatively, outsource and have someone like Vendr handle the process for you.

None of these will remove the need for questionnaires entirely, but they will bridge the gap until we reach a future where they are not required.

Limited Employee Visibility

Employees do not care about TPRM programs. They want to use the tools they know and love to be as effective as possible. TPRM teams often do not give enough clarity on the process involved. As an employee, I want to see what software is allowed, what’s been requested before and where in the process my request is.

It’s imperitive to have a single pane of glass for your employees. This can be custom-built, a standard ITSM tool, or a dedicated tool. These days all tools have an API, so no matter what you use, it should be easy to connect from that to a single place. If you ask employees what their number one frustration is when procuring software, I guarantee you 99% of the time that it’s the fact they have no visibility on the process.

Keeping your customers happy is essential, especially when you sometimes have to deny their requests. Even better is showing them alternative tools available for their use case. I may be a diehard Jira user, but if Asana is available to me and it’s more accessible, then I’ll use what I can get my hands on without the lengthy request. A great technique I recommend to TPRM teams is to dogfood your own process every 6-12 months. Even better, gather the whole procurement team and go through it as a tabletop exercise. There’s often no better way to fix products than to go through what the customer experiences.

Lack of Checkpoints

As mentioned in my previous blog post, to have an effective TPRM program, you need checkpoints to observe and catch risky vendors. Hard-enforced gates are preferred since it’s hard to undo once you’ve locked in a contract. Many teams, unfortunately, need more technical capabilities or leadership support to implement these types of gates.

TPRM teams need to add more gates, but they also need a way to bring that into their existing tooling. I would recommend partnering with your enterprise security team to look at building gates into the most critical IT areas, such as:

  • Limiting desktop software via application allow/block listing.
  • Auditing OAuth logins like “Log-In With Google”.

Limiting these two will keep software sign-ups lean to stop land and expand before it happens. Both of these require a lot of resources to manage over the long term; however, putting in alerts and running an audit mode approach may be easier, especially in smaller orgs. However, I would suggest that you not be afraid to block things when you need to. Some software companies have a predatory approach, growing in your organization and charging you for security/privacy features once they’ve reached critical mass. In these cases, if the software has made it in and doesn’t provide significant value, then you need a way to stop it.

As a side note, A growth team’s primary goal is to make it easier for people to sign-up and use their tools. This is the backbone of what we call “product-led growth” which most software today adopts. This is at odds with TPRM, whose goal is to limit and control software sprawl in the enterprise. As PLG becomes more commonplace, you’ll see more vendors slipping through your controls’ cracks, so effective monitoring is required even if you have gates in place.

No Tooling Committee

At the end of the day, many TPRM-related tasks are business decisions. Sometimes these decisions are small, but occasionally significant decisions need outside help. Having a tooling committee, ideally made up of IT, security and software leaders in your organization, will ensure you have a good variety of views and can come to an agreement on use cases.

TPRM is much easier with management buy-in. If you’re building a new program, this is one of the first things you should do. You should be encouraged to make tough calls as an individual, but there are going to be escalations that are needed for business-level decisions. Commonly this will manifest itself when a new technology is released. You’ll find you have two or more versions of similar software in use.

A personal example of this was a time when we found out we had five separate Twilio accounts and one Vonage account. We used these to do API-based SMS messaging in our products, and all the teams created individual accounts. We brought up centralized management to the committee with a recommendation to unify on Twilio. Nobody wanted to be the owner, so management assigned it to a team, and we worked with them to ensure this one account was set up securely.

Going through and unifying on a single tool is not commonly liked by employees, but as a business, it saves cash, it saves time, and it means you can give great support to that one tool. A great analogy I’ve heard is that if you asked every employee to pick a colour and mixed them, it would end up a dull, muddy grey. You want colours to shine, and sometimes leaving that decision up to a small, informed group of individuals is a better approach.

No Focus on Automation

As previously mentioned, your TPRM team will not scale with the business. Cloud software has seen an explosion in popularity, and the amount of apps is expanding exponentially. Many teams still have a fully manual or semi-manual way of working and need to catch up when it comes to automation. Please do not fall into the trap of 24/7 manual reviews. It’s easy to do, but automation is key. Once you have the basic program down, you need to start automating. The key to automation is practical triage. If you can quickly and accurately triage each use case, you can decide what path to go down. It would be even better if you could attach some elements of quantitative risk to your analysis. Measuring risk using pre-set criteria takes a lot of work to do effectively, though. I’d be wary of tools like SecurityScorecard or BitSight. These tools can be helpful, but many folks misuse them. They only look at the score without considering the context of how the score is generated. These tools often work off best estimate data and can often contain significant quantities of false positives for specific categories.

In terms of automation, I have seen teams entirely automating their low-risk use cases. This can be as simple as using low-code automation like that found built into Jira or be as complex as custom-built tooling that collects information from tools like Whistic or Vendr via APIs. TPRM analysts tend to side towards being risk averse and dislike automation, but something for TPRM analysts to consider is the following:

Opportunity cost is a risk in itself. You want to be spending your time reviewing high risk applications and securing software in use today. Automating low-risk ventures frees up your time for these more critical reviews and helps reduce real-world risk.

What matters here is that you are reducing the manual work required. Look at what you do daily and be critical about what you can automate if you change processes and workflows, don’t strive for perfection but settle for good enough unless there’s a regulatory or high-risk element to it.

Building a Great TPRM Program

Perfect is subjective. The needs of a TPRM analyst, an engineer and a senior leader will differ. The maturity of your organization is another factor, as a startup will have different needs than a large-scale enterprise. Below is what I consider a mature program in 2023 for a relatively established enterprise.

  • A software portfolio app or ITSM tool exists. This has all of the software used within the business and can be queried by any employee to see if a tool is allowed or disallowed. Recommendations are made for alternatives within specific categories when an app is denied.
  • Senior TPRM engineers engage with new products being brought into the business and use hardening techniques to ensure they are set up to reasonable standards on day one of being used. Developed programs may utilize SSPM techniques and connect them with automated compliance tools like Drata and Vanta.
  • Sprawl is reduced through projects that unify on single tools to do a job. Instead of licences for Asana, Jira and Notion the team may unify the entire company on a single hardened app. Categories of apps are listed in the software portfolio tool, so it’s clear what the recommended approach is. If you give employees the onus to use whatever tools they want, then making strong, supported recommendations is critical to limit sprawl.
  • The team may work with IT and Security to enforce controls on workstations or managed browsers to allowlist/blocklist applications. Very mature programs may tie this in with the software portfolio list to automatically block disallowed apps from being run on workstations.
  • Software spending is monitored and kept reasonable. TPRM partners with IT and Finance to monitor and alert when new tools are required or expanding rapidly in the organization.
  • Heavy automation and triage is in place with custom tooling that automatically reviews applications against set criteria. Low-risk apps are entirely automated, with some potential sampling or continuous auditing to ensure issues don’t arise. These reviews use a mix of data from vendor-provided sources, custom collections and consider the data the tool will have access to make a risk quantification.
  • Senior management is engaged with procurement, and a tooling committee exists to discuss exceptions. TPRM analysts do not need to make judgment calls on developer tooling, but it’s escalated to the tooling committee and engineering management.
  • TPRM analysts work with the business to understand changing risk appetites and develop their program to move the needle with that. The team works with regulated industries teams to segment the most secure groups into their own categories. They may also segment off higher-risk teams to allow them to build new products like a startup without overly restrictive controls.
  • The team analyzes recent market trends and works with business analysts to prepare for new categories of tools before they release publicly. Web3 and Generative AI tools are great examples of this in recent years.
  • You have OKRs and metrics that track the effectiveness of your program. Some recommended metrics may include:
    • SLAs for review times - Helps set expectations
    • Customer happiness / NPS - Monitors customer satisfaction with the process
    • Risk reduction - Measure the impact the team is having
    • Spend reduction - Visibility for leadership on cost savings
    • Automation time - Time saved with automation activities
  • Finally, contributing back to the ecosystem is always good. MVSP and Dropbox’s VSMC are great examples of this.

Summary

Hopefully, this was useful in guiding you in improving your TPRM program and gave you some ideas on overcoming these challenges to improve your programs. I’ve got one last blog post upcoming in my TPRM series: a set of predictions for 2023 and beyond!