CHAPTER 7: Third-Party Risk Management

TL;DR – Key Takeawaysfrom Chapter 7

i. Third-party risk is about dependency, not supplier numbers
The real challenge is understanding which services rely on which vendors,and how failures or changes can cascade across operations and customers.
ii. Risk lives at the engagement level
Treating vendors and engagements separately allows organisations to trackscope, data, access, and criticality as relationships evolve over time.
iii. TPRM only works when run as a lifecycle
Effective third-party risk management is continuous: identifying, tiering,assessing, contracting, monitoring, and offboarding, not a one-off onboardingexercise.
iv. TPRM must connect to cyber, privacy, and regulatory change
Vendor outages, breaches, data processing, and new outsourcing rulesintersect. TPRM adds value when it feeds into shared risks, controls, anddecisions.

Third-party risk management is not about stopping people from using vendors. It is about helping the organization:

1. Understand how critical services depend on external providers
2. Make informed decisions about who to trust with what, and on what terms
3. Detect when vendor risk changes and respond before it becomes an incident
4. Show regulators, customers, and boards that supply chain risks are managed, not guessed

In practice, that means treating third-party risk as scenario-based risk:

1. What could happen through a vendor
2. How it would affect your services, customers, and obligations
3. What you are doing about it, and how you will know if exposure changes

In 2026, very few services are purely “internal.” Most sit on top of layers of external technology and service providers.

It is no longer enough to say “we have many suppliers.” The real shift is dependence:

1. Horizontal platforms

1. Cloud providers, identity platforms, payment gateways, communication tools, core SaaS.
2. Outages or breaches can affect many services at once.

2. Vertical and sector-specific providers

1. Industry-specific software, data providers, logistics partners, and specialized outsourcers.
2. Failures can damage your ability to operate in particular markets or lines of business.

3. Physical and technology mix

1. Real-world providers (couriers, facilities, data centers) intertwined with digital services.

This mix creates cascading risk: a single issue at one provider can ripple across multiple services, regions, and customers. TPRM has to make those dependencies visible, not just record names and contracts.

A common failure mode in TPRM is treating each vendor as a single, static risk. In reality, what matters is the engagement:

1. Vendor

1. The legal entity or group (for example, “GlobalCloud Inc.”).
2. Has attributes like financial health, jurisdiction, and broad security posture.

2. Engagement

1. The specific service or set of services you buy from that vendor, with its own:
1. Purpose and business owner
2. Data types and volumes processed
3. Regions and hosting locations
4. Access types (for example, admin access, VPN, API, on-site staff)
5. Interfaces with your systems and processes

Over time, engagements change:

1. A vendor that started by providing a simple SaaS tool starts processing more sensitive data.
2. A supplier takes on additional roles, such as consulting, support, or on-site work.
3. A new integration gives them direct access to production systems.

If you treat vendor risk as a one-time “tick box” at onboarding, you will miss this scope creep.

A practical TPRM model:

1. Stores vendors and engagements separately
2. Tracks changes in each engagement’s data, access, and service criticality
3. Ties assessments and risk levels to the engagement, not just the vendor name

In data-model terms, “vendor” and “engagement” are just specialized forms of the shared service and dependency objects introduced in Chapter 2.

You do not need a complex method to get value from TPRM. A clear lifecycle is enough:

1. Identify and map

   1. Build and maintain an inventory of vendors and engagements.
   2. Link each engagement to the services, entities, and data it supports.
      
      

   This is where you turn an unstructured “pile” of suppliers into a more reliable picture of your supply chain.

2. Tier and scope

   1. Classify engagements by:

   1. Criticality to operations and customers
   2. Data sensitivity and volume
   3. Connectivity and access level

   2. Use these tiers to decide how deep and frequent assessments should be.
      
      

   Tiering is your main control for keeping effort proportionate and aligned to inherent risk.

3. Internal Review and decide

   1. Run due diligence appropriate to the tier (questionnaires, document review, certifications, independent reports).
   2. Consider both security/privacy and financial/operational resilience.

   3. Decide whether to:

   1. Proceed
   2. Proceed with conditions
   3. Seek alternatives
      
      
   Here you are using the risk assessment and treatment steps from Chapter 3, but at the engagement level.
   
   

4. Contract and onboard

   1. Reflect risk and control expectations in contracts and data protection terms.
   2. Align internal teams on how the engagement will work in practice (access, escalation paths, reporting).
      
      
   Contracting and onboarding should translate risk decisions into controls and obligations you can later test and evidence.
   
   

5. Monitor and review

   1. Track incidents, changes in scope, new data types, and changes in the vendor’s posture.
   2. Reassess on a regular cadence appropriate to the tier, and whenever something material changes.
      
      
   This is the monitor step in the risk loop: watching for new information that should change your view of exposure.
   
   

6. Of board and transition

   1. Plan how you will exit: data return and deletion, access removal, and service migration.
   2. Capture lessons learned and feed them back into criteria and templates.
      
      

   Each step should produce data that lives in your GRC system (engagements, risks, controls, issues, evidence), not in scattered documents.

The hardest part of TPRM is not the first assessment; it is staying aligned as reality changes. To handle this:

1. Treat change events as part of your TPRM workflow, such as:
1. New data categories or volumes
2. New regions or hosting changes
3. New integrations or access types
4. New services from the same vendor, or mergers and acquisitions
   
   
2. Require engagement owners to log these changes and trigger quick reassessments where needed.
3. Connect regulatory change items to TPRM, so new rules about outsourcing, resilience, or data transfers can prompt updates to assessments and contracts.

This is where the vendor vs engagement split becomes critical. You might:

1. Accept one engagement with a vendor
2. Reject, delay, or reshape another

based on the different risk profiles.

Third-party risk sits at the intersection of several parts of this guide:

1. Risk Management Excellence: Many top enterprise risks have third-party components; engagements should be linked to scenarios and treatments.
2. Compliance and Regulatory Change Management: Outsourcing, resilience, and privacy rules often flow through vendors; TPRM must reflect changes in those expectations.
3. Cyber Risk and Resilience: Vendor outages, breaches, and access issues are core cyber scenarios; incident and continuity plans should reference key engagements.
4. Data Privacy and Protection: Vendor and engagement records should show who is processing what personal data, under which legal bases and contracts.
5. GRC Strategy and Maturity: Use automation and AI to remove friction in TPRM (for example, document extraction and triage), while keeping humans accountable for decisions to accept or change vendor relationships.

Useful TPRM metrics focus on critical exposures and follow-through, for example:

1. Percentage of Tier 1 and Tier 2 engagements with current assessments and contracts aligned to actual scope
2. Number of significant vendor-related incidents or outages per quarter, and how many led to changes in controls or contracts
3. Time from identifying a material change in an engagement (new data, new region, new integration) to updated risk assessment and decision
4. Coverage of critical services with mapped key vendors and engagements
5. Percentage of high-priority TPRM actions completed on time

These metrics should connect directly to resilience and risk reporting, not sit in a separate supplier dashboard.

To strengthen third-party risk management using this model:

1. Build or refine a vendor and engagement inventory for a subset of critical services.
2. Tier engagements based on criticality, data, and access; agree what each tier means for assessment and review effort.
3. For your top few vendors, check whether current contracts and assessments match how you actually use them today.
4. Integrate vendor and engagement data with incident, regulatory change, cyber, and privacy processes so changes and events flow through consistently.

Handled this way, third-party risk stops being a separate, “poor relation” process and becomes part of how you understand and protect your core services.

Continue to Chapter 8 - Enterprise Risk