There’s an old expression that says the most dangerous statement a person can make is “we’ve always done it this way.” I think we can all agree that we need to grow and adapt as the world around us changes. That’s why over the past few months, we’ve shown you ways to switch to a risk-first approach and align your risk and compliance activities to your business objectives.
Recent trends show that companies are recognizing this need for change with larger budgets being allocated to risk reduction activities and a greater focus on the impact of these activities on the business. However, what’s interesting to me is how few companies are looking at their Third-Party Risk Management (TPRM) programs and how to adapt them for the modern era. So many of us rely on “tried-and-true” methods to evaluate third parties. But I’m here today to show you there is a better way!
Vendor Risk Management vs. Third-Party Risk Management
Before we begin, I want to start by pointing out the differences between Vendor Risk Management (VRM) and Third-Party Risk Management. A lot of people use these terms interchangeably but they are actually two very different things. The origins of VRM came from the need to assess vendors, sometimes referred to as your supply chain, to evaluate each vendor’s ability to provide goods and services to support the organization.
Organizations conducting VRM generally start with a set of requirements to vet their vendors, assess them using a standard information-gathering questionnaire and utilize contracts to document expectations for each vendor.
Recently the concept of TPRM has become more popular. However, we are seeing companies pivot to using this term while still applying the concepts of VRM. As the name suggests, TPRM expands the scope of your program to include any outside party that poses risk to your organization. This includes mergers and acquisitions, partners, contractors, professional services, staff augmentation providers, federal agencies, customers, and of course, your vendors.
But moving to TPRM is more than just a name change and a longer list of parties. TPRM goes beyond a set of requirements to measure how impactful the third party is on your organization, what the risk of doing business with this third party is and where you can make changes to reduce that risk.
If your TPRM program can’t answer those questions yet, then you may be stuck in VRM.
Can this vendor provide goods or services that meet our requirements? And if not, what steps can we take to reduce the gaps.
What is the impact of these external parties on our ability to meet our business objectives? And what can we do to reduce the risk to our organization?
Managing Third Parties
The most critical difference between VRM and TPRM, though, is how third parties are viewed and managed within the organization. VRM programs traditionally run independently of other risk or compliance programs and are closely aligned with procurement and contracting activities. As noted above, sets of requirements are used to assign vendor scores, which are maintained in a vendor register. Data is collected related to the vendor at a point in time and reassessed at a set cadence.
In contrast, TPRM activities are embedded into your risk and compliance programs and centralized around a common business goal or activity. Third-party risk assessments are conducted based on the potential impact on the company’s ability to meet its objectives and are reassessed often as new information is collected.
When you make this mind shift you’re no longer assessing a vendor’s ability to align with a set of requirements and highlighting non-conformities but rather assessing each third party’s impact on your organization’s success and recommending risk reduction activities to support your organization’s growth.
Say goodbye to VRM (and your questionnaires)
If you’re ready to move forward with true TPRM, then you need to be prepared to say goodbye to VRM. And for some of you, that may mean saying goodbye to your questionnaires. Before you panic, hear me out.
For those of you who don’t know, before I worked for Reciprocity®, I deployed and utilized Reciprocity ZenGRC at several companies. Five years ago when I deployed it for the first time, my favorite thing was the questionnaire feature! The first thing I did was make a list of things I wanted to ask the vendors. What are your password requirements? Do you encrypt your endpoints? When did you last test your BCP?
I created that questionnaire template in ZenGRC and began sending it off with every new vendor request and contract renewal. I loved it! It streamlined the process, allowed me to apply a set of standards to all vendors and enabled me to identify gaps so they could be addressed in contracts. As time went on we were able to update the questionnaire to add more questions, include things like privacy and data protection and even collect documentation. There are a lot of benefits of using questionnaires.
However, after operating the program for a while, I began to see some of the disadvantages come to light. First and foremost, questionnaires are tedious – no one likes to fill them out and no one likes to review them.
This often leads to rushed work, reusing old answers or assigning it to a newer team member or intern to “just get it done.” And even if a more seasoned team member were to complete it, the answers you receive back are only as good as the information available to that person. Frankly, the accuracy of the questionnaire is questionable at best.
Secondly, even if the information is perfectly accurate when it is provided, it is immediately outdated. Annual questionnaires don’t account for the rapidly changing nature of business and the continuous changes in the threat landscape.
And on top of that, questionnaires provide little to no actual evidence that the third party can or is meeting the requirement. Even if you modify your questionnaires to ask “can you meet this requirement?”, without evidence and continuous updates, it can create a false sense of security and leave large risk blind spots.
Now I know what you’re thinking, “but what about weighted questionnaires?”. They can calculate a risk score based on the third party’s answers! Yes, that is true and one of the many benefits of questionnaires. But alone, they are insufficient in truly identifying your highest risk third parties.
Don’t get me wrong, weighted questionnaires or common sets of criteria are great for categorizing your third parties, but they do nothing to measure how impactful the third party is on your organization, what the risk of doing business with this third party is, and where you can make changes to reduce that risk. And remember, that’s the real focus of TPRM.
Your Path Forward With TPRM
Start With Business Objectives
I was recently talking to a prospective customer of ours who said he was really underwater at work and was looking for ways to conduct more efficient vendor assessments. He indicated that their company was assessing several new software applications and he had spent the past few weeks emailing vendors, reviewing questionnaires and sending out follow up questions. He was frustrated.
When I asked him what his goal was in conducting these activities, he indicated “the company wants a new CRM tool so I need to ensure it meets our security and compliance requirements.” He was stuck in VRM mode.
I asked him why they needed a new CRM tool and he indicated that the organization wanted to expand their sales to include US federal customers and needed to replace some applications, such as their CRM, with ones that are FedRAMP compliant. Now we’re getting somewhere!
Remember, the goal of TPRM is to determine how impactful the third party could be to your organization. Or to phrase it differently, how impactful will this third party be on your organization’s ability to meet its goals. But if you don’t know what those business goals are, how can you assess the risk? That’s why step one in your TPRM journey must be understanding your business and their objectives. If you’re not sure what I mean by this, take a look at this recent blog.
As you continue through your TPRM transformation journey, the next step is to evaluate your current assessment methods. You must focus on the risk, not the compliance, of the third party. Remember this is Third-Party RISK Management, not Third-Party COMPLIANCE Management.
The process to conduct a TPRM assessment is no different than any other risk assessment. You must determine the impact the third party will have on your ability to meet your objective and the likelihood of that impact occurring. And in order to do that, you need to collect some information. Spoiler alert, none of it comes from a questionnaire.
What will this third party have access to? – Data is quickly becoming the most valuable resource on earth. As threat actors continue to evolve, the cost of breaches and fallout thereafter is growing exponentially. That’s why you need to understand what data the third party will have access to.
Because the more critical the data is, the more impact it will have on your organization should it get breached. A third party’s inherent impact score will increase as the criticality of their data access increases. A catering company delivering lunch and a contracted IT service provider are two very different types of third party.
How likely is the third party to impact that data? – This question is slightly more difficult to answer because there are a lot of different factors that go into it. Technical factors like network security holes, missed patches and application vulnerabilities. As well as compromised credentials, geopolitical threats and adverse reputation.
I like to think of these things as indicators of risk. Just like your car’s check engine light, these scores can be used as red flags. If you walk up to a bridge and pieces are falling off, that’s a red flag and you might seek an alternative. If you see a third party has a significant amount of missed patches on their software, that’s a red flag. And the more red flags, the more likely this third party is to cause a negative impact.
But the good news is there are several providers out there who monitor and report on these factors and provide independently generated ratings and scores. When you ingest this information into your TPRM process, you’re able to use it as a basis to determine a third party’s likelihood score. The lower the rating the more likely that third party is to impact you.
Thinking back to our friend and his CRM troubles, the application would contain data related to their US federal customers and the third party could potentially have access to this data. This would be a high impact third party, or a 5 on his impact scale.
Then utilizing his organization’s third party security rating provider, he was able to assess them and found that they had “D” rating with several red flags related to leaked credentials and unpatched vulnerabilities. This is a 4 on his likelihood scale.
This third party’s inherent risk is a 20. And if you have a GRC application that can ingest this information directly, you can calculate all of this via automation.
Just like any other risk assessment, the next step is to select a treatment plan. The best way to do this is with pre-established acceptable risk thresholds. This will enable you to quickly identify your highest risk third parties and focus on evaluating their compensating controls. Control efficacy assurance often comes from industry standard documentation, such as SOC reports, or other artifacts like uptime and availability statistics, insurance certifications and BCP/DR tests.
Oftentimes third parties will make these documents available through a trusted network where you are able to access them asynchronously. This enables you to quickly gather the information you need to determine if the compensating controls have reduced the residual risk of this third party.
Depending on your industry and regulatory requirements, you may also need to account for any complementary user entity controls (CUECs). Using a GRC application that maps your controls directly to your Third Parties will enable you to ensure your CUECs are functioning and sufficiently reduce the risk to a desired level.
Tying it all together
After walking through this process with the prospective customer he came back to me a few days later and said “it worked!”. He took the three potential third parties, determined their inherent risk, evaluated their compensating controls and determined that two of the third parties were outside the company’s risk tolerance.
He was able to show that if the data stored within the application were to be breached, it would significantly limit the company’s ability to do business with the US government and thus prevent them from meeting their goals. When he put it in the language the board could understand, they were thrilled. And the best part, it was all done with automation!
The newly released Reciprocity® ROAR Platform was built to help automate your third-party risk management process. Start with your business objectives, scope in your third parties and transform your risk reporting into the future. Sign up for a free trial to see it in action.
Read more from Meghan on TPRM in our latest white paper, “5 Steps To Reduce the Web of Uncertainty in Third-Party Risk Management”.