Third-party risk management (TPRM) is the practice of identifying, assessing, and continuously monitoring the risk an organization inherits from the outside parties it relies on: software vendors, cloud providers, contractors, data processors, payment partners, and the suppliers behind all of them. The goal is not to eliminate those relationships. It is to understand what each one can do to you, decide whether that exposure is acceptable, and notice when it changes.
That last part—noticing when it changes—is where most programs built before 2020 quietly fail. This guide walks through what TPRM covers, how a working program runs day to day, and why the field has moved away from once-a-year questionnaires toward continuous, evidence-based monitoring.
What is third-party risk management?
Third-party risk management is a program, not a single tool. It governs the full relationship with an external party from the moment someone in procurement or a business unit wants to buy something, through onboarding, through the years the vendor is in production, to the day the contract ends and access has to be revoked.
People use a few related terms, and the distinctions are worth getting right because regulators and analysts use them precisely. Vendor risk management (VRM) is the subset of TPRM concerned with paid suppliers—the vendors you have a contract with. TPRM is broader. It includes parties you may not pay directly: affiliates, agents, joint-venture partners, open-source maintainers, and anyone with access to your data or systems.
A simple way to hold it: every vendor is a third party, but not every third party is a vendor you pay.
What counts as a third party, and why the count keeps climbing
A third party is any external entity whose failure, breach, or misbehavior can become your problem. The list is longer than most teams expect once they inventory it honestly: the SaaS tools individual teams expensed without telling IT, the sub-processor your main vendor relies on, the contractor with a laptop on your VPN, the analytics script running in your customer's browser.
Two forces keep expanding the count. The first is that software is now assembled from other software, so adopting one vendor often means inheriting ten of theirs. The second is that buying has decentralized. A marketing manager can stand up a new tool with a credit card before security ever hears the name. Most organizations underestimate their real third-party footprint, and the gap between the official vendor list and the actual one is itself a risk.
TPRM was never only about cybersecurity
Cybersecurity risk
The vendor's controls, its attack surface, its history of incidents, and whether a compromise on their side reaches your data.
Financial & viability risk
A vendor running out of money can disrupt you as badly as one that gets breached. Sudden financial distress in a critical supplier is an operational threat.
Operational & concentration risk
If too many critical functions route through a single provider—or several providers on the same cloud region—you have concentration risk even if every vendor is individually healthy.
Compliance & regulatory risk
The vendor handles regulated data or performs a regulated function, and their lapse becomes your violation.
Reputational risk
Their labor practices, security posture, or public failures attach to your brand in ways that are difficult to anticipate and slow to repair.
AI risk
A vendor that feeds your data into a model, trains on your inputs, or makes automated decisions about your customers introduces exposure that the old questionnaire never asked about.
How a third-party risk program actually runs
Strip away the software and a TPRM program is a lifecycle. The same five stages show up in every framework, whether you call them by these names or others.
Intake and tiering. Capture what the vendor will do, what data it will touch, and assign an inherent risk tier. Tiering is the highest-leverage step in the whole program—it decides how much scrutiny everything downstream gets.
Due diligence and assessment. Gather evidence: SOC 2 reports, ISO 27001 certificates, penetration test summaries, and answers about how they handle your data. The output is a view of residual risk after accounting for the controls they actually have in place.
Continuous monitoring. Watch for change after the vendor goes into production: a breach, a leaked credential set, a deteriorating posture, an expired certificate, a downgrade in financial health. This is the stage that point-in-time programs skip.
Remediation and issue management. When an assessment or monitor turns up a problem, someone has to own it, the vendor has to fix it, and the fix has to be verified. A finding with no owner and no deadline is a finding that will reappear in next year's audit unchanged.
Offboarding. The contract ends. Access has to be revoked, data returned or destroyed, and the records have to show it happened. Offboarding is the most neglected stage—and dormant vendor access is a recurring source of breaches that no one is watching for.
Why point-in-time questionnaires stopped being enough
The traditional model was an annual cycle. Once a year you sent each vendor a long questionnaire, they filled it out, you filed the answers, and you moved on. It is like checking your bank balance once a year and assuming nothing happened in between.\n\nA vendor can pass a clean security review in January and get breached in March—and under the annual model you would not know until the following January. Beyond timing, questionnaires are self-reported: they ask the vendor to grade their own homework. Most vendors answer honestly, but honest answers describe intentions and policies, not the live state of their systems. Security teams also drown in returned questionnaires they do not have time to read closely, while vendors copy-paste answers across dozens of near-identical forms.
Evidence-based, control-based continuous monitoring
Evidence-based means a risk decision is backed by something verifiable rather than a vendor's say-so: the SOC 2 control reference, the configuration screenshot, the scan result, the audited statement. The claim and the proof travel together.\n\nControl-based means the assessment is organized around the security controls a vendor should have, mapped to recognized frameworks, rather than around a particular questionnaire's wording. The result: the vendor's living state—not their annual paperwork—becomes the thing you track. A control either has current evidence behind it or it does not, and 'does not' is a finding you can act on.
The regulations pushing TPRM forward
Much of the recent investment in TPRM is driven by rules that now require it explicitly, with named expectations rather than vague gestures at 'due care.' The common thread: 'we trusted our vendor' is no longer an acceptable answer to a regulator.
Key regulations and their TPRM requirements
| Regulation | Region / Sector | Key TPRM requirement |
|---|---|---|
| DORA (Digital Operational Resilience Act) | EU — financial entities | Maintain a register of ICT providers; manage concentration in critical providers; contractual requirements for third-party resilience. |
| NIS2 Directive | EU — critical infrastructure | Widened scope of supply chain security obligations; raised penalties for non-compliance and inadequate third-party oversight. |
| GDPR | EU — all sectors handling personal data | Controllers remain accountable for processors; data processing agreements and vendor due diligence are required by law. |
| SEC Cybersecurity Disclosure Rules | US — public companies | Material cybersecurity incidents—including vendor breaches—must be disclosed; governance and risk management processes must be documented. |
| ISO 42001 | Global — AI governance | Emerging standard for AI management systems; programs are adding AI-specific controls as vendors increasingly process data through models. |
Days, not weeks
Time from vendor intake to a risk decision. Programs that take weeks to clear low-risk vendors create pressure to route around them—which is how shadow vendors appear.
>80% coverage
Share of critical vendors under active continuous monitoring between assessments. In most organizations, this number is far lower than leadership assumes.
<24 hours
Target time from a monitored vendor breach to the right person inside your organization knowing and acting on it.
Findings close rate
Open findings that never resolve are the clearest sign that the program produces paperwork instead of outcomes. Track percentage closed by their stated deadline.
Fourth-party and concentration risk
Your vendors have vendors. The cloud platform your SaaS tool runs on, the email service it uses to reach you, the sub-processor it sends data to: these are your fourth parties, and you have no contract with them. Fourth-party risk is hard to see precisely because it sits one layer past your direct relationships, and mapping it usually means inferring the dependency chain from your vendors' own disclosures and from external signals.
Concentration risk is the pattern that emerges when you map far enough. You may have carefully diversified across five vendors for a critical function, only to discover that all five run on the same cloud provider in the same region. The diversification was an illusion. Regulators in financial services have grown specifically worried about this, because a single cloud outage can take down a function across an entire sector at once.
Frequently asked questions
What is the difference between TPRM and VRM?
Vendor risk management covers the paid suppliers you contract with. Third-party risk management is broader and includes any external party that can affect you—paid or not—including affiliates, agents, and sub-processors. VRM is a subset of TPRM.
What is the difference between inherent risk and residual risk?
Inherent risk is the exposure a vendor creates before considering any of their controls, driven mainly by what data and access they have. Residual risk is what remains after accounting for the controls they actually have in place and that you have verified.
Is a SOC 2 report enough to clear a vendor?
It is useful evidence, not a complete answer. A SOC 2 describes controls over a past audit period and a defined scope. It does not tell you the vendor's state today, and it may not cover the systems that hold your data. Treat it as one input, check its scope and date, and pair it with continuous monitoring.
How often should vendors be reassessed?
Tier-based, not calendar-based. Critical vendors warrant continuous monitoring plus periodic deeper review; low-risk vendors may need little after onboarding. Reassessing every vendor annually on the same schedule wastes effort on the low-risk ones and still misses changes that happen between cycles for the high-risk ones.
Does TPRM cover AI vendors differently?
It is starting to. A vendor that processes your data through AI models, trains on your inputs, or automates decisions about your customers introduces exposures that traditional questionnaires were not written to catch—including data use, model provenance, and automated decision accountability. Programs are adding AI-specific controls and questions, and standards like ISO 42001 are emerging to give them structure.
