Skip to main content
green gradient background, "The Future of Application Security Is Already Here." and a read the report button.
Category: Third-Party & Vendor

Third-Party Risk Management

Also known as: TPRM, Third-Party Risk Management (TPRM), Vendor Risk Management, Supplier Risk Management
Simply put

Third-Party Risk Management (TPRM) is the practice of identifying and reducing the risks that arise when an organization relies on outside vendors, suppliers, or partners. It covers evaluating those external parties and putting measures in place to limit the harm they could pose to the organization's data, operations, or finances. It is an ongoing activity rather than a one-time check.

Formal definition

Third-Party Risk Management (TPRM) is a discipline within an organization's broader risk management program focused on the continuous identification, assessment, and mitigation of risks introduced by third parties such as vendors, suppliers, and partners, including those integrated into the organization's IT infrastructure. It typically addresses risks to data, operations, and finances and is commonly treated as part of an organization's cybersecurity and governance, risk, and compliance (GRC) posture. TPRM is generally structured as a lifecycle process spanning identification, assessment, and ongoing management rather than a single point-in-time evaluation; specific scope, controls, and governance approaches vary by organization, and the term should not be read as a certification, standard, or legally mandated program in itself. The nature and stringency of TPRM obligations may differ depending on sector, jurisdiction, and applicable regulatory or contractual requirements, which readers should verify against authoritative sources for their context.

Why it matters

Organizations increasingly depend on external vendors, suppliers, and partners for critical functions, and each of these relationships can introduce risk to the organization's data, operations, and finances. When a third party is integrated into an organization's IT infrastructure, weaknesses in that party's controls can become weaknesses in the organization's own posture. TPRM matters because the risks introduced by third parties do not remain external; they can propagate into the organization that engaged them, making the management of these relationships an essential part of cybersecurity and broader governance, risk, and compliance (GRC) practice.

Because third-party relationships evolve over time, a single point-in-time review is generally insufficient. Vendors change their systems, their subcontractors, and their own risk exposure, and an organization's reliance on them may deepen or shift. Treating TPRM as a continuous process rather than a one-time check allows organizations to detect and respond to changes in a third party's risk profile as they arise, rather than discovering problems only after harm has occurred.

It is important to note that TPRM is a discipline and practice, not a certification, standard, or legally mandated program in itself. The degree to which formal third-party risk controls are required, and the specific form they take, may depend on sector, jurisdiction, and applicable regulatory or contractual obligations. Readers should verify the requirements that apply to their own context against authoritative sources rather than assuming a universal standard.

Who it's relevant to

Compliance and GRC teams
Those responsible for governance, risk, and compliance often own or coordinate TPRM as part of the organization's broader risk management program. They are typically concerned with ensuring that third-party relationships are assessed and monitored in a way consistent with applicable regulatory and contractual requirements, which vary by sector and jurisdiction.
Information security and cybersecurity professionals
Because third parties are frequently integrated into an organization's IT infrastructure, security teams treat TPRM as an essential cybersecurity practice. They focus on the risks that external vendors and suppliers can pose to the organization's data and systems, and on the continuous monitoring needed to detect changes in a third party's risk profile.
Procurement and vendor management functions
Teams that engage and manage external vendors, suppliers, and partners are directly involved in identifying third parties and assessing the risks they present before and throughout the business relationship. Their role connects the operational decision to use a third party with the ongoing management of the risks that decision introduces.
Risk officers and executive leadership
Those accountable for the organization's overall risk posture rely on TPRM to understand and limit potential harm to data, operations, and finances arising from external dependencies. Because the scope and stringency of these programs vary by organization, leadership generally sets the risk appetite and governance approach that shapes how TPRM is applied.

Inside TPRM

