Resource - Policy Guide
Third Party Risk Management Policy
Why the policy is the control that matters most
Assessments score individual vendors. The policy decides which vendors get assessed, how deeply, who owns the outcome and what happens when one fails. Every weakness in a third-party programme eventually traces back to something the policy left undefined.
A policy is what makes decisions defensible
Without a policy, every vendor decision is a judgement call by whoever happened to be in the room. With one, decisions trace back to an approved standard - which is precisely what auditors, regulators and boards ask you to demonstrate after an incident.
Most policies govern effort, not exposure
Typical policies mandate the same process for every third party. The result is uniform activity and uneven protection: heavy diligence on a marketing tool, thin oversight of the provider behind a payment flow. Tiering only works when it is driven by service criticality.
Fourth parties need explicit coverage
If the policy defines scope as parties you contract with, subcontracting chains fall outside it by construction. Operational-resilience regimes expect the opposite, so the definition of scope has to reach onward dependencies.
The components
Eight components of a defensible TPRM policy
Read them as a sequence. Purpose and scope establish the boundary, mapping and tiering set proportionality, and the remaining components apply controls across the lifecycle through to exit.
1. Purpose, principles and risk appetite
State what the policy exists to achieve and the risk appetite it enforces: which categories of third-party exposure the organisation will not accept, which it will accept with controls, and the outcomes the programme is accountable for. Without an appetite statement, tiering thresholds later in the policy have nothing to anchor to.
2. Scope and definitions
Define third party broadly enough to capture suppliers, outsourced service providers, cloud platforms, intra-group arrangements, agents and introducers - and state explicitly that material subcontractors and fourth parties are in scope for identification and concentration purposes. Name what is out of scope so the boundary is deliberate rather than accidental.
3. Governance, roles and reporting
Allocate accountability: the approving committee, the executive owner, the business service owners who own each dependency and its residual risk, procurement's onboarding gate, and the third-party risk function that maintains the standard and register. Specify what is reported, to whom and how often, including the escalation path for breaches of appetite.
4. Dependency mapping requirement
Mandate that every third-party relationship is recorded against the business services, processes and data flows it supports, and that the mapping is completed before tiering. This single clause is what turns the rest of the policy from generic process into proportionate governance. This is the Where. step.
5. Risk tiering and due diligence standards
Set the criteria that assign a tier - criticality of the supported service, data sensitivity, regulatory relevance, substitutability, concentration - and state the minimum due diligence each tier requires before contracting. Make clear that spend is not a tiering criterion, and that tier can be overridden upward with documented rationale.
6. Contracting and ongoing monitoring
Require the contractual provisions the organisation will not go without: audit and information rights, security and privacy schedules, subcontractor notification, service levels, and exit assistance. Define the monitoring obligation per tier - continuous for critical dependencies, scheduled reassessment for the rest - plus the trigger events that force an out-of-cycle review.
7. Incident, concentration and exit
Cover failure explicitly: incident notification expectations and internal roles, the requirement for documented contingency for every critical dependency, at least annual review of concentration across shared infrastructure and fourth parties, and the exit criteria, data-return and transition obligations that apply on termination.
8. Compliance, exceptions and review
Close with enforcement: how adherence is assured, what constitutes a breach, who may grant an exception and for how long, the register in which exceptions are recorded, and the review cycle and approver for the policy itself. An exception route that is documented is used properly; one that is absent is simply worked around.
From guide to document
Use these components as your section structure, then adapt appetite, tier thresholds and cadences to your regulatory mandate. Our vendor risk management policy template gives you drafted clause content to work from, and the readiness assessment benchmarks the programme the policy will govern.
The foundational principle
Start with Where.
A policy that mandates the same process for every third party is easy to write and impossible to run well. The mapping clause is what changes that: once each relationship is tied to the business service it supports, tiering, diligence and monitoring all become proportionate by construction.
Start with where. Then write the policy that governs it.
What a good policy achieves
The measure of the policy is not its length. It is whether someone new to the organisation could read it and correctly decide how much scrutiny a given third party deserves.
Frequently asked
What is a third party risk management policy?
A third party risk management policy is the board-approved document that defines how an organisation governs risk arising from the external parties it relies on. It sets scope and definitions, allocates accountability, establishes how third parties are tiered, and states the minimum due diligence, monitoring, incident and exit requirements for each tier.
What should a third party risk management policy include?
Eight components: purpose and risk appetite; scope and definitions including fourth parties; governance roles and committee reporting; the dependency mapping requirement; risk tiering criteria; tier-based due diligence standards; ongoing monitoring and review cadence; and incident, concentration and exit provisions. It should also state review frequency, exception handling and how compliance is assured.
Who owns the third party risk management policy?
The board or a delegated risk committee approves it. A named executive - typically the chief risk officer - owns it. Day-to-day execution splits between business service owners who own the dependency and its risk, procurement which controls onboarding, and a third-party risk function which maintains the standard, register and map.
How is a policy different from a standard or procedure?
The policy states principles and mandatory requirements and changes rarely. Standards set the measurable bar, for example what evidence a tier-1 vendor must supply. Procedures describe the operational steps someone follows. Keeping them separate means you can tune operational detail without returning to the board.
How often should the policy be reviewed?
Annually as a minimum, and out of cycle when the regulatory environment changes, after a material third-party incident, following a merger or significant outsourcing decision, or when internal audit raises a finding against it. Record the review date and approver in the document itself.
Start with Where.
A 45-minute executive review. We map one critical service with you and show you what your current programme is missing.