Third-party risk programmes stall when procurement thinks security owns supplier risk, security thinks the business owner does, and the business owner thinks signing the contract was the end of it. This template is a ready RACI matrix for the full third-party lifecycle, from the decision to use a supplier to exit and data deletion, naming for each activity who is Responsible, who is Accountable, who is Consulted and who is Informed. It is built around the lifecycle that US banking regulators set out in their 2023 Interagency Guidance on Third-Party Relationships and the ownership duties that DORA places on financial entities, but it works for any sector. It is written for heads of procurement, TPRM leads, CISOs, risk managers and the business owners who hold supplier relationships. For the programme as a whole, see the Third-Party Risk Management Guide; for the general RACI method and the incident matrix, see the Security RACI Matrix Template.
How to use this template
- Replace placeholders: text in square brackets, such as [Organisation], [Head of Procurement] and [Risk Committee], is for your own role titles. Use roles, not names, in the matrix.
- Keep one A per row: every activity has exactly one Accountable role. Where you are tempted to write two, split the activity.
- Read the codes as: R = Responsible (does the work, can be several roles), A = Accountable (owns the outcome and signs off, one role), C = Consulted (two-way, before the decision), I = Informed (one-way, after the decision). A blank cell means no defined role for that activity.
- Scale by tier: the matrix assumes the four tiers produced by the Vendor Tiering and Inherent Risk Questionnaire Template. Where a row applies to some tiers only, the tier is stated.
- "Must" and "should": "must" is mandatory; "should" is recommended practice where a justified exception may apply.
1. Purpose and principles
1.1 This RACI defines who owns each activity in the management of risk from suppliers, service providers, outsourcers, cloud and SaaS providers, and other third parties that access [Organisation]'s data, systems or premises, or support its important business services.
1.2 Accountability for a third-party relationship stays with [Organisation]. Using a third party does not transfer accountability for the outcome; the US Interagency Guidance states that a banking organisation's use of third parties does not diminish its responsibility to meet legal requirements, and DORA Article 28(1)(a) says financial entities remain fully responsible for compliance with their obligations.
1.3 The business owner of the relationship is accountable for the risk it brings, within the risk appetite approved by [Board or Risk Committee]. The [TPRM team] runs the method; specialist functions advise; procurement controls the gate to contract.
1.4 Owner of this document: [Chief Risk Officer or Head of TPRM]. Approver: [Risk Committee]. Review at least every [12] months, after a reorganisation, after a significant supplier incident, and when a new regulation applies.
2. Roles
| Code | Role | Typical holder | Authority to note |
|---|---|---|---|
| BRD | Board or risk committee | [Board Risk Committee] | Approves policy and appetite; may approve or delegate approval of the highest-risk contracts |
| EXE | Senior manager for third-party risk | [Chief Risk Officer or COO] | Accepts residual risk above [threshold]; under DORA, the role monitoring ICT third-party arrangements |
| BO | Business owner | [Head of the function using the service] | Owns the need, the relationship and the residual risk |
| PRO | Procurement | [Head of Procurement] | Controls supplier onboarding and contract issue |
| TPRM | Third-party risk team | [TPRM lead], usually second line or in GRC | Owns the method, the inventory and the tier |
| SEC | Information security | [CISO or delegate] | Security assessment and security requirements |
| IAM | Identity and access | [IAM lead] | Supplier accounts, OAuth grants, API keys and service accounts |
| LEG | Legal | [General Counsel] | Contract terms, audit rights, liability |
| DPO | Data protection | [DPO] | Processor terms, transfers, privacy assessments |
| BCM | Business continuity | [BCM lead] | Criticality, exit plans, concentration |
| FIN | Finance | [Accounts payable lead] | Supplier master data and bank detail changes |
| IA | Internal audit | [Head of Internal Audit] | Independent review of the programme (third line) |
3. Planning and sourcing
| Activity | BRD | EXE | BO | PRO | TPRM | SEC | LEG | DPO | BCM |
|---|---|---|---|---|---|---|---|---|---|
| 3.1 Approve third-party risk policy and appetite | A | R | I | C | R | C | C | C | C |
| 3.2 Define the business need and data or access required | A/R | C | C | C | C | C | |||
| 3.3 Start the intake and tiering questionnaire | R | A | C | ||||||
| 3.4 Assign the inherent risk tier | C | I | A/R | C | C | C | |||
| 3.5 Decide if the service supports a critical or important function | I | R | C | A | |||||
| 3.6 Approve a Tier 1 engagement before sourcing continues | I | A | R | C | R | C | C |
4. Due diligence and selection
| Activity | EXE | BO | PRO | TPRM | SEC | IAM | LEG | DPO | BCM |
|---|---|---|---|---|---|---|---|---|---|
| 4.1 Scope due diligence by tier | I | C | A/R | C | C | C | |||
| 4.2 Security questionnaire and evidence review | I | A | R | C | |||||
| 4.3 Review assurance reports (SOC 2, ISO/IEC 27001 certificate scope) | A | R | |||||||
| 4.4 Review integration design: accounts, OAuth scopes, API keys, network paths | C | I | A | R | |||||
| 4.5 Privacy assessment, processor terms and transfers | C | I | C | C | A/R | ||||
| 4.6 Financial viability and sanctions screening | I | A/R | I | C | |||||
| 4.7 Resilience, concentration and fourth-party review (Tier 1 and 2) | C | R | C | A | |||||
| 4.8 Consolidate findings and recommend residual rating | C | I | A/R | C | C | C | C | ||
| 4.9 Accept residual risk within appetite | I | A | I | C | C | ||||
| 4.10 Accept residual risk above appetite | A | R | I | C | C |
Row 4.10 moves accountability to the senior manager (or to [Board Risk Committee] above [threshold], if your delegations say so): the business owner still presents the case, but cannot accept risk above appetite on their own. Record each acceptance with an expiry date, as described in the Security Exceptions and Risk Acceptance Guide.
5. Contracting and onboarding
| Activity | BO | PRO | TPRM | SEC | IAM | LEG | DPO | BCM | FIN |
|---|---|---|---|---|---|---|---|---|---|
| 5.1 Draft security schedule, incident notice period and audit rights | C | R | C | C | A | C | |||
| 5.2 Agree exit, data return and deletion terms | C | R | C | C | A | C | C | ||
| 5.3 Confirm no contract or purchase order without a recorded tier and residual rating | I | A/R | C | C | |||||
| 5.4 Sign the contract within delegated authority | A | R | I | C | I | ||||
| 5.5 Record supplier in the inventory and register of information | C | R | A | C | |||||
| 5.6 Provision supplier access with named owner and expiry | A | I | C | R | |||||
| 5.7 Verify and set up supplier bank details | I | C | A/R |
Contract wording for row 5.1 is in the Third-Party Security Contract Clauses Template. Row 5.7 exists because changes to supplier bank details are a common fraud route; see the Invoice Redirection and Supplier Bank Detail Fraud Guide.
6. Ongoing monitoring
| Activity | EXE | BO | PRO | TPRM | SEC | IAM | DPO | BCM | IA |
|---|---|---|---|---|---|---|---|---|---|
| 6.1 Periodic reassessment on the tier schedule | R | I | A/R | R | C | C | |||
| 6.2 Service performance and SLA reviews | A/R | C | I | C | |||||
| 6.3 Continuous monitoring alerts (ratings, breach news, certificate expiry) triage | I | A/R | C | ||||||
| 6.4 Review supplier access and integrations every [quarter] | A | I | C | R | |||||
| 6.5 Track remediation actions to closure | A | R | C | ||||||
| 6.6 Approve material change in scope, data or subcontractors | A | C | R | C | C | C | C | ||
| 6.7 Report third-party risk metrics to the board | A | I | C | R | C | C | I | ||
| 6.8 Independent review of the TPRM programme | I | I | C | A/R |
7. Supplier incidents
| Activity | EXE | BO | TPRM | SEC | IAM | LEG | DPO | BCM |
|---|---|---|---|---|---|---|---|---|
| 7.1 Receive supplier incident notice and open an internal incident | R | R | A | |||||
| 7.2 Revoke or rotate credentials and tokens held by the supplier | I | I | A | R | ||||
| 7.3 Assess notification duties to regulators and individuals | I | C | C | C | A | R | ||
| 7.4 Invoke continuity or workaround for a disrupted service | I | R | I | C | A | |||
| 7.5 Decide whether to suspend, reassess or exit after the incident | A | R | R | C | C | C | C |
Incident handling detail sits in the Incident Response RACI Template; this section covers only the hand-offs between the relationship owners and the incident team.
8. Termination and exit
| Activity | BO | PRO | TPRM | SEC | IAM | LEG | DPO | BCM | FIN |
|---|---|---|---|---|---|---|---|---|---|
| 8.1 Maintain and test the exit plan (critical or important services) | R | C | A | ||||||
| 8.2 Decide to terminate and serve notice | A | R | I | C | C | ||||
| 8.3 Remove all supplier accounts, OAuth grants, keys and network paths | I | I | C | A/R | |||||
| 8.4 Obtain data return and deletion confirmation | A | R | C | C | C | C | |||
| 8.5 Close supplier record, block payments and update the register | I | R | A | R |
For the full exit checklist, see the Vendor Offboarding and Termination Guide.
Implementation guidance
Rollout steps
- Map current reality first: walk [3 to 5] recent supplier onboardings and one recent exit, and record who actually did each step. The gaps between this and the matrix are your first findings.
- Agree the A column with executives: the accountable roles in sections 3 and 4 are the contentious ones. Settle them at [Risk Committee] before circulating the full matrix.
- Wire the gates into tools: make row 5.3 a hard control in the procurement or ERP workflow, so no purchase order can issue without a tier and residual rating in the inventory.
- Pilot on new Tier 1 and 2 suppliers for [one quarter], then apply to reassessments of existing suppliers by tier.
- Train business owners: most will not know they are accountable for residual risk and supplier access reviews. A short briefing and a one-page summary of their rows is enough.
- Review after the first supplier incident or after [12] months, whichever comes first, and adjust.
Choosing an operating model
| Model | Who holds the method | Fits | Watch for |
|---|---|---|---|
| Centralised TPRM team | Dedicated team in risk or GRC | Regulated and large organisations with many Tier 1 suppliers | Business owners treat TPRM as the risk owner; keep the BO accountable in rows 4.9 and 6.4 |
| Procurement-led | Procurement runs intake and coordinates specialists | Mid-sized organisations with strong sourcing processes | Commercial pressure to waive due diligence; give TPRM or SEC the right to block in row 3.6 |
| Federated | Each business unit, with central standards | Groups with autonomous divisions | Inconsistent tiering; keep the inventory and method central |
| Small organisation | One risk or security lead covering TPRM, SEC and DPO columns | Under [250] staff or few critical suppliers | Merge columns but keep BO accountability and the procurement gate; see Third Party Risk for Small Organisations |
Where identity fits
Most supplier compromises reach the customer through access the customer granted: shared accounts, OAuth applications with broad scopes, long-lived API keys and VPN accounts that outlive the contract. That is why the IAM column is Responsible in rows 4.4, 5.6, 6.4, 7.2 and 8.3, and why access reviews sit with the business owner rather than with procurement. See OWASP NHI Top 10 NHI3 Vulnerable Third-Party NHI Guide and Third-party NHI due diligence questions drawn from real breaches.
Measuring whether it works
- Percentage of active suppliers in the inventory with a tier, residual rating and named business owner.
- Number of contracts or purchase orders issued without a recorded tier (target zero).
- Percentage of Tier 1 and 2 reassessments completed on schedule.
- Percentage of supplier access reviews completed by business owners each quarter.
- Median days from supplier exit to confirmed removal of all access.
- Number of risk acceptances past their expiry date.
For board-level reporting, see Third-Party Risk KPIs and KRIs to Report to the Board.
Common failure patterns
- TPRM marked accountable for residual risk: the team that assesses the risk cannot also own it; the business owner must accept it within appetite.
- Procurement bypass: SaaS bought on corporate cards or free trials escapes row 3.3. Pair the RACI with expense and SSO discovery.
- No owner after signature: monitoring rows have no A, so reassessments lapse once the project that bought the service closes.
- Exit forgotten: access removal in row 8.3 has no owner, and supplier accounts and tokens stay live for months.
- Two A entries per row: joint accountability between security and procurement means each waits for the other.
Framework mapping
| Framework | Reference | Template section |
|---|---|---|
| NIST CSF 2.0 | GV.RR-02 (roles and authorities); GV.SC-02 (supplier roles and responsibilities); GV.SC-05 (requirements in contracts); GV.SC-06 (due diligence before relationships); GV.SC-07 (supplier risk assessed and monitored); GV.SC-08 (suppliers in incident activities); GV.SC-10 (provisions after partnership ends) | All |
| NIST SP 800-53 Rev. 5 | SR-1 Policy and Procedures; SR-3 Supply Chain Controls and Processes; SR-6 Supplier Assessments and Reviews; SA-9 External System Services | 3 to 6 |
| ISO/IEC 27001:2022 | Annex A 5.19 (supplier relationships); 5.20 (security in supplier agreements); 5.21 (ICT supply chain); 5.22 (monitoring and change of supplier services); 5.23 (cloud services) | 3 to 8 |
| DORA | Article 5(2) (management body approves and reviews ICT third-party policy); Article 28(2) strategy and policy; 28(3) register of information; 28(4) pre-contract assessment; 28(8) exit strategies | 3, 4, 5, 8 |
| US Interagency Guidance (2023) | Lifecycle: planning, due diligence and selection, contract negotiation, ongoing monitoring, termination; board oversight and management responsibilities | 3 to 8 |
For how these regimes compare, see the Third-Party Risk Regulatory Map and the DORA ICT Third-Party Risk and Register of Information Guide.
Standards and references
- Federal Reserve, FDIC and OCC: Interagency Guidance on Third-Party Relationships: Risk Management
- EUR-Lex: Regulation (EU) 2022/2554 (DORA)
- NIST: SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
This template summarises regulatory expectations for planning purposes and is not legal advice. Related NHI Mgmt Group resources: Vendor Tiering and Inherent Risk Questionnaire Template · Security RACI Matrix Template · Third-Party Risk Management Guide · TPRM Programme Health Check · Third-Party Risk Management Maturity Model