Third-Party Risk Management

Third-party risk management for procurement and second-line teams

Third-party risk management (TPRM) is the discipline of categorising, assessing, contracting, monitoring, and exiting third-party relationships against a regulator-aligned framework. This page shows the canonical lifecycle as a BPMN process map and covers the obligations under CPS 230, DORA, OSFI B-10, and the OCC bulletins.

By Jack Finnegan · Updated 21 May 2026

Map your TPRM lifecycle Operational resilience hub

What it is

What third-party risk management actually is

Third-party risk management (TPRM) is the discipline of identifying, assessing, contracting, monitoring, and exiting relationships with external parties that provide goods or services to the firm. Modern TPRM regimes go beyond traditional procurement vendor management to include security, compliance, financial, operational, ESG, and concentration risk - and increasingly, fourth-party risk (the vendors of vendors).

The major regulator frameworks all require similar shapes: APRA CPS 230 (Australia) requires a material service-provider register and ongoing arrangement monitoring; EU DORA requires an ICT third-party register and contractual provisions; OSFI Guideline B-10 / E-21 (Canada) covers third-party arrangements; the US OCC Bulletin 2023-17 covers the same ground for federally-supervised banks. The terminology differs but the lifecycle is the same.

The problem today

Most TPRM registers do not know which vendors share which data centre

The pattern: procurement runs a vendor register with 1,800 entries; security runs a separate vendor security questionnaire process; the operational resilience team maintains a third-party register for the regulator. None of the three are joined up, none capture fourth parties properly, and concentration risk (multiple critical vendors sharing the same hyperscaler region or the same payroll provider) is not visible at all. When an incident hits, the firm spends 48 hours discovering which of its services were affected.

The fix is structural: one TPRM lifecycle owned by the second line, one register of record, fourth parties tracked through to the relevant level, and each material relationship visualized as a BPMN process so the integration points are visible. That is the artefact CPS 230 reviewers and DORA-mandated registers actually want.

Four pillars

Four pieces of a working TPRM programme

Categorisation

Not every third party deserves the same depth of due diligence. Material / critical / important categorisation drives proportionate process - "material" maps closely to APRA CPS 230 and DORA terminology.

Due diligence

Financial, security, compliance, ESG, operational, and concentration risk. Sourced from vendor questionnaires, external attestations (SOC 2, ISO 27001, ISAE 3402), and ongoing monitoring services.

Contractual provisions

Regulator-required clauses (audit rights, sub-contracting, data location, exit assistance), service levels with tolerances aligned to operational resilience, and termination triggers.

Monitoring and exit

Ongoing performance monitoring, incident notification, change-control oversight, and a tested exit plan (not just a contract clause) for every material relationship.

Process Map

The TPRM lifecycle as a process map

The canonical lifecycle - identify, categorise, due-diligence, assess, contract, onboard, monitor, exit - with the risk-acceptance gateway that most diagrams treat as automatic.

Open in editor

Third-party risk management lifecycle as a process map

The TPRM lifecycle rendered as a BPMN 2.0 process. Identify the need for a third party, categorise (material vs non-material), perform due diligence, assess residual risk, contract, onboard, monitor on the agreed cadence, and exit through the planned offboarding flow.

Identify the need for a third party - the capability or service required.
Categorise the candidate (material vs non-material, criticality tier).
Run due diligence proportionate to the categorisation: financial, security, compliance, ESG, concentration.
Assess residual risk against the firm's risk appetite and any regulator-set obligations (CPS 230, DORA, OSFI B-10).
If residual risk exceeds appetite, escalate, mitigate, or decline. Otherwise contract.
Onboard, including operational integration and the agreed monitoring controls.
Monitor on the agreed cadence; trigger re-assessment on material change.
Exit through planned offboarding when the contract ends or the risk profile shifts.

What this diagram shows: The lifecycle starts when a need for a third party is identified - often through procurement, sometimes through engineering or business teams. Categorisation determines the depth of due diligence that follows. The residual-risk assessment compares due-diligence findings to the appetite; the gateway routes acceptable risks to contract-and-onboard and unacceptable risks to escalate-or-decline. Monitoring runs on the agreed cadence; planned offboarding closes the relationship cleanly, rather than the unplanned exits that drive most regulator concern.

FAQ

Frequently asked questions

What is third-party risk management?

Third-party risk management (TPRM) is the discipline of identifying, assessing, contracting, monitoring, and exiting relationships with external parties that provide goods or services to the firm. Modern TPRM covers security, compliance, financial, operational, ESG, concentration, and fourth-party (vendors of vendors) risk.

What is the difference between TPRM and vendor management?

Vendor management is the broader procurement-led discipline of managing supplier relationships (selection, contracting, performance, payment). TPRM is the risk-focused subset - it adds explicit security, compliance, and resilience risk assessment and ongoing monitoring. In small firms the two are the same function; in larger firms TPRM sits with the second-line risk function while vendor management stays with procurement.

What is fourth-party risk?

Fourth-party risk is the risk arising from your third parties' own third parties. Example: your payroll vendor uses a hyperscaler cloud region; an outage at that region affects your payroll even though you have no contract with the hyperscaler. Modern regulations (CPS 230, DORA) require firms to track fourth parties for material services - not just the immediate vendor.

Which regulations require TPRM?

Most financial-services regulators now have explicit TPRM requirements. APRA CPS 230 (Australia) requires a material service-provider register and ongoing arrangement monitoring. EU DORA (Regulation 2022/2554) requires an ICT third-party register, contractual provisions, and concentration analysis. OSFI Guideline B-10 / E-21 (Canada) covers third-party arrangements. The US OCC Bulletin 2023-17 covers federally-supervised banks. The terminology differs but the underlying lifecycle is the same.

How does process mapping fit into TPRM?

Process maps visualise the integration between your firm and a material third party - which step they execute, which data they touch, which downstream process depends on them. Without that diagram, "material service-provider arrangement" is an abstract category; with it, you can see what fails when the third party fails. The map also exposes fourth-party concentration (multiple maps share the same hyperscaler) that is invisible at the register level.

Does BA Copilot replace our TPRM platform?

No. BA Copilot is the modelling layer. It produces the BPMN process maps that show how each material third party integrates with the firm. Dedicated TPRM platforms (Prevalent, OneTrust, ProcessUnity, ServiceNow IRM) own the register, the questionnaire workflow, and the contractual evidence. BA Copilot integrates by exporting BPMN that the TPRM platform attaches to the vendor record.

Jack Finnegan, Founder & CEO, BA Copilot

From the founder

14 Years in BPMN

I'm Jack Finnegan. I've spent fourteen years working hands-on with BPMN, as an analyst, an engineer, and a product director, where I felt every sharp edge of legacy business process platforms.

BA Copilot is the platform I wanted on every one of these projects: AI-first process management, which treats BPMN as a first-class output rather than an export afterthought.

Jack Finnegan on LinkedIn

Sources

Sources and verification

Last verified 21 May 2026 by Jack Finnegan.

References cited on this page:

EU DORA (Reg. 2022/2554)
APRA CPS 230
OSFI Guideline B-10 (Third-Party Risk Management)
OCC Bulletin 2023-17 (Third-Party Risk Management)

Make third-party risk visible end-to-end

Open the TPRM lifecycle template, customise it to your categorisation scheme, and produce the BPMN maps that show how each material third party integrates with your firm.