TPRM Lifecycle: 6 Phases of Third-Party Risk Management

Third-party risk management (TPRM) is the process of identifying, assessing, and controlling the risks your organization inherits from vendors, suppliers, and partners that touch your data, systems, or operations. A TPRM program runs every third party through a lifecycle of six phases: planning and tiering, due diligence, contracting, onboarding, ongoing monitoring, and offboarding, with risk reassessed throughout the relationship rather than once at signing. It matters because the supplier is now a common way in: 48 percent of breaches in Verizon's 2026 DBIR involved a third party, up from 30 percent the year before.

Attackers have learned that the easiest way into a hardened target is often through a weaker supplier, and single vendor compromises have cascaded into thousands of victim organizations at once. This guide walks through the TPRM lifecycle and process flow step by step, who owns each phase, how to assess and monitor vendors, the frameworks and regulations that shape the discipline, what a TPRM policy and maturity model look like, and the fourth-party risk most programs miss.

Updated: November 2026. Adds a TPRM process flow with owners and gates, a comparison of the 5-, 6- and 7-phase lifecycle models, a NIST CSF 2.0 (GV.SC) mapping, TPRM roles, policy, data-model and maturity guidance, and Verizon's 2026 DBIR data on how slowly third parties fix exposed cloud accounts. Still reflects the 48 percent third-party breach finding, the MOVEit supply-chain wave, NIST SP 800-161 (C-SCRM), and the EU DORA regulation now in force.

What is third-party risk management?

Third-party risk management (TPRM) is a structured program for handling the risk that comes with relying on outside parties. Any vendor that stores your data, connects to your network, or supports a critical business function introduces risk you do not fully control, and TPRM is how you bring that risk into view and keep it within tolerance.

A few related terms overlap:

• Vendor risk management (VRM) is often used interchangeably with TPRM, though TPRM is slightly broader, covering any third party, not only paid vendors.
• Supply chain risk management emphasizes the flow of goods, software, and services, and in cybersecurity is often called C-SCRM (Cybersecurity Supply Chain Risk Management).
• Fourth-party risk is the risk from your vendors' vendors, the parties you have no direct relationship with but still depend on.

The unifying idea is simple: your security is only as strong as the weakest partner with access to your data or systems.

Why third-party risk management matters now

Third-party breaches have moved from edge case to main event. The Verizon Data Breach Investigations Report shows a sharp multi-year rise in third-party involvement: about 15 percent in 2024, 30 percent in 2025, and 48 percent in 2026. That means nearly half of breaches in the latest report involved a third party. On cost, IBM's Cost of a Data Breach Report 2026 found that breaches starting with a supply chain compromise averaged USD 4.96 million, close to the USD 4.99 million global average; IBM's Cost of a Data Breach Report 2025 had found that breaches starting with third-party vendor or supply chain compromise averaged USD 4.91 million, second only to malicious insiders (USD 4.92 million) and above the USD 4.44 million global average.

The reason is structural. Modern businesses run on dozens or hundreds of interconnected vendors, and each integration is a potential path in. Two landmark incidents made the stakes obvious:

• SolarWinds (2020) showed how a compromised software update pushed to a trusted vendor's customers could hand attackers access to thousands of organizations, including government agencies, at once.
• MOVEit (2023) saw the Cl0p ransomware group exploit a single zero-day in a widely used file-transfer product, cascading into roughly 2,700 organizations and exposing the data of tens of millions of individuals. Our profile of the Cl0p ransomware group breaks down how that campaign worked.

These are not anomalies; they are the model attackers now follow. The full picture is in our third-party data breach statistics and vendor risk statistics roundups.

Types of third-party risk

TPRM is broader than cybersecurity, though cyber is the sharpest edge. A complete program considers:

• Cybersecurity risk — a vendor breach exposing your data or providing a path into your network.
• Compliance and regulatory risk — a third party's failure creating legal exposure for you under GDPR, HIPAA, or sector rules.
• Operational risk — a critical vendor outage disrupting your ability to operate.
• Financial risk — a vendor's instability or failure affecting your business.
• Reputational risk — a partner's misconduct or breach damaging your brand by association.
• Concentration and fourth-party risk — over-reliance on a single provider, or hidden dependence on a vendor's own suppliers.

