Third-Party Risk Management: A Practical Guide

Third-party risk management (TPRM) is the work of governing a relationship from planning through exit. A practical program defines the service and its risks, assesses providers before selection, puts appropriate protections in the contract, monitors the relationship as it changes, and prepares a workable termination or transition. The depth of that work should reflect the service’s importance, access, dependencies, and potential impact if it fails.

TPRM is not a one-time questionnaire or a single annual review. A questionnaire can help gather evidence, but decisions also need owners, documented reasoning, follow-up on material gaps, and a plan for change or exit. The U.S. banking agencies’ 2023 final guidance names the five lifecycle stages: planning, due diligence and selection, contract negotiation, ongoing monitoring, and termination. That guidance is banking-specific; it is not a universal law for every organization. Read the interagency guidance.

1. Set governance and define the scope

Start by deciding who owns the business relationship, who is responsible for assessing its risks, who can accept an exception, and how significant concerns reach senior management. Make the escalation path clear before an assessment produces a difficult finding.

Keep a usable inventory of relationships. A practical record might include:

Provider, service, internal business owner, and relevant risk owner.
Data handled and systems, facilities, or people the provider can access.
Service criticality, dependencies, subcontracting where known, and likely disruption effects.
Assessment status, material findings, decisions, and remediation owners.
Contract status, renewal or review dates, and planned end date or exit considerations.

This is a practical starting set of fields, not a regulator-mandated universal template. Adjust it to the organization, applicable requirements, and relationship. An inventory is useful only if owners keep it current and use it to prioritize work.

2. Plan before selecting a provider

Describe the business need and the outcome the service must deliver. Identify the data and systems involved, dependencies on the service, plausible disruption scenarios, affected customers or operations, and alternatives such as another provider, an internal capability, or stopping the activity.

Use that context to set the assessment depth and the monitoring you will need later. NIST’s cybersecurity supply-chain guidance supports a multilevel approach tailored to use case and criticality. It is a technical resource focused on cybersecurity supply-chain risk management (C-SCRM), not a universal TPRM law or an all-purpose vendor checklist. See NIST SP 800-161 Rev. 1 Update 1.

3. Assess risk and choose proportionate due diligence

Assess the relationship, not just the provider’s general reputation. A provider’s exposure depends on what it will do for you, what it can access, how difficult it would be to replace, and what could happen if its service becomes unavailable or unreliable. Use a risk-based tiering method if it helps allocate effort, but document what a tier means and who can approve exceptions. There is no single scoring model in the cited guidance that fits every organization.

Evidence to request

Tailor requests to the service and its risk. Possible evidence categories include:

Security governance and controls relevant to the service and the information it handles.
Resilience and continuity arrangements, including how the provider would communicate and recover from a disruption.
Incident handling and notification processes that support your response needs.
How the provider manages subcontractors and dependencies that matter to your service.
Assurance material or other evidence that can be checked against your required outcomes.
Operational or financial viability information where a failure in those areas could affect the relationship.

These are possible categories to tailor, not an exhaustive official checklist. Ask for evidence that answers a decision-relevant question. Record what was reviewed, limitations, material gaps, compensating measures, and the person who accepted any residual risk. Do not treat a questionnaire score by itself as completed oversight.

Compare candidates consistently

When choosing between providers, assess them against the same service-specific criteria: ability to meet required outcomes, relevant security and resilience evidence, data and system access, dependencies, likely effects of disruption, contract and assurance terms, viability concerns where relevant, and feasible transition options. Weight the criteria according to the relationship’s context; identical scores can conceal very different impacts.

4. Negotiate an agreement that supports the service

Carry material assessment findings into contract discussions. The agreement should fit the actual service, risks, and applicable law. Involve legal, procurement, security, business, and other appropriate owners early enough to resolve gaps before the relationship begins.

Depending on the relationship, discuss how the agreement will support:

The service scope, responsibilities, performance expectations, and how material changes are communicated.
Security, confidentiality, and handling of relevant information.
Incident notification and cooperation where the service could affect your response.
Appropriate assurance, evidence access, or review rights.
Subcontractor controls or visibility where dependencies affect the risk.
Remediation, service failure handling, continuity, and termination rights.
Data return or disposition, access removal, records, and transition assistance at exit.

These are topics to consider, not a universal contract clause list. Their wording and enforceability depend on the service, bargaining context, and applicable law. Resolve the practical question behind each term: if there is an incident, a material change, or an exit, how will the organization know what happened and keep its own obligations manageable?

5. Monitor the relationship as it changes

Set monitoring triggers and a review cadence based on the relationship’s risk and importance. The sources support risk-based management; they do not prescribe one annual review schedule for every provider.

Monitoring may include performance against service expectations, material changes in service or access, incidents, unresolved assessment findings, remediation progress, new dependencies, and updated assurance evidence. Track only what is relevant to the relationship and feasible to maintain. Assign an owner to review signals, decide whether they change the risk, and escalate deteriorating performance or unresolved issues.

Reassess when something meaningful changes, such as a new use of the service, expanded data access, a provider incident, a significant subcontractor change, repeated service failures, or a planned renewal. Record the change, its effect on the original assumptions, actions and deadlines, and the decision about continued use.

