Basel TPRM Principles: Third-Party Risk as Financial Resilience
From Vendor Management to Resilience: What Actually Changed
For twenty years, third-party risk meant outsourcing registers and annual vendor reviews. The Basel Committee’s 10 December 2025 Principles for the sound management of third-party risk retire that framing — explicitly superseding the 2005 Joint Forum outsourcing paper — and replace it with a resilience question: when this provider fails, does the bank keep operating?
The structure reflects the shift. Principles 1–9 address banks across governance, risk management, and strategy through the full third-party service provider (TPSP) life cycle; Principles 10–12 address supervisors, including systemic concentration monitoring and cross-border coordination. Twelve principles, one baseline, applied proportionately to criticality — with explicit room for jurisdictional regimes like the EU’s DORA to sit on top.
Pair with Vendor Due Diligence Checklist, DORA Compliance, NIST CSF 2.0, and Enterprise Risk Management.
The 12 Principles, Mapped to the TPSP Life Cycle
| Life-cycle stage | Principles (paraphrased) | Bank deliverable |
|---|---|---|
| Governance & strategy | Board oversight and accountability; risk appetite including tolerance for disruption; clear roles and resourcing | Board-approved TPRM policy with disruption-tolerance statements |
| Risk assessment | Comprehensive pre-contract risk assessment proportionate to criticality | Scored assessment file per arrangement, refreshed on change |
| Due diligence | Financial, operational, security, and legal diligence on the provider and key nth parties | Diligence packs with remediation-tracked gaps — never a pass/fail checkbox |
| Contracting | Written agreements with audit rights, nth-party visibility, performance standards, and exit provisions | See audit-rights section below |
| Onboarding | Controlled transition with testing before live dependence | Parallel-run evidence, cutover sign-off |
| Ongoing monitoring | Performance, risk, and control monitoring proportionate to criticality; maintained registers of arrangements and key nth parties | Quarterly scorecards; annual deep reviews for critical services |
| Termination & exit | Actionable exit strategies and testing — portability, data return, transition assistance | Tested exit plans, not shelf documents |
| Supervision (10–12) | Supervisor monitoring of sector concentration; cross-border coordination | Examination-ready registers and reporting |
Note what is deliberately absent: prescriptive control lists. The principles set outcomes and proportionality; DORA, the EBA guidelines, and national rules supply the detailed prescriptions. Build once to the stricter layer, map outward to the principles.
Three Risk Lenses (Stop Conflating Them)
1. Critical-service risk. Which arrangements, if disrupted, stop payments, settlement, customer access, or regulatory reporting? Criticality drives everything: assessment depth, monitoring frequency, exit testing, and board reporting. Maintain a ranked critical-services register reviewed quarterly — not the 400-row vendor spreadsheet where the core banking host sits next to the office stationery supplier.
2. Supply-chain (nth-party) risk. Your provider’s providers: the cloud region under the SaaS, the sub-processor holding the data, the fourth-party library in the payment flow. Requirements that work: contractual notification of material sub-outsourcing, right-to-object windows for critical changes, flow-down of security and audit terms, and registers that name key nth parties — not “see vendor’s SOC report” as a substitute for knowing who they are.
3. Concentration risk. Same provider across five critical services; same cloud region under three providers; same geography for primary and backup processing. Map concentrations explicitly — by provider, by sub-outsourcer, by jurisdiction, by fourth-party technology — and set appetite limits (e.g., no single provider supporting more than X critical services without a tested alternative). Supervisors now monitor sector-level concentration too; expect questions that start “show me everyone who depends on…”
Contract Clauses That Satisfy Supervisors (With Teeth)
Audit rights fail in predictable ways: unlimited-in-theory rights no one has ever exercised, provider-approval gates that function as vetoes, and remediation clauses without timelines. Draft for testability:
- Access and inspection: named scope (systems, data, premises, personnel interviews), notice periods that shrink with severity, regulator direct-access acknowledgment, and your right to delegate to qualified third parties.
- nth-party visibility: disclosure of material sub-outsourcing before it takes effect, consent or objection rights for critical-service chains, and flow-down of audit and security terms.
- Performance and resilience SLAs: availability, recovery time/point objectives tied to your disruption tolerance, incident notification windows (hours, not weeks), and root-cause plus remediation reporting.
- Exit as an actionable clause: data return formats and timelines, transition assistance periods with fees pre-agreed, source-code or configuration escrow where continuity depends on it, and termination rights triggered by control failures — not just insolvency.
- Remediation mechanics: finding → dated corrective plan → verification evidence → closure sign-off by your team, with fee or service-credit consequences for repeat failures.
Calendar a test of at least one audit right per critical provider per cycle. An untested right reads as decorative under examination — the same standard applied to SOX 404 controls and PCI DSS vendor requirements.
Evidence Expectations: What the File Must Show
Supervisors and internal audit converge on the same question set:
- Register completeness: every TPSP arrangement plus key nth parties, with criticality ratings and review dates. Reconcile the register to procurement, AP, and IT asset inventories quarterly — orphan vendors (paid but unregistered) are findings.
- Risk assessment currency: pre-contract assessments plus refresh triggers (incident, acquisition, scope change, material subcontractor change). A 2023 assessment for a 2026 dependency is stale by definition.
- Monitoring artifacts: scorecards, review meeting minutes, incident logs with disposition, and follow-through on remediation — see Month-End Close discipline applied to vendor oversight.
- Exit readiness: tested portability (data exports that actually import elsewhere), transition runbooks with named owners, and recovery exercises that include at least one provider-failure scenario per year.
- Board reporting: disruption-tolerance statements, concentration maps, overdue remediation aged like audit findings, and incident themes — reported to the risk committee and, for material items, the full board under Audit Committee oversight.
TPRM Maturity Checklist (Banks and Fintechs)
| Level | Governance | Life cycle | Evidence |
|---|---|---|---|
| 1 — Ad hoc | No owner; spreadsheet register | Contracts without audit teeth; no exit plans | Missing or scattered |
| 2 — Developing | Named owner; policy drafted | Risk assessments for new deals; annual reviews | Partial files; gaps known |
| 3 — Defined | Board-approved appetite incl. disruption tolerance | Full life-cycle coverage; nth-party visibility for critical chains | Complete, versioned, reviewer-signed |
| 4 — Assured | Independent testing of the framework itself | Tested exits; concentration limits enforced; cross-border coordination | Examination-ready; trends reported to the board |
Most institutions sit at level 2 and report as if at level 4. The honest self-grade — validated by internal audit, not self-attested by the program owner — is itself evidence of governance maturity. Target level 3 within one examination cycle, with the level-4 testing layer (independent framework assurance) the year after.
FAQ
Does this replace DORA for EU entities?
No — DORA remains binding with detailed ICT-risk prescriptions. Treat the Basel principles as the global baseline your program also satisfies; map once, comply with both, and let DORA’s specifics drive implementation depth in the EU.
How do supervisors assess concentration risk?
Through registers and reporting that reveal shared dependencies across banks — common providers, regions, and fourth-party technologies — plus institution-level concentration maps you should already maintain for your own resilience planning.
Next Steps
- Confirm your critical-services register and nth-party visibility this quarter — those two artifacts drive every other requirement.
- Rewrite one template contract with testable audit rights, notice windows, and exit mechanics, then roll the clauses across renewals.
- Test one exit and exercise one audit right before the next examination cycle, and report both outcomes to the risk committee with the remediation they surfaced.
