Third-party risk management (TPRM), and why most programs stall.

Third-party risk management is the practice of understanding and controlling the risk created by the organizations you depend on. TPRM is the common abbreviation, and it covers more than security: concentration and resilience, financial stability, regulatory and sanctions exposure, data protection, and the fourth parties your third parties depend on in turn.

The reason it exists as a discipline at all is a structural asymmetry. When you outsource a function you transfer the work, but you do not transfer the accountability — to your regulator, your customers, or the public. What you do transfer is control. TPRM is the set of practices that tries to close the distance between those two facts.

The terms in this area are used loosely, and the distinctions are worth holding: vendor risk management usually means the security and performance risk of parties you buy from; supplier risk management is the same idea in procurement language, more common in the UK and in manufacturing; supply chain risk extends past your contracted parties to the chain behind them. TPRM is the widest of the four in practice, and the one regulators use.

TPRM in cyber security usually means the security slice of that wider discipline — whether a vendor can be trusted with your data, your credentials and your network connections. It is the largest component and the one that generates most of the work, but treating it as the whole of TPRM is how programs miss the supplier who is secure and financially failing, or secure and about to be acquired by a competitor.

Third-party risk management is important because accountability for a failure stays with you when control over it does not. A regulator, a customer or a court holds your organization responsible for data you handed to somebody else. Every supplier you add extends the number of places that data can be lost from, without extending the number of places you can defend.

Four things have made that asymmetry sharper than it was a decade ago.

1. Most of your attack surface now belongs to other people. A typical organization runs on hundreds of SaaS products, API integrations, contractors with standing credentials and managed service providers with privileged access. The perimeter you can patch is a small and shrinking fraction of the perimeter that can be used against you.
2. Supervisory expectations moved from having a policy to showing evidence. The question examiners ask is no longer whether you assess vendors, but what you knew about a specific critical vendor between reviews, and when you knew it. That is a materially harder question, and it is answered with records or not at all.
3. Concentration turns one supplier’s failure into everybody’s incident. When an identity provider, a payments processor or a single cloud region goes down, it does not take out one company — it takes out every company behind it at once, including the alternates you assumed were independent.
4. It gates your own revenue. Your customers run this process on you. A slow or unevidenced security review is a deal that closes a quarter late, which makes TPRM a commercial function as much as a control function — and is usually the argument that unlocks a budget when the risk argument has not.

What importance does not justify is treating every supplier the same. The programs that fail are rarely the ones that took third-party risk too lightly; they are the ones that took all of it equally seriously, spread a fixed amount of effort evenly across hundreds of vendors, and ended up with thin assurance everywhere and real assurance nowhere. Which is what tiering, below, exists to prevent.

Third-party vendor risk management is the two terms run together, and most of the time the person using it means TPRM. The words are treated as interchangeable in job titles, RFPs and software categories, and for most conversations that is harmless.

It stops being harmless at the point you scope a program. A vendor is someone you buy from. A third party is anyone outside your organization whose failure lands on you — which includes vendors, and also includes parties you have no purchase order with at all: joint venture partners, introducers and agents, franchisees, outsourced regulators’ agents, open-source maintainers, and the recipients of data you share without paying for the privilege.

Programs scoped from the accounts payable ledger inherit that gap silently. The supplier list is the obvious starting inventory and it is the wrong one to stop at: it is complete for spend and incomplete for risk. If the register was built by exporting vendors from finance, the parties missing from it are precisely the ones nobody has assessed.

Organizations commonly anchor a TPRM framework to something external — NIST SP 800-161 for supply chain risk, ISO 27036, the NIST Cybersecurity Framework’s supply chain category, or a sector rulebook. Anchoring is useful for defensibility, but a framework someone can actually run has to answer six questions of its own:

