TPRM Third-Party Risk Management.

Third-Party Risk Management (TPRM) treats your suppliers, subcontractors and service providers as an extension of your own attack surface. The logic is simple: if a vendor processes your data, runs your infrastructure or sits in your delivery chain, then their weaknesses become your incidents. TPRM is the discipline that makes that exposure visible, contractual and continuously monitored rather than discovered at the moment of breach.

The four phases practitioners actually run

TPRM is not a one-off questionnaire. It is a lifecycle that runs from the first contact with a vendor to the day you switch them off. Most mature programmes structure it in four phases:

• Onboarding due diligence. Before signing, you assess the supplier against the risk they introduce. A SaaS provider holding personal data and a stationery vendor do not get the same scrutiny. Tiering by criticality is what stops the programme drowning.
• Contract clauses. The contract is where assurance becomes enforceable: security obligations, audit rights, breach notification timelines, sub-processor disclosure, data location and exit terms. If it is not in the contract, you cannot demand it later.
• Ongoing assurance. Risk does not freeze at signature. Reassessment cadence, certificate tracking (ISO 27001, SOC 2), continuous monitoring of the vendor security posture and review of fourth-party dependencies keep the picture current.
• Off-boarding. When the relationship ends, you reclaim or confirm destruction of data, revoke access and close the residual exposure. The phase teams most often skip, and the one that leaves orphaned credentials behind.

Why it became a board-level conversation

TPRM used to live in procurement. It moved to the board because the headline failures of the last decade came through the supply chain, not the front door. The SolarWinds incident showed an attacker reaching thousands of organisations by compromising a single trusted software update. The CrowdStrike outage showed that a faulty update from one critical provider could halt operations across entire sectors at once. Both reframed third parties as systemic risk, not a procurement checkbox.

Regulation followed. NIS 2 makes supply chain security an explicit duty for in-scope entities and holds management bodies accountable for getting it wrong. DORA goes further for financial entities, devoting one of its five pillars to ICT third-party risk, imposing specific contractual requirements and bringing critical ICT providers themselves under oversight. For a regulated firm, TPRM is no longer good practice, it is a documented obligation.

How TPRM differs from neighbouring disciplines

TPRM sits alongside vendor management and general risk management, but it is narrower and sharper than either. Vendor management optimises cost, performance and the commercial relationship. TPRM cares specifically about the security, resilience, privacy and compliance risk a third party introduces. It also differs from internal ISMS work: your controls stop at your perimeter, but your accountability does not. You can outsource the activity, you cannot outsource the risk. That asymmetry is the whole reason the discipline exists.