Third-party risk management framework

A third-party risk management framework, and how to actually build one.

A third-party risk management framework is the set of standing decisions that stop every supplier assessment being argued from first principles: what counts as a third party, how they are tiered, what evidence you accept, who can say no, and what triggers a fresh look. It is not a policy document and not a questionnaire. This page sets out the eight components a framework has to define, which external standard to anchor to and why, a build sequence you can run in order, a maturity model for grading what you already have, and how the whole thing maps onto DORA, NIS2 and the UK operational resilience rules.

Last reviewed 24 August 2026 by Darren Craig

What a TPRM framework is, and what it is not

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

A TPRM framework is the operating model. It is the layer between the policy — which states intent and gets board approval — and the procedures, which tell a named person what to do on a Tuesday. The framework is what makes those procedures consistent: it holds the definitions, the tiers, the thresholds, the evidence standards and the decision rights that every procedure then references.

Policy — what the organisation commits to and who owns it. Short, approved, rarely changed. Ours is set out at third-party risk management policy template.
Framework — how the commitment is operationalised. Scope, tiers, risk appetite, evidence standards, cadence, roles, metrics, escalation. Changes when the business or the regulation changes.
Procedure — the steps for a specific task. How to onboard a supplier, how to run a reassessment, how to offboard. Changes whenever the tooling does.

The failure this distinction prevents is the common one: a fifteen-page policy that reads well at board level and gives an analyst nothing actionable, sitting alongside procedures that were written by whoever had the tooling open and contradict each other. If two analysts assessing similar suppliers can reasonably reach different conclusions, the gap is in the framework, not in the analysts.

The second thing a framework is not: a questionnaire. A question set is an evidence instrument. It tells you what a supplier says about itself. The framework is what decides which suppliers get that questionnaire, what a given answer is worth against independent evidence, and what happens when the answer is unacceptable.

Which standard to anchor to

Anchoring to a recognised standard buys defensibility — you are answering to a published control set rather than to your own judgement. None of them will run your programme for you.

Standard	What it covers	Anchor to it when
ISO/IEC 27036	Information security for supplier relationships, in four parts: overview, requirements, guidance for ICT supply chain, and cloud services	You want a supplier-relationship standard specifically, and you are already in the ISO family
ISO/IEC 27001:2022, A.5.19–A.5.23	Supplier relationships, security in supplier agreements, ICT supply chain, monitoring supplier services, cloud services	You are certified or certifying, and the framework has to survive the same audit
NIST SP 800-161 Rev. 1	Cybersecurity supply chain risk management practices for systems and organisations — the most detailed of the set	You need depth, you have engineering appetite, or a US customer or contract points at it
NIST CSF 2.0, GV.SC	The supply chain category inside the Govern function — ten outcomes, deliberately outcome-worded rather than prescriptive	You want a light, board-legible spine that maps outward to almost everything else
A sector rulebook	DORA, NIS2, the UK operational resilience regime, APRA CPS 230 — obligations rather than a control framework	One of them applies to you. Then it is not a choice, and the standards above become how you evidence it

Pick one primary anchor and map the rest to it. Programmes that try to be natively compliant with four standards at once end up with a control set nobody can hold in their head, which is the condition under which people quietly stop using it.

The eight components a framework must define

If your framework does not answer all eight of these in writing, the answers are being improvised per supplier — which is the definition of a programme that cannot be audited and does not scale.

1. Scope — what counts as a third party
Software vendors, hosting and cloud, contractors, resellers, professional services, the payroll bureau, the confidential waste firm, the cleaning contractor with out-of-hours building access. State the boundary explicitly and state what is excluded and why. Ambiguity at this line is where coverage quietly fails, and it is the first thing an assessor probes.
2. Tiers — how many, and what puts a supplier in each
Tier on data sensitivity, access level and substitutability, not on invoice value. The mismatch between spend and risk is where most surprises live: the £4,000-a-year tool with an API key into your CRM outranks the £400,000 facilities contract. Each tier must oblige something concrete — assessment depth, approval level, monitoring frequency, contract terms.
3. Risk appetite — what is acceptable, and what is a stop
What you will accept as-is, what needs compensating controls and a deadline, and what is a refusal. If nothing is ever a refusal, the programme is advisory and everyone in procurement already knows it. Write at least one condition that stops a deal, and name who can overrule it.
4. Evidence standards — what counts, and how it is validated
A questionnaire response, a SOC 2 Type II, an ISO 27001 certificate with its statement of applicability, a penetration test summary, external security ratings, a trust portal. State what each is worth, what its expiry is, and — the part usually missing — how it is corroborated rather than filed. An unvalidated questionnaire is a record of what a supplier was willing to type.
5. Cadence and triggers — scheduled and event-driven
Reassessment intervals by tier, plus the events that force one early: a breach, an acquisition or change of control, a material change of service or subprocessor, a sustained rating drop, entry into administration. Triggers are the half that regulators mean by “ongoing” and the half most frameworks omit.
6. Roles and decision rights — named, not committees
Who owns the relationship, who performs the assessment, who accepts residual risk, who can override a stop, and who is accountable to the board. Name roles. A framework that assigns a decision to “the risk committee” has assigned it to nobody available on the day it is needed.
7. Contractual minimums by tier
The clauses that must appear before signature: security obligations, breach notification with a stated deadline, audit and inspection rights, subcontractor disclosure and change control, data location and return, service levels, exit assistance. Framework work, not legal work — legal drafts the wording, the framework decides which tier gets which clause and who may waive it.
8. Metrics and reporting — in outcomes, not activity
Inventory coverage, proportion of critical suppliers with current validated evidence, time from a supplier issue arising to detection, time to remediation, exceptions open and who accepted them. “Assessments completed this quarter” measures the team’s workload, not the organisation’s exposure, and a board that is shown it will ask the wrong questions for years.

