The Third Party Risk Institute Podcast

Building a Winning Third Party Risk Management Program: Strategy, Steps & Pitfalls to Avoid

• Linda Tuck Chapman • Episode 1

Share episode

In this episode of The Third Party Risk Institute Podcast, we explore what it really takes to build a successful Third Party Risk Management (TPRM) program from the ground up or improve the one you already have.

Whether you're starting fresh or reassessing your current framework, this episode breaks down the seven foundational steps to help you structure a program that supports business objectives, regulatory expectations, and real-world risk mitigation.

What we cover in this episode:

  • What Third-Party Risk Management really means (beyond the checkboxes)
  • Common challenges and why many programs fail to scale
  • The 7 essential building blocks of an effective TPRM program
  • How to align TPRM with your enterprise risk and procurement functions
  • Tips to avoid overwhelm while increasing efficiency and visibility
  • Where most teams go wrong and how to fix it

You’ll walk away with practical guidance on:

  • Governance structures that work
  • Risk segmentation and lifecycle controls
  • Crafting policy, standards, and procedures that are realistic (and enforceable)
  • Managing stakeholders and getting executive buy-in
  • Tools and frameworks to support your operations in 2025 and beyond

This episode is based on the insights from our popular blog post, "Build a Winning Third Party Risk Management Program," which has already helped hundreds of risk professionals clarify and upgrade their approach. 

View Blog: https://thirdpartyriskinstitute.com/build-a-winning-third-party-risk-management-program/

This Episode is Perfect for:

  • Risk Managers
  • Procurement Leaders
  • Compliance and Governance Professionals
  • Internal Auditors
  • CISOs and Vendor Risk Analysts

Want more?

Visit Third Party Risk Institute Ltd to explore our certification programs, downloadable templates, and upcoming events designed for professionals serious about advancing their TPRM capabilities.

🎧 Enjoying the podcast?
Explore more resources, expert insights, and certification programs at www.thirdpartyriskinstitute.com

📱 Follow us on LinkedIn for real-world conversations and industry trends: Third Party Risk Institute Ltd.

📬 Have a question or topic you'd like us to cover?
Email us at: info@thirdpartyriskinstitute.com

Welcome to the deep dive. Today we're tackling uh a really crucial aspect of modern business. Third-party risk management.

Now that might sound a bit technical, but basically it's all about managing the risks that come with working with, you know, external organizations, your vendors, your suppliers, partners,

right? All of them.

Yeah. You name it. And you, our listener, are probably keen to get a handle on this stuff quickly and thoroughly without getting sort of bogged down in jargon.

Exactly.

So that's our mission. today to give you a clear, efficient understanding of TPRM and maybe even uncover a few surprises about why it's just so vital in today's world.

Absolutely. And we're diving into this white paper, build a winning TPRM program. It's a really comprehensive guide packed with insights on setting up a strong strategy.

Okay.

And you know, in today's business landscape, we're just relying more and more on third parties, which well, it offers loads of advantages, but it also brings significant risks, right?

I mean, consider this. Over 60% of data breaches involve a third party.

Wow, over 60%.

Yeah, that alone really underscores why this is so important. It highlights how your security, your whole setup is only as strong as your weakest link.

And that link could easily be a vendor.

Could very well be a vendor you trust. Exactly.

Okay, let's unpack this a bit then. What exactly is thirdparty risk management or TPRM and why should we, you know, really care about it?

So TPRM and yeah, times you hear it called vendor risk management or VRM. It's fundamentally the process of well first identifying then assessing and then mitigating the risks that pop up when you work with these external entities.

Okay.

And when we say third party, we're talking about really any organization outside your direct corporate structure. That could be software vendors, raw material suppliers, cloud service providers, uh even your cleaning contractors potentially.

Huh. Anyone you do business with.

Pretty much anyone you do business with who isn't directly part of your company. Think of it like maybe your company is an island, right? And your third parties are like bridges to other islands. TPRM is about making sure those bridges are well secure and they won't suddenly collapse on you.

Right. So, we're not just talking about the big obvious tech companies we all use. It's much broader.

Precisely. And TPRM matters because look, these third party relationships can bring fantastic benefits. You get specialized expertise, maybe cost savings, definitely increased efficiency sometimes.

Sure. Yeah.

But they also introduce risks. These vendors often get access to your sensitive data, maybe your IT systems, even critical business processes.

And if their controls are weak, well, you're vulnerable. Vulnerable to data breaches, service outages, legal headaches, compliance issues, even damage to your reputation.

Yeah, that makes sense.

And the statistics, they really paint a clear picture. The majority of organizations have experienced significant disruptions because of failures, you know, on the part of their third parties.

So, it's not really an if, but a win.

It often feels like that. Yeah. Yeah. It's not if a third party incident will happen, but often when?

That's a sobering thought. So, what kind of risks are we actually talking about here? Is it all just data breaches?

No, it's a pretty broad spectrum actually. I mean, yeah, think about cyber security and data privacy. That's a big one. The risk of a vendor getting hacked and exposing your customer data for instance.

Right. Classic example.

Exactly. But then there's operational risk like what if a critical cloud provider has an outage? That could bring your operations grinding to a halt.