The most damaging incidents usually combine several at once: a cyber breach at a critical vendor becomes an operational outage, a compliance failure, and a reputational hit simultaneously. A mature enterprise program may also account for geopolitical, geographic, strategic, ethical, or environmental risk where those factors are material to the relationship.

Who owns third-party risk management?

No single operating model fits every organization. TPRM often spans procurement, security, legal, privacy, compliance, business owners, and enterprise risk, so the important thing is not which team has the label but whether accountability is explicit.

Example TPRM RACI

R = Responsible, A = Accountable, C = Consulted, I = Informed.

TPRM roles and responsibilities

The RACI above shows who signs off. Day to day, each function carries a distinct job in a TPRM program:

• Board and senior management: approve the risk appetite and the TPRM policy, and receive regular reporting on critical vendors, open issues, and concentration risk.
• TPRM office or risk function: owns the methodology, inherent-risk scoring, the vendor inventory, exceptions, and program metrics.
• Business owner: requests the vendor, explains what data and access it needs, and accepts the residual risk of the relationship.
• Procurement: runs intake, makes sure no contract skips the program, and holds the contract record and renewal dates.
• Security: assesses controls, reviews evidence such as SOC 2 and penetration test reports, and watches for vendor incidents.
• Legal and privacy: negotiate security, data-protection, audit, and exit clauses, and track notification duties.
• Internal audit: tests independently whether the program runs the way the policy says it does.

US banking regulators describe the same split in the Interagency Guidance on Third-Party Relationships issued by the Federal Reserve, FDIC, and OCC in June 2023: the board of directors oversees third-party risk and holds management accountable, management builds and runs the policies and processes, and periodic independent reviews check that the program works as designed. Outside banking, the practical lesson is that each of those three layers needs a named owner.

The third-party risk management lifecycle

Illustrative grouping of the lifecycle; the text treats contracting and onboarding as separate phases and places reassessment within ongoing monitoring.

Effective programs manage each vendor through a repeatable lifecycle rather than a one-time check at signing. The stages below are a common six-phase model; smaller programs compress them, but the logic holds.

TPRM process flow at a glance

Read as a process flow, each phase has a trigger that starts it, an output it must produce, and a gate the vendor has to pass before moving on. A failed gate does not mean skipping ahead: it means remediating, formally accepting the risk with sign-off, or walking away.

The last column maps each phase to the Cybersecurity Supply Chain Risk Management (GV.SC) category in the Govern function of the NIST Cybersecurity Framework 2.0. Its ten outcomes run from knowing suppliers and prioritizing them by criticality (GV.SC-04) to planning for what happens after a partnership ends (GV.SC-10), and NIST's C-SCRM quick-start guide (SP 1305) turns them into first steps for smaller teams.

1. Planning and vendor tiering

Before onboarding, define the relationship and assess inherent risk: what data and access will this vendor have, and how critical are they? Tier vendors by that risk so a payroll processor with access to employee data gets far more scrutiny than a supplier of office snacks. Tiering is what makes the rest of the program scalable, because it focuses effort where the risk actually is.

2. Due diligence and risk assessment

Assess the vendor's security posture before you commit. This is where questionnaires, attestations, and ratings come in (covered in the next section). The depth of due diligence should match the vendor's tier: a critical vendor with access to sensitive data warrants deep review, including evidence, while a low-risk vendor may need only a light-touch check.

3. Contracting

Bake security and accountability into the contract. Strong agreements specify security requirements, data-handling obligations, breach-notification timelines, a right to audit, compliance expectations, and, importantly, an exit strategy. The contract is your main lever for holding a vendor accountable, so what is not written down is hard to enforce later.

Security clauses to put in vendor contracts

For critical vendors, consider making the following explicit:

• breach-notification timelines;
• right-to-audit or assurance rights;
• required security testing or evidence;
• encryption and access-control expectations;
• subprocessor and fourth-party disclosure;
• data-location and cross-border handling terms;
• incident-cooperation duties;
• business-continuity and recovery expectations;
• data return or deletion at termination;
• exit assistance and transition obligations.

4. Onboarding

Bring the vendor into your environment with least-privilege access, documented data flows, and the controls the assessment identified. Onboarding is where the agreed controls actually get implemented, and where a clean inventory of what the vendor can touch is established.

5. Ongoing monitoring

Risk is not static, so assessment cannot be a one-time event. Continuously monitor for changes in the vendor's posture, new vulnerabilities, breaches, security-rating drops, or shifts in the services they provide, and re-assess critical vendors on a defined cadence. Public signals such as a vendor's breach notices, status page updates, and subprocessor lists can be checked daily with web scraping tools, so the team learns of a change within a day of it being published. Continuous monitoring is the phase most programs underinvest in, and it is where real-world risk actually changes.

Monitoring matters because vendors fix exposures slowly. In the Verizon 2026 DBIR, only 23 percent of third-party organizations fully remediated missing or weak multifactor authentication on their cloud accounts, and for weak passwords and permission misconfigurations it took almost eight months to resolve half of the findings. Outside-in signals from attack surface management can show when a critical vendor exposes something new, but each alert still needs an owner and a deadline.

6. Offboarding

When the relationship ends, close it out deliberately: revoke access, disconnect integrations, retrieve or confirm destruction of your data, and formally settle remaining obligations. A forgotten vendor account with lingering access is a classic breach vector, so offboarding is a security control, not just paperwork.

5, 6, or 7 phases? How TPRM lifecycle models compare

Search for the TPRM lifecycle and you will find five, six, and seven phases. The work is the same; the models differ in where they draw the lines.

Pick the model that matches how your teams hand work to each other, then keep it consistent in the policy, the tooling, and the reporting. If you are a US bank or work for one, align your phase names with the Interagency Guidance so examiners can follow the trail. If you are an EU financial entity, map the same phases to the DORA ICT third-party requirements covered in our guide to DORA testing and TLPT.

Inherent risk vs residual risk

TPRM works best when it separates the risk a vendor creates before controls from the risk that remains after controls.

• Inherent risk is the exposure created by the relationship itself: the data involved, level of access, criticality of the service, geographic factors, and operational dependence.
• Residual risk is what remains after controls such as encryption, MFA, network restrictions, contractual safeguards, monitoring, and independent assurance are considered.

For example, a cloud payroll provider storing employee identity data may begin as High inherent risk. After strong encryption, MFA, restricted access, current assurance evidence, and contractual controls are validated, the residual risk may fall to Moderate. The final decision should be based on residual risk, not inherent risk alone.

How to assess a vendor's security

Several methods exist, and mature programs combine them rather than relying on any single one.

The strongest signal is independent evidence. A completed questionnaire is a starting point; a current SOC 2 report or a recent penetration test report shows the vendor's controls were actually examined by an outside party. This cuts both ways: your own customers increasingly demand the same evidence from you, which is why many companies commission a pentest specifically to satisfy their clients' third-party risk reviews.

Frameworks and regulations that shape TPRM

You do not have to invent a program from scratch. Several standards and regulations define what good looks like.

For regulated organizations, especially EU financial firms under DORA, third-party risk management is now a legal requirement with specific, auditable outcomes, not just good practice.

What a TPRM policy should include

A TPRM policy is the short, approved document that turns the lifecycle into rules people must follow. Procedures and templates can live elsewhere; the policy itself should answer these questions:

• Scope: which third parties are covered, including free SaaS tools, contractors, and affiliates.
• Risk appetite and tiering: the criteria that make a vendor critical, high, moderate, or low risk.
• Roles and decision rights: who can approve a vendor, who can accept residual risk, and who can grant an exception.
• Minimum due diligence per tier: the evidence each tier must provide, such as a SOC 2 report, ISO 27001 certificate, or recent penetration test.
• Required contract clauses: breach notification, right to audit, subprocessor disclosure, data return, and exit terms.
• Monitoring and reassessment cadence: how often each tier is reviewed, and which events trigger an early review.
• Issue management and exceptions: how findings are tracked, how long remediation can take, and how exceptions expire.
• Incident and offboarding duties: how a vendor breach feeds your incident response plan and how access and data are closed out.
• Reporting and review: what the board sees, how often, and when the policy itself is reviewed.

