Third-Party Risk Management (TPRM) Guide: Lifecycle

Most organisations now run critical processes on suppliers they assess once at signing and then stop watching, while those suppliers hold their data, their tokens and sometimes their administrator access. Third-party risk management (TPRM) is the discipline of knowing which suppliers matter, assessing them in proportion to that, writing security into the contract, and monitoring the relationship until the last credential is revoked at exit. Regulators now expect it: DORA requires a register of every ICT contract, NIS2 makes supply chain security a baseline measure, and US banking agencies issued joint life cycle guidance in June 2023. This guide covers the full TPRM life cycle, tiering, contract clauses, SaaS and OAuth integrations as third-party access, fourth parties and concentration risk, the regulatory drivers, and the metrics that show a programme works. It is written for TPRM, GRC, procurement and security teams building or repairing a programme.

Key takeaways

Tier before you assess. Assessment depth should follow inherent risk (data accessed, system access and business criticality), not contract value or the order in which procurement raises requests.
The life cycle does not end at signing. NIST CSF 2.0 GV.SC-07 expects supplier risk to be monitored "over the course of the relationship", and the US interagency guidance and DORA both treat termination and exit as stages to plan for.
Integrations are third-party access. OAuth tokens, API keys and connected apps held by a SaaS supplier can open your tenant as surely as a contractor's VPN account, and they rarely appear in the vendor inventory.
Look past the direct supplier. Fourth parties and concentration on a few cloud and SaaS providers create shared failure points that questionnaires on single suppliers will not reveal.
Contracts are your main lever after signing. Audit rights, breach notification timelines, subcontracting approval, data return and exit assistance must be agreed before the deal closes, not requested after an incident.

What TPRM covers and how it differs from procurement

A third party is any organisation whose relationship with you can affect your security, operations or compliance: suppliers, cloud and SaaS providers, managed service providers, outsourcers, contractors and partners. A fourth party is your supplier's supplier, and "nth party" extends the chain further. TPRM differs from procurement in purpose: procurement buys at a fair price, TPRM decides whether and how much risk the relationship introduces, then keeps checking.

Inherent risk: the risk the relationship carries before any controls, driven by what data the supplier touches, what access it has, and how critical the service is. Inherent risk sets the tier.
Residual risk: what remains after the supplier's controls, your own compensating controls and contract terms are taken into account. Residual risk is what a risk owner formally accepts.
Scope beyond cyber: mature programmes also cover financial viability, privacy, resilience, compliance and sanctions; security usually owns only the cyber assessment.

The US agencies put accountability bluntly: a banking organisation's use of third parties "does not diminish its responsibility to meet these requirements". DORA recital 64 says a financial entity "should at all times remain fully responsible for complying with its obligations". Outsourcing moves the work, not the accountability.

The TPRM life cycle

The Interagency Guidance on Third-Party Relationships: Risk Management (Federal Reserve Board, FDIC and OCC, issued 7 June 2023) describes "a continuous life cycle" of five stages: planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination. It replaced the agencies' earlier outsourcing and third-party guidance. Most programmes add inventory and onboarding as explicit stages.

Stage	Key activities	Output	CSF 2.0 outcome
Inventory and planning	Capture every supplier, including card spend, free SaaS and developer tools; record business owner, service, data and access	Supplier register with an owner for every row	GV.SC-04 "Suppliers are known and prioritized by criticality"
Tiering	Inherent risk questionnaire completed by the business owner; criticality and data classification	Tier and assessment depth	GV.SC-04, GV.SC-03
Due diligence	Proportionate assessment: assurance reports, questionnaire, evidence review, outside-in scan, financial and sanctions checks	Findings, residual risk rating, go or no-go	GV.SC-06 planning and due diligence before the relationship
Contracting	Security schedule, data protection terms, audit rights, notification timelines, subcontracting and exit clauses	Signed terms mapped to tier	GV.SC-05 requirements integrated into contracts
Onboarding	Provision access and integrations with least privilege; named supplier contacts; incident contacts exchanged	Access and integration records linked to the supplier	GV.SC-02 roles and responsibilities, GV.SC-08 incident planning
Ongoing monitoring	Reassessment by tier, assurance report renewal, findings tracking, outside-in monitoring, incident and news alerts, access reviews	Updated risk rating, remediation status	GV.SC-07 monitored "over the course of the relationship"
Offboarding	Revoke accounts, tokens, keys and network paths; confirm data return or deletion; execute exit plan	Closure record with deletion confirmation	GV.SC-10 activities "after the conclusion of a partnership or service agreement"