Okay. Compliance and legal risks are also key. Maybe a supplier violates labor laws or uh data protection regulations like GDPR. That could land you in hot water,

right? Even if it wasn't you directly.

Mhm. Mhm. We also need to consider financial risk. What if a key vendor goes bankrupt? That can severely impact your service delivery.

Hadn't thought of that one.

Yeah. And reputational risk is another big one. If a third party you work with gets involved in some kind of scandal, it can definitely damage your brand just by association.

Guilt by association

pretty much. And even strategic risks come into play like maybe you become too reliant on one single vendor and you lose critical skills inhouse.

Okay,

don't forget geopolitical and location risks especially with international vendors and increasingly ESG risks environmental, social, governance issues within your supply chain.

Wow.

It's a complex web really a whole network of potential vulnerabilities.

That is quite a list. Uh Given that wide range, it totally makes sense that different types of organizations might have different priorities, right?

Yeah.

How does industry play a role here?

Oh, absolutely. A bank, for instance, they'll likely be hyperfocused on regulatory compliance uh and the cyber security practices of their fintech vendors.

Makes sense, right?

Yeah, definitely.

But then say a manufacturing company, they might prioritize the stability of their supply chain much more and maybe the ESG practices of their raw material suppliers.

Different focus entirely.

Totally different. Interesting. ly a recent delight survey, this was in 2023, found that cyber security and info risks were the top concern for like 62% of organizations in their third party relationships.

Okay, so cyber is dominant.

It's clearly a dominant worry. Yeah. But it's crucial to remember that a strong TPRM program needs to look at all the relevant risk types, not just cyber.

Right. That whole list you just gave.

Exactly. The specific risks you focus on should really be identified early on, like when you're first bringing a vendor on board. That way, you can put the right controls and oversight in place throughout the whole relationship.

So, don't just jump on the cyber bandwagon even though it's important.

Right? While cyber gets a lot of attention, ignoring other risks can leave you just as exposed.

Okay, so we know what TPRM is, why it's so critical given all those potential risks. But what are some of the big challenges companies are facing right now in actually managing these relationships?

Yeah, the TPRM landscape is definitely getting more complex. No question. We're seeing, like I said, a much greater reliance on outside providers. Regulations are becoming stricter and unfortunately cyber attackers are increasingly targeting those very supply chains. One major challenge is just the sheer growth of these vendor ecosystems. Companies are now working with hundreds, sometimes thousands of third parties.

Thousands. Wow.

Yeah. The average company apparently shares data with over 580 third party vendors.

That's a lot of connections.

It is. And each one of those relationships is a potential point of weakness. In fact, get this. A staggering 98% of organizations have a relationship with at least one third party that has been breached in the past.

98%. That's almost everyone.

Practically everyone. So, this explosion of vendor relationships means TPRM programs have to somehow scale to cover this huge inventory, often with pretty limited resources. Yeah,

it's like trying to keep track of everyone you've ever exchanged emails with. It can get overwhelming fast.

That sounds like trying to plug holes in a sinking ship while more holes keep appearing. So, what's maybe one key takeaway about this increasing complexity?

I think the key takeaway is just that relying on this vast network of vendors inherently increases your attack surface, period. Each vendor is a potential entry point for bad actors. So, your TPRM program really needs to be robust enough to manage this expanding landscape.

It can feel that way. And the frequency of these third party incidents, that's a major concern, too, right? These aren't rare events anymore.

No, not at all. In 23, 61% of companies experienced a third-party data breach or cyber security incident. And a whopping 73% have had a significant disruption caused by a vendor in just the last 3 years.

73%.

Yeah. And we've seen some really high-profile examples that hammer this home. Think about the Target breach back in 2013.

Oh, yeah. I remember that. The HVAC vendor.

Exactly. Attackers got in through an HVAC vendor's stolen credentials. It ended up costing Target over $200 million or the Solar Winds in incident. More recently, a software supply chain attack that hit thousands of organizations, described as one of the most widespread and sophisticated hacking campaigns ever.

Right? Those are huge.

They are. And what's fascinating about the Target breach, going back to that, it wasn't some super cutting edge cyber attack on Target itself. It was a relatively simple vulnerability and a much smaller vendor that gave them the initial foothold.

So, it wasn't even a tech vendor technically,

right? It really underscores this critical insight. Even seemingly lowrisk vendors, if they have network access, can become that critical entry point. It just highlights the need for really granular access controls and thorough security assessments across your entire vendor ecosystem, not just your obvious tech partners.

Those are definitely wakeup calls.

Yeah.

And it sounds like the attackers are getting smarter about who they target, focusing on that supply chain.

Absolutely. There's a clear trend. Thread actors are deliberately targeting third parties. especially technology providers because they know if they compromise them they can then hit multiple downstream customers

like a force multiplier for them.

Exactly. Around 75% of third-party breaches in recent years targeted software or technology supply chains.

Wow.

So this means every industry needs to be extra vigilant about vetting and monitoring their tech vendors. And on top of that, you've got the increasing regulatory pressure and scrutiny.

Yeah, you mentioned that

data breaches at third parties are a top concern for regulators globally. We're seeing tighter regulations, more enforcement actions.

Thank

Well, for example, the OC fined Morgan Stanley $60 million for failing to oversee a vendor that mishandled customer data. And then the SEC added another $35 million penalty on top of that.