Keep the policy short enough that procurement and business owners will actually read it. If customers already ask you for evidence during their own vendor reviews, the same tiering logic helps you decide which assurance to publish, as our guide to SOC 2 penetration testing explains.

What to automate in TPRM

Automation helps the program scale, but it should remove repetitive work rather than automate final risk judgment.

Good candidates for automation include:

• vendor intake and inventory updates;
• inherent-risk scoring and tier assignment;
• questionnaire routing;
• evidence-expiry reminders;
• reassessment scheduling;
• breach and security-rating alerts;
• remediation ticket creation;
• reporting and dashboard updates;
• offboarding reminders.

Keep human review for exceptions, final risk acceptance, material contract decisions, and complex evidence interpretation. Automation should accelerate the workflow, not replace accountability.

Vendor inventory fields: a simple TPRM data model

Automation and reporting only work if the vendor inventory holds consistent data. The Interagency Guidance treats a current inventory that flags higher-risk and critical relationships as core documentation. Whether you use a spreadsheet, a GRC tool, or a dedicated TPRM platform, these are the field groups most programs need:

Start with the fields you will actually maintain. A smaller inventory that is complete and current is more useful than a large schema full of blanks.

Metrics that show a TPRM program is working

Measure the program so you can prove it works and find where it does not. The metrics that matter:

• Vendor inventory coverage — the share of your actual third parties captured and tiered, versus the shadow vendors still invisible to the program.
• Assessment completion and timeliness — how many critical vendors have a current, in-date assessment rather than a stale one.
• Time to onboard — how long due diligence takes, which balances speed against thoroughness.
• Concentration exposure — how many critical functions depend on a single vendor or a shared upstream provider.
• Issue remediation — when a vendor assessment surfaces a gap, how quickly it gets resolved or risk-accepted with sign-off.
• Fourth-party visibility — the share of critical vendors whose key subcontractors you actually know.

Trend these over time. A maturing program shows rising coverage, shrinking assessment backlogs, and better-understood concentration risk.

A simple TPRM maturity model

Maturity models help you decide what to fix next. There is no single official TPRM maturity scale, so treat the four levels below as a practical DeepStrike checklist rather than a standard:

Most organizations sit at level 1 or 2 for most of their vendors. Moving critical vendors to level 3 usually delivers more risk reduction than polishing the whole portfolio at once.

The role of penetration testing in third-party risk

Penetration testing sits on both sides of the third-party relationship, which is what makes it uniquely useful here.

Looking outward at your vendors, a recent, well-scoped pentest report is some of the strongest evidence a critical vendor can provide that its defenses were actually tested by an independent party, far stronger than a self-completed questionnaire. Asking data-rich vendors for their latest test results, and the scope behind them, is a practical way to move due diligence from self-attestation toward evidence.

Looking inward, your own customers are running the same playbook on you. As third-party risk reviews become standard in enterprise procurement, more organizations commission a penetration test specifically to satisfy their customers' TPRM and vendor-assessment requirements. A recent independent pentest can reduce due-diligence friction by giving customers evidence that key controls were actively tested. In that sense, being a well-tested vendor can support procurement confidence in a market where everyone is assessing everyone else.

When a vendor is breached

A mature TPRM program should connect directly to incident response. When a critical vendor reports a breach:

1. Identify the affected service, data, and business processes.
2. Activate contractual notification and cooperation clauses.
3. Reduce or suspend access where containment requires it.
4. Obtain the vendor's timeline, indicators of compromise, and current assessment.
5. Hunt internally for downstream compromise or misuse of trusted access.
6. Assess fourth-party exposure and shared upstream dependencies.
7. Determine legal, regulatory, contractual, and customer-notification duties.
8. Track the vendor's remediation and compensating controls.
9. Reassess residual risk after the incident.
10. Decide whether to continue, restrict, or exit the relationship.

