What Is Third-Party Risk Management (TPRM)? A Practitioner's Guide
By ScruteXPublished
Recent supply chain incidents broke several TPRM assumptions at once. Attackers used stolen OAuth tokens tied to a vendor’s integration and queried customer CRM data. No password was cracked and no MFA prompt appeared. The vendor had been compromised for months before customers were touched. Organizations with mature security programs were hit too. Maturity at your own perimeter does not protect you from a vendor’s source code account.
The victims had not failed at their own perimeter. The weak point was a vendor.
That is the problem third party risk management (TPRM) exists to solve.
Third-party risk management is the continuous process of identifying the vendors, suppliers and service providers your organization depends on, assessing the risk each one adds, and controlling that risk through contracts, monitoring and exit plans, from onboarding to offboarding.
This guide covers what TPRM includes, why it has moved from a compliance task to a breach-prevention task, how the lifecycle works in practice, how to tier vendors, and how to stand up a program in 90 days.
What is third party risk management?
TPRM is the discipline of managing the risk that comes from organizations you do business with. People use it interchangeably with vendor risk management and supply chain risk management, and no single department universally owns it. That last point causes real trouble, and we return to it in the mistakes section.
The terms differ in practice more than the definitions suggest. Vendor risk management (VRM) usually means a procurement-led process: send a security questionnaire, file the answer, repeat each year. TPRM is wider. It covers every external party that touches your data, systems or operations:
- SaaS and cloud providers
- Managed service providers and contractors with system access
- Payment processors and data processors
- Software dependencies and API integrations
- Resellers, affiliates and outsourced business functions
It also covers more than cyber risk. A vendor can fail you through a breach, an outage, a regulatory action, a financial collapse or a scandal. A mature program tracks all of these, and the security team owns one slice of the work.
What types of third-party risk exist?
Security teams tend to see only the cyber row. Boards and regulators see all of them.
| Risk type | The question it answers | Typical trigger |
|---|---|---|
| Cyber and data security | Can an attacker reach our data or systems through this vendor? | Vendor breach, leaked vendor credentials, exposed vendor service |
| Operational and concentration | What stops if this vendor stops, and how many of our vendors depend on the same provider? | Outage, insolvency, shared cloud dependency |
| Compliance and privacy | Does this vendor's handling of our data keep us inside the law? | Cross-border transfer, missing data processing terms |
| Financial | Can this vendor stay in business long enough to deliver? | Funding loss, acquisition, price shocks |
| Reputational | Does being associated with this vendor damage trust in us? | Public scandal, sanctions exposure |
| Fourth-party | Whom does our vendor depend on, and do we know? | Vendor's subcontractor or hosting provider fails |
Fourth-party risk deserves attention because it is where visibility drops fastest. You rarely have a contract with a fourth party. You still absorb the consequences of its failure.
How does the TPRM lifecycle work?
A workable lifecycle has seven stages. Programs fail at the handoffs between them, so each stage below includes what good looks like.
1. Build the inventory. List every third party, who in the business owns the relationship, what data they touch and what they connect to. Pull from procurement, accounts payable, SSO and OAuth app lists, and cloud marketplace invoices. Shadow IT shows up in payment records and token lists long before it shows up in a vendor register. Expect the first pass to find far more vendors than anyone listed.
2. Tier by inherent risk. Rank each vendor by the damage it could cause before any controls are considered. The next section gives criteria.
3. Run due diligence in proportion to the tier. Tier 1 vendors get a security evidence review: audit reports with scope checked (a SOC 2 report that excludes the product you use proves little), penetration test summaries, architecture questions and a review of fourth parties. Lower tiers get lighter checks.
4. Contract for the risks you found. Security requirements, breach notification windows, audit and assessment rights, subcontractor flow-down, data return and deletion, and exit assistance. A finding without a contract term has no force behind it.
5. Monitor continuously. An annual questionnaire describes the vendor on the day they filled it in. Continuous monitoring watches for changes: new exposures, leaked credentials, expiring certificates, ransomware listings and news. Pair it with event-based reviews triggered by an acquisition, an incident or a scope change.
6. Track remediation to closure. An assessment that finds twelve gaps and closes none is documentation, not risk reduction. Give each finding an owner, a due date and an escalation path. The DBIR data on slow vendor fixes shows why this stage needs follow-up.
7. Offboard cleanly. Revoke access and tokens, retrieve or confirm deletion of data, and close the register entry. Dormant vendor connections are a quiet source of exposure.
How should you tier your vendors?
Tiering decides where scarce hours go. Four questions do most of the work:
- Data: Does the vendor store or process regulated, sensitive or customer data, and at what volume?
- Access: Does it have network, API, OAuth or privileged access to production systems?
- Criticality: Does a business process stop if the vendor fails, and how fast?
- Substitutability: How long would it take to replace them?
| Tier | Typical profile | Evidence expected | Review cadence |
|---|---|---|---|
| 1 (Critical) | Sensitive data at scale, production access, or no fast substitute | Audit reports with scope check, pen test summary, full questionnaire, contract with notification and audit terms, continuous external monitoring | At least annual, plus event-driven |
| 2 (Important) | Limited sensitive data or non-critical connectivity | Standard questionnaire, certification review, external monitoring | Every one to two years |
| 3 (Low) | No sensitive data, no connectivity, easily replaced | Basic due diligence at onboarding | At renewal |
These tiers and cadences are practice guidance from how programs are commonly run, not regulatory requirements. Your regulator may set its own definition of critical or material providers, and that definition overrides this table.
Why do questionnaires alone fall short?
Questionnaires do real work. They collect contractual commitments, document a vendor's stated controls and create the audit trail regulators ask for. Governance, risk and compliance (GRC) suites handle that workflow well, and for a large team with a dedicated TPRM function, a best-of-breed workflow tool paired with a separate ratings source is a reasonable architecture.
They have three structural limits:
- They are self-reported. The vendor writes the answers.
- They are point-in-time. The answers age from the day they are submitted.
- They are silent about what the vendor did not think to mention.
Outside-in evidence covers part of that gap. External monitoring can see exposed services, certificate problems, leaked credentials tied to the vendor's domains, stealer-log hits, lookalike domains aimed at your staff, and mentions on ransomware leak sites, all without asking the vendor's permission. It cannot see inside the vendor. It will not tell you how they handle source code access, whether their MFA covers service accounts, or whether they will call you quickly after an incident. Security scores can also misattribute assets, so a low score is a prompt to ask a question, not a verdict.
The stronger argument is correlation. A vendor's exposure matters most when it connects to yours: a vendor with leaked credentials that also holds an integration into your CRM is a different risk from a vendor with leaked credentials that touches nothing of yours. Five disconnected tools make you do that join by hand. A connected view makes it routine, and smaller teams in particular rarely have the hours to do it manually.
What do regulators expect from TPRM?
Expectations vary by region and sector. This table is orientation, and you should confirm current text with counsel or your regulator.
| Regime | Where | What it asks for on third parties |
|---|---|---|
| DORA | EU financial entities | ICT third-party risk management, including a register of information on contractual arrangements with ICT providers; applies from 17 January 2025 |
| NIS2 | EU essential and important entities | Supply chain security, including security in the relationship with direct suppliers, as one of the required risk-management measures (Article 21) |
| APRA CPS 230 | Australian regulated entities | A register of material service providers submitted to APRA each year; in force since 1 July 2025 |
| RBI Master Direction on Outsourcing of IT Services | Indian regulated entities | Issued 10 April 2023, effective 1 October 2023. The board and senior management remain ultimately responsible for the outsourced activity |
| US interagency third-party guidance | US banks (OCC, FDIC, Federal Reserve) | Risk-based management across the full life of the third-party relationship |
On CPS 230 specifically, existing contracts with material service providers could stay on old terms until the earlier of the next renewal or 1 July 2026. From that date, any agreement not yet updated must meet the standard, including evergreen contracts that never renew. If you are an Australian entity, check that your legacy contracts are done.
One pattern is shared across all of these: the regulated firm stays accountable for the outcome. Outsourcing the service does not outsource the responsibility.
What mistakes do TPRM programs make most often?
- Treating every vendor the same. A uniform 200-question form for every supplier burns analyst time on the stationery vendor and leaves the payment processor under-reviewed.
- Reviewing once a year and calling it monitoring. Risk changes between reviews. The Drift compromise ran for months before customers heard about it.
- Ignoring non-human access. OAuth grants, API keys and service accounts rarely appear in vendor registers.
- Assessing without remediating. Findings that nobody owns do not close.
- Leaving ownership unclear. When procurement, security, legal and the business each assume another team owns it, nobody does. Name a single accountable owner for the program, and a business owner for each Tier 1 vendor.
- Having no exit plan. A Tier 1 vendor you cannot leave is a concentration risk you have accepted without deciding to.
How do you start a third party risk management program in 90 days?
A lean team can reach a defensible baseline in a quarter if it resists building everything at once.
| Window | Actions | Output |
|---|---|---|
| Days 1 to 30 | Build the inventory from procurement, SSO and OAuth app lists. Name the program owner and business owners. Draft tier criteria. | Vendor register with owners |
| Days 31 to 60 | Tier every vendor. Run due diligence on Tier 1. Add notification and assessment terms to Tier 1 contracts at the next opportunity. | Tier 1 evidence files, contract gap list |
| Days 61 to 90 | Switch on continuous external monitoring for Tier 1 and Tier 2. Set up the remediation tracker. Write the offboarding checklist. | Monitoring in place, first board-ready report |
Budget matters. A team without spend for a full GRC suite can still do the first two phases in a spreadsheet and a shared inbox. The register and the tiering decisions are what count, and they transfer into any tool you buy later.
How do you measure a TPRM program?
Count outcomes, not activity. Useful measures:
- Percentage of vendors with an assigned tier and a business owner
- Percentage of Tier 1 vendors with current evidence (within the last 12 months)
- Percentage of Tier 1 contracts with a breach notification window and assessment rights
- Median days to close a vendor finding, split by severity
- Number of OAuth apps and API integrations with no named business owner
- Offboarded vendors with confirmed access revocation and data deletion
Report the trend to the board each quarter. A rising count of unowned integrations or a lengthening time to close findings is the signal worth raising.
Key takeaways
- TPRM covers every external party that touches your data, systems or operations, across cyber, operational, compliance, financial and reputational risk.
- Third-party involvement in breaches grew 60% year over year to 48%.
- Tier vendors by inherent risk, then spend effort in proportion. Not every vendor deserves the same review.
- Treat integrations and OAuth tokens as vendors. The Drift breach ran on tokens, not passwords.
- Questionnaires supply commitments and an audit trail. Continuous external evidence supplies change detection. Programs need both.
- You stay accountable for what your vendors do with your data, and your regulator will say so.
Are you exposed through a vendor?
You can run these checks today without any tool.
- You cannot list the OAuth apps and API tokens that connect to your CRM, email and cloud storage, or nobody owns each one.
- Your Tier 1 vendors' contracts have no breach notification window, or the window is longer than 72 hours.
- Your last security review of a critical vendor is more than 12 months old, or you hold only a certificate and have never checked its scope.
- You have never searched for your vendors' domains in leaked credential sources or ransomware leak site listings.
- You could not revoke a critical vendor's access within one hour.
If two or more apply, start with the inventory and the token list. Everything else in the lifecycle depends on them.
What Scrutex finds here
Scrutex scores each vendor domain from external signals: exposed services, certificate problems and lookalike domains. It matches vendor domains against stealer logs, paste sites and breach corpora, and it checks vendors against ransomware leak site postings. Then it shows each vendor finding next to the assets of yours it could affect, so a vendor with leaked credentials and a live integration into your systems rises above one that touches nothing. Setup is agentless and starts from a domain.
Scrutex sees the outside only. It will not show you a vendor's internal controls, how they handle source code access, or what happens inside your own network. It complements assessments and audits and does not replace them.
What that looks like
Check your vendors' domains before your next review
Enter a vendor domain and findings begin returning immediately. Domain only, no credit card. Start on the free tier at platform.scrutex.ai/sign-up.
If vendor risk is your problem: Vendor Insights scores vendors continuously and ties each finding to the assets of yours it could affect.
If credentials are your problem: Data Exposure Insights covers stealer logs and paste sites for your domains and your vendors' domains.
Go deeper: use the vendor security assessment template to run the Tier 1 evidence review described above.
Go sideways: read how to find leaked credentials on the dark web for the credential side of vendor risk. For how third-party exposure fits a wider program, see what CTEM is.
FAQ
What is third-party risk management in simple terms?
TPRM is how an organization finds, assesses and controls the risks created by the vendors, suppliers and partners it relies on. It runs from selecting a vendor to monitoring them to ending the relationship.
What is the difference between TPRM and vendor risk management?
The terms overlap heavily. VRM usually refers to a procurement-led, security-questionnaire process for vendors. TPRM is the wider term and includes contractors, affiliates, integrations and fourth parties, and risks beyond cyber.
What are the main steps in a TPRM program?
Build an inventory, tier vendors by risk, run proportionate due diligence, contract for the risks found, monitor continuously, track remediation to closure, and offboard cleanly.
How often should you assess third-party vendors?
Set cadence by tier. Critical vendors warrant at least an annual review plus reviews triggered by incidents, acquisitions or scope changes. Lower tiers can follow a lighter schedule.
Who owns third-party risk management?
Ownership differs across organizations. Whatever the structure, name one accountable program owner and a business owner for each critical vendor so that findings have someone to chase them.