Whoa.

And upcoming regulations like the EU's Digital Operational Resilience Act, Doro they call it. That's going to require even more rigorous vendor due diligence.

So what's the core message then from these regulatory actions? It feels Like the bar is constantly being raised.

Yeah, it is. And the message, the core message is that regulators are increasingly holding companies accountable for the security practices of their vendors. We outsourced it. That's just no longer a valid defense, especially when it comes to protecting customer data or ensuring the resilience of critical operations.

Okay, point taken.

And another big challenge, you mentioned resources earlier. Many organizations face internal resource constraints, right?

Oh yeah, big time. Often TPM M teams are underst staffed. They have limited budgets. Maybe lack strong executive support. Over 62% of security and risk leaders say their TQRM function just doesn't have enough resources.

Of course, 60%.

Yeah. And trying to manage hundreds of vendor assessments and ongoing oversight with a tiny team, it leads to burnout, bottlenecks.

I can imagine.

Common pain points include just getting the necessary documents from vendors. That takes time, a lack of internal resources, like we said, and simply the time it takes to handle the sheer volume of assessments.

So if a company's struggling with resources, what's a strategic way to handle that? You can't assess everyone equally, right?

No, you can't. A strategic approach is to prioritize ruthlessly based on risk. You simply can't do deep dive assessments on every single vendor. So focus your limited resources on the vendors that pose the highest potential impact to your business if something goes wrong. This involves effective risk taring, which uh we can definitely talk more about later.

Okay, so it's not just external threats but internal limitations driving the challenge too.

Exactly. And the risk landscape itself just keeps evolving. Cyber threats get more sophisticated supply chain attacks, ransomware, all that. We've seen the importance of supply chain resilience highlighted by things like CO 19

for sure.

And there's this growing focus on ESG risks. Interestingly, over half of organizations now include ESG criteria in their third party risk assessment.

ESG, environmental, social, governance.

Right. We're also seeing the rise of fourth party or nth party risk becoming more important. It's not just your direct vendors but their subcontractors too.

Oh boy, it goes deeper.

It does. All of this means the scope of TPRM is just expanding beyond just security and financial risk. Now it includes operational resilience, ESG, deeper supply chain visibility. So to address these challenges, we're seeing trends like centralizing the TPRM function. About 90% of organizations are moving towards this model.

Centralizing it makes sense. for consistency.

Yeah, especially in regulated industries like financial services, it's at 62% centralized there compared to maybe 46% in non-financial sectors.

There's also a big focus on risk tiering like I mentioned and identifying critical vendors so they get the most attention.

Okay.

Ultimately, the impact of third party failures can be huge financial losses, reputational damage, operational disruptions, increased regulatory scrutiny.

Yeah,

Gartner actually estimates a third party cyber breach can cost 40 % more to fix than an internal one.

40% more. Okay, this all really underscores why a strong TPR program isn't just a nice to have, it's well, it's a necessity.

So, how do we actually go about building one of these winning programs? Where do we even start?

Right? Well, the white paper we're looking at outlines a pretty clear sevenstep life cycle approach. It draws heavily on guidance from regulators like the Office of the Controller of the Currency, the OC.

Okay. Seven steps. Step one.

Step one is establish governance. and policy. This is your absolute foundation. You need buyin from the top, an executive sponsor, a clear mandate that makes TPRM a board level concern, not just an IT thing.

Okay. Top down support

critical. Then you need a formal TPRM policy. This document needs to clearly define the scope, your organization's risk appetite, how much risk are you willing to tolerate, right?

It should outline minimum control requirements for vendors and how issues get escalated. This policy should also probably reference relevant regulations or industry standards you need to follow. It's basically setting the rules of engagement for how your company will manage third party risk.

So setting the rules of the game right from the start. What's a common pitfall companies run into when they're setting up this initial governance?

Oh, a common one is treating the TTRM policy like a static document that just sits on a shelf somewhere.

Check the box. Done.

Yeah, exactly. To be effective, it needs to be a living document. It has to be regularly reviewed, updated to reflect chang in the threat landscape, new regulations, changes in your own business operations, and that executive support, it needs to be more than just lip service. It has to translate into actual adequate resources and clear accountability.

Makes sense. Needs to be real.

Precisely. You also need to define your overall TPRM framework. The kind of endto-end process for onboarding and managing vendors. Many organizations align this with standards like ISO 270001 or maybe NIST.

Okay.

You need to decide on your or organizational structure. Will you have a centralized team, a decentralized approach where business units handle their own vendors or something in between? Like we said, centralized models are increasingly favored for consistency, right?

Then clearly defined roles and responsibilities. Who owns the program? Who actually does the assessments? Who makes the final decisions? A steering committee bringing together stakeholders from different departments, legal, IT, procurement, business units is also really crucial.

Get everyone on the same page.

Exactly. And finally, you absolely absolutely need to integrate TPRM with your broader enterprise risk management erm and governance risk and compliance GRC structures. Third party risk shouldn't be off in its own little silo, right?

Your TPR policy should align with your overall company risk appetite and reporting lines. So by the end of this first step, you should have an approved policy, a defined process, and a clear governance structure in place. In a nutshell, step one is all about getting your own house in order internally before you even start. really looking hard at your vendors.

