A practical guide to third-party risk management: what TPRM means, the lifecycle regulators expect, how DORA, NIS2, GDPR, PRA, US banking guidance and POPIA frame it, a maturity model, KRIs and a worked supplier example.
Last updated: 2 November 2026
Third-party risk management (TPRM) is the discipline of identifying, assessing, controlling and monitoring the risks your organisation takes on when it relies on outside parties: vendors, suppliers, cloud providers, data processors, contractors, distributors and partners. A working TPRM programme tells you who your third parties are, which ones matter most, what could go wrong with each, and what you are doing about it, from the first conversation with a supplier to the day the contract ends.
This guide explains what TPRM means in practice, the lifecycle regulators expect you to follow, how the main rules in the US, UK, EU and South Africa frame the obligation, and how to build a programme that is proportionate to a mid-sized organisation rather than a global bank.
What is TPRM? A plain definition
TPRM meaning: third-party risk management is the set of policies, processes, roles and records an organisation uses to manage risk arising from its relationships with external parties. It covers the whole relationship, not just the security questionnaire sent during procurement.
A few terms come up constantly:
| Term | What it means |
|---|---|
| Third party | Any external organisation or person you have a business arrangement with: vendors, suppliers, processors, consultants, resellers, joint venture partners |
| Fourth party | Your third party's own suppliers and subcontractors (for example, the cloud host behind your payroll provider) |
| Vendor risk management (VRM) | A subset of TPRM focused on suppliers you buy from. Many teams use the terms interchangeably |
| Critical (or important) third party | One whose failure would significantly harm your operations, customers, finances or regulatory standing |
| Inherent risk | Risk before any controls, based on what the third party does for you and what data or systems it touches |
| Residual risk | Risk left after the third party's controls and your own contractual and monitoring safeguards |
TPRM sits inside your wider governance, risk and compliance programme. If you are setting that up from scratch, our guide to what GRC is and how the pieces fit together is a useful starting point.
Why third-party risk management matters
Outsourcing moves work to someone else. It does not move accountability. Almost every regime that touches this area says the same thing in different words: you stay responsible for what your suppliers do on your behalf. The EU's Digital Operational Resilience Act, for example, says financial entities "shall, at all times, remain fully responsible" for their obligations when they use ICT providers (DORA Article 28(1)).
The risks fall into several categories, and a mature programme looks at all of them, not only cybersecurity:
| Risk type | Typical example |
|---|---|
| Information security | A SaaS provider is breached and your customer data is exposed |
| Privacy and data protection | A processor uses personal information for its own purposes or transfers it without safeguards |
| Operational and resilience | A critical provider has an outage and you cannot serve customers |
| Concentration | Many of your key services depend on one cloud region or one provider |
| Financial | A supplier becomes insolvent mid-contract |
| Compliance and legal | A distributor breaches sanctions, anti-bribery or consumer protection rules in your name |
| Reputational and ESG | A supplier's labour or environmental practices become public |
| Fourth-party | A subcontractor you have never heard of handles your data |
The TPRM lifecycle
The clearest primary-source description of the lifecycle comes from the US federal banking agencies. Their Interagency Guidance on Third-Party Relationships: Risk Management, issued by the Federal Reserve Board, the FDIC and the OCC and published in June 2023, describes a "continuous life cycle" with five stages: Planning; Due Diligence and Third-Party Selection; Contract Negotiation; Ongoing Monitoring; and Termination.
The guidance is written for banks, but the stages work for any organisation. Below, each stage is expanded with the practical outputs you should have at the end of it. We add two steps that most programmes need in practice: building the inventory first, and assessing and tiering risk as a distinct step.
Stage 0: Build the third-party inventory
You cannot manage what you have not listed. Pull suppliers from accounts payable, contract repositories, SSO and expense data, and ask each department what tools they use. Record, at minimum, the owner, the service provided, the data and systems involved, and the contract dates. A simple vendor risk register is enough to start.
Output: one inventory of every third party, with a named internal owner.
Stage 1: Planning
Before signing anything, the business owner should explain why the third party is needed, what it will do, what data and systems it will touch, and what happens if it fails. This is where you decide whether the relationship supports a critical activity.
Output: a short business case and an initial criticality view.
Stage 2: Risk assessment and tiering
Score inherent risk from a few factors: data sensitivity, system access, operational dependency, regulatory exposure and spend. Use the score to place the third party in a tier. The tier then decides how much due diligence you do. Our vendor risk assessment guide has a full tiering matrix and scoring model you can copy.
Output: an inherent risk score and a tier (for example, low, standard, critical).
Stage 3: Due diligence and selection
Collect evidence in proportion to the tier: a questionnaire, security reports or certifications, policies, financial checks, sanctions screening, and for processors, data protection terms. Do not ask a low-risk stationery supplier for the same pack as your core hosting provider. If you need a ready-made question set, use our vendor risk assessment questionnaire with 60 questions by tier.
Output: reviewed evidence, findings logged, and a go, conditional go or no-go decision.
Stage 4: Contract negotiation
Turn findings into obligations. Typical clauses cover security requirements, breach notification, audit and access rights, subcontracting approval, data location, service levels, business continuity, cooperation with regulators, termination rights and data return. Several regimes set out minimum contract content (see the regulatory table below).
Output: a signed contract with the required clauses and any remediation commitments.
Stage 5: Onboarding and ongoing monitoring
Monitoring frequency should follow the tier. Critical third parties might be reviewed annually with continuous checks in between; low-risk ones every two to three years or on contract renewal. Monitor service performance, incidents, changes in ownership or subcontractors, expiring certifications and open remediation items.
Output: a review calendar, tracked issues and current evidence.
Stage 6: Termination and offboarding
Plan the exit before you need it. Confirm data return or deletion, revoke access, transfer services and keep records. For critical services, regulators increasingly expect a documented and tested exit plan.
Output: a closed record with evidence of data handling and access removal.
TPRM regulations and frameworks by jurisdiction
Most "what is TPRM" guides are US-centric and mention GDPR in passing. The table below maps the rules that most often drive TPRM obligations for organisations operating across the US, UK, EU and South Africa. It is a starting point, not legal advice; check which rules apply to your sector.
| Jurisdiction | Rule or framework | What it expects from TPRM |
|---|---|---|
| US (banking) | Interagency Guidance on Third-Party Relationships (Fed, FDIC, OCC, 2023) | Risk management tailored to the organisation's "size, complexity, and risk profile" and the nature of the relationship; more rigorous oversight for relationships supporting critical activities; five-stage lifecycle |
| US and global (any sector) | NIST Cybersecurity Framework 2.0 (26 February 2024) | A dedicated Govern category, Cybersecurity Supply Chain Risk Management (GV.SC), with ten subcategories covering programme set-up, supplier criticality, contracts, due diligence, monitoring, incident planning and post-relationship provisions |
| EU (financial entities) | DORA, Regulation (EU) 2022/2554, applying from 17 January 2025 | ICT third-party risk managed as part of the ICT risk framework (Art 28(1)); a register of information on all ICT contractual arrangements (Art 28(3)); exit strategies for ICT services supporting critical or important functions (Art 28(8)); minimum contract terms (Art 30) |
| EU (essential and important entities) | NIS2, Directive (EU) 2022/2555 | Supply chain security as a required cybersecurity risk-management measure (Art 21(2)(d)), taking into account each direct supplier's specific vulnerabilities and the quality of its products and security practices (Art 21(3)) |
| EU and UK (personal data) | GDPR Article 28 (and UK GDPR) | Use only processors "providing sufficient guarantees"; a written contract with set terms; no sub-processors without the controller's prior written authorisation |
| UK (PRA-regulated firms) | PRA SS2/21 Outsourcing and third party risk management | Supervisory expectations on outsourcing and third-party arrangements, complementing the UK operational resilience rules |
| UK (financial sector providers) | Critical third parties regime, PS16/24 | Rules for providers that HM Treasury designates as critical third parties, in force from 1 January 2025 and applying to a provider once its designation order takes effect |
| South Africa | POPIA sections 19 to 21 | A responsible party must ensure, by written contract, that an operator establishes and maintains the security measures in section 19; the operator must notify the responsible party immediately if there are reasonable grounds to believe personal information was accessed by an unauthorised person |
| Global (certifiable) | ISO/IEC 27001:2022 | Annex A includes supplier relationship controls (5.19 to 5.23) covering supplier policies, agreements, ICT supply chain, monitoring and cloud services |
Two patterns stand out. First, every regime is risk-based: none expects identical treatment for every supplier. Second, the expectations converge on the same artefacts: an inventory, a criticality decision, evidence of due diligence, contract terms, monitoring records and exit plans. Build those once and you can show them to any regulator or auditor.
For South African organisations, POPIA's operator rules are usually where TPRM starts. Our POPIA compliance guide covers operators alongside the other conditions for lawful processing.
How to build a TPRM programme: step by step
This is a practical sequence for an organisation without an existing programme. A small team can complete the first five steps in about a quarter.
- Agree scope and ownership. Decide which third parties are in scope (start with all suppliers that touch data, systems or customers). Name an executive sponsor and a programme owner. Make each business relationship owner accountable for their suppliers.
- Write a short TPRM policy. Two to four pages: scope, roles, tiering approach, minimum due diligence per tier, approval authority, review frequency and exit requirements. Regulators and auditors will ask for it.
- Build the inventory. Use the sources in Stage 0. Expect to find more suppliers than anyone thought you had.
- Tier everything. Apply a simple inherent risk score. Usually only a small share of suppliers are critical; those get most of your effort.
- Assess critical and high-risk suppliers first. Send tiered questionnaires, review evidence, and log findings as issues with owners and due dates.
- Fix your contract templates. Add the clauses your regulators require so new contracts are compliant by default. Prioritise renewals of critical contracts.
- Set the monitoring calendar. Schedule reviews by tier, track certificate and report expiry dates, and define triggers for an early review (an incident, a change of ownership, a new data type).
- Plan exits for critical services. Document how you would move or bring the service in-house, how long it would take, and what data you need back.
- Report. Give leadership a regular view of critical suppliers, overdue assessments, open high-risk issues and concentration risks.
Key risk indicators worth tracking
| Indicator | Why it matters |
|---|---|
| % of third parties with an assigned tier | Shows whether your inventory is usable |
| % of critical third parties assessed within the review period | Core coverage measure |
| Open high-risk findings past due date | Shows whether remediation is real |
| Critical third parties without a documented exit plan | Resilience gap |
| Third parties onboarded without due diligence | Policy bypass, often through credit card purchases |
| Critical services dependent on the same provider | Concentration risk |
TPRM maturity model
Use this to judge where you are and what to fix next. It is our own model, not a regulatory standard.
| Level | Description | Typical signs |
|---|---|---|
| 1. Ad hoc | Checks happen only when someone remembers | No inventory; questionnaires in email; no tiering |
| 2. Defined | A policy and inventory exist | Spreadsheet register; one questionnaire for everyone; reviews at onboarding only |
| 3. Risk-based | Effort follows risk | Tiering drives due diligence; findings tracked; contract templates updated |
| 4. Managed | Monitoring is continuous and reported | Review calendar by tier; KRIs to leadership; exit plans for critical services; fourth parties recorded |
| 5. Integrated | TPRM is part of enterprise risk and resilience | Third-party risks feed the risk register; scenario testing with critical providers; automation for evidence collection and review |
Most mid-sized organisations should aim for level 3 within a year and level 4 for their critical suppliers.
Worked example: tiering and managing a new payroll provider
This is an illustrative example of how the lifecycle runs for one supplier.
Planning. HR wants to move payroll to a cloud provider. The service processes salary, banking and identity data for every employee in the UK and South Africa. If it failed on payday, staff would not be paid.
Risk assessment and tiering. Data sensitivity: high (financial and identity data). System access: integration with HR system. Operational dependency: high (payroll is time-critical). Regulatory exposure: UK GDPR and POPIA. Result: critical tier.
Due diligence. The team sends the critical-tier questionnaire and requests the provider's latest independent security assurance report, its sub-processor list, its business continuity test summary and its standard data processing terms. Review produces three findings: the sub-processor list includes a support centre in a third country not covered by the draft contract; the continuity test summary is 18 months old; multi-factor authentication is optional for customer administrators.
Contract. Legal adds processor terms meeting GDPR Article 28 and POPIA section 21, a requirement to notify the company of breaches without undue delay, prior approval for new sub-processors, audit rights, a commitment to enforce MFA on the company's tenant, and a 90-day exit assistance clause with data return in a standard format.
Monitoring. The provider is reviewed annually, with an early review triggered by any breach, change of ownership or new sub-processor. The continuity test finding stays open until an updated summary arrives. The HR owner confirms service quality each quarter.
Exit plan. The team documents a fallback: a manual payroll run through the bank for one cycle, and the data fields needed to migrate to an alternative provider.
Every step leaves a record: tier, evidence, findings, contract terms and review dates. That record is what an auditor, regulator or customer will ask to see.
Common TPRM mistakes
- Treating TPRM as a procurement form. Risk changes during the relationship; one-off checks miss it.
- One questionnaire for everyone. It overwhelms small suppliers and under-tests critical ones.
- Ignoring suppliers bought on cards. SaaS tools bought outside procurement often hold the most sensitive data.
- Findings with no owner. If issues are not tracked to closure, the assessment was mostly paperwork.
- No exit plan. Exit is the stage regulators increasingly probe for critical services, and the one most programmes skip.
- Forgetting fourth parties. Ask critical suppliers for their subcontractor list and how they assess them.
Frequently asked questions
What does TPRM stand for?
TPRM stands for third-party risk management: the process of identifying, assessing, mitigating and monitoring risks that come from relying on external organisations such as vendors, suppliers, processors and partners.
What is the difference between TPRM and vendor risk management?
Vendor risk management focuses on suppliers you buy goods or services from. TPRM is broader and also covers partners, distributors, agents, affiliates and other relationships that are not strictly purchases. In practice, many organisations use the terms interchangeably.
What are the stages of the third-party risk management lifecycle?
The US banking agencies' interagency guidance names five stages: planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination. Most programmes add an inventory step at the start and a distinct risk assessment and tiering step before due diligence.
Who is responsible for third-party risk management?
Accountability usually sits with senior management, with a central programme owner (often in risk, compliance, security or procurement) running the process. Each business owner of a supplier relationship is responsible for that supplier day to day. Regulators are clear that outsourcing a service does not outsource responsibility for it.
Is third-party risk management a legal requirement?
It depends on your sector and location. Financial entities in the EU must manage ICT third-party risk under DORA, entities in scope of NIS2 must address supply chain security, any organisation using processors under GDPR or operators under POPIA must have compliant contracts and safeguards, and UK and US regulators set expectations for regulated firms. Even where no rule names TPRM, customers and auditors increasingly expect it.
How often should third parties be reassessed?
Base frequency on tier. A common approach is annually for critical suppliers, every one to two years for standard suppliers and at renewal for low-risk ones, with early reviews after incidents, ownership changes or a change in the data or service provided.
Run TPRM in one place
Spreadsheets work for the first few dozen suppliers, then the review calendar, evidence and findings start to drift apart. Core GRC's third-party risk management module lets you keep your vendor inventory, tiering, assessments, evidence and issues together, see which reviews are due, and connect vendors to the processing activities and risks they affect. Core IQ, the platform's agentic AI, helps teams work through assessments and keep records current.
Cover photo by Olena Kholina on Unsplash