Building it: the third-party risk management process sequence matters

The sequence matters. Most rebuilds fail because they start at step four — buying a question set — before anyone has agreed what is in scope.

Build the inventory first, and accept that it is wrong
Pull from accounts payable, the CRM, SSO and identity logs, expense claims and cloud spend. Every one of these is partial, and the union of them is still incomplete — shadow IT and departmental purchases sit outside all of them. Publish a first-pass inventory anyway. A wrong list that people can correct beats a perfect list that never ships.
Define scope and tiers before assessing anything
Components 1 and 2 above. This is the step that determines how much work the whole programme is, so it is worth arguing about properly, once. Tier the inventory you just built — quickly and roughly at first, on data, access and substitutability.
Agree risk appetite with the people who will be overruled by it
Procurement, legal and the business owners who will hit the stop conditions. Appetite agreed by security alone gets renegotiated in the first live deal and then has no force afterwards.
Set evidence standards, then choose the question set
In that order. Standardised sets — SIG, CAIQ or a trimmed internal set — are instruments serving the standard, not substitutes for it. See SIG and CAIQ for what the common sets cover.
Write the contractual minimums into templates now
Retrofitting audit rights and breach-notification deadlines into a live contract costs a renewal cycle and considerable goodwill. Getting them into the standard template costs one conversation with legal.
Assess the critical tier properly, and only the critical tier
Depth proportional to exposure means the top tier gets full assessment with validated evidence and a named security contact. Working alphabetically through four hundred suppliers is the single most reliable way to spend a year and finish with nothing defensible.
Turn on continuous monitoring before you finish assessing
Monitoring is not the last step, it is the one that makes the assessments hold their value. Outside-in ratings, breach and dark-web signal and public-record change give you the between-assessments picture that annual review cannot. See security ratings.
Wire findings to owners, deadlines and escalation
A finding with no owner and no date is a note. This is the step at which a framework becomes a programme: every gap produces an action, an accountable name, a deadline and a defined consequence for missing it.
Report outcomes, then review the framework against them
Run the metrics from component 8 for two quarters, then revisit the framework itself. Tiers almost always need adjusting after real data arrives — usually because the critical tier was drawn too wide to be affordable.

A maturity model for grading what you already have

Most organisations asking this question already have something. This is a way to say honestly which level it is at, and what the next level actually requires.

Level	What it looks like	What moves you up
1 — Reactive	A supplier list in a spreadsheet. Assessments happen when procurement remembers or a customer asks. No tiers, no appetite, no triggers.	Define scope and tiers, and publish an inventory with an owner against each critical entry
2 — Defined	A written framework and a standard questionnaire. Onboarding is consistent. Nothing systematic happens between assessments, and evidence is filed rather than validated.	Evidence validation against independent sources, and continuous monitoring on the critical tier
3 — Managed	Tiered assessment, validated evidence, continuous monitoring, findings tracked to owners and deadlines. Reporting is in outcomes. Event triggers are defined and fire.	Fourth-party visibility, concentration risk assessed across the portfolio, exit plans tested rather than written
4 — Optimised	Coverage across the full estate rather than the top tier. Supply-chain dependencies mapped beyond direct suppliers. Regulatory reporting generated from live data.	Holding it there as the estate grows — which is a capacity problem, not a method problem

The jump from 2 to 3 is where most programmes stall, and it is rarely a knowledge gap. It is arithmetic: validating evidence and monitoring continuously across a few hundred suppliers is more work than a team of two or three can do by hand, whatever the framework says.

Mapping the framework to what will be asked of it

Different rulebooks, largely the same underlying demands.

A framework earns its keep when a regulator, an auditor or a large customer asks how you manage supplier risk and you can answer from one document rather than assembling one. For UK and EU organisations, four regimes account for most of the asking.