Inventory and tiering by criticality and data access

You cannot tier what you have not found. Build the inventory from accounts payable, contract management, corporate card spend, single sign-on application lists, OAuth consent grants in your identity provider and SaaS admin consoles, and proxy logs; each source finds suppliers the others miss.

Tier on three questions answered by the business owner: what data will they see, what access will they have, and what happens if they fail for a week. The interagency guidance describes critical activities as those that could cause significant risk if the third party fails, have significant customer impacts, or significantly affect financial condition or operations, and adds "It is up to each banking organization to identify its critical activities." The EBA outsourcing guidelines (para 29) use a similar test for "critical or important functions".

Tier	Typical profile	Assessment depth	Reassessment
1: Critical	Supports a critical function, holds sensitive data at scale, or has privileged or network access	Full questionnaire, SOC 2 Type 2 or ISO/IEC 27001 review with scope check, evidence sampling, pen test summary, exit plan	Annual, plus continuous monitoring and event-driven review
2: High	Personal or confidential data, or a standing integration with write scopes	Standard questionnaire plus assurance report review	Annual or every 18 months
3: Moderate	Limited internal data, read-only integration, replaceable service	Short questionnaire or trust centre review	Every two years
4: Low	No data, no access, commodity goods	Sanctions and basic financial check only	At renewal

Review the tier whenever the scope changes. A tier 3 marketing tool becomes tier 2 the day someone connects it to the CRM with a broad OAuth scope.

Due diligence: evidence over self-attestation

Independent assurance first: a SOC 2 Type 2 report or ISO/IEC 27001:2022 certificate answers more than most questionnaires, if you check scope, period end date, exceptions, carved-out subservice organisations and the user entity controls you must operate. See the SOC 2 Guide and the ISO 27001 Certification Guide.
Standard questionnaires second: accept SIG, CAIQ, HECVAT or VSA responses before writing your own, and add only targeted questions for gaps. See the Security Questionnaires Guide.
Verify, do not just collect: for tier 1, sample evidence (an MFA policy export, an access review record, an incident test report) and check outside-in signals such as exposed services and email authentication records, as prompts for questions rather than verdicts.
Ask about subcontractors: "Reliance on Subcontractors" is an interagency due diligence item; request the subprocessor list and processing locations.
Scope with NIST: NIST SP 800-161 Rev. 1 includes an SCRM assessment scoping questionnaire (Table 26), now also in a fillable version.

Contracting: security clauses that matter

The interagency guidance lists contract factors including "The Right To Audit and Require Remediation", "Responsibilities for Providing, Receiving, and Retaining Information", "Confidentiality and Integrity", "Operational Resilience and Business Continuity" and "Indemnification and Limits on Liability", and expects notification when the supplier changes its use of subcontractors. DORA Article 30 sets mandatory clauses for every ICT contract and extra ones for critical or important functions. A practical security schedule includes the following.

Clause	What to require	Driver
Security requirements	Named baseline (for example ISO/IEC 27001 certification maintained, MFA for all admin access, encryption in transit and at rest), with a duty to notify material control changes	CIS Safeguard 15.4; NIST SP 800-53 SA-9
Breach notification	Notice within a fixed number of hours of discovery (often 24 to 72), named contacts, cooperation with your investigation and regulatory reporting	DORA Art. 30; NIS2 reporting chain; GDPR Art. 33(2) for processors
Right to audit and assurance	Annual assurance report; audit or on-site assessment rights for tier 1; remediation of findings within agreed times	Interagency guidance; DORA Art. 30(3); EBA GL/2019/02
Subcontracting	Prior notice or approval of new subcontractors for critical services; flow-down of security terms; current subprocessor list	DORA Art. 30; GDPR Art. 28(2)
Data location and handling	Processing locations, segregation, retention and deletion periods	DORA Art. 30(2); GDPR Chapter V
Access and credentials	Named individual accounts only, MFA, least privilege, notice of leavers within one business day, no storage of your credentials outside approved vaults	NIST SP 800-53 SA-9, AC-2; see the Third-Party Access Guide
Exit and data return	Return in a usable format, certified deletion, transition assistance for an agreed period	DORA Art. 28(8) and 30(3); EBA GL/2019/02

Small buyers rarely get bespoke terms from large SaaS providers: record the gap against standard terms as residual risk and compensate with your own configuration, logging and access controls.

Where identity fits: SaaS, OAuth and supplier access

Many recent third-party breaches ran through tokens a supplier held for its customers, or through supplier staff whose accounts reached customer systems.