Okay. Step one,

yeah,

lay the groundwork, get the house in order. What comes next? Step two.

Step two is to inventory third party relationships and categorize vendors. Simple idea, but crucial. You can't manage what you don't know exists. Right. Right.

So, you need a comprehensive inventory of all your third party relationships. This usually means working closely with procurement, accounts payable, and the individual business units to identify all the vendors, suppliers, partners, even those less obvious relationships that might be hiding. them all.

Find them all. You might even need to include downstream third parties or fourth parties if they're critical to a key service.

Okay.

Once you have this inventory and it's never truly finished, it's ongoing, you need to classify or segment these third parties based on risk because not all vendors pose the same level of threat.

Makes sense. Like you said, we wouldn't treat the company that delivers office supplies the same way we treat our main cloud storage provider.

Exactly.

So, what are the key factors to consider when we're cate izing these vendors by risk.

Good question. Common classification factors include first their criticality to your operations. If this vendor fails, could it cause a major outage, a significant financial loss, or maybe a serious compliance breach?

Okay, how important are they?

Right? Then you need to consider their inherent risk tier. This is your initial assessment of risk before you even look at the specific controls a vendor has in place. It's based purely on what they do for you and the kind of data they handle or systems they access.

Okay? like baseline risk.

Yeah, exactly. You can often use a standardized questionnaire just for this initial tiering. And finally, categorizing by service type like IT services, professional services, manufacturing or by risk domain like information security risk, compliance risk can help you involve the right internal experts in the later due diligence process.

Okay.

The outcome of this step should be a living inventory, often called a vendor register. It should have a profile and a risk tier for each third party along with an assign kind internal owner who's responsible for that relationship. It's like creating a map of your external ecosystem and highlighting the potentially dangerous territories.

All right, so we know who our third parties are. We have a map and we know roughly how risky they might be initially. Yeah. Step three sounds like where we really dig into that risk properly.

You're right on track. Step three is to perform risk assessment and due diligence on vendors. So with your inventory and risk tiers in place, you now need to really assess and validate the risks for each third party, focusing obviously on those you've identified as higher risk. This is your due diligence process. It happens both before you bring a vendor on board and then also on an ongoing basis throughout the relationship,

right? Not just once,

definitely not. This typically involves collecting detailed information about their controls, their capabilities, usually using due diligence questionnaires. Standardized ones like the SIG from shared assessments or the CI for cloud providers can be a good starting point.

Sig and CI Okay,

but you'll likely need to tailor them, you know, to the specific vendor, the service they provide. So, we're basically asking them to show their homework, right? But what kind of homework are we actually looking for? What proof

exactly? And you absolutely want to go beyond just their self-reported answers on a questionnaire,

right? Need proof.

You need proof. Request independent artifacts, things like SSA18 or SUC2 audit reports. And for anyone not familiar, these are reports from independent auditors looking at a service organization's controls, security availability, confidentiality, all that. Okay, those sound important. They are. You might also want ISO 27,0001 certificates, recent penetration test results, maybe financial statements to check stability, business continuity or disaster recovery plans.

We need PDR plans. Yeah.

Privacy policies, proof of insurance, compliance attestations for things like IPA or PCIDSS if relevant. These documents provide that independent validation of their controls.

Okay. get the evidence, then what?

Then you need to evaluate their overall risk posture. We call this the residual risk. It's essentially the inherent risk we talked about minus the effectiveness of the controls they have in place.

Inherent risk minus controls equals residual risk. Got it?

Right. Tools like scoring matrices can help make this consistent, but some qualitative judgment, some expert review is also really important. If you identify any gaps or issues, and you probably will,

yeah, likely

you'll need to work with the vendor on remediation plans or maybe figure out compensating controls on your end. So if a vendor doesn't have the ideal control, a compensating control might be a different measure you take that achieves a similar level of risk reduction. In some cases though, if the risks are just too high and can't be mitigated, you might actually have to reject a vendor. About half of mature programs actually have the authority to do this.

Wow. Okay. So they can be the gatekeeper.

I need to be. It's also a really good idea to leverage external risk intelligence, things like security rating services. You might have heard of bits. or security spore card.

Yeah, I've seen those.

They give you an outside in view. Financial risk monitoring services, too. This gives you a more complete picture beyond just what the vendor tells you.

That sounds like a lot of information to gather and analyze for each vendor, especially the high-risisk ones. Step four must be about putting all that hard one knowledge into action, right, in the contract.

Exactly. Step four is riskbased contracting and onboarding. So, once you've done your due diligence and decided, okay, we're moving forward. with this vendor. It's absolutely crucial to formalize the relationship in a contract that actually embeds risk management,

not just the standard legal boilerplate.

Yeah, definitely not. Work closely with your legal team to include key protective clauses in every third party contract, especially for those higher risk engagements.

Okay. Like what kind of clauses?

Things like outlining specific security requirements, maybe referencing standards, listing specific measures, mandating prompt breach notification like within for 48 hours, not weeks later.

Yeah, that's key.

Reserving your right to audit and assess their controls. Addressing subcontractor responsibilities. Do they need your approval to use their own vendors for your work? Defining clear service levels and performance expectations, SLAs's. Outlining termination and exit procedures. How do you get your data back?

