Third Party Risk Management (TPRM): What It Is and How to Build a Program

Third party risk management (TPRM) is the discipline of identifying, assessing, and controlling the risks that come from the external organizations a company depends on: vendors first, and often customers and partners as well. The work runs through seven components: inventory, risk assessment, due diligence, contract management, assurance, awareness, and incident management.

Dependence on third parties concentrates risk in ways most organizations only see after something breaks. The July 2024 CrowdStrike incident made the point at scale: a faulty content update from one security vendor disabled roughly 8.5 million Windows devices and cancelled more than 5,000 flights worldwide in a single day. No attacker was involved. A trusted dependency failed, and every organization downstream inherited the failure. Vendor webs make this worse: a vendor of yours may also be a vendor of your other vendors, so one incident travels.

What counts as a third party?

Technically, a third party is any entity outside the organization, a definition broad enough to cover almost every external relationship. In practice, most TPRM programs narrow their scope to vendors, since those relationships carry the most direct operational and security risk. Some organizations extend the program to customers and partners, particularly where those relationships involve data exchange or regulatory obligations. That extension changes the work substantially, and is covered in the second half of this guide.

Why is TPRM hard?

The fundamental challenge is that TPRM imposes one organization's standards on an independent entity. The vendor is not obligated to follow internal policies unless a contract requires it, and there is no direct control over how they operate. Enforcement is therefore collaborative rather than directive, and the enforcement power lives almost entirely in contracts and relationship management.

The second challenge is coordination. Third-party risk touches legal, procurement, IT, and information security at minimum, so the program cannot run inside a single team. The skills that make it work reflect that: risk management (evaluating, quantifying, and prioritizing risk across very different relationship types) and contract review (reading legal language, negotiating terms, and knowing which protections matter most), sitting side by side.

What are the seven components of a TPRM program?

NIST SP 800-161 Rev. 1 provides the full industry-standard control set for cyber supply chain risk management. For a program starting from zero, these seven components are the minimum:

1. Inventory

You cannot manage what you do not know exists, so the vendor inventory plays the same role a technology asset register plays for infrastructure. Where no inventory exists, the practical starting point is to work backwards from financial records: payments made and contracts signed surface the vendors the organization is already engaged with.

2. Risk assessment

Each vendor in the inventory gets a risk rating based on factors relevant to the organization's context: what data or systems the vendor can access, whether they hold security certifications, and whether they have been involved in recent incidents. This rating is foundational because it determines the level of due diligence, contractual controls, and ongoing oversight applied to each vendor.

3. Due diligence

Scrutiny should be proportional to risk, and the questions should fit the service. Sending a janitorial vendor the same due diligence questionnaire (DDQ) as a cloud provider is disproportionate and counterproductive. The program should also define thresholds for when documentary evidence, such as certifications and self-assessments, is sufficient, versus when the risk warrants an on-site audit or in-person review.

4. Contract management

Contracts are the heart of TPRM because they are the mechanism that gives risk-reduction expectations legal weight. Security and privacy clauses are typically handled in dedicated annexes to keep agreements organized and specific. Bargaining power is a real constraint: large providers like AWS offer standardized terms they rarely deviate from. Where terms cannot be negotiated, the realistic approach is compensating controls, vendor risk monitoring, and internal safeguards that reduce exposure even under contract terms that are not ideal.

5. Assurance

TPRM does not end at signature. Certifications expire and may not be renewed, security postures change, and new risks emerge, so a structured assurance program reassesses vendors on a recurring cadence and confirms they still meet their contractual obligations.

6. Awareness

A common failure mode is over-trusting vendors because they are familiar or long-standing, and modern procurement makes it easy to subscribe to a cloud service and accept its terms with a click. Awareness work targets three audiences: internal staff who share confidential material with vendors, outsourced personnel who need role-based training, and the vendor organizations themselves. Raising awareness with vendors can feel like imposing one company's culture on another; the workable approach is to request artifacts such as training completion reports as evidence, and to arrange a session directly with the vendor only when no proof is forthcoming.

