Third-Party Risk Management Maturity Model

Most third-party risk programmes measure how many questionnaires they sent, not how much supplier risk they actually reduced. Suppliers now hold customer data, run help desks, host critical platforms and connect to core systems through OAuth apps and integration tokens that nobody in procurement ever sees. This model applies the NHI Mgmt Group five levels (Ad hoc, Developing, Defined, Managed, Optimised) to third-party risk management (TPRM) across eight capability areas, using NIST SP 800-161 Rev. 1, NIST CSF 2.0 GV.SC, the June 2023 US interagency guidance and DORA as reference points. It is written for security, risk and procurement leads who need an honest baseline and a roadmap, and for executives who need to know what the next level buys.

Key takeaways

Five levels, eight areas. Score inventory, tiering, due diligence, contracts, monitoring, third-party NHIs, incident and exit, and governance separately; one average hides the weak spot.
Inventory comes before questionnaires. You cannot tier, assess or exit a supplier you do not know you have, and the 2023 interagency guidance treats a complete inventory as the basis of risk-based oversight.
Third-party NHIs are a dimension of their own. The Salesloft Drift and Gainsight incidents were supplier breaches delivered through OAuth tokens, not through anything a questionnaire asked about.
Level 3 (Defined) is the realistic first target. It means every supplier is known, tiered by criticality, assessed in proportion and bound by security clauses, with access you can revoke.
Exit is part of maturity. CSF 2.0 GV.SC-10 and DORA both expect plans for what happens when a relationship ends, including data return and credential revocation.

The five levels

Level	Name	What it looks like
1	Ad hoc	Suppliers are onboarded by whoever buys them. There is no single supplier list, security is asked about only for large contracts, and risk is discovered when a supplier has an incident. Integrations and OAuth apps are approved by individual users.
2	Developing	A TPRM owner exists and a standard questionnaire is used for new suppliers. An inventory is being built from procurement and finance data but misses shadow SaaS. Contracts include security clauses inconsistently. Reassessment rarely happens.
3	Defined	A policy and procedure cover the full life cycle: planning, due diligence, contracting, monitoring and termination. Every supplier is tiered by criticality and data access, assessment depth follows the tier, standard clauses cover breach notice, subcontractors, audit and data return, and third-party NHIs are inventoried with owners.
4	Managed	Monitoring is continuous for critical suppliers: control reports, external attack surface and breach intelligence feed a risk score. OAuth grants and integration tokens are scoped, time-limited and monitored. Metrics are reported to the risk committee and findings are tracked to closure.
5	Optimised	TPRM is integrated with enterprise risk, resilience and procurement. Concentration and fourth-party risk are modelled, exits are tested, supplier credentials are revoked automatically at contract end, and lessons from incidents change tiering and contract standards.

Capability areas

The table shows what Level 1, 3 and 5 look like in each area. Levels 2 and 4 sit between them: partial coverage of the Level 3 or Level 5 description.

Capability area	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Inventory	Supplier list exists only in accounts payable	Single register of suppliers, services, data held and systems connected, reconciled with procurement and SSO	Register updated automatically from procurement, SaaS discovery and contract systems; fourth parties recorded for critical suppliers
Tiering and criticality	All suppliers treated alike	Tiers based on data sensitivity, system access and support of critical activities	Tiers recalculated on change; concentration across suppliers modelled
Due diligence	Ad hoc questions for large deals	Assessment depth by tier: questionnaire, evidence (SOC 2, ISO/IEC 27001 certificate and scope) and remediation plans	Evidence reused from shared assessments, validated by testing or onsite review for the top tier
Contracts	Supplier paper accepted as is	Standard clauses: breach notice, subcontractor notice, right to audit, data return and destruction, security requirements	Clauses tied to tier, with service levels for notification and measurable security obligations
Ongoing monitoring	None after signature	Reassessment cycle by tier; findings tracked	Continuous signals (control reports, attack surface, breach news) with defined escalation thresholds
Third-party NHIs	Users consent to OAuth apps freely; vendor API keys in shared mailboxes	Admin consent workflow; every integration token, OAuth app and supplier service account has an owner, scope and expiry	Short-lived, IP-restricted tokens; per-integration API monitoring; automatic revocation on contract end or supplier breach
Incident and exit	No plan for supplier failure	Suppliers named in incident plans; exit plans for critical suppliers	Exit and substitution tested; credentials and data access withdrawn on a runbook
Governance and reporting	No owner	Policy approved; TPRM owner; regular reporting to management	Board-level oversight of critical relationships; independent review of the programme

Where the model maps to frameworks