Third-Party Inventory
A maintained record of external vendors, suppliers, service providers, and other parties with whom an organization has a relationship. Serves as the foundation for identifying which relationships fall within TPRM scope; the level of detail captured generally depends on the nature of the engagement and the data or systems involved.
Risk Assessment and Tiering
The process of evaluating and categorizing third parties according to the level of risk they present, often considering factors such as access to sensitive data, criticality to operations, and regulatory exposure. Tiering allows organizations to allocate due diligence effort proportionately, with higher-risk relationships generally receiving deeper scrutiny.
Due Diligence
Pre-engagement and ongoing evaluation of a third party's security, privacy, financial, and operational posture. May involve questionnaires, review of independent attestations (such as a SOC 2 report or ISO/IEC 27001 certification), and assessment of the party's own controls. Note that reliance on a certification or attestation is an input to due diligence, not a substitute for independent judgment.
Contractual Controls
Provisions in agreements that allocate responsibilities and obligations between parties, which may include security requirements, data protection terms, audit rights, breach notification, and subcontracting restrictions. Where personal data is involved, specific contractual arrangements may be required by applicable law depending on jurisdiction and the roles of the parties.
Ongoing Monitoring
Continuous or periodic oversight of third parties after onboarding, since risk profiles can change over the life of a relationship. May include reassessment, review of updated attestations, and tracking of performance and incidents. The frequency and intensity generally correspond to the risk tier assigned to the party.
Offboarding and Termination
Controlled wind-down of a third-party relationship, addressing matters such as return or deletion of data, revocation of access, and closure of open obligations. Often overlooked relative to onboarding, though residual risk can persist if exit steps are incomplete.
Fourth-Party and Subcontractor Risk
Risk arising from parties engaged by an organization's direct third parties (and beyond). Because an organization typically has no direct relationship with these entities, oversight is generally exercised indirectly through contractual flow-down requirements and disclosure obligations placed on the direct third party.

Common questions

Answers to the questions practitioners most commonly ask about TPRM.

Is Third-Party Risk Management a regulatory requirement in its own right?
TPRM is not itself a single, universal legal mandate. It is a discipline and set of practices that organizations adopt to identify, assess, and monitor risks arising from their vendors, suppliers, and other external parties. That said, elements of TPRM may be required indirectly. For example, data protection regimes such as the GDPR in the EU generally require controllers to use processors that provide adequate guarantees and to govern those relationships through contracts, and sector-specific rules (such as those affecting financial services or healthcare) may impose oversight obligations on outsourced arrangements. The specific requirements differ by jurisdiction, sector, and the nature of the relationship, so readers should verify obligations against the applicable law or regulation rather than treating TPRM as a standalone legal duty.
Does obtaining a vendor's certification, such as ISO/IEC 27001 or SOC 2, mean the third-party risk is addressed?
Not on its own. A certification or attestation report is one input into a TPRM assessment, not a substitute for it. Certifications such as ISO/IEC 27001 and SOC 2 are voluntary or contractual in nature and reflect a scope, point in time, and set of controls defined by the vendor and its auditor. The certified scope may not cover the specific systems, services, or data relevant to your engagement, and a certificate does not by itself demonstrate compliance with any particular regulation that applies to you. Effective TPRM generally involves reviewing the scope and currency of such reports, understanding any exceptions or qualifications noted, and assessing residual risk in the context of your own use case. Application to particular circumstances requires professional judgment.
How do organizations typically classify or tier their third parties for risk assessment?
A common approach is to segment third parties by the level of risk they present, so that oversight effort is proportionate. Tiering criteria often include the sensitivity and volume of data accessed or processed, the criticality of the service to operations, the degree of system access, and any regulatory exposure the relationship creates. Higher-risk or 'critical' vendors generally receive more rigorous due diligence and more frequent monitoring, while lower-risk vendors may be subject to lighter review. The exact tiers and thresholds are organization-specific and should reflect the entity's own risk appetite and applicable obligations.
What contractual provisions are commonly used to allocate and manage third-party risk?
Contracts are a primary control mechanism in TPRM. Provisions frequently addressed include the scope and purpose of processing or service delivery, security and confidentiality obligations, audit or assessment rights, breach and incident notification requirements, subcontracting (or onward transfer) restrictions, data location and cross-border transfer terms, and provisions governing termination and return or deletion of data. Where personal data is involved, data protection regimes such as the GDPR generally require specific contractual terms between controllers and processors. The precise terms needed depend on the jurisdiction, the data categories, and the nature of the arrangement, and drafting for a specific situation calls for professional judgment.
How is third-party risk monitored on an ongoing basis rather than only at onboarding?
TPRM is generally treated as a lifecycle activity rather than a one-time onboarding check. Ongoing monitoring commonly includes periodic reassessment on a cadence linked to the vendor's risk tier, review of updated audit reports or certifications as they are reissued, tracking of security incidents or performance issues, and reassessment when the scope of the relationship or the applicable regulatory environment changes. The intensity and frequency of monitoring are typically calibrated to the risk the third party presents, and practices vary considerably across organizations and sectors.
How does TPRM address risk from a vendor's own subcontractors, sometimes called fourth-party risk?
Risk can extend beyond direct suppliers to the parties they in turn rely on, often referred to as fourth-party or supply-chain risk. Organizations commonly manage this by requiring visibility into material subcontractors, using contractual controls over onward subcontracting, and, where relevant, flowing down security and data protection obligations. In data protection contexts, regimes such as the GDPR generally address the engagement of sub-processors, typically requiring authorization and equivalent obligations. Visibility into deeper tiers of a supply chain is often limited in practice, so this entry does not describe a definitive method; the appropriate approach depends on the criticality of the relationship and applicable requirements, which should be verified against current authoritative sources.

