Third-party risk management policy template

A third-party risk management policy that survives an audit.

A third-party risk management policy template is only useful if it makes decisions rather than describing intentions. This is the complete section-by-section outline we would expect to see in a policy that holds up under DORA, NIS2 or CPS 230 scrutiny — what each section must state, and the specific sentences auditors look for and usually cannot find.

Download it

This template is available as a Word document. The full section-by-section outline is on this page; the download is the editable version, with bracketed placeholders marking every decision your organisation has to make. Get it from the resource library, filed under Templates.

Policy, framework, procedure

Three words used interchangeably, which is why so many policies do the wrong job.

The policy states what the organisation requires and who is accountable. It is short, approved at a senior level, and changes rarely.
The framework describes how the requirement is met — the tiering model, the assessment approach, the control set.
The procedures are the step-by-step instructions people follow, and they change often.

The common failure is a twenty-page “policy” full of procedural detail. It goes out of date within a quarter, and because changing it needs board approval, it stays out of date. Keep the policy to what must be approved, and let the framework and procedures move underneath it.

The sections a policy needs

Twelve sections. If your policy is missing one of these, it is the one you will be asked about.

1. Purpose and scope
What the policy governs and what it excludes. State explicitly whether it covers intra-group entities, contractors and fourth parties, because those are the boundaries that get argued about later.
2. Definitions
What counts as a third party, what makes one critical, and what “material change” means. Vague definitions are how a supplier ends up untiered for two years.
3. Roles and accountability
Named roles, not departments. Who owns the relationship, who owns the risk decision, who may accept residual risk, and what the board sees. Regulators increasingly expect a person, not a function.
4. Risk appetite and acceptance thresholds
The most-skipped section, and the one that determines whether the programme functions. Without a stated threshold every finding escalates, nothing closes, and the register grows until people stop reading it.
5. Tiering model
The criteria that place a third party in each tier, written so that two people applying them independently reach the same answer. Tier on data, access and criticality — never on contract value.
6. Due diligence requirements by tier
What must be assessed before contracting, at what depth, for each tier — and what cannot be waived. See supplier risk management for how the assessment itself is run.
7. Contractual requirements
The clauses that must appear: right to audit, incident notification within a window that lets you meet your own regulatory deadlines, subcontractor disclosure, data location and return, and destruction at exit.
8. Ongoing monitoring
What is monitored between assessments, how often each tier is reassessed, and what events trigger an off-cycle review — a breach, an acquisition, a material change in external posture.
9. Issue and remediation management
How findings are raised, who owns them, the SLA by severity, escalation when a third party does not respond, and the consequences that actually apply.
10. Concentration and fourth-party risk
How concentration is identified and what the organisation does about it. This section barely existed five years ago and is now a standard regulatory question.
11. Offboarding
Access revocation, data return and destruction, evidence retained. Registers routinely contain suppliers who left years ago and still hold credentials.
12. Review, approval and record-keeping
Who approves the policy, how often it is reviewed, and where the evidence trail lives. Date and version it — an undated policy is an audit finding on its own.

A tiering model you can lift

Adapt the thresholds to your organisation, but keep the shape: tier on what a third party can reach and what breaks without it.

Tier	Typical criteria	Minimum treatment
Critical	Processes special-category or regulated data; privileged or production access; no viable short-term substitute	Full assessment with evidence, continuous monitoring, annual reassessment, exit plan, board visibility
High	Processes personal data at volume, or integrated access to core systems	Full assessment, continuous monitoring, reassessment on defined cadence
Medium	Limited data, no privileged access, replaceable within an acceptable window	Proportionate assessment, monitoring, periodic review
Low	No organisational data, no system access	Screening at onboarding, review on change only

Two rules worth writing into the policy alongside the table: tier is set on inherent risk before any assessment, and it is re-derived when the relationship changes rather than inherited from onboarding.

Mapping to the frameworks that will ask

Write the policy once, then show how it satisfies each regime.

NIS2 — Article 21(2)(d) requires measures covering each direct supplier and service provider, and Article 21(3) requires you to account for supplier-specific vulnerabilities and practices. Your tiering and monitoring sections carry this. See NIS2.
DORA — expects a register of information on ICT third-party arrangements, contractual provisions, concentration analysis and exit strategies. Sections 7, 10 and 11 are where those land. See DORA compliance.
ISO 27001 — supplier relationship controls map to sections 6, 7 and 8. See ISO 27001.
APRA CPS 230 — material service provider identification, and obligations around monitoring and exit. See APRA CPS 230.

Keep the mapping as an appendix rather than restructuring the policy around any one framework. Frameworks change; the underlying policy should not have to.

A template is a starting point

Adopting a template unchanged is worse than having no policy. An auditor’s first question is how the thresholds were set, and “they came with the template” is a poor answer. The sections above are the structure worth copying; the risk appetite, tiering thresholds and SLAs are decisions your organisation has to make and be able to justify.

Questions

The policy, answered.

What should a third-party risk management policy contain?

Purpose and scope, definitions, named accountability, risk appetite and acceptance thresholds, the tiering model, due diligence by tier, required contract clauses, ongoing monitoring, issue and remediation management, concentration and fourth-party risk, offboarding, and review and approval.

What is the difference between a TPRM policy and a TPRM framework?

The policy states what is required and who is accountable, and is approved at a senior level. The framework describes how that requirement is met — tiering, assessment method, control set. Keeping them separate is what stops the policy going stale, since the framework can change without a board approval cycle.

How often should the policy be reviewed?

Annually as a floor, and on material change — a new regulatory obligation, a significant incident, or a change in the operating model. Record the review date and the version, because an undated policy is a finding on its own.

Do we need a separate vendor risk assessment template?

The assessment questionnaire is a procedure document, not part of the policy. Keep them separate: the policy says a tier-one supplier requires a full assessment with evidence; the assessment template is the instrument that delivers it, and it will change far more often.

Keep reading

A policy is the easy part. Operating it isn’t.

Book a 30-minute call and we will show you the policy running as a live programme — tiering, assessment, monitoring and evidence, on your own suppliers.

Book a 30-min demo →Meet The Agency