Integration tokens: Google Threat Intelligence Group reported that from 8 August 2025 an actor it tracks as UNC6395 used compromised OAuth tokens of the Salesloft Drift application to export data from many Salesforce instances, then searched it for AWS access keys, passwords and Snowflake tokens. Salesloft and Salesforce revoked all active access and refresh tokens on 20 August. See the Salesloft Drift breach, and the Gainsight Salesforce breach for a later case with the same pattern.
Contractor endpoints: in the Snowflake breach, Mandiant observed infostealer infections "on contractor systems that were also used for personal activities", and the affected accounts had no MFA, unrotated credentials and no network allow lists.
Support and help desk access: the Okta support system breach showed a supplier's own service account exposing customer data, and the Marks and Spencer cyberattack began with impersonation of a third-party user.

Treat each integration as a supplier relationship: register it, tier it on its OAuth scopes, give it an owner and an expiry, review it with other access, restrict scopes and source IPs, and prefer short-lived or federated credentials over static API keys. See the SaaS and OAuth App Governance Guide and the Third-Party Access Guide.

Continuous monitoring and offboarding

Scheduled reassessment: by tier, triggered from the register, with assurance report expiry tracked as a date field.
Event-driven review: a supplier breach, acquisition, new subprocessor or scope change should reopen the assessment.
Outside-in signals: external attack surface changes, leaked credentials for supplier domains and threat intelligence on supplier products, routed to the relationship owner with a deadline.
Access telemetry: alert on supplier logins or integration API calls from new countries, Tor, or bulk export patterns.
Offboarding: disable supplier accounts, revoke OAuth grants and API keys, remove network allow-list entries, rotate secrets the supplier saw, and certify data deletion. The Cloudflare breach shows the cost of credentials left unrotated after a supplier incident.

Fourth parties and concentration risk

Your tier 1 suppliers depend on their own cloud, identity, payment and support providers. When one of those fails or is breached, several of your suppliers can fail at once. The EBA outsourcing guidelines (para 25) call out "the concentration risk posed by outsourcing critical or important functions to a limited number of service providers", and para 66(a) asks firms to weigh "outsourcing to a dominant service provider that is not easily substitutable". DORA defines ICT concentration risk in Article 3(29) and requires a preliminary concentration assessment before contracting under Article 29. The interagency guidance flags "dependency on a single provider for multiple activities".

Map critical fourth parties only: ask tier 1 suppliers for the subcontractors behind your service.
Aggregate across suppliers: count how many critical services ultimately depend on the same cloud region, identity provider or payment processor.
Test substitutability: document how long a switch would take for each critical function.
Plan exits: keep tested exit plans for the most concentrated dependencies. See the Business Continuity and Disaster Recovery Guide.

Regulatory drivers and standards

Source	Who it applies to	What it asks of TPRM
DORA, Regulation (EU) 2022/2554, Articles 28 to 30	EU financial entities	Register of information on all ICT contracts (templates in Implementing Regulation (EU) 2024/2956), pre-contract assessment, concentration risk, mandatory contract clauses, exit strategies. See the DORA Guide.
NIS2, Directive (EU) 2022/2555, Article 21(2)(d) and 21(3)	Essential and important entities in the EU	Supply chain security including relationships with direct suppliers and service providers, taking account of each supplier's vulnerabilities and secure development practices; Article 22 coordinated risk assessments of critical supply chains. See the NIS2 Directive Guide.
EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02)	EU credit institutions, investment firms, payment and e-money institutions	Since 30 September 2019: outsourcing register (para 52), critical or important function test, concentration risk, contract and exit terms
US Interagency Guidance on Third-Party Relationships (June 2023)	US banking organisations supervised by the Federal Reserve, FDIC and OCC	Five-stage life cycle, critical activities, contract factors; "does not impose any new requirements" but sets supervisory expectations
NIST SP 800-161 Rev. 1	US federal agencies; widely used voluntarily	Cybersecurity supply chain risk management at enterprise, mission and business process, and operational levels; scoping questionnaire
ISO/IEC 27036 series	Any acquirer or supplier	Part 1 (2021) overview and concepts for acquirers and suppliers; further parts cover requirements, ICT supply chain and cloud services
NCSC supply chain security guidance	UK organisations (voluntary)	12 principles in four stages: understand the risks, establish control, check your arrangements, continuous improvement

How to implement a TPRM programme

