What is Third-Party Risk Management (TPRM)? A programme-level view of supplier risk

The five parts of a TPRM programme, how it differs from one-off assessments, and what regulators expect.

TPRM 8 min read

What is it?

Third-Party Risk Management (TPRM) is the ongoing programme an organisation runs to identify, evaluate, monitor and govern the risks introduced by every third party in its supply chain — SaaS vendors, cloud platforms, consultancies, sub-processors and their downstream dependencies.

Where a single vendor assessment answers "should we approve this supplier now?", TPRM answers "how do we govern all suppliers, together, over time?"

Why does it matter?

Modern organisations depend on hundreds of third parties. A single supplier failure can disrupt operations, expose customer data, or trigger regulatory action. Regulators increasingly expect a programme view — GDPR, NIS2 and DORA all require that third-party risk is managed as a discipline, not case-by-case.

A TPRM programme is also how an organisation makes its supplier decisions defensible. Individual assessments answer point-in-time questions. The programme records the pattern of decisions and shows an outside reviewer that oversight actually happened.

Common challenges

  • Fragmented ownership. Procurement, security, legal, IT and business owners each hold a piece.
  • Assessments treated as one-off events. Approvals granted at onboarding are rarely revisited.
  • Inventory drift. The list of active vendors diverges from what teams actually use.
  • Evidence goes stale. SOC 2 reports and DPAs age; nobody notices until the next audit.
  • Findings without follow-up. Risks are documented but not tracked to closure.

Best practice

A well-run TPRM programme has five moving parts:

  1. Inventory — a living record of who your third parties are and what data they touch.
  2. Tiering — a repeatable way to decide how deep an assessment should go, based on the data and criticality involved.
  3. Assessment — evidence-based due diligence performed against defined requirements.
  4. Monitoring — periodic reassessment plus signal collection between assessments (breach notifications, sub-processor changes, evidence expiry).
  5. Governance — clear ownership, documented decisions, and reporting to leadership.

The five parts must connect. An inventory nobody references, or assessments no one revisits, add cost without reducing risk.

How Governly supports this area

Governly focuses on the assessment step: mapping customer requirements to verifiable vendor evidence and producing a traceable decision. The output — a versioned, auditable assessment — is designed to slot into a broader TPRM programme rather than replace it.

Put this into practice

Governly applies the Requirements-to-Evidence Mapping methodology to your own vendors. Start from the Recommended Enterprise Baseline, upload your own requirements, or build from scratch — then add the vendor documents and receive a traceable due diligence report.