Third-Party Risk vs Supply Chain Risk: Scope Differences and Running Both

Third-party risk management and supply chain risk management are often run by different teams with different tools, and the incidents that hurt most tend to fall in the gap between them. Third-party risk looks at the organisations you have a relationship with and what they can do to your data and services. Supply chain risk looks at the products, components and services you depend on, and at the chain behind them, including suppliers you never contracted with. This guide compares the two directly: definitions from primary sources, a side-by-side table, when each lens applies, how to run them as one programme, and the failure patterns at the boundary. It is written for third-party risk, procurement, security architecture and software assurance teams. For the full TPRM lifecycle see the Third-Party Risk Management Guide, and for the federal C-SCRM model the NIST SP 800-161 Cyber Supply Chain Risk Management Guide.

Key takeaways

• Short answer: third-party risk is about relationships, supply chain risk is about what flows through them. TPRM asks "can we trust this organisation with this access?". Supply chain risk asks "can we trust this product, component or service, and everything upstream of it?".
• They overlap but neither contains the other. A marketing agency with your customer list is a third-party risk with little supply chain angle. An open source library in your build is a supply chain risk with no contract at all.
• NIST CSF 2.0 puts both under one category. GV.SC, Cybersecurity Supply Chain Risk Management, covers suppliers, customers, partners and the products and services they provide, so one governance owner is reasonable.
• The methods differ. TPRM relies on due diligence, contracts and assurance reports. Supply chain risk adds provenance, SBOMs, build integrity, component authenticity and concentration analysis.
• Run one inventory, two lenses. A shared supplier and component register, with both questions asked of the critical entries, closes most of the gap.

What each term means

• Third-party risk: risk arising from relationships with external organisations that provide services, hold data, have access to systems or act on your behalf. The US banking agencies' Interagency Guidance on Third-Party Relationships: Risk Management (OCC Bulletin 2023-17, issued June 2023 by the OCC, Federal Reserve and FDIC) frames it as a lifecycle, with risk management scaled to the criticality of the activity each third party supports. It rescinded the OCC's earlier 2013 guidance and its 2020 FAQs.
• Supply chain risk: NIST SP 800-53 Rev. 5 defines it as the potential for harm or compromise arising from security risks from suppliers, their supply chains and their products or services, covering threats and vulnerabilities both in the products and services and in the supply chain itself. NIST SP 800-161 Rev. 1 (updated November 2024) focuses on products and services that may contain malicious functionality, be counterfeit, or be vulnerable through poor manufacturing or development practices, and on the organisation's reduced visibility into how acquired technology is built and deployed.
• The common ground: NIST CSF 2.0 category GV.SC treats suppliers, customers and partners and their products and services in one place, from GV.SC-01 (a C-SCRM programme, strategy and policies) to GV.SC-10 (activities after a relationship ends).

Side-by-side comparison

When each lens applies

Two incidents show the difference. In the SolarWinds Supply Chain Compromise, tampered Orion builds were signed and shipped as normal updates, and fewer than 18,000 customers may have installed them. A supplier questionnaire would not have caught this; build integrity and update monitoring are supply chain controls. In the Salesloft Drift Breach 2025, OAuth tokens that a chatbot integration held for customer Salesforce tenants were taken from the supplier's environment. That is a third-party access question first: what the integration could reach, and how the supplier protected its tokens.

Running both as one programme

1. Set one governance owner and policy. Use GV.SC-01 as the anchor: one C-SCRM and third-party policy, with TPRM and software or hardware assurance as named workstreams. See the Supplier Security Policy Template.
2. Build a single register. List suppliers (GV.SC-04: known and prioritised by criticality) and link each to the products, components and integrations it provides. Add significant open source and sub-tier components even where there is no supplier record.
3. Tier on both axes. Score access and data (third-party lens) and operational dependence, update path and component exposure (supply chain lens). Take the higher tier.
4. Apply lens-specific due diligence. For access-heavy suppliers: assurance reports, contract clauses (GV.SC-05) and access reviews. For product suppliers: SBOMs, signing, secure development attestations and vulnerability disclosure. See the SBOM Guide.
5. Look one tier down. Ask critical suppliers for their material subcontractors and component sources. See the Fourth-Party and Nth-Party Risk Guide.
6. Monitor continuously. Report and certificate expiry for third parties; new vulnerabilities in SBOM components and unexpected update behaviour for products (GV.SC-07).
7. Plan for the end. Offboarding removes access and tokens for third parties; for products it means migration paths when a component reaches end of life (GV.SC-10).

Small vs large organisations: a small organisation can run both lenses from one spreadsheet, asking the supply chain questions only for software it installs and integrations it connects. A large or regulated organisation usually needs a TPRM platform for relationships and separate tooling for SBOM and dependency analysis, joined by a shared supplier identifier. Financial entities in the EU also need an ICT third-party register under DORA; see the DORA ICT Third-Party Risk and Register of Information Guide.

Each lens in depth

For each option below: the threat it is built for, how it fails, the controls that make it work, when to choose it and a worked example.

Third-party risk

Threat model. Third-party risk management looks at the relationship: what a supplier can access, what data it holds and what happens if it fails. The OCC, Federal Reserve and FDIC interagency guidance (OCC Bulletin 2023-17, 6 June 2023) frames this as a lifecycle with risk management scaled to the criticality of the activity, and it rescinded OCC Bulletins 2013-29 and 2020-10. The threat model is an attacker who uses a supplier's legitimate access (T1199) or a supplier failure that interrupts a critical service.

Failure modes. Questionnaires collected and filed but never acted on; tiers set by spend rather than access; and no monitoring between annual reviews.