Set policy and ownership: approve a policy defining tiers, assessment depth and risk acceptance authority; name a programme owner and, in larger organisations, a vendor risk committee for tier 1 decisions and exceptions.
Build the inventory: reconcile the sources above into one register; expect many SaaS and OAuth apps procurement never saw.
Tier the existing population: run the inherent risk questionnaire on every active supplier, starting with those that access production or sensitive data.
Pilot on one business unit: run the full life cycle for 20 to 30 suppliers, measure cycle time and tune tier thresholds. Keep the old process running in parallel until one cycle completes, so you can roll back without leaving suppliers unassessed.
Repaper contracts: add the security schedule to new contracts now and to tier 1 renewals first.
Connect identity data: link supplier accounts and integrations to register entries so that offboarding triggers revocation.
Add continuous monitoring: start outside-in monitoring and event triggers on tiers 1 and 2 with a triage path, then extend once false positives are understood.
Report and improve: report metrics quarterly and review the tiering model annually against incidents and near misses.

Decision guidance

Small organisations: a spreadsheet register, a one-page inherent risk form, SOC 2 or ISO/IEC 27001 evidence and a standard security schedule cover most needs; focus on the few suppliers holding customer data or admin access.
Large or regulated organisations: a dedicated platform pays off at a few hundred assessments a year or when a regulatory register such as DORA's is required; integrate it with procurement, contracts and the identity provider.
Questionnaire or evidence: prefer assurance reports and targeted evidence for mature suppliers; use full questionnaires where no independent assurance exists.
Outside-in ratings: useful for monitoring at scale and for prioritising tier 3 and 4 suppliers; insufficient alone for tier 1, because they cannot see internal controls.
Accept, mitigate or exit: when residual risk exceeds appetite, your own compensating controls (scoped tokens, network restrictions, customer-managed keys) are often faster than supplier remediation.

Measurement and framework mapping

Track a small set of metrics that show coverage, speed and follow-through:

Inventory coverage: percentage of suppliers found through spend, SSO and OAuth discovery that are in the register and tiered.
Assessment currency: percentage of tier 1 and 2 suppliers with an in-date assessment and assurance report.
Contract coverage: percentage of tier 1 contracts with audit, breach notification, subcontracting and exit clauses.
Remediation: median age of open supplier findings, and the number past their due date.
Offboarding completeness: percentage of exited suppliers with all accounts, tokens and keys revoked within five business days.
Cycle time: median days from request to risk decision, by tier.

Framework	Where TPRM sits
NIST CSF 2.0	GV.SC-01 to GV.SC-10 (Cybersecurity Supply Chain Risk Management); DE.CM for monitoring external service provider activity
NIST SP 800-53 Rev. 5	SR family (SR-3 supply chain controls and processes, SR-5 acquisition strategies, SR-6 supplier assessments and reviews, SR-8 notification agreements); SA-9 external system services
CIS Controls v8.1	Control 15 Service Provider Management: 15.1 inventory, 15.2 policy, 15.3 classify, 15.4 contract security requirements, 15.5 assess, 15.6 monitor, 15.7 securely decommission
ISO/IEC 27001:2022 Annex A	5.19 information security in supplier relationships, 5.20 within supplier agreements, 5.21 ICT supply chain, 5.22 monitoring, review and change management of supplier services, 5.23 use of cloud services

Common failure patterns

Assessing once, at signing: the file is never revisited while scope, ownership and subcontractors change.
Tiering on spend: a free or low-cost SaaS tool with a broad OAuth grant to your CRM or mailbox carries more risk than a large hardware contract, as the Salesloft Drift breach showed.
Integrations outside the register: OAuth apps approved by individual users or admins never reach TPRM, so nobody owns their scopes or expiry. See the Klue OAuth breach.
Reading the SOC 2 cover page only: the opinion is accepted without checking scope or exceptions.
Incomplete offboarding: supplier accounts and tokens survive the contract because no one links the exit to identity revocation.
Questionnaire fatigue: huge custom forms sent to every supplier produce copy-pasted answers, not better decisions.

Practitioner checklist

Build one supplier register from procurement, spend, SSO and OAuth consent data, with a business owner for every entry.
Tier every active supplier on data, access and criticality, and review the tier on any scope change.
Accept standard questionnaires and assurance reports before issuing custom ones, and read SOC 2 reports for scope and exceptions.
Add a security schedule with audit, breach notification, subcontracting, credential and exit terms to all tier 1 and 2 contracts.
Record every OAuth integration and API key held by a supplier, with scopes, owner and expiry.
Map fourth parties behind critical services and measure concentration on shared providers.
Trigger reassessment on supplier incidents, acquisitions and new subprocessors, not only on the calendar.
Revoke all supplier accounts, tokens and keys at exit and obtain written confirmation of data deletion.

Third-Party Risk Management (TPRM) Guide