Third-Party Risk Management Process: A Complete Guide

The evidence that most third-party risk management processes aren’t working is no longer theoretical. 

In 2025 and 2026 alone:

• Marks & Spencer (M&S) watched its retail operations grind to a halt after attackers accessed its systems through a shared third-party delivery provider.

• Qantas had 6 million customer records exposed through a compromised offshore call center platform
• Stryker had 80,000 employee devices wiped via a breached mobile device management console 

Third-party breaches have doubled year over year. Organizations have more vendors than ever, smaller GRC teams than needed, and TPRM processes that were designed for a different era. The gap between a process and a program has never been more consequential. 

This guide walks through each stage of the TPRM lifecycle and explains where third-party risk processes typically break down and what a functional design actually looks like. 

Step 1: How many vendors do you actually have?

Before you get to onboarding and monitoring vendors, you need to know who you are actually relying on. Most TPRM programs underestimate their vendor footprint by 30 to 40%, according to industry estimates, largely because of shadow procurement and business-unit-led tool adoption that go uncaptured by central GRC teams. 

Before your first questionnaire goes out, the foundational question is: who are you actually relying on? That includes direct vendors, but increasingly it has to include fourth parties – the vendors your vendors rely on. The Qantas breach traced back to a third-party call center platform, not Qantas’s own infrastructure. Regulatory frameworks like GDPR, HIPAA, and DORA are explicit about extended supply chain visibility, and enforcement is catching up with that language.

Building a live vendor roster means connecting to the systems where vendor relationships actually live: identity providers like Okta, procurement platforms, ticketing systems like ServiceNow or Jira. A static spreadsheet updated at contract signing will always be incomplete. The inventory needs to be updated as the business adds tools, not after the fact.

The signal that your third-party risk management process is broken at this stage: your review cadence is slower than your procurement cadence. If developers and business units are onboarding SaaS tools faster than your team can track them, you’re managing a fraction of your actual risk surface.

Step 2: Risk Tiering Correctly

While many enterprises tier their vendors based on contract value or perceived criticality. This approach has two fundamental problems. First, it conflates cost with risk. The Home Depot breach didn’t come from a major strategic partner – it came from a SaaS vendor handling a narrow function. Low-spend vendors with meaningful data access or system integration are consistently undertiered in programs that use contract value as a proxy for risk.

Second, static tiering treats risk classification as permanent, when in practice a vendor’s profile changes constantly as their access expands, your relationship deepens, or their own security posture degrades.

The right framework for third-party vendor risk tiering is data access type, not spend. A vendor with access to public data only sits in a different risk tier than one processing sensitive PII or with production system access – regardless of what they charge you. That classification should also update dynamically: when a vendor’s access scope changes, their tier should change too, not at the next annual review.

The second piece that most processes miss is two-dimensional scoring. Most GRC tools generate a single vendor score, collapsing two distinct questions into one number: How likely is this vendor to be breached? And if they are, how severely does it affect us? Separating impact from likelihood gives your team a more actionable picture of where to focus remediation efforts.

Find out more about the VISO TRUST approach to scoring in this webinar.

Step 3: Due Diligence & Assessment

Typically, in TPRM programs, due diligence is done with a questionnaire and self-reporting from vendors, which is then evaluated by a risk team. This step seems straightforward, but the questionnaires have become a persistent TPRM pain point. Vendors are slow to respond to questionnaires, and they only represent a point in time. 

A mature vendor risk assessment process combines two approaches that the industry has historically kept separate. 

1. Outside-in signals (security ratings, attack surface scanning, dark web monitoring) show you what an attacker sees. 
2. Private disclosures (SOC 2 reports, penetration test results, ISO certifications, policy documentation) show you what controls are actually in place. 

Neither alone tells the whole story. Outside-in signals miss internal controls; self-reported documents aren’t validated against external reality.