6. Plan for termination and transition

Plan exits early for important services, rather than waiting for a provider failure or contract expiry. Decide whether the activity will move to another provider, return in-house, or stop. Consider the operational, compliance, financial, and customer effects of transition. The Federal Reserve’s 2024 material explicitly identifies these impact areas. See the Federal Reserve’s third-party risk management material.

Make the plan concrete: identify decision owners, transition dependencies, access that must be removed, information and records to retrieve or dispose of, continuity measures, customer communications where relevant, and contractual duties. For a critical service, consider whether a transition is realistically executable with the resources and time available. Review the plan when dependencies or the service change.

7. Improve the program using evidence

Use assessment outcomes, incidents, service performance, and exit exercises to refine risk tiers, evidence requests, contract standards, and monitoring. Look for recurring gaps across relationships and decide whether the cause is a weak control, an unclear ownership model, or an unrealistic process. NIST describes C-SCRM as an integrated, multilevel program that includes strategy, plans, policies, and risk assessments. Its scope is cybersecurity supply-chain risk, which complements but does not replace broader TPRM.

A practical TPRM checklist

Scope: Identify the service, owner, data and system access, dependencies, and plausible disruption effects.
Plan: Set the required outcomes, assessment depth, approval path, and future monitoring needs before selection.
Assess: Request relevant evidence, document material gaps, and compare provider capabilities to service needs.
Decide: Record the selection rationale, risk acceptance, exceptions, and remediation owners.
Contract: Put workable service, oversight, incident, change, and exit arrangements into the agreement as appropriate.
Monitor: Track relevant performance, changes, findings, incidents, and dependencies with named owners.
Exit: Keep a feasible transition path and address continuity, access, information, records, and customer effects.
Improve: Use outcomes and exercises to update the program and its priorities.

Common mistakes and how to correct them

Mistake	Why it falls short	Practical correction
Using the same questionnaire for every provider	It can collect irrelevant evidence while missing the service’s real exposure.	Start from the use case, access, criticality, and disruption effects; tailor requests accordingly.
Equating a completed questionnaire with approval	Answers may be incomplete, unverified, or disconnected from a decision.	Review evidence, record gaps and limitations, assign remediation, and document the decision owner.
Reviewing every relationship on the same schedule	A fixed cadence ignores differences in importance and changes.	Set review triggers and frequency by risk, and reassess when material changes occur.
Leaving security and procurement to work in isolation	Assessment findings may never become workable contract terms or operating controls.	Connect business, risk, security, procurement, and legal owners through selection and contracting.
Planning exit only after a problem occurs	Data, operational dependencies, and customer effects can make an urgent transition impractical.	Define plausible exit paths early and revisit them as the service and dependencies change.
Treating a risk score as a universal truth	A score can hide assumptions and does not itself determine acceptable risk.	Show the underlying criteria, service context, evidence, material gaps, and approval rationale.

Regulatory and scope notes

The 2023 U.S. interagency final guidance is directed at banking organizations. The 2024 community-bank guide is voluntary and designed for community banks; it says material may be useful to banks of any size, while relevance depends on size, complexity, risk profile, and the relationship. Neither should be presented as a universal requirement for all organizations. Read the community-bank guide announcement.

A joint agency release in September 2026 describes proposed replacement guidance as principles-based and non-binding, and says the agencies plan to rescind existing guidance and replace it once guidance is finalized. The release gives a comment deadline as 60 days after Federal Register publication; do not derive a calendar deadline from the release alone. The proposal is not a final or effective rule. Read the joint agency release.

Or skip the browser setup

For a narrow evidence-gathering task such as capturing a publicly accessible provider page for internal review, a screenshot can preserve what was visible at a point in time. A screenshot does not establish that a provider meets a control, validate the underlying evidence, or replace assessment and approval. ScreenshotNeo is a website screenshot API and MCP server for developers made by Yorker Media. It can return a screenshot or PDF with one GET request; see the API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before capture; each of those steps can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, with response headers indicating the page verdict and billing status. Its MCP server provides screenshot, page information, and PDF capture tools for AI agents. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots.

Frequently asked questions

Is TPRM the same as cybersecurity supply-chain risk management?

No. TPRM covers the broader relationship lifecycle. C-SCRM focuses on cybersecurity risks in products and services across the supply chain. NIST SP 800-161 is a technical C-SCRM resource that can support the cybersecurity part of a broader program.

Does every third party need the same depth of assessment?

No. Tailor the work to the service, access, criticality, dependencies, and likely impact. Record the rationale so a lighter process is a deliberate decision rather than an undocumented exception.

Is an annual review enough?

There is no universal annual cadence in the cited materials. Set cadence and event-driven triggers according to relationship risk and importance, and revisit the assessment when material facts change.

Can a provider’s assurance report settle the assessment?

It can be useful evidence, but assess its scope and relevance to your service and required outcomes. Note any coverage gaps and determine whether additional evidence or controls are needed.

What is the most useful first step for a small program?

Establish a basic relationship inventory with named owners, service context, access, dependencies, and importance. That gives the organization a basis for deciding which relationships need deeper work first.