What is third-party risk management (TPRM)?

Third-party risk management (TPRM) is the ongoing process of identifying and addressing risks that outside organizations introduce to a business. It starts when a company first considers a supplier and continues through the entire relationship. A third-party risk assessment is one part of the process; TPRM also determines when to reassess a supplier, who resolves a finding, and how to safely end access.

Verizon's 2026 Data Breach Investigations Report says third parties were involved in 48% of the breaches it studied, a 60% increase over the previous report. A security incident is only one possible outcome. A supplier can also fail to deliver a critical service or create a regulatory problem the buying team did not anticipate.

Effective TPRM connects the risk review to the decision to use a supplier. That means finding potential issues early enough to change the purchase, then keeping the assessment current as the relationship changes.

What is third-party risk management?

Third-party risk management identifies, monitors, and mitigates risks posed by suppliers and other outside parties throughout the relationship. A TPRM program usually combines an inventory of third parties with rules for tiering, due diligence, approval, monitoring, and offboarding.

A third party might be a software provider handling customer information, a logistics partner carrying inventory, or a contractor with access to company systems. The risk depends on what the party does and the exposure it creates. A supplier with access to sensitive data might need a more in-depth security and privacy review. A sole-source provider of a critical component may need closer attention to financial health and continuity plans.

TPRM involves more than a questionnaire. A questionnaire may surface a weak control, but the team still has to decide whether to request remediation, accept the residual risk, change the contract, or choose another supplier. That decision also needs an owner and an expiration or reassessment date.

TPRM vs. vendor risk management and supply chain risk management

These terms overlap, and companies do not use them consistently. Vendor risk management (VRM) commonly refers to managing risks associated with contracted vendors. TPRM can include a wider set of outside parties, including service providers and business partners. Supply chain risk management (SCRM) focuses on dependencies in the supply chain, including the availability and integrity of goods or services.

Whichever label a company uses, every material relationship needs coverage. Procurement and risk teams should agree on a shared inventory, clear ownership, and a consistent trigger for reviews.

What is fourth-party risk?

A fourth party is an organization that one of your third parties relies on to deliver its service. A payroll provider, for example, may use a separate cloud hosting company. An outage or breach at that hosting company could affect you even though you have no direct contract with it.

Fourth-party oversight should be proportional. Directly assessing every fourth party is rarely practical, so focus on dependencies that could materially affect the engagement. For a critical supplier, ask which subcontractors are essential, what access they have, and how your supplier supervises them. Contract terms can require notice of material subcontractor changes or incidents.

Why does TPRM matter now?

Third-party relationships give companies access to expertise and capacity, but they also extend a company's exposure beyond its own controls. Verizon's 2026 breach findings show how often outside parties appear in investigated incidents. Each supplier's risk depends on its role, so the depth of each assessment should match the exposure that supplier creates.

The exposure is also operational. If a payment processor goes down, finance may be unable to settle transactions. If a sole-source manufacturer stops production, procurement may struggle to find an alternative. A TPRM program identifies those dependencies before an incident and gives teams a response plan.

Regulation adds obligations for some relationships. Requirements vary by industry and location, so the TPRM program should identify which obligations apply to each relationship rather than attach every framework to every supplier.

For example, financial institutions subject to the European Union's Digital Operational Resilience Act (DORA) may need specific information about technology service providers. Legal and compliance teams should set the relevant rules; procurement helps apply them when a supplier is first proposed.

How do AI vendors change third-party risk?

An AI supplier review should cover how the tool will be used and what could change after approval. A vendor may update the model behind a product, so the review should establish how the supplier communicates material changes and when your team needs to retest the tool. This applies to dedicated AI tools and to AI features added to software you already use.

At intake, ask what data the tool receives and whether the supplier may use it to train models. Identify any third-party model providers the service depends on, then review how those dependencies affect oversight. The contract should address data use and notice of material changes.

For uses covered by the EU AI Act, the organization deploying the system may also have its own obligations. Your assessment of the supplier is one part of documenting how those obligations are met.

The seven stages of the TPRM lifecycle

The TPRM lifecycle follows seven phases:

1. Discover and inventory. Record who the supplier is, what service it provides, who owns the relationship, and which business processes depend on it. Bring new suppliers into the inventory when an employee first requests them, rather than waiting for an invoice to reveal the relationship.
2. Tier by criticality. Determine how harmful a disruption or failure would be. Consider data access, operational dependence, and the availability of alternatives. A risk tier helps the team choose a proportionate review instead of imposing the same questionnaire on every purchase.
3. Assess and perform due diligence. Gather evidence suited to the risk tier. A security review might examine a System and Organization Controls (SOC) 2 report. A critical service review might examine continuity plans. Record the scope of the assessment and any unanswered questions.
4. Mitigate and decide. Assign each material finding to an owner. The team may require a corrective action, add a contract protection, accept a documented exception, or decline the supplier. A completed assessment should lead to a decision that procurement can see before approval.
5. Contract and onboard. Translate the agreed controls into the contract and confirm that required approvals are complete before access or payment begins. Set expectations for incident notification, subcontracting, and the handling of company data where relevant.
6. Monitor and reassess. Review the relationship when its scope changes, an assessment expires, or an incident occurs. A critical supplier may warrant scheduled checks. The review frequency should reflect risk rather than a single calendar rule for every vendor.
7. Offboard securely. Confirm the end of access and the disposition of company data. Record any surviving contractual duties and update the supplier inventory so an inactive relationship does not appear current.

These stages are all connected. If procurement can’t see that a finding remains open, a contract may advance before the organization has accepted the risk. If risk teams do not learn that the supplier's scope has expanded, an old assessment may be used for a materially different engagement. Zip's supplier risk maturity model provides a way to examine those handoffs in your own program.

Common TPRM challenges

Most TPRM problems show up between teams rather than inside a single questionnaire. The risk team may have an assessment record, while procurement has the request and finance has the payment record. When those records diverge, it's hard to determine which review applies to the supplier currently in use.

In its 2026 global TPRM survey, KPMG reports that 18% of surveyed organizations have fully integrated TPRM with enterprise risk management. Only 17% report the highest level of TPRM data quality. More than four in five organizations, in other words, still run supplier risk on records that are partly disconnected or not fully trusted.

The timing of intake is another common problem. An employee might choose a vendor and negotiate terms before asking security for a review. By the time the contract is ready to sign, that review can delay the purchase. Procurement orchestration connects intake to later purchasing steps so the right teams can assess a supplier while the choice is still open.

Finally, a TPRM program can put considerable effort into initial approval and then lose sight of the relationship. A new use of customer data or a change in subcontractors may alter the risk. Offboarding gets missed when no one tells security that a contract has ended. Clear relationship ownership and event-based reassessment make these changes visible.

How to build a TPRM program that works

A strong TPRM program gives each supplier a clear path from initial request through offboarding.

Assign ownership and create a shared supplier record

Start by defining who owns the program and who makes decisions about individual suppliers. A risk owner should set assessment criteria and escalation rules. Procurement needs to know when a request requires review, while the business owner remains accountable for how the supplier will be used.

Build a supplier inventory that procurement and risk teams can both rely on. Each record should identify the business owner, the service provided, and the supplier’s risk tier. Connect it to the relevant contract and assessment status. If your systems cannot automatically share updates, establish a clear source of truth for each field.

Tier suppliers when they are requested

Start tiering at intake, while the supplier choice is still open. Ask whether the supplier will handle sensitive data, support a critical service, or take part in a regulated activity. The answers determine which reviews the request needs. An intake-to-procure process can route those reviews before the purchase advances without subjecting every supplier to the same level of scrutiny.

Standardize reviews and document decisions

Use a consistent questionnaire and evidence set so reviewers can compare suppliers. Leave room to request more detail when a relationship presents unusual risks. Define which findings require remediation, who can approve an exception, and how the decision reaches procurement before approval.

Reassess suppliers and close out relationships

Set review triggers that match each supplier’s risk. Scheduled reassessment helps, but an incident or major scope change may require an earlier review. When the relationship ends, confirm access has been removed, and company data has been handled as agreed.

Periodically trace a recent supplier request through the program. The record should show who reviewed key findings, what they decided, and when the next review is due.

TPRM frameworks, standards, and regulations

Frameworks can provide a common vocabulary for assessing suppliers. They are not interchangeable with legal requirements, and none eliminates the need to understand the actual engagement.

