Third-Party Risk Management (TPRM): Definition and Use in Compliance

What is Third-Party Risk Management (TPRM)?

Third-Party Risk Management is how a regulated firm governs the risks it takes on when it depends on outside parties to deliver its services. Banks rarely build everything in-house. They rent cloud infrastructure, buy sanctions screening data, outsource card processing, and contract call centers. Each relationship imports risk that the bank still owns.

TPRM treats every vendor as a potential point of failure and manages that exposure across the relationship's full life: selection, due diligence, contracting, monitoring, and termination. The scope is broad. Operational risk shows up when a payment processor goes dark. Data protection risk appears when a vendor with personally identifiable information suffers a breach. Financial crime risk emerges when an outsourced onboarding provider runs weak customer due diligence.

Consider a mid-size bank that outsources transaction monitoring to a RegTech vendor. If that vendor's models miss a money laundering typology, the bank files no Suspicious Activity Report, and the regulator holds the bank accountable, not the vendor. The 2023 US interagency guidance is blunt on this: a bank's use of third parties does not diminish its responsibility to operate safely and comply with the law.

Good TPRM answers three questions for every relationship. What could go wrong? How likely and how severe? What controls reduce the residual exposure to a level the firm accepts? It connects directly to risk appetite, because some vendor risks are worth taking and some are not. The output is a defensible record showing the firm knew its vendors, sized the risk, and managed it.

How is Third-Party Risk Management (TPRM) used in practice?

In practice, TPRM runs as an operating process owned jointly by procurement, risk, compliance, and the business lines that use the vendors. It starts before a contract exists. When a business unit wants to engage a supplier, intake routes the request through a risk questionnaire that captures what the vendor does, what data it touches, and whether it supports a critical service.

That intake produces a risk tier. A cloud host running core banking sits in the top tier and gets deep due diligence: independent audit reports, security architecture review, financial health checks, and site visits for the most critical cases. A marketing email tool sits low and clears with a light review. Tiering keeps effort proportional, which matters when a large bank manages thousands of active vendors.

After signing, monitoring takes over. Teams track certification renewals, run annual reassessments, and watch for trigger events: a vendor data breach, a downgrade, negative adverse media, or a change in ownership. A practical workflow: a security researcher publishes a vulnerability in a widely used file-transfer tool, and within the day the TPRM team queries its inventory, identifies four vendors using that tool, and opens remediation tasks for each.

Most firms run this on a GRC platform that holds the inventory, schedules reassessments, and escalates overdue items. The recurring failure is inventory drift, vendors signed outside the process. Linking purchase-order approval to TPRM sign-off closes that gap and aligns the program with the bank's three lines of defense model, where the business owns the relationship and risk provides oversight.

Third-Party Risk Management (TPRM) in regulatory context

Supervisors worldwide now expect formal TPRM, and the expectations have sharpened fast. In the US, the OCC, Federal Reserve, and FDIC issued joint Interagency Guidance on Third-Party Relationships in June 2023, replacing separate agency rules with one risk-based framework covering planning, due diligence, contract negotiation, ongoing monitoring, and termination.

Europe moved further toward hard law. The Digital Operational Resilience Act (DORA), which applies from January 2025, requires financial entities to maintain a register of all ICT third-party arrangements, classify which support critical functions, and impose specific contractual terms. It also created an EU-level oversight regime for critical ICT providers like major cloud platforms. The UK's PRA and FCA built parallel rules through their operational resilience policy and a critical third parties regime.

The financial crime angle matters too. The Wolfsberg Group and FATF guidance both address reliance on third parties for parts of CDD, and FATF's standards permit reliance only when the bank keeps ultimate responsibility and can obtain underlying records on request.

A concrete example: a European bank outsourcing cloud storage of customer data must, under DORA, document the arrangement in its register, confirm the provider meets data residency requirements, secure audit and access rights in the contract, and have a tested exit plan if the provider fails. Miss any of these and the supervisor can fine the bank, regardless of whether an incident actually occurred. The shift is clear: TPRM is now examined, not assumed.

Common challenges and how to address them

The first challenge is the incomplete inventory. You cannot manage vendors you do not know you have. Shadow IT and business-unit contracts signed without compliance review create blind spots, and these are exactly where examiners and incidents find the firm exposed. The fix is procedural: route every purchase through TPRM intake and reconcile the vendor list against accounts-payable data quarterly to catch what slipped past.

Second is depth without drowning. Treating every vendor the same wastes effort on low-risk suppliers and starves attention from critical ones. Risk tiering solves this, but only if the tiers drive real differences in due diligence and monitoring cadence. A critical vendor should get continuous monitoring; a low-risk one needs a periodic check.

Third is fourth-party risk. Your vendor's subcontractors can take you down. The 2023 MOVEit breach hit thousands of organizations through their vendors' use of one file-transfer tool. Address this by requiring critical vendors to disclose their material subcontractors and notify you of changes, written into the contract.

Fourth is concentration risk. When most of an industry runs on the same handful of cloud providers, a single outage becomes systemic. There is no clean fix at the firm level, but mapping concentration, building exit and substitution plans, and setting clear impact tolerances for each critical service keeps the firm honest about what it can actually withstand.

Manual evidence collection is the quiet drain. Chasing SOC 2 reports and certification renewals by email burns analyst hours. Regulatory compliance automation and continuous monitoring feeds cut that work and replace point-in-time snapshots with live signals.

Related terms and concepts

TPRM sits inside the broader operational resilience agenda, which asks whether a firm can keep delivering its critical business services through disruption, including disruption that starts at a vendor. The two disciplines share vocabulary: both rely on impact tolerance to define how much disruption a service can absorb before causing intolerable harm.

Several risk concepts feed TPRM scoring. Inherent risk is the exposure a vendor relationship carries before controls; residual risk is what remains after controls apply. The gap between them is the control environment, the contractual terms, audit rights, and monitoring the firm puts in place. Tiering decisions trace back to the firm's risk appetite.

On the financial crime side, TPRM intersects with reliance arrangements. When a bank uses an outside provider for identity verification or enhanced due diligence, the quality of that vendor becomes an AML control that the MLRO must stand behind.

Two adjacent terms round out the picture. Fourth-party risk extends scrutiny to subcontractors, and concentration risk captures the danger of too many firms depending on too few providers. Frameworks like ISO 31000 for risk management and ISO 27001 for information security give programs a structure to build on, and vendor SOC 2 reports give the evidence to verify it.