• Scope. What counts as a third party here? Software vendors, contractors, resellers, professional services, the payroll bureau, the cleaning contractor with building access? Ambiguity at this line is where coverage quietly fails.
• Tiers. How many, what puts a vendor in each, and what each tier obliges — assessment depth, approval level, monitoring frequency, contract terms.
• Risk appetite. What you will accept, what needs compensating controls, and what is a stop. If nothing is ever a stop, the program is advisory.
• Roles. Who owns the relationship, who assesses, who accepts residual risk, and who can override. Named roles, not committees.
• Evidence standards. What counts — a questionnaire response, a SOC 2 Type II report, a certification, external monitoring — and how each is validated rather than filed.
• Cadence and triggers. What reassessment is scheduled, and what events force one early: a breach, an acquisition, a material service change, a rating drop.

Written this way, the framework becomes the thing that makes the program repeatable when the person who built it leaves — which is the actual test.

Each of those six is unpacked, with a build sequence, a maturity model and a self-assessment, on how to build a third-party risk management framework.

US supervisory expectations on third-party risk are set in several places at once. Banking agencies — the OCC, Federal Reserve and FDIC — issued joint interagency guidance on third-party relationships in 2023, replacing their separate regimes and organizing expectations around the relationship lifecycle. The FFIEC’s IT Examination Handbook carries the outsourcing and architecture detail examiners work from. The SEC’s cybersecurity disclosure rules require public companies to describe how they identify and manage risks from third-party use, and to disclose material incidents — including incidents that reach them through a service provider. HIPAA imposes business associate obligations in healthcare, and CMMC pushes requirements down the defense supply chain by contract rather than by regulation.

Read together, they converge on four expectations, and it is more useful to build to those than to any single rulebook:

1. Know your third parties and their criticality — a complete, risk-ranked inventory.
2. Diligence proportionate to risk, before commitment — evidenced, not asserted.
3. Ongoing monitoring — explicitly, not a periodic re-issue of the same questionnaire.
4. Governance and accountability — someone named, reporting that reaches the board, and records that show the process ran.

The word doing the most work across all of them is ongoing. It is the expectation programs most often fail, and the one most visible when an examiner or a customer asks what changed at a critical vendor between annual reviews.

Verify from outside as well as inside. Questionnaires and external assessment answer different questions. The first tells you what a vendor believes and intends; the second tells you what their infrastructure actually shows — exposed services, expiring certificates, leaked credentials, infrastructure changes — without needing their cooperation or their calendar.

Spend your diligence before signature. That is the only point in the relationship where you have leverage, and it is where security requirements become contract terms instead of requests.

Right-size the questionnaire. A 300-question set sent to a low-tier vendor produces a slow, low-quality answer and trains everyone involved to treat the process as bureaucracy. Ask fewer things, and validate the answers.

Make monitoring trigger something. A rating change that reaches nobody is a dashboard. Define who is notified, what threshold prompts contact, and what contractual right you are invoking when you make it.

Follow the chain past your contract. Your vendor’s vendors carry your data too, and concentration risk hides there — three critical suppliers can all sit on one platform. Supply chain risk covers that layer.

Report in outcomes. Coverage of the inventory, time from a vendor issue arising to detection, time to remediation, exceptions accepted and by whom. Those are answerable to a board. “Assessments completed” is not.

Most of what fails above is a capacity problem wearing a process problem’s clothes. A team of three running full assessments across four hundred vendors on an annual cycle would need to complete two every working day, forever, on top of onboarding, remediation and reporting. It does not happen, and the part that gives way is the monitoring between assessments — the part that would have caught something.

TPRM solutions address that arithmetic in four places: holding the register and its tiering, pre-populating assessments from evidence the vendor has already provided, monitoring posture from the outside between assessments, and composing the reporting. The honest test of any of them is not how many controls they map but how much human effort they remove per vendor.

What no tool changes: who decides to onboard a vendor, what risk appetite is, and who accepts a residual risk. Those stay with the people a regulator will ask. A programme that has automated the logistics and kept the decisions is the one that scales; one that has done the reverse has bought a filing system with opinions.

For the buying decision — categories, what separates a platform from a filing system, and how the market prices — see third-party risk management software. For what can be safely automated and what must not be, see AI third-party risk management.