Right, the exit plane.

Allocating liability and ensuring they have adequate insurance like cyber liability insurance.

And specifying compliance and regulatory requirements they need to meet. like GDPR or a HYPA.

So, we're making sure the legal agreements have real teeth when it comes to risk. Are there any must-have clauses that sometimes get overlooked?

Good question. A frequently overlooked one is that right to audit. Ensuring you have the contractual right to assess their controls periodically is just crucial for ongoing oversight later on. Don't assume you have it if it's not in writing.

Got it. Write it down.

Absolutely. You also want to make the actual onboarding of the vendor conditional on them, resolving any high-risk issues you found during due diligence.

Oh, okay. So, you need to fix this before we fully let you in.

Exactly. You can even put deadlines for those fixes right in the contract. Then, as you integrate the vendor into your systems, make sure you implement baseline security controls on your end. Things like lease privilege access, using VPNs with multiffactor authentication, maybe segregated accounts, data encryption where possible,

control what you can control,

right? And finally, establish really clear communication channel. with the vendor specifically for any riskrelated matters and set up regular checkpoints especially for your critical suppliers.

Okay, so contracts are solid, vendors are onboarded securely, but risk doesn't just disappear then, right? It's ongoing. Step five must be about keeping an eye on things over time.

You're spot on. Step five is ongoing monitoring and oversight. Risk management isn't a one-time event at onboarding. It absolutely needs to be continuous throughout the entire entire vendor life cycle.

Okay.

Based on the vendor's risk tier that you assigned back in step two, you need to schedule periodic risk reassessments or audits. For your high-risisk vendors, this might be annually, maybe less often for lower risk ones.

Makes sense. Risk based frequency.

Exactly. You should also try to leverage continuous monitoring tools. Those cyber security rating services we mentioned, threat intelligence feeds, financial monitoring. These can give you near realtime insights into their changing risk posture between your formal assessment. So you get alerted if something pops up

hopefully. Yeah. Maintain an issue, log track any problems that arise, any gaps found, and make sure they're actually being addressed and remediated by the vendor.

Follow through.

You have to. You also need to oversee the vendor's performance against their contractual service levels, SLAs's. Are they meeting expectations? And monitor their ongoing compliance with relevant regulations. Do they still have that ISO certification? Did they renew their SOC2?

Get the poof again.

Keep Getting the proof for critical vendors. It's really important to have an established process for incident response coordination. What happens if they have a breach that affects you? And maybe even conduct joint business continuity or disaster recovery testing with them.

Joint testing. That sounds evolved.

It can be. But for truly critical partners, it's worth it.

Yeah.

And finally, make sure there's a good feedback loop with the internal business owners, the people who actually work with the vendor dayto-day. They can often provide valuable early warnings about potential issues.

Right. The folks on the ground. So, it's a combination of regular checkups and always being on the lookout for red flags, but how do you balance the effort of all this continuous monitoring, especially with those limited resources we talked about?

Yeah, it's definitely a balancing act. And I think the key is to automate where you possibly can. Leverage those continuous monitoring tools to get automated alerts about potential issues.

Let the tools do the leg work.

Exactly. Focus your manual efforts, like those in-depth audits, on your highest risk vendors and maybe trigger ad hoc reassessments based on significant events like if a vendor gets acquired or if there's a major change in their service or if one of those monitoring tools flags a serious issue.

Okay, so automate, prioritize, and react to triggers. That makes sense. Step six sounds like it's about how all this information gets used within the larger organization, connecting it back.

Exactly right. Step six is integration with GRC and reporting a truly effective TPRM program like we hinted at before. or doesn't operate in a vacuum. It needs to be tightly integrated with your overall governance, risk, and compliance, your GRC activities,

right? The big picture.

Yeah. Think of GRC as the umbrella covering all your risk and compliance efforts. So, integration means incorporating thirdparty risks into your main enterprise risk register. So, they're visible right alongside your internal risks,

not hidden away.

Not hidden away. You also need to establish a regular reporting cadence on TPRM to various stakeholders. Senior management should probably get quarterly updates, significant incidents, high-risisk vendors, progress on mitigation plans. Okay.

The board of directors, they'll want maybe annual or semianual reports, the big picture, results of audits, overall compliance posture, strategic initiatives. Interestingly, current reporting to boards is still kind of low, maybe around 40%.

Room for improvement there.

Definitely. And the business units themselves, they need to be informed about the performance and the specific risks of the vendors they rely on.

Makesense. they need to know.

It's also really crucial to develop key performance indicators or KPIs to measure the effectiveness of your TPR and program itself. Things like what percentage of our vendors have been assessed? How long does it take us to complete an assessment? How many third-party incidents did we have? Are we actually reducing risk over time?

Measuring the program's health.

Exactly. Current adoption of fully defined metrics is also quite low, maybe only 22%. So another area for maturity. Use the outputs of the program, the assessment the metrics to drive continuous improvement and make sure your TPRM activities complement other risk and compliance functions like infosc procurement IT change management. This integration helps create that holistic view of risk across the entire enterprise.

So it's about making sure everyone who needs to know is informed using data to improve and connecting the dots across the organization. And that brings us to the final step, step seven, which sounds like it's about saying goodbye to a vendor.