DORA. For EU financial entities, the ICT third-party pillar is prescriptive in a way the standards are not: a register of information covering every ICT contractual arrangement, specified contract provisions, pre-contractual due diligence, concentration risk assessment and documented exit strategies. Your framework’s components 1, 4, 7 and 8 have to reach that bar specifically — set out in full at DORA third-party risk management.
NIS2. Article 21 makes supply chain security an explicit management obligation for in-scope entities in the EU, and reaches UK suppliers indirectly through their EU customers’ contracts and questionnaires rather than directly. NIS2 explained covers who is in scope and what the UK position actually is.
UK operational resilience. The FCA and PRA regime turns on important business services, impact tolerances and mapping the dependencies — including third parties — that support them. PRA SS2/21 sets supervisory expectations on outsourcing and third-party risk, and the critical third parties regime extends direct oversight to designated providers serving the sector. Your tiering has to be reconcilable with your important business services, which is a stricter test than tiering on data sensitivity alone.
ISO 27001. A.5.19 to A.5.23 are where a certification audit meets this framework. The gap auditors find most often is A.5.22 — monitoring, review and change management of supplier services — because it is the control that annual reassessment cannot satisfy.

Read together they converge on four demands, and building to those is more durable than building to any single rulebook: a complete, risk-ranked inventory; diligence proportionate to risk and evidenced before commitment; genuinely ongoing monitoring; and governance with named accountability and records that show the process ran.

Framework self-assessment twelve questions

Twelve questions. Answer them against your current framework in writing — if an answer takes more than a sentence or cannot be found in a document, that is the finding.

Can you state what counts as a third party, and what is excluded?
And does the exclusion list have a reason against each entry rather than an omission?
Is your inventory reconciled against accounts payable in the last quarter?
An inventory nobody reconciles is a snapshot of the day it was built.
Do your tier definitions turn on data, access and substitutability?
Rather than on spend, contract value or who shouted loudest.
Is there a written condition under which a supplier is refused?
And has it ever been applied? If not, the appetite statement is decorative.
Does each evidence type have a stated worth and an expiry?
A SOC 2 Type II covering a period that ended fourteen months ago is not current evidence, and a framework should say so before an auditor does.
Is any supplier answer validated against independent evidence?
External scanning, public records, breach history. If not, every assessment rests on self-attestation.
Are event triggers defined, and has one fired in the last year?
Defined triggers that never fire usually mean nothing is watching for the events.
Do you know what changed at your critical suppliers since the last review?
This is the question an examiner or a large customer asks, and the one annual reassessment structurally cannot answer.
Is residual risk accepted by a named individual with authority?
Not a committee, and not the analyst who found it.
Do contracts at each tier carry the minimum clauses your framework requires?
Sample five live critical contracts. The result is usually instructive.
Do you know which of your suppliers depend on the same fourth parties?
Concentration risk is invisible at supplier level and obvious one layer down. See supply chain risk.
Does your board reporting contain a single outcome metric?
Coverage, detection time or remediation time. If every number is an activity count, the board cannot tell whether exposure is rising or falling.

Where good frameworks break

Almost never on method. The frameworks that fail in practice are usually well written. They break on capacity: a team of three cannot validate evidence and monitor continuously across four hundred suppliers, so the framework’s requirements quietly become aspirational and the programme reverts to an annual documentation exercise that satisfies nobody. Before adding a control, check whether the existing ones are actually being run — and if they are not, the honest options are to narrow scope, add people, or automate the parts that are mechanical.

FAQ

Framework questions.

What is a third-party risk management framework?

The set of standing decisions that make supplier risk assessment consistent and repeatable: what counts as a third party, how suppliers are tiered, what evidence is accepted and how it is validated, who holds which decision rights, what reassessment cadence and triggers apply, what contract terms each tier requires, and how the programme reports. It sits between the policy, which states intent, and the procedures, which describe individual tasks.

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

The policy states what the organisation commits to and is approved at board level. The framework says how that commitment is operationalised — tiers, thresholds, evidence standards, decision rights. A policy without a framework produces inconsistent assessments; a framework without a policy has no authority behind it when someone wants an exception.

Which standard should a TPRM framework be based on?

ISO/IEC 27036, ISO 27001:2022 A.5.19–A.5.23, NIST SP 800-161 Rev. 1 and the NIST CSF 2.0 GV.SC category are all defensible anchors, and a sector rulebook such as DORA may settle the question for you. Pick one primary anchor and map the others to it rather than trying to be natively compliant with several at once.

How long does it take to build a TPRM framework?

The framework document itself is a few weeks of work for someone who knows the organisation. Getting an accurate inventory and genuine agreement on risk appetite is the part that takes months, and it is the part that determines whether the framework is used or filed.

Is a framework the same as a vendor risk management framework?

In practice the terms are used interchangeably. Vendor risk management usually refers to parties you buy from, while third-party risk management is broader and covers any external dependency including non-purchased relationships. The components are the same either way.

How often should the framework itself be reviewed?

Annually as a floor, and whenever something changes it materially: a new regulatory obligation, a significant change in the supplier estate, a merger, or an incident that the framework failed to anticipate. Reviewing it against your own outcome metrics after two quarters of real data is more useful than reviewing it on a date.

Keep reading

A framework is only as good as the capacity behind it.

Book a 30-minute call and we will run one of your critical suppliers through the framework above — tiering, outside-in evidence and the gaps a questionnaire would have missed.

Book a 30-min demo →See the TPRM guide