The solution is to blend signals using AI risk assessments, as VISO TRUST does. To give you a full picture, the platform looks at outside-in signals you are already using, such as BitSight and SecurityScorecard, and validates answers on SOC 2 attestations and other security documents to deliver a comprehensive assessment. These assessments can be refreshed as needed, so they are no longer point-in-time.

Step 4: Vendor Onboarding & Contractual Controls

The weakest link in most third-party risk management processes is what happens between the risk assessment and the signed contract. Organizations commonly identify security gaps during due diligence and then approve the vendor anyway, with no binding plan to close those gaps.

The Marks & Spencer and Qantas incidents both point to the same structural problem: attackers didn’t breach the organizations directly. They got in through vendors – third-party platforms with legitimate access and insufficient controls. In both cases, the question isn’t just whether those vendors were assessed. It’s whether security requirements were contractually anchored before vendor onboarding began, and whether access was scoped tightly enough to limit blast radius if something went wrong.

The right time to negotiate security controls is before onboarding, not after. Once a vendor is integrated into your operations, your leverage to require remediation drops substantially. Security requirements, SLAs for incident notification, audit rights, and data handling obligations should all be in the contract – not captured in a risk exception spreadsheet reviewed annually.

For fourth parties, your only lever is the contract with the direct vendor – requiring they maintain their own supplier risk management program and flow down relevant controls to subprocessors. This is where contractual controls and vendor inventory work together: you can only require fourth-party oversight for vendors you know you have.

Step 5: Continuous Monitoring

The key to vendor risk monitoring is making sure that monitoring is continuous. As attackers exploit vulnerabilities in a matter of hours, not days, such as threat actors pouncing on a critical Ivanti Sentry vulnerability within 24 hours of its disclosure, quarterly or even monthly risk evaluation is far from sufficient. You need real-time intelligence. A vendor can appear to have good controls until it is compromised, and you need the tools to respond quickly.

Quarterly vendor reviews are not continuous monitoring. Monthly scans are not continuous monitoring. Effective continuous vendor monitoring requires distinguishing between signal types. Real-time alerts for breach disclosures and critical vulnerability announcements need to be separated from scheduled scans of general security posture. A vendor breach reported in the news, like the Marks & Spencer disruption that kept grocery shelves empty for weeks, requires an immediate impact assessment, not a slot in next month’s review cycle.

The second challenge with continuous monitoring is alert fatigue. Most monitoring tools generate raw signals without business context, leaving analysts to manually determine whether a vendor security event is relevant to their organization. The problem isn’t volume, it’s the absence of prioritization logic. What matters is not that a vendor had a security event. It’s whether that event affects the systems they run for you, the data they hold, or the access they have.

Business context is what separates signal from noise: 

1. How critical is this vendor to our operations? 
2. What data do they hold? 
3. What mitigation controls are already in place? 

Monitoring tools that don’t incorporate this context force analysts to reconstruct it manually for every alert, which is unsustainable when you’re managing hundreds of vendors.

For teams at that scale, the only viable path to genuine continuous vendor monitoring is automation. The right goal is a system that surfaces contextually relevant alerts, quantifies business impact, and enables rapid reassessment when something changes, without requiring a human to bridge the gap for every event.

The Underlying Principle

The breaches making headlines – Marks & Spencer, Qantas, Stryker, Home Depot – aren’t failures of intention. The organizations involved had security programs. What they illustrate is the gap between a third-party risk management process that exists on paper and one that functions under real-world conditions: when vendors change, when access expands, when attackers move faster than review cycles.

A process is only as good as the intelligence feeding it and the automation executing it. Static questionnaires, annual reviews, and manual spreadsheets aren’t a risk management program – they’re the appearance of one. The organizations managing third-party risk effectively are those that have built processes capable of operating continuously, scaling with vendor growth, and connecting security signals to business context without requiring an analyst to manually bridge the gap for every event.

The steps aren’t complicated. The design is what’s hard and what most third-party risk management processes still haven’t gotten right.

To learn more about VISO TRUST and how we can improve and scale your TPRM program, contact our team or book a demo.