That's right. Step seven is offboarding and termination management. Just like onboarding, when a third party relationship comes to an end, it's just as important to manage that process carefully from a risk perspective.

Can't just walk away.

No, definitely not. You need to ensure a clean separation. That means all access, physical and logical, is revoked promptly. Any company data they held needs to be returned or securely destroyed. And you often need certification of that destruction for sensitive data.

Get proof of destruction.

Get the proof for critical services, you'll need to invoke any exit or transition assistance clauses that you hopefully put in the contract back in step four to ensure a smooth handover to a new vendor or back in house. Currently, the rate of having exit plans for high-risisk vendors is only about 48%. So, that's a potential gap for many.

Another area to watch.

Yeah, it's also good practice to conduct a final risk review after termination just to see if any lingering obligations or risks remain. And finally, make sure to update all your records, the inventory access list, and notify all relevant internal stakeholders that this vendor is no longer approved or active. Managing offboarding in a controlled way helps prevent potential risks from materializing even after the relationship officially ends. It's the final stage but just as important as the beginning.

Okay, that sevenstep approach really lays out a comprehensive road map. Now, the white paper also touches on how TPRM fits in with existing ERM enterprise risk management frameworks. You mentioned GRC. Can you elaborate a bit on how TPRM ERM and GRC all fit together.

Absolutely. It can seem like alphabet soup sometimes, but they're closely related. Like we said, GRC is the overarching framework for managing governance, risk, and compliance across the organization. ERM, enterprise risk management, is a key component of GRC. It's focused specifically on identifying, evaluating, and mitigating all types of risks that could affect the organization's ability to achieve its objectives.

Okay, ERM is part of GRC,

right? And third party risks are definitely within the scope of ERM. So, TPRM really should be seen as an outward- facing component of your overall GRC efforts and it needs to be integrated directly into your ERM framework.

Makes sense.

If your organization uses a standard ARM framework like COSO or maybe ISO 31000, you should be incorporating third party risk scenarios into that framework. Your specific TPRM controls, the things you check vendors for, should also be mapped back to your primary control framework, whether that's NIST, CSF, ISO 2701, or something else.

Connect the controls.

Connect the controls. Many organizations are also leveraging GRC technology platforms to manage their TPRM activities alongside other risks. This allows for a single source of truth for all risk data, which is huge.

Avoid silos.

Exactly. Integration also means that third party risks follow the same reporting and escalation paths as other significant risks within the organization. They get the same level of attention. Ultimately, embedding TPRM within your GRC and ERM frameworks promotes a consistent risk culture. It ensures that compliance requirements like GDPR or SOX are extended consistently to your third parties as well. And it facilitates better incident coordination when something does go wrong, whether it starts internally or externally. It's really about making sure everyone is speaking the same risk language, looking at risk holistically.

It sounds like it's all about creating that unified approach, managing risk consistently regardless of whether it originates inside or outside the company walls. The white paper also includes some uh real world case studies. Right. Can you talk us through a couple of those. I think examples really help drive the lessons home.

Definitely the case studies provide some pretty stark reminders of what can go wrong, but also importantly highlight the benefits of getting TPRM right. Let's start with the one we already mentioned, Target's 2013 data breach.

Right. The HVAC vendor again.

Exactly. Attackers gain access to Target's network by compromising that small HVAC vendor. This just perfectly underscored the weakest link concept. Even a small, seemingly low-risk vendor with network access can become a major vulnerability.

Yeah,

the lessons here are pretty clear. The need for stringent access controls things like network segmentation, multifactor authentication even for nonIT vendors, and the importance of assessing the security of all vendors with any kind of network access. The cost, as we said, was massive financial and reputational damage for Target. So, what's maybe the enduring lesson from the Target breach for our listeners, do you think?

Yeah, it's a costly reminder that even seemingly innocuous s need scrutiny. The enduring lesson seems to be that you absolutely need to apply a riskbased approach to all vendors, not just the ones you initially think are high-risisk based on what they do. Any network connection is a potential risk. What's another key example?

Another really significant one is the Solar Wind supply chain attack in 2020. This was a different kind of problem, more of a fourth party risk issue for many of the victims.

How so?

Well, attackers managed to insert malicious code into a legitimate Solar Winds software update. That update was then downloaded and installed by thousands of Solar Winds customers effectively giving the attackers a back door into all those different organizations systems.

Wow. Through trusted software.

Exactly. Through a trusted channel. This highlighted the critical importance of software supply chain security. It means monitoring not just your direct vendors but also the security of the technology they use and incorporate into their products.

Deeper visibility needed

much deeper. Organizations need to adopt principles like zero trust. Don't inherently trust anything. Always very Ify, push your vendors for secure software development practices. Things like continuous monitoring and anomaly detection become crucial for spotting unusual activity. And having a comprehensive software inventory, sometimes called an esbomb, software bill of materials, is becoming more important.

That's