The Conduent breach shows how long notice can take when the breach sits at a vendor.

Do not forget fourth-party risk

Your vendors have vendors, and their weaknesses can reach you. Fourth-party (and beyond, "Nth-party") risk is the dependence you inherit through your direct suppliers, and it is largely invisible unless you go looking. The MOVEit incident is the textbook case: many victim organizations had no direct relationship with the file-transfer product at all; they were exposed because a vendor, or a vendor's vendor, used it.

You cannot assess every party in the chain, but you can require your critical vendors to demonstrate their own third-party risk management, ask about their key subcontractors, and factor concentration risk, many of your vendors depending on the same upstream provider, into your planning. NIST SP 800-161 explicitly extends to this deeper supply chain for exactly this reason.

Common third-party risk management challenges

TPRM is conceptually straightforward and operationally hard. The obstacles most programs hit:

• Scale. Large organizations depend on hundreds or thousands of vendors, and assessing every one to the same depth is impossible. Without risk-based tiering, teams either burn out trying or assess nothing meaningfully.
• Questionnaire fatigue and self-reported data. Security questionnaires are the backbone of most programs, yet they are self-reported, often out of date, and answered by people incentivized to look good. They are a starting point, not proof.
• Point-in-time blindness. A vendor assessed as secure at signing can be breached, acquired, or degraded a year later. Programs that assess once and forget miss exactly the moment risk changes.
• Fourth-party invisibility. Most organizations cannot see past their direct vendors into the subcontractors those vendors rely on, which is where incidents like MOVEit did their damage. Our supply chain attack statistics show how far these dependencies reach.
• Shadow procurement. Business units sign up SaaS tools without security review, creating vendor relationships the TPRM program never sees.
• Resource constraints. TPRM is labor-intensive, and small teams struggle to keep pace with onboarding volume, reassessments, and monitoring at once.

Recognizing these limits is what pushes programs toward tiering, continuous monitoring, and independent evidence rather than questionnaire checkboxes.

Building a TPRM program: where to start

If you are maturing a program, a workable path looks like this:

Start with an inventory and tiering. You cannot manage third-party risk you cannot see. Build a complete vendor inventory, including the shadow SaaS, then tier each vendor by the data and access it holds. This single step focuses everything that follows.

Standardize assessment by tier. Define what due diligence each tier requires, deep evidence review for critical vendors, lighter checks for low-risk ones, so effort scales with risk instead of treating every vendor the same. Lean on independent evidence like SOC 2 and pentest reports over self-assessment where the stakes are high.

Operationalize monitoring. Move from one-time assessments to continuous oversight of your critical vendors, watching for breaches, posture changes, and new exposures, with a defined cadence for reassessment. This is where a program stops being a procurement gate and becomes real risk management.

Tie it to the business. Connect TPRM to incident response, so a vendor breach triggers your own playbook, and to procurement, so no critical vendor is onboarded without review. The cost of getting this wrong is measured in real dollars; IBM's 2025 breach research put third-party and supply-chain compromise among the most expensive root causes, and the broader cost of a data breach climbs when a third party is involved.

Maturity is incremental. An inventory with basic tiering already puts you ahead of most organizations; continuous monitoring of critical vendors is what separates a strong program from a compliance exercise.

Best practices for a strong TPRM program

• Tier by risk and focus effort there. Deep due diligence for critical, data-rich vendors; light-touch for low-risk ones.
• Make monitoring continuous. A signing-day assessment tells you nothing about the vendor's posture a year later.
• Put security in the contract. Breach notification, right to audit, data handling, and exit terms are your enforcement levers.
• Demand independent evidence. Prefer SOC 2 reports, ISO 27001 certificates, and recent pentest reports over self-reported questionnaires alone.
• Own offboarding. Revoke access and confirm data destruction the moment a relationship ends.
• Map critical dependencies. Know your concentration and fourth-party exposure before an incident reveals it for you.