7. Incident management

Third-party incident management differs from traditional incident response because the ability to act is limited: there is no intervening in a vendor's systems, and the organization largely depends on the vendor's assurances. Vendors do not always proactively disclose, and some incidents only come to light through the organization's own threat intelligence, which can be as simple as reading industry news and participating in security forums. Tabletop exercises with key vendors establish communication and escalation paths before a real event tests them.

How does TPRM change when customers are in scope?

Customers are the other main category of third party: relationships where the organization exchanges data, services, or access with an external party. Bringing them into scope reverses the dynamic. Instead of imposing obligations, the organization becomes the vendor in the relationship, and the contractual responsibilities land on its side of the table.

Each of the seven components shifts:

Three of those shifts deserve expansion:

Regulated customers extend their obligations to you. A customer subject to PCI DSS, for example, is required to push compliance requirements onto the third parties it works with. Serving that customer can mean pursuing certification or aligning controls to their standard, whether or not the organization would have chosen to otherwise.

Questionnaire response is an organizational capability. Customer due diligence requests arrive continuously and cannot be handled by one person. The best-practice approach is a centralized database of pre-approved answers mapped to common topic areas (incident response, patch management, access control) that keeps responses fast and consistent. What gets shared needs review, especially in competitive bids where no contract exists yet; externally shareable versions of policies are worth preparing in advance.

Breach notification timelines are commitments. When the organization experiences an incident, customer notification windows are often contractually defined and sometimes legally mandated. The inventory should capture those timeframes so the response process can meet them, and the communication overhead, sometimes including public relations, should be planned rather than improvised.

Where TPRM fits in a security program

TPRM is one of the roughly 19 security capabilities that make up an effective security program, and it leans on several of the others: asset management supplies the discipline the vendor inventory copies, incident response supplies the process third-party incidents plug into, and the policy framework supplies the standards contracts enforce. SOC 2 CC9.2 expects vendor and business partner risks to be assessed and managed, so a working TPRM program produces its compliance evidence as a byproduct. The SOC 2 vendor management post covers how auditors read the vendor side, and the security vendors documentation gap post covers what happens when the evidence is missing.

Frequently Asked Questions

What is the difference between TPRM and vendor risk management?

Vendor risk management is the vendor-focused core of TPRM. Third party risk management is the broader discipline, extending to customers and partners when those relationships involve data exchange or regulatory obligations. Many organizations use the terms interchangeably because their program only covers vendors.

What is a DDQ?

A due diligence questionnaire: the structured set of questions one organization sends another to assess its security and compliance posture before or during a business relationship. Mature programs tailor DDQ depth to vendor risk and maintain a pre-approved answer library for responding to the DDQs their own customers send.

What standard should a TPRM program follow?

NIST SP 800-161 Rev. 1 (Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations) has a reference control set. SOC 2 CC9.2 and ISO 27001 Annex A supplier controls define what auditors expect to see in practice.

How many vendors does a TPRM program need to cover?

All of them in the inventory, but not all with the same depth. Risk-based tiering concentrates due diligence and monitoring on vendors with access to sensitive data or critical operations, while low-risk vendors get lightweight review. Proportionality is what keeps the program sustainable.

Was the CrowdStrike outage a cyberattack?

No. The July 2024 outage was caused by a faulty content update to CrowdStrike's Falcon sensor, not by an attacker. It still stands as a third-party risk case study: a single trusted dependency failing disabled roughly 8.5 million Windows devices and disrupted airlines, hospitals, and banks worldwide.

Do small companies need TPRM?

Yes, scaled down. A company of any size depends on cloud providers, payment processors, and SaaS tools, and customer security reviews increasingly ask how those dependencies are managed. A vendor inventory, basic risk tiers, and contract review at renewal are achievable for a small team and cover the bulk of the exposure.