this event had huge national security implications and really led to a renewed focus on supply chain risk across the board. So what's the big takeaway regarding fourth party risk from the Solar Winds incident? Both of those examples really show how devastating the consequences of poor TPRM can be, especially in cyber security. The big fourth party risk takeaway from Solar Winds, it seems to me, is that your responsibility doesn't stop with your direct vendors. You're implicitly trusting their security practices and the security of their subcontractors and the software components they use. You need visibility as far down that chain as realistically possible. Are there other types of risks highlighted in the case studies beyond cyber? Yes, definitely. The white paper also discusses Morgan Stanley's data center equipment disposal fiasco. This wasn't a cyber attack at all, but a failure in basic operational risk management involving a third party vendor they hired to decommission old IT equipment.

What happened?

They apparently didn't properly oversee the process. The vendor messed up and hundreds of old servers and hard drives containing unencrypted customer data somehow ended up being auctioned off online instead of being wiped and destroyed properly.

Oh my goodness. Unencrypted customer data. auction off.

Yeah. It resulted in over $150 million in regulatory fines and related costs for Morgan Stanley.

Wow.

The lesson here is that TPRM extends way beyond just IT security. It applies to any vendor handling sensitive data or impacting critical operations, even in seemingly mundane tasks like equip disposal. It emphasizes the need for proper vendor selection, thorough oversight of the work being done, and detailed tracking and inventory management. And the key regulatory Takeaway again is that we outsourced it is simply not an excuse.

Right. You can outsource the task but not the responsibility.

Precisely. So what does this Morgan Stanley case tell us about the overall scope of TPRM?

Well, it's a really stark reminder that TPRM needs to be holistic. It has to cover all potential risks, operational compliance, physical security, not just the cyber ones. It really highlights that TPRM isn't just about bits and bites. It's about managing the entire life cycle of your relationship with any third party that can significantly impact your business. for your customers. The white paper also mentions a positive example too, right? To show the upside. Yes, thankfully. It uses a hypothetical but illustrative example of a bank that proactively invested in its TPRM program. They identified that a critical software vendor lacked a robust business continuity plan during a routine assessment.

Okay.

So, instead of just noting the risk, they actively worked with the vendor to help them develop and test a proper BCP. Later, that same vendor suffered a ransomware attack. Oh wow.

But because the bank had proactively addressed the BCP issue, the disruption to the bank's own services was minimized. Their proactive approach not only increased their operational resilience, but also strengthened their relationship with that vendor. It even informed some strategic decisions they made later about diversifying suppliers in that area.

So, it paid off.

It really did. It shows how TPRM can be more than just a defensive measure. It can actually be a strategic asset. So, what's the key message you take away from this positive example? These case studies really bring the importance and the different facets of TPRM to life. The key message from the positive example seems clear. Investing in TPRM isn't just about avoiding fines or breaches. It can actually make your organization more resilient, more agile, and strategically sounder in the long run. Now, the regulatory landscape for TPRM seems quite complex with different rules in different places. What are some of the key standards and requirements organizations really need to be aware of?

Yeah, the regulatory environment is definitely significant. And it varies. In the financial services sector, it's particularly detailed. You have the OC and other inter agency guidance in the US which outlines that full life cycle approach. We discussed inventories, tiering, due diligence, board oversight, the works.

Okay. Banks have it tough.

They do. The EU also has regulations like the EBA guidelines on outsourcing and the upcoming DORA digital operational resilience act, which focuses heavily on ICT risk and requires really rigorous due diligence and ongoing monitoring of ICT providers. Other regions like Singapore with their MAS guidelines and the UK with FCA requirements also have specific expectations for managing outsourcing and third party risk. These regulations often emphasize riskbased approaches, the need for comprehensive vendor inventories, thorough due diligence, strong contractual safeguards, ongoing monitoring, and clear board oversight. So for a company operating globally, maybe what's the biggest challenge when it comes to navigating all these diverse financial regulations.

Yeah, that sounds like a headache keeping track of slightly different rules everywhere. So, financial institutions are under particularly close scrutiny. What about data protection and privacy laws? They must play a big role, too.

Oh, absolutely. That's another critical area. Laws like GDPR in Europe, the CCPAC P in California, and HIPPA for healthcare in the US, they all impose specific obligations on companies regarding their third party data processors or service providers. Right?

GDPR, for example, explicit Ely requires data controllers to conduct due diligence on their processors and have formal data processing agreements DPAs in place that spell out security responsibilities.

DPA

IPA mandates similar business associate agreements BAAS with any third party that handles protected health information PHI. These laws essentially make robust TPRM a legal requirement whenever personal or sensitive data is involved. So what's maybe a crucial element to remember when you're contracting with a third party who will handle personal data under GDPR. What must that DPA include?

Good point. The contract needs those specifics.

Yeah.

And beyond the actual laws and regulations, are there any key industry standards or certifications that play a significant role in TPRM things companies might use to benchmark?

Yes, absolutely. Industry standards like ISOIC 27,0001, the big information security standard, include specific controls related to supplier security management. Achieving ISO 27,0001 certification often means demonstrating you have a robust TPRM process in place.

Okay, so ISO is relevant.

Very relevant. NIST standards like NIST SP800161 for supply chain risk management and the widely used cyber security framework CSF also provide valuable guidance for organizations handling payment card data. PCIDSS has specific requirements for overseeing service providers who touch that data.

PCIDSS, right?