The bottom line

Third-party risk management has become one of the highest-leverage disciplines in security because the attack path so often runs through a supplier rather than your own perimeter. With nearly half of breaches now involving a third party and single-vendor compromises cascading into thousands of victims, a signing-day questionnaire is not enough. Run every vendor through a real lifecycle, tier by risk, assess with independent evidence, monitor continuously, and account for the fourth parties hiding behind your direct suppliers. The regulations, from DORA to NIST 800-161, are converging on exactly that expectation.

Your vendors connect to you through VPN accounts, SSO trust, SaaS integrations, and API keys, and those access paths deserve the same scrutiny as the vendors themselves. As part of a TPRM program, DeepStrike penetration testing can validate whether a compromised third party could actually use that access to reach your critical systems and data. If you want an independent view of your third-party exposure, contact DeepStrike to scope a test.

Frequently asked questions

What is third-party risk management in simple terms?

It is how an organization manages the risk created by the outside companies it depends on, vendors, suppliers, and partners that touch its data, systems, or operations. TPRM identifies those parties, assesses how risky each one is, sets controls and contract terms, and monitors them over time so a weakness at a supplier does not become a breach at your company.

What is the difference between TPRM and vendor risk management?

The terms are often used interchangeably. Vendor risk management (VRM) focuses on paid vendors, while third-party risk management is slightly broader, covering any third party you rely on, including partners and non-vendor relationships. In practice most programs treat them as the same discipline.

What are the stages of the TPRM lifecycle?

A common model has six phases: planning and vendor tiering, due diligence and risk assessment, contracting, onboarding, ongoing monitoring, and offboarding. The key idea is that risk management continues throughout the relationship, not just at signing, with the depth of effort matched to how critical and data-rich each vendor is.

What is fourth-party risk?

Fourth-party risk is the risk you inherit from your vendors' vendors, the subcontractors and suppliers your direct third parties depend on. You have no direct relationship with them, which makes the risk hard to see, but it is real: many MOVEit victims were exposed through a vendor's use of the software rather than their own. NIST SP 800-161 specifically addresses this deeper supply chain.

Which frameworks and regulations apply to third-party risk?

Key frameworks include NIST SP 800-161 (cybersecurity supply-chain risk), NIST SP 800-53 and the NIST CSF, and ISO/IEC 27036. On the regulatory side, the EU's DORA (in force since January 2025) mandates specific third-party risk practices for financial firms, and GDPR, HIPAA, and various sector rules impose obligations to manage third parties that handle your data.

What is a vendor security questionnaire (SIG or CAIQ)?

A vendor security questionnaire is a standardized set of questions sent to a third party to evaluate its security controls. The most common are the SIG (Standardized Information Gathering) questionnaire from Shared Assessments and the CAIQ from the Cloud Security Alliance. They give a structured, comparable view of a vendor's posture, but because they are self-reported, mature programs pair them with independent evidence such as SOC 2 reports, ISO 27001 certificates, and recent penetration test results.

What are the 5 phases of third-party risk management?

The five-phase model used in the 2023 US Interagency Guidance is planning, due diligence and third-party selection, contract negotiation, ongoing monitoring, and termination. Six-phase models, like the one in this guide, split out onboarding; seven-phase models usually split vendor inventory and risk assessment into steps of their own. All of them cover the same work.

What is the difference between TPRM and GRC?

Governance, risk, and compliance (GRC) is the umbrella for how an organization sets policy, manages enterprise risk, and proves compliance. TPRM is one discipline within it, focused on the risk that comes from vendors, suppliers, and partners. Many teams run TPRM inside a GRC platform, but the TPRM lifecycle, inventory, and vendor evidence are specific to third parties.

What should a TPRM policy include?

A TPRM policy should define which third parties are in scope, the risk appetite and tiering criteria, roles and decision rights, minimum due diligence per tier, required contract clauses, monitoring and reassessment cadence, issue and exception handling, incident and offboarding duties, and board reporting. Keep it short and put templates and step-by-step procedures in supporting documents.