Third-party risk management, 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.

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.

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.