What is third-party risk management (TPRM)?
Third-party risk management (TPRM) means identifying, assessing, monitoring, and treating the risks that vendors, suppliers, and partners bring, across the whole relationship.
Third-party risk management (TPRM) is the practice of identifying, assessing, monitoring, and treating the risks that vendors, suppliers, and other outside parties bring, such as security, privacy, operational, and concentration risk. It covers the whole relationship: due diligence before onboarding, ongoing monitoring and reassessment, and exit.
Why TPRM matters
Most companies now run on dozens or hundreds of outside services, from cloud hosting and payroll to marketing tools with access to customer data. Each one extends your attack surface and your obligations. Many of the largest breaches of the last decade started at a supplier, and regulators have responded: banks answer to the 2023 Interagency Guidance on Third-Party Relationships in the US, EU financial entities must keep a register of ICT third-party arrangements under DORA, and frameworks like SOC 2, ISO 27001, HIPAA, and NIS2 all require supplier oversight.
Customers ask too. If your product processes their data, your vendors are their fourth parties, and their security questionnaires will ask how you manage them.
The lifecycle
- PlanDecide what the relationship needs and what risks it brings.
- Due diligenceAssess the vendor based on its risk tier.
- ContractWrite security and exit terms into the contract.
- MonitorReassess on a schedule and whenever something changes.
- ExitOffboard safely, including returning or destroying data.
Types of third-party risk
| Risk | What it means | Example |
|---|---|---|
| Cybersecurity | A vendor's weak security exposes your data or systems | A breached file transfer tool leaks customer records |
| Privacy | A vendor processes personal data in ways you can't defend | A marketing tool shares data with its own partners |
| Operational | A vendor outage stops your business | Your payment processor is down for a day |
| Concentration | Too much depends on one vendor or region | Every critical system runs in one cloud region |
| Compliance | A vendor causes you to break a rule | An offshore support team handles data that must stay in the EU |
| Financial and reputational | A vendor fails or becomes an embarrassment | A key supplier goes bankrupt mid-contract |
Proportionality
Regulators and good practice both expect oversight that matches the risk. That's why programs tier vendors and adjust how deep each review goes.
A typical program sorts vendors into three or four tiers based on the data they touch, the access they have, and how much the business depends on them. The top tier gets a full questionnaire, a review of their SOC 2 report or ISO certificate, contract review, and yearly reassessment. The bottom tier gets a short form or none at all.
| Tier | Typical vendor | Due diligence | Reassessment |
|---|---|---|---|
| Critical | Cloud hosting, core processors, anyone with production access | Full questionnaire, SOC 2 Type II review, security and exit terms, business continuity evidence | Yearly, plus monitoring |
| High | Tools holding customer or employee personal data | Standard questionnaire and SOC 2 or ISO 27001 review | Yearly |
| Moderate | Internal tools with limited sensitive data | Short questionnaire | Every two years |
| Low | No data access, easy to replace | Basic record and contract check | On renewal |
Reading vendor evidence
Collecting questionnaires is the easy part. The value comes from reading the answers against evidence. A vendor that answers yes to multi-factor authentication should have a SOC 2 report that tests it, with no exception noted. When the SOC 2 report lists exceptions or complementary user entity controls (CUECs), those become your follow-ups: either the vendor fixes the gap or you add a control on your side.
Good programs check the scope and date of every report, note carve-outs for subservice organizations, and track expiry dates so a report from two years ago is not treated as current.
Continuous monitoring
Point-in-time reviews miss what happens between them. Most programs add some form of monitoring for their top tiers: security ratings, breach and news alerts, certificate and report expiry, and changes in what the vendor does for you. A change in scope, like a vendor that starts processing a new data type, should trigger a fresh review.
Common mistakes
- Sending every vendor the same 300-question questionnaire.
- Filing answers without reading them against evidence.
- Treating a SOC 2 report as a pass without reading the exceptions.
- Losing track of which vendors hold which data.
- No exit plan for critical vendors.
- Findings that never make it into the risk register.
What regulators expect
| Rule or framework | Third-party expectation |
|---|---|
| US Interagency Guidance (2023) | Risk-based oversight across planning, due diligence, contracts, monitoring, and termination for banks |
| DORA | A register of ICT third-party arrangements, mandatory contract terms, and exit plans for EU financial entities |
| NIS2 | Supply chain security as one of the Article 21 risk-management measures |
| HIPAA | Business associate agreements and oversight of anyone handling protected health information |
| SOC 2 and ISO 27001 | Supplier risk assessment and monitoring as tested controls |
Contract terms that matter
- Security requirements the vendor must meet, and how they will prove it.
- Breach notification within a set number of hours.
- Your right to audit, or to receive their SOC 2 report every year.
- Where data is stored and processed, and which subprocessors are used.
- Data return and deletion at the end of the contract.
- Service levels, and what happens when they are missed.
- Termination rights and exit support for critical services.
Building a program from scratch
- InventoryPull a vendor list from accounts payable, SSO, and expense reports. It will be longer than you expect.
- ClassifyRecord what data and access each vendor has, and who owns the relationship.
- TierSort vendors into tiers with a short, consistent set of questions.
- Assess the top tierStart with critical vendors. Review their SOC 2 reports and send a questionnaire sized to the risk.
- Record findingsLog gaps as findings with owners and dates, and add serious ones to the risk register.
- Set the rhythmSchedule reassessments by tier and add intake questions so new vendors are tiered before contracts are signed.
Metrics to track
- Vendors by tier, and share with a current assessment.
- Critical vendors with an exit plan.
- Open vendor findings by age and severity.
- Average days from intake to approval.
- Vendors whose SOC 2 report has expired.
How TruOps helps
TruOps tiers vendors by the service and data involved, sizes each questionnaire to the tier, and gives each vendor its own portal. Agents check vendor answers against their SOC 2 report and scan results, flag conflicts for a person to review, and turn gaps into findings that feed your risk register. People approve every rating.
What to look for
If reading questionnaires is your bottleneck, a portal that just sends them won't help. Look for tiering, evidence checks, and findings your vendors can see.
Questions
What is the difference between vendor risk management and TPRM?
They're often used interchangeably. TPRM is broader and can include partners, affiliates, and other third parties who aren't vendors.
What is fourth-party risk?
Risk from your vendors' own vendors.
How often should vendors be reassessed?
It depends on the tier. Critical vendors are usually reassessed every year with monitoring in between. Low-risk vendors may only be checked at renewal.
Is a SOC 2 report enough for vendor due diligence?
It covers a lot, but read it closely. Check the scope, the period, any exceptions, and the complementary user entity controls you are expected to run. Then ask about anything the report does not cover.
Who owns third-party risk?
Usually a TPRM or vendor risk team within security, risk, or procurement. The business owner of each relationship stays accountable for the vendor.
Related
Tier vendors, read their evidence first, and ask only what it can't answer.
→Use casesVendor risk assessmentsTier, assess, and check vendors without getting buried in questionnaires.
→LearnVendor tieringSizing vendor oversight to vendor risk.
→LearnSecurity questionnaireWhat customer security questionnaires are and how to answer them.
→See it run on your own data.
Book 30 minutes with a GRC specialist. Bring a real document, like a SOC 2 report, risk register, or vendor list (redacted is fine), and we'll show TruOps AI working on it.