In March 2023, attackers compromised a build server at 3CX, a VoIP software vendor with 600,000 customers, and pushed a trojanized desktop app to end users — a supply chain attack traced back to a single infected employee laptop at a trading firm two steps removed. Two months earlier, GoTo disclosed that a threat actor had stolen encrypted backups using credentials taken from a third-party cloud storage provider. These weren't edge cases. IBM's 2023 Cost of a Data Breach report put the average cost of a breach involving a third party at $4.76 million, above the global average of $4.45 million. Third-party risk management (TPRM) is the discipline of identifying, assessing, and continuously monitoring the risk that vendors, suppliers, and software dependencies introduce into your environment — and it has moved from a procurement checkbox to a board-level metric.
What Is Third-Party Risk Management?
Third-party risk management is the set of processes an organization uses to identify, evaluate, and continuously monitor the security, operational, financial, and compliance risks introduced by external parties it relies on — vendors, contractors, cloud providers, and the open-source or commercial software components those parties ship. It typically starts before a contract is signed, with a vendor security questionnaire and a risk tier assignment (critical, high, medium, low), and continues for the life of the relationship through periodic reassessment, SOC 2 or ISO 27001 report reviews, and monitoring for new disclosures. NIST SP 800-161 (Cybersecurity Supply Chain Risk Management Practices) and ISO/IEC 27036 are the two most cited frameworks underpinning formal TPRM programs. In practice, most TPRM programs today extend beyond legal and procurement into engineering, because "third party" now includes the thousands of open-source packages a codebase pulls in via npm, PyPI, or Maven — each one a vendor relationship that never signed a contract.
Why Did Third-Party Risk Become a Board-Level Issue?
Third-party risk became a board-level issue because a handful of incidents demonstrated that a single compromised vendor can cascade into thousands of downstream victims within days. The SolarWinds Orion breach, disclosed in December 2020, used a trojanized software update to compromise roughly 18,000 customers, including nine U.S. federal agencies. The MOVEit Transfer breach in May 2023, exploited via a zero-day SQL injection (CVE-2023-34362) in Progress Software's file-transfer product, ultimately affected more than 2,600 organizations and exposed data on over 93 million individuals, according to breach-tracking firm Emsisoft. The Target breach of 2013 — still cited in TPRM training material more than a decade later — started with stolen credentials from an HVAC contractor and led to 40 million payment card numbers being stolen. Each incident shifted liability and headlines from the vendor to the customer, which is why 10-K risk factor sections and audit committee agendas now routinely include third-party and supply chain risk as a standing line item.
What Are the Main Categories of Third-Party Risk?
The main categories of third-party risk are cybersecurity risk, operational risk, compliance risk, financial risk, and reputational risk, and most mature TPRM frameworks score vendors across all five. Cybersecurity risk covers whether a vendor's own network, or the code it ships, can be used as an entry point — this is the category exploited in SolarWinds, MOVEit, and the 2020 Log4Shell-adjacent wave of dependency attacks. Operational risk covers concentration: if a single cloud provider or payment processor goes down, does your business stop? Compliance risk covers whether a vendor's practices put you out of alignment with frameworks you're contractually or legally bound to, such as HIPAA, PCI DSS, or GDPR — a healthcare company using a subprocessor with no signed BAA is carrying unmanaged compliance risk regardless of how good that subprocessor's uptime is. Financial risk covers vendor solvency (a critical vendor going bankrupt is a business continuity event), and reputational risk covers association — being named in the same breach disclosure as a compromised vendor, even without direct data loss, still costs stock price and customer trust, as several Okta customers experienced after Okta's October 2023 support-system breach exposed session tokens tied to their environments.
How Do New Regulations Change What TPRM Programs Must Do?
New regulations change TPRM programs by converting what used to be voluntary best practice into a mandatory, time-boxed, and auditable obligation. The SEC's cybersecurity disclosure rule, effective December 2023, requires public companies to disclose material cybersecurity incidents — including those originating at a third party — on Form 8-K within four business days of determining materiality, which means TPRM programs now need incident notification clauses and response SLAs written into every critical vendor contract, not just an annual questionnaire. The EU's Digital Operational Resilience Act (DORA), which became applicable on January 17, 2025, requires financial entities to maintain a register of all ICT third-party providers, conduct concentration risk analysis, and in some cases subjects "critical" ICT providers to direct oversight by EU regulators. In the U.S., the 2022 update to NIST SP 800-161 explicitly folded software supply chain provenance — SBOMs, build integrity, provenance attestation — into the federal definition of supply chain risk management, which flows down through FedRAMP and DFARS contract requirements to any vendor selling into government. The practical effect: TPRM teams that used to run a spreadsheet and an annual questionnaire cycle now need a live, evidence-backed inventory they can produce during an audit within days, not weeks.
What Does a Modern TPRM Program Actually Include Today?
A modern TPRM program includes vendor tiering, continuous monitoring, contractual controls, and — increasingly — direct technical visibility into the software those vendors ship, not just paperwork about their security posture. Vendor tiering assigns a risk level at onboarding based on data access and business criticality, which determines assessment depth: a critical-tier vendor might require a full SOC 2 Type II review and penetration test report, while a low-tier vendor gets a lightweight questionnaire. Continuous monitoring has replaced the annual reassessment cycle for high-risk vendors, using external attack surface scanning, breach notification feeds, and financial health signals so a vendor's risk score updates the week a CVE drops rather than the week of the next scheduled review. Contractual controls — right-to-audit clauses, breach notification SLAs (increasingly 24-72 hours rather than "promptly"), and SBOM delivery requirements — have become standard in enterprise vendor agreements since 2022. The newest and fastest-growing component is software composition visibility: because most "vendors" today are really open-source packages, mature programs now require a Software Bill of Materials (SBOM) for any delivered software, in SPDX or CycloneDX format, so the security team can check incoming components against known-vulnerable package lists the moment a new CVE is published, rather than waiting for the vendor to notify them.
How Is Third-Party Risk Management Different from Software Supply Chain Security?
Third-party risk management and software supply chain security overlap heavily but differ in scope: TPRM is a governance discipline covering all external relationships (vendors, contractors, cloud providers, financial risk, compliance risk), while software supply chain security is a technical discipline focused specifically on the integrity and provenance of the code, packages, and build pipelines an organization consumes and ships. A TPRM questionnaire might ask a vendor whether they have a SOC 2 report; software supply chain security asks whether the specific package version in your dependency tree is affected by a specific CVE, whether that vulnerable function is actually reachable from your application's code paths, and whether the artifact you deployed matches what was actually built from reviewed source. The Log4Shell disclosure in December 2021 (CVE-2021-44228) is the clearest illustration of the gap: a TPRM questionnaire answered six months earlier would have said nothing about Log4j, because no vendor discloses every transitive dependency in a static form — yet within days, security teams needed to know, package by package, whether log4j-core 2.x was present anywhere in their estate and whether it was invoked in a way that was actually exploitable. Programs that treat TPRM as paperwork and supply chain security as a separate engineering function end up with blind spots exactly where SolarWinds- and Log4Shell-style incidents originate.
How Safeguard Helps
Safeguard closes the gap between vendor questionnaires and actual exploitability by giving security and engineering teams live, technical evidence for third-party and open-source risk instead of point-in-time attestations. Reachability analysis traces whether a vulnerable function in a third-party package or transitive dependency is actually invoked by your application's code paths, so teams can separate the CVEs that need an emergency patch from the thousands that are present but unreachable and non-exploitable. Griffin AI, Safeguard's security-focused AI agent, triages new vendor and dependency vulnerabilities against your specific codebase and deployment context, cutting through alert volume that would otherwise require a full TPRM team to review manually. Safeguard both generates SBOMs for software your organization ships and ingests SBOMs from vendors, giving procurement and security teams a single, machine-readable inventory to check against new CVE disclosures the moment they're published rather than waiting for a vendor's next scheduled attestation. When a fix is available, Safeguard opens auto-fix pull requests that update the affected dependency directly in your repository, shrinking the time between "a third-party component is vulnerable" and "the vulnerable version is no longer in production."