What is third-party risk management? A 2026 primer

Third-party risk management (TPRM) is the discipline of measuring, and continuously re-measuring, the risk an organisation inherits from the outside companies it depends on. Your cloud host, your payments processor, your KYC vendor and your IT support firm all sit inside your attack surface. TPRM is how you put a defensible number on that, keep it current, and act on it.

This primer covers the three numbers a serious program runs on, the order in which you compute them, and the common mistakes that make an assessment look thorough while actually proving very little.

The three numbers

Every mature TPRM program reduces to three quantities, computed in this order:

• Inherent risk (criticality): how much damage this vendor could do if it failed or was breached, independent of any controls. It is a property of what the vendor does for you, not how well they do it.
• Control maturity: how well the vendor actually mitigates that risk, derived from a questionnaire and the evidence behind it.
• Residual risk: what is left after controls. Inherent risk moved up or down by control maturity, then clamped so the result stays defensible.

Inherent risk comes first, and that order matters

A common and costly mistake is to send every vendor the same questionnaire and infer risk from the answers. Regulators expect the opposite. Rate criticality first, from dimensions such as operational impact, data sensitivity, regulatory exposure, financial exposure and lock-in. Those combine into a tier (Low, Medium, High or Critical) before a single control question is asked.

The tier then decides how deep the questionnaire goes. A critical payments vendor is probed for demonstrated effectiveness across many domains; a low-criticality advisory firm answers a short, policy-level set. Rating first is what lets you justify, to a vendor or an auditor, why one vendor got 140 questions and another got 25.

Control maturity is a score, not a checkbox

Pass/fail questionnaires throw away information. A control that technically 'exists' can be a one-line policy nobody follows or a fully monitored, independently audited capability, and pass/fail cannot tell them apart. Maturity scoring rates each control on a 0 to 5 scale, from 'absent' to 'independently assured and continuously improved', and weights the answer by how much assurance the question demanded.

Aggregate those weighted answers and you get a 0 to 100 control-maturity score, per security domain. The per-domain breakdown is as valuable as the headline number: it tells you a vendor is strong on access control but weak on business continuity, which is exactly the kind of finding that drives a remediation plan.

Evidence is what separates assurance from paperwork

A questionnaire on its own is a set of claims. Assurance comes from evidence. The efficient pattern is answer-driven: a vendor that claims a control exists must substantiate it, so evidence is requested only for the controls actually in play. A 'No' is an admitted gap with nothing to prove, and a certification the vendor holds is requested as a report rather than re-interrogated question by question.

Crucially, each piece of evidence should be reviewed against the specific control it is meant to support, not merely filed. A penetration-test report is read for open critical findings and their remediation status; an attestation is checked for currency and scope. Uploading a document is not the same as evidencing a control.

Residual risk is a matrix, not a feeling

Residual risk is the inherent tier shifted by the control-maturity band. Strong, evidenced controls pull a vendor down the tier ladder; weak or absent controls push it up. Two clamps make the result defensible: a low-impact vendor can never become Critical no matter how bad its controls, and a Critical vendor with weak controls stays Critical no matter how much paperwork it produces. Below a minimum coverage threshold, residual risk simply equals inherent risk, because you have not learned enough to move it.

Why it never ends

Vendors change, certifications expire and new frameworks land. TPRM is continuous, not a point-in-time audit. Scores should recompute whenever an answer or a piece of evidence changes, so the number on the board pack is today's number rather than last year's snapshot. A program that cannot re-grade a vendor the moment its SOC 2 expires is measuring history, not risk.