And in many industries, it's become common practice to rely on SOC reports, specifically SOC1 for financial controls and SOC to for security, availability, confidentiality, etc. as a form of vendor assurance. While these standards aren't always strict legal requirements themselves, they're often expected by customers or regulators and they can definitely help organizations demonstrate due diligence. So, if a vendor provides you with, say, a SOC2 report, what key information should you really be looking for inside that report? What tells you if they passed?

Yeah, understanding those reports is key. It sounds like navigating this whole regulatory and stand landscape is a really significant part of building and maintaining a winning TPRM program. Finally, the white paper talks about tools, platforms, and processes that can help manage all this complexity. What are some of the key recommendations there? What tech can help?

Right. Leveraging the right tools and processes is pretty crucial for managing TPRM effectively, especially given the sheer scale of modern vendor ecosystems we've been talking about. One big category is dedicated TPRM software platforms.

Okay. Specific software for this.

Yeah, these platforms can provide a centralized repository for all your vendor information, automate workflows for things like sending out questionnaires and tracking remediation, and often come preloaded with standard questionnaires like the SIG or CIQ tools like One Trust, prevalent, bits, TPRM module, Service Now, VRM. There are quite a few out there.

Are companies using these?

Adoption is still growing. Maybe 50% aren't using a dedicated platform yet, but investment is increasing with around 45% planning to invest more. They can significantly reduce manual effort and improve consistency.

Okay. Well,

Security ratings and continuous monitoring services are another key area. These offer that external objective risk intelligence. We talked about security scorecard, bidsite, upgrade are big names here. They monitor a vendor's external security posture, look for data breaches on the dark web. Some even monitor financial health. Adoption here is surprisingly low still, maybe only 13 14%. So, there's a big opportunity for companies to get better real-time visibility.

Yeah. Seems like low hanging fruit.

It does. Then you have questionnaire and assessment exchanges. These are platforms or networks like Cybergx or Wistik that allow vendors to complete one standardized assessment often based on SIG or CIIQ and share it securely with multiple customers. This can hugely reduce the burden on both you and your vendors less repetitive work.

Share the assessment once, use it many times.

That's the idea. Emerging technologies like automation and AI are also starting to play a role. AI can potentially help process questionnaire responses faster, analyze free form text answers, monitor news feeds for vendor incidents. Some use robotic process automation, RPA, for repetitive tasks. Adoption of AI specifically is still very low, maybe 5%, but lots of companies around 61% are exploring it.

AI is coming for TPRM, too.

Seems like it. Critically, integrating your TPRM processes and tools with your other core GRC and IT systems like identity and access management, IM, IT service management, TSM procurement contract management is essential for that holistic view and for reducing shadow IT vendors

connect everything

try to and finally beyond tools establishing robust processes is key things like continuous improvement processes for the TPRM program itself annual reviews maybe using a maturity model like the VRMM incorporating thirdparty scenarios into your incident response and scenario planning drills and even providing vendor awareness and training giving your vendors guidance and templates can help them meet your expectations. So, for a company just starting to formalize its TPRM program, what's maybe one piece of technology they should consider looking into early on to get the biggest bang for their buck?

Good question. It sounds like there's a growing array of tools and technologies available to help organizations tackle this complex area effectively.

There really is. And the right mice, of course, will depend on the specific needs, the size, the industry, and the maturity of your organization's TPRM program. The key trend, though, is definitely moving towards more or automation in centralized systems. This frees up your valuable risk experts to focus less on chasing documents and more on actual risk analysis and decision-m.

Well, this has been an incredibly insightful deep dive into third party risk management. Uh to quickly summarize what we've covered, it seems abundantly clear that TPRM is absolutely essential in today's interconnected business world. That's because of our increasing reliance on all these external organizations and well the significant risks that come with those relationships.

Absolutely. Building a strong program isn't simple, but it requires that structured life cycle approach we walk through. Starting with strong governance and policies, then thorough vendor inventory and categorization, rigorous due diligence, making sure contracts are risk based, keeping up with continuous monitoring, integrating everything with your overall risk management frameworks like ERM and GRC, and finally having a plan for careful offboarding.

You've nailed the key steps,

and it's not just some technical exercise off to the side. It really feels like a fundamental part of sound business strategy in the modern era.

Exactly. It really is. And for you, our listener, who wanted to gain that knowledge quickly and thoroughly without feeling overwhelmed, we really hope this deep dive has provided a solid foundation in the critical aspects of TPRM. Remember, a proactive and well-managed TPRM program isn't just about avoiding problems, avoiding those fines and breaches. It's really about building resilience and trust throughout your entire extended enterprise.

So, here's maybe a Final thought for you to consider as we wrap up. In this increasingly interconnected world where your business is just inevitably intertwined with countless others, how will proactively and strategically managing the risks of your extended digital ecosystem, your vendors, your partners, their vendors, how will that not only protect you but actually become a key competitive advantage? Maybe demonstrating to your customers, your partners, your regulators that you take security and resilience seriously across the board.

That's a great point to ponder.

Perhaps you might want to explore some of the those specific TPRM software platforms we mentioned. Many offer free trials or demos. Or maybe delve deeper into the specific regulatory guidelines like DORA if you're in the EU or OC guidance if you're a US bank that are most relevant to your particular industry.

Good next steps.

Thanks for joining us for this deep dive.

Head Shot

Linda Tuck Chapman (LTC)

Host