Common misconceptions

Obtaining a vendor's certification or attestation (such as ISO/IEC 27001 or SOC 2) means TPRM obligations are satisfied.
Certifications and attestations are voluntary or contractual assurances with defined scope and validity periods; they are evidence to be evaluated, not proof that a specific relationship is adequately controlled. The scope of an attestation may not cover the services actually provided, and reliance on it does not transfer or discharge an organization's own accountability. Readers should confirm scope, currency, and applicability against the underlying report.
TPRM is a one-time exercise completed at onboarding.
A third party's risk profile can change over the course of the relationship, so TPRM is generally treated as an ongoing lifecycle activity spanning selection, contracting, monitoring, and offboarding. Assessing risk only at onboarding leaves changes in control posture, ownership, or subcontracting arrangements undetected.
Outsourcing a function to a third party transfers the associated compliance responsibility to that party.
Engaging a third party does not, by itself, transfer accountability. Under many data protection regimes, an organization acting in a controller-type role generally retains responsibility for how its data is handled by service providers, and allocation of obligations depends on the specific roles, contractual terms, and applicable law in the relevant jurisdiction. Application to particular circumstances requires professional judgment.

Best practices

Maintain a current inventory of third parties and use a defined, documented tiering method so that due diligence and monitoring effort is proportionate to each relationship's risk.
Treat certifications and attestations as inputs to be evaluated for scope, currency, and relevance rather than as conclusive assurance, and supplement them with your own assessment where warranted.
Incorporate risk-appropriate contractual controls—such as security and data protection terms, breach notification, audit rights, and subcontractor flow-down requirements—and align them with obligations under the applicable law of the relevant jurisdiction.
Establish ongoing monitoring with reassessment frequency tied to risk tier, so that changes in a third party's posture, ownership, or subcontracting are identified over the life of the relationship.
Extend oversight beyond direct third parties to fourth-party and subcontractor risk through disclosure and flow-down provisions, recognizing that such oversight is generally exercised indirectly.
Define and execute structured offboarding steps, including data return or deletion and access revocation, and verify obligations against the latest authoritative regulatory and standards sources rather than assuming requirements are static.
a promotional banner asking how ready are you for PCI DSS 4.0? With a call-to-action to get the checklist now.