Controls. Tier by criticality and access, require assurance reports for access-heavy suppliers, write security and notification clauses into contracts, and review access granted to each supplier.

Decision criteria. Use this lens first for SaaS, managed services and any supplier holding data or credentials.

Worked scenario. A marketing SaaS supplier holds OAuth tokens to the CRM. TPRM tiers it high because of that access, requires a Type 2 report and limits the token scopes, so a later supplier breach exposes far less.

Supply chain risk

Threat model. NIST SP 800-161 Rev. 1 (updated 1 November 2024) focuses on products and services that may contain malicious functionality, be counterfeit, or be vulnerable through poor manufacturing and development practices, and on reduced visibility into how acquired technology is developed. The threat model is a compromised product or update (T1195, T1195.002).

Failure modes. Assessing the supplier's organisation but not its software; no component inventory; and no plan for when a trusted update is malicious.

Controls. Acquisition requirements (SR-5), supplier assessments (SR-6), component authenticity (SR-11), SBOMs for critical software and staged update roll-out with monitoring.

Decision criteria. Use this lens for software, hardware and components embedded in your own products or critical systems.

Worked scenario. A monitoring agent update behaves unusually. Because updates roll out to a canary group first and the SBOM shows the affected component, the team halts the roll-out before it reaches production.

Where the two lenses overlap

Many suppliers need both lenses at once. A managed detection provider is a third party with privileged remote access and a supply chain risk through the agent it deploys on every endpoint. A SaaS integration is a relationship with contract terms and a software component whose update you do not control. Treating such suppliers under only one lens leaves a gap: TPRM checks the provider's certifications and contract, but nobody asks how its agent updates are signed and staged; or the software team inventories the component, but nobody limits the access the vendor's staff hold.

Threat model for the overlap. The attacker compromises the supplier, then uses either its access or its software to reach every customer at once. That is why a single supplier incident can turn into many customer incidents, and why the supplier list needs a field recording both the access granted and the software deployed.

Controls for the overlap. For each top-tier supplier, record the identities and tokens it holds in your environment, the software it runs there, how updates are delivered, and who is notified and how fast if either is compromised (GV.SC-10 covers activities after a relationship ends, including revoking that access). Test the plan once a year with a tabletop that assumes the supplier is the source of the attack.

Worked scenario. A remote support vendor reports a breach of its own environment. Because the supplier record lists its accounts and its installed agent, the team disables the vendor accounts, rotates the credentials the agent used, blocks the agent's outbound connections, and then reviews logs for activity from either path during the exposure window. The TPRM file supplies the contacts and contract terms; the supply chain record supplies the software facts. Neither alone would have been enough.

Where identity fits

The boundary between the two lenses is often a non-human identity. A supplier's integration reaches your tenant through OAuth tokens or API keys; a managed provider uses service accounts and remote tooling; a compromised build pipeline is a compromised machine identity with signing rights. Inventory the credentials each supplier and product holds, scope them tightly, and include their revocation in both incident response and offboarding. See the Remote access and PAM vendors as tier-zero suppliers guide.

Detection and measurement

• Register coverage: percentage of critical suppliers linked to the products, integrations and components they provide.
• Dual-lens coverage: percentage of top-tier entries assessed under both lenses in the last 12 months.
• SBOM coverage: percentage of critical software products with a current SBOM on file.
• Integration credential hygiene: percentage of third-party integrations with a named owner, documented scopes and a rotation or expiry date.
• Time to assess exposure: hours from a public supplier or component incident to a confirmed list of affected systems.
• Fourth-party visibility: percentage of critical suppliers that have disclosed material subcontractors.

Common failure patterns

• Questionnaires used for product risk. A clean assessment of the supplier says nothing about whether its update channel was tampered with.
• Open source outside both programmes. No contract means no TPRM record, and no engineering owner means no supply chain review.
• Integrations missed by procurement. Users connect OAuth apps without a purchase, so the access never reaches the third-party register.
• Two registers that never reconcile. TPRM and engineering hold different supplier names and identifiers, so an incident takes days to map.
• Tiering on spend. Low-cost suppliers with privileged access or a code path into production are ranked as low risk.
• No offboarding of credentials. Contracts end but tokens, keys and service accounts remain active.

Framework mapping

ISO/IEC 27036 covers supplier relationships in depth; see the ISO/IEC 27036 Supplier Relationships Guide.

Practitioner checklist

• Name one owner for third-party and supply chain risk, with both workstreams in one policy.
• Keep one register linking suppliers to products, components and integrations.
• Tier on access, data, operational dependence and code path, not on spend.
• Ask for SBOMs and signing practices from critical software suppliers.
• Bring open source dependencies and OAuth integrations into scope explicitly.
• Request material subcontractor disclosure from critical suppliers.
• Rehearse a supplier incident: list affected systems and revoke credentials within a set time.
• Remove supplier credentials and tokens at contract end.

Standards and references

• NIST: SP 800-161 Rev. 1 Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
• NIST CSRC: Glossary, supply chain risk
• OCC: Bulletin 2023-17, Third-Party Relationships: Interagency Guidance on Risk Management
• NCSC: Supply chain security guidance, the principles
• MITRE ATT&CK: T1195 Supply Chain Compromise
• MITRE ATT&CK: T1199 Trusted Relationship

Related NHI Mgmt Group resources: Third-Party Risk Management Guide · NIST SP 800-161 Cyber Supply Chain Risk Management Guide · Software Supply Chain Security Guide · Fourth-Party and Nth-Party Risk Guide · SOC 2 Type 1 vs Type 2