ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
TPRM, third-party risk management, is the discipline of knowing which outside organisations your business depends on, deciding how much risk each one carries, checking them before you commit, binding them by contract, watching them for as long as the relationship lasts, and being able to leave. Every regulator that examines a bank, an insurer, a payment firm, a healthcare provider or a listed company now asks to see that programme in writing. This guide explains what TPRM is, why the question keeps arriving from so many directions, and what a documented programme actually contains.
The one-sentence version: TPRM is the management of the risk that arises when someone else does part of your work. The five-stage version is how every supervisor describes it. The 2023 Interagency Guidance on Third-Party Relationships from the Federal Reserve, the FDIC and the OCC sets the lifecycle out as planning, due diligence and third-party selection, contract negotiation, ongoing monitoring and termination, with governance running across all five. DORA’s Chapter V, the EBA outsourcing guidelines, the PRA’s SS2/21 and the Financial Stability Board’s December 2023 toolkit describe the same sequence in different words.
That agreement matters more than it looks. A TPRM programme built on the lifecycle can be shown to a US bank examiner, an EU financial supervisor, a SOC 2 auditor, a PCI DSS assessor or a data protection authority without being rewritten for each of them. A programme built on one regulator’s checklist cannot, and rebuilding it for each new regime is a cost the lifecycle approach avoids.
| Stage | The question it answers | The record it leaves |
|---|---|---|
| Planning | Should we engage a third party for this at all, and can we oversee it? | A sourcing risk assessment, approved before selection |
| Due diligence and selection | Is this provider suitable, and what did we find? | A scored questionnaire, an assurance review, a due diligence report, a decision record |
| Contract negotiation | Does the contract carry every provision our regimes require? | A completed requirements checklist and the executed contract |
| Ongoing monitoring | Is the provider still what it was when we signed? | Service reports, findings, reassessments, incident and change logs |
| Termination | Can we get out, and did we get our data back? | An exit plan, a transition record, a destruction certificate |
Outsourcing guidance began as a banking topic. It is now written into a dozen regimes that reach well beyond banks, and each states the same principle in its own vocabulary: the organisation that contracts an activity out keeps the responsibility for it.
The practical consequence is that TPRM is no longer a compliance function’s project. It is the one programme that every one of those obligations tests, which is why building it once on the lifecycle and mapping outward is cheaper than building it seven times.
Examiners do not ask whether you manage third-party risk. They ask for the record. The Interagency Guidance lists ten classes of documentation it expects to see, and the list is a fair summary of what any regime wants: a current inventory of every relationship flagging the critical ones; the planning and risk assessments; due diligence results and recommendations; executed contracts; remediation plans; the risk and performance reports received from providers; complaint monitoring where the provider faces customers; the provider’s own reports of disruptions and breaches; the results of independent reviews; and periodic reporting to the board, including dependency on a single provider for several activities.
A programme that produces those ten records as a by-product of running is documented. A programme that produces a policy and a spreadsheet is not, however good the policy is.
Every regime says effort must be proportionate to risk, and none of them says how. Tiering is the answer: a fixed set of inherent-risk questions, asked before any due diligence, whose answers place a relationship in a band. The band then decides the questionnaire depth, the contract form, the monitoring cadence and whether an exit plan is required. Tiering is what stops a programme spending its year on the office cleaning contract while a cloud platform supporting a critical function goes unreviewed.
DORA and the EBA use the term “critical or important function”; the Interagency Guidance says “critical activities”. Both mean a function whose disruption would materially impair the organisation’s operations, its regulatory standing or its service to customers. The determination is made about the function, and every provider supporting it inherits the stricter treatment.
A provider’s own subcontractor can hold your data, run your service and cause your outage without ever signing a contract with you. DORA Article 29(2), GDPR Article 28(4) and HIPAA’s subcontractor chain all reach that party, and a TPRM programme needs a register of them and rights of notice and objection over changes.
The dependency that individual relationship reviews cannot see: one provider or group supporting several critical functions, a provider that is not easily substitutable, or a subcontractor or region shared by several of your critical providers. DORA Article 29 requires it to be assessed before contracting, and boards are expected to see it reported.
| Failure | What it looks like | What fixes it |
|---|---|---|
| No single inventory | Procurement, IT and the business each hold a different list | One register, reconciled against accounts payable and access records |
| Due diligence after signature | The questionnaire goes out in month three | A gate: no purchase order or access without a completed review |
| Contracts without the provisions | Audit rights and exit terms negotiated away | A requirements checklist completed before execution, with recorded exceptions |
| Monitoring by inbox | Whatever the provider sends is filed | A cadence by tier, with defined triggers for escalation |
| Exit as an afterthought | The first exit plan is written the week the provider fails | Exit plans written before signing and tested on a schedule |
| Subcontractors invisible | Nobody can say who the provider’s own critical supplier is | A fourth-party register confirmed with the provider at each review |
At minimum: a board-approved policy and a risk appetite statement; a single inventory with tiering and critical-function mapping; a planning assessment used before selection; tiered due diligence with questionnaires that already exist; a contract requirements checklist mapped to your regimes; monitoring procedures with a cadence and an escalation path; exit plans for critical arrangements, tested; concentration and fourth-party registers; and the reporting that puts all of it in front of the board. The TPRM Toolkit ships those as 86 templates on the lifecycle, with every document mapped to the 188 requirement identifiers across the twelve regimes above, so the same programme answers whichever supervisor asks.
Two companion pieces on this site go deeper: our guide to third-party risk management across four regimes, and the vendor security questionnaire playbook for the day the questionnaire arrives from a customer rather than from you. From here, the TPRM lifecycle, the Interagency Guidance, the third-party risk management framework, the TPRM policy, the third-party risk assessment, the vendor due diligence checklist and fourth-party risk guides each take one part of the programme further.
Vendor risk management is the older, narrower term, and it tends to mean suppliers you pay. TPRM covers any third party, whether or not a contract or payment exists: affiliates, consultants, referral partners, resellers and the subcontractors behind them. The regulators use the broader term deliberately.
Yes. ISO/IEC 27001, SOC 2, PCI DSS, GDPR, HIPAA and NIS2 all impose third-party obligations on organisations that are not financial institutions. The banking regimes are the most detailed, which is why the lifecycle they describe is the best structure for everyone else too.
All of them, in the inventory. Not all of them to the same depth. Tiering exists so that the majority of low-risk relationships take a short questionnaire and standard terms, and the capacity goes to the providers that could actually hurt you.
The inventory, with a tier and a named owner against every relationship. Nothing else in the programme can be sized, scheduled or reported until that exists, and building contract clauses or monitoring routines first produces documents nobody can apply.
September 13, 2026
September 13, 2026
September 13, 2026
September 13, 2026
September 13, 2026