Capability area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	Other references
Governance, policy	GV.SC-01, GV.SC-03, GV.SC-09	SR-1, SR-2	Interagency guidance: oversight and accountability
Inventory, tiering	GV.SC-04	SA-9	DORA register of information
Due diligence	GV.SC-06	SR-6, SA-4	ISO/IEC 27036-2
Contracts	GV.SC-05, GV.SC-02	SR-3, SR-8	ISO/IEC 27001:2022 A.5.20
Monitoring	GV.SC-07	SR-6, SA-9	ISO/IEC 27001:2022 A.5.22
Third-party NHIs	GV.SC-07	AC-20, SA-9	CIS Controls v8.1 Control 15
Incident and exit	GV.SC-08, GV.SC-10	SR-8	Interagency guidance: termination

Self-assessment questions

Score each area at the level that describes the whole estate today, not the best supplier. A control applied to the top 20 suppliers but not the rest is Level 2.

Inventory: could you list, within a day, every supplier that holds your customer data or connects to a production system?
Tiering: is there a written rule for what makes a supplier critical, and does it match the activities your business could not run without?
Due diligence: does a low-risk supplier get the same 300-question form as your cloud platform, or does depth follow the tier?
Contracts: how many critical contracts include breach notification within a defined period, subcontractor notice and data return on exit?
Monitoring: when did you last reassess your ten most critical suppliers, and what changed as a result?
Third-party NHIs: which OAuth apps and integrations hold read access to your CRM, mail or code, who approved them and when were their tokens issued?
Incident: if a supplier told you today that its token store was breached, could you revoke every credential it holds within hours?
Exit: for each critical supplier, is there a tested plan to move the service and confirm data destruction?
Governance: does the board, or a committee it designates, see the critical supplier list and approve those contracts?

Moving up: roadmap

From Ad hoc to Developing

Appoint a TPRM owner and agree the scope with procurement, legal and security.
Build a first inventory from accounts payable, contract records and SSO application lists.
Adopt one standard questionnaire for new suppliers; a recognised format saves suppliers and you time. See the Security Questionnaires Guide.
Turn off unrestricted user consent to third-party apps in your main identity provider and route requests to an admin consent workflow.

From Developing to Defined

Publish a TPRM policy covering the full life cycle the 2023 interagency guidance describes: planning, due diligence and selection, contract negotiation, ongoing monitoring and termination. See the Third-Party Risk Management Guide.
Define tiers and assessment depth per tier, then tier every existing supplier, starting with those that hold data or connect to systems.
Create a contract clause library and apply it at renewal. See the Vendor Security Assessment Template.
Inventory third-party NHIs: OAuth grants, integration tokens, supplier service accounts and API keys, each with an internal owner and expiry. See the SaaS and OAuth App Governance Guide.

From Defined to Managed

Add continuous monitoring for the top tier and set thresholds that trigger reassessment.
Restrict integration tokens by source IP range and scope, and alert on bulk exports per integration. The Gainsight Salesforce breach involved 285 OAuth tokens, some years old, that had never expired.
Name critical suppliers in incident plans and run a joint exercise with at least one of them.
Report metrics (below) to the risk committee each quarter.

From Managed to Optimised

Map concentration and fourth-party dependencies for critical services. See the Third-Party Concentration Risk Guide.
Test exit plans and automate credential revocation when a contract ends or a supplier reports a breach.
Commission an independent review of the programme and feed incident lessons back into tiers and clauses.

Metrics that show progress

Inventory coverage: share of suppliers with data or system access that are in the register and tiered.
Assessment currency: share of critical suppliers assessed within their tier's cycle.
Finding closure: median days to close high-risk supplier findings.
Contract coverage: share of critical contracts with breach notice, audit and data return clauses.
Third-party token hygiene: number of OAuth grants and integration tokens with no owner or older than your maximum lifetime.
Revocation time: hours from a supplier breach notice to all its credentials revoked.

Common failure patterns

Questionnaire theatre: large forms completed once at onboarding, never verified and never repeated.
Procurement-only inventory: free and card-paid SaaS, and OAuth apps users approved themselves, never appear. The Salesloft Drift breach reached Salesforce tenants through an integration's tokens, not a contract anyone reviewed for access.
Ignoring outsourced people processes: help desks and contractors that can reset credentials are a third-party attack path, as the Marks and Spencer cyberattack showed.
No exit: contracts end but supplier accounts, API keys and data copies remain.

Practitioner checklist

Score all eight capability areas separately and agree a target level per area with the risk owner.
Reconcile the supplier register with procurement, finance, SSO and SaaS discovery data.
Write down the criticality rule and tier every supplier that holds data or connects to systems.
Scale due diligence by tier and accept existing evidence where it is current and in scope.
Apply a standard security clause set at every new contract and renewal.
Inventory third-party OAuth apps, integration tokens and supplier service accounts with owners and expiry.
Name critical suppliers in incident response plans and keep a revocation runbook per supplier.
Maintain tested exit plans for critical suppliers, including data return and credential removal.
Report the six metrics quarterly and have the programme reviewed independently.

Third-Party Risk Management Maturity Model: Five Levels from Ad Hoc to Optimised