What does TPRM software do?

TPRM software helps teams maintain supplier records, send assessments, track findings, and schedule follow-up. Some products focus on cyber monitoring, while others integrate assessment data with broader risk records. Procurement teams should evaluate how the software connects to the moment a supplier is requested and to the decisions that follow.

Ask a prospective vendor to demonstrate a single, realistic case during evaluation. Key questions to evaluate include:

• What information is gathered when a proposed supplier will handle customer data?
• Which specialist reviews are triggered automatically at intake?
• Can procurement see if a risk finding remains unresolved before proceeding?
• Does the reviewer have access to previous assessments and updated scope at contract renewal?

Integration is important here; a standalone assessment is useful only if its results reach the people who can act on them. An existing TPRM platform may already perform the specialist review well. In that case, connecting it to procurement may be more sensible than replacing it. Zip's comparison of supplier risk management software covers the range of available tools.

How Zip brings TPRM into procurement

Zip's Risk Orchestration connects supplier checks with the purchasing process. It includes risk scoring from multiple data sources, approval routing by risk level, a centralized supplier risk record, and scheduled reassessment. Searchable audit logs let teams reconstruct how a decision was made.

The starting point is the purchase or supplier request. Intake information can determine which specialists review the proposed engagement. Security can assess potential data risk, while procurement tracks the overall request. Supplier Onboarding is where teams collect supplier information as the relationship moves toward approval.

Zip also integrates with existing systems. If an organization has a dedicated TPRM or governance, risk, and compliance (GRC) platform, the practical question is how the two systems will exchange requests, assessment results, and later status changes. Confirm those details during evaluation.

Start the risk review when the supplier is proposed

TPRM works best as an ongoing program with a clear entry point. It helps an organization decide which third parties require deeper review, what to do with findings, and how to monitor a relationship after approval. Procurement has a crucial role because it often sees a proposed supplier before the relationship is established.

Begin by tracing one request. Check when the risk team first learned about the supplier and whether the assessment outcome could change the approval. Then follow the record through renewal and offboarding. The gaps you find will give you a practical plan for improving the program.

For a hands-on review, use Zip's global supplier risk checklist. If you are ready to connect checks with purchasing, book a demo to discuss your current process.

Frequently asked questions

What is the difference between TPRM and a third-party risk assessment?

TPRM is the full program for managing outside-party risk throughout a relationship. A third-party risk assessment is a specific evaluation within that program. TPRM determines when an assessment is needed, who acts on its findings, and what triggers another review.

What are the stages of the TPRM lifecycle?

A useful TPRM lifecycle has seven stages: discover and inventory, tier by criticality, perform due diligence, mitigate findings, contract and onboard, monitor and reassess, and offboard. Monitoring and remediation may repeat as the relationship changes.

Is vendor risk management the same as TPRM?

The terms often overlap. Vendor risk management usually focuses on vendors with a direct business relationship. TPRM can cover a broader set of outside parties. Organizations should define the scope of their own program, so material relationships do not fall between labels.

What is fourth-party risk?

Fourth-party risk comes from organizations that a third party depends on. A cloud provider used by your payroll vendor is one example. The relevant question is whether a failure at that provider could disrupt the service or expose your data, and how your direct supplier manages that dependency.

What percentage of breaches involve a third party?

In its 2026 Data Breach Investigations Report, Verizon says third parties were involved in 48% of the breaches it studied. The number reflects that report's dataset and definition of involvement. It is not a forecast for an individual company's suppliers.

Which frameworks are used for third-party risk management?

Organizations may draw on NIST SP 800-161 for cybersecurity supply chain risk, ISO/IEC 27036 for supplier security, and the SIG or CAIQ questionnaires for due diligence. The right combination depends on the supplier's role and applicable obligations.

What should procurement ask when evaluating TPRM software?

Ask when a review is triggered, which system owns the assessment, and whether the result can affect purchase approval. Then check what happens when the supplier's scope changes or a review expires. A demonstration using a real purchase scenario can reveal gaps that a feature checklist misses.

Does TPRM have to start in procurement?

No. Risk and security teams often own the program and perform specialist assessments. Procurement can provide an early trigger when a new supplier is requested and keep the result visible during approval. The ownership model should match the organization, but the teams need a dependable handoff.