CYBERSECURITY · 10 min read · #third-party-risk #vendor-security #TPRM #supply-chain-attacks
Sixty-one percent of enterprise breaches now originate through a vendor, supplier, partner, or third-party software component. Most organisations still assess these risks with annual questionnaires built for a threat environment that existed fifteen years ago.
Cybersecurity · Business Infomatics Research Desk
The security investment conversation in most boardrooms is still organised around the internal perimeter — the firewalls, the endpoint security, the identity and access management systems, the security operations centre. These are necessary investments and they are not being abandoned. But the logic of perimeter-centric security — invest heavily in the walls and the threats that matter most are the ones that attack those walls directly — no longer describes where the most consequential risks actually sit.
The SolarWinds compromise in 2020 was the first attack to make third-party risk a board-level conversation at scale. The Kaseya attack in 2021 demonstrated that managed service providers were viable vectors for simultaneous compromise of thousands of end clients. The MOVEit breach in 2023 — exploiting a file transfer tool used by hundreds of organisations in their supply chains — affected more than 2,500 organisations before the vulnerability was fully contained. Each of these events followed the same structural pattern: attackers found the connection between a trusted third party and their real targets more accessible and less well-defended than the targets themselves.
The pattern has not slowed. Mandiant's 2025 threat intelligence report identified third-party compromise as the initial access vector in 61 percent of the incidents it responded to in the previous year — up from 44 percent in 2022. The figure keeps moving in one direction for a reason that is structural rather than accidental: as enterprise security controls improve, the most sophisticated attackers increasingly look for the path of least resistance, and that path increasingly runs through the extended supplier ecosystem rather than through the organisation directly.
Enterprise breach origin by attack vector, 2025. Third-party and supply chain vectors now account for the majority of initial access incidents. Source: Mandiant M-Trends, 2025.
61% of enterprise breaches now originate through a third-party vendor, partner, or supply chain component — up from 44% in 2022. (Mandiant, 2025)
Why Existing TPRM Programmes Are Not Built for This Threat
Third-party risk management as a formal discipline emerged from the financial services regulatory environment of the early 2000s. Its foundations are the vendor questionnaire — a document, often running to hundreds of questions, sent to suppliers asking them to attest to their security practices — and the periodic review cycle, typically annual, that revisits those attestations. These tools were designed to demonstrate due diligence to regulators in an environment where vendor relationships were fewer in number, more static in nature, and where the digital attack surface they represented was significantly smaller.
Neither condition applies in 2025. The average enterprise now has hundreds to thousands of vendor relationships with some level of digital access to its systems or data — a number that has grown dramatically as organisations have outsourced more operations to SaaS providers, managed service providers, and specialised technology vendors. The access these vendors have is often significant — not just data processing agreements but API-level integration with core systems, network-level connectivity that bypasses external perimeter controls, and software components running in production environments.
Number of vendors with data access, by organisation size. Enterprise-scale organisations have hundreds of vendors with critical data access — most assessed annually at best. Source: CyberArk Third-Party Access Report, 2025.
An annual questionnaire sent to a vendor is a point-in-time attestation of a security posture that may change significantly between assessments. A vendor that passed last year's assessment may have since experienced a breach that has not been disclosed, undergone significant infrastructure changes, or had key security personnel depart. The questionnaire tells you what the vendor said about their security posture at a moment in time — it tells you nothing about what their actual posture is today.
The Three Categories of Third-Party Risk That Most Programmes Miss
Nth-Party Risk: Your Vendor's Vendors
When an organisation assesses a direct vendor, it is assessing the first link in a supply chain that may extend several levels deeper. The software that vendor uses to manage their operations, the cloud infrastructure their product runs on, the open-source components in their codebase — each of these represents an additional attack surface that the direct vendor relationship assessment does not reach. The Log4Shell vulnerability in 2021 was present in hundreds of commercial software products whose customers had no direct knowledge of the underlying Java component and its vulnerability.
Nth-party risk — the risk that flows through your vendors' own third-party relationships — is the hardest category to manage because it requires visibility beyond the direct relationship boundary. Software bill of materials requirements, now mandatory for federal contractors in the United States and increasingly expected in enterprise procurement in Europe, are a step toward addressing this. They provide visibility into the components within a software product that can be assessed for known vulnerabilities. But they address one category of nth-party exposure and do not reach the full scope of what flows through a complex vendor ecosystem.
Access Creep: Permissions That Were Granted and Never Reviewed
Vendor access to enterprise systems is almost always granted in response to a specific project or integration requirement at a specific point in time. The project completes, the integration goes live, the people involved move on. The access credentials remain. In Forrester's 2025 privileged access research, 58 percent of security professionals reported that vendor accounts in their environments had broader permissions than were required for their current function — often because access was granted for an initial project scope and never revised as that scope changed or ended.
This access creep creates persistent, dormant attack surface that can be exploited years after the original business justification for the access has passed. Reviewing and right-sizing vendor access on an ongoing basis — connecting access entitlements to active business relationships rather than treating them as a one-time provisioning decision — is the hygiene practice that most organisations know is correct and most have not operationalised at scale.
Vendor assessment frequency vs. breach probability in the following 24 months. Continuous monitoring reduces breach probability by 88% compared to no formal assessment. Source: Ponemon Institute, 2025.
58% of security professionals report vendor accounts in their environment have broader permissions than their current function requires. (Forrester, 2025)
Software Supply Chain Risk: The Open-Source Exposure
The average commercial software application contains hundreds of open-source components. These components are maintained by communities ranging from well-resourced foundations to individual developers maintaining packages in their spare time. When a vulnerability is discovered in a widely-used component — as occurred with Log4j, XZ Utils, and several other high-profile examples in recent years — it propagates through every product that depends on that component, regardless of whether the product vendor has any visibility into the dependency.
The response to this risk has moved faster in the past two years than in the previous decade. Software composition analysis tools that inventory open-source dependencies and track them against vulnerability databases are now standard in mature software development organisations. The SBOM requirements embedded in US federal procurement and being adopted in European regulatory frameworks are creating pressure for broader adoption. But the deployment of these practices across the enterprise software supply chain — including the mid-market vendors whose security practices receive less scrutiny than those of the largest technology companies — remains uneven.
Building a TPRM Programme That Matches the Current Risk Environment
Average third-party breach cost by TPRM programme maturity. Organisations with no programme pay 5× the breach cost of those with integrated GRC platforms. Source: IBM Cost of a Data Breach, 2025.
Risk-Tier Your Vendor Population — Then Differentiate Your Controls
Not every vendor represents the same risk. A SaaS productivity tool with no access to sensitive data presents a different risk profile from a managed security service provider with privileged access to core infrastructure. A one-size-fits-all assessment programme that applies the same controls to both categories is inefficient and ineffective simultaneously — it overburdens low-risk vendors with compliance requirements that consume procurement capacity, while failing to apply adequate scrutiny to high-risk relationships.
Effective TPRM starts with a tiering framework that categorises vendors by the combination of their access level — what systems and data they can reach — and their criticality — how dependent the organisation is on their continued operation. Tier 1 vendors with privileged access and high criticality receive continuous monitoring, on-site assessments, and contractual security requirements with audit rights. Tier 3 vendors with limited access and low criticality receive lighter-touch assessment and standard contractual terms. The proportionate application of controls to risk level is what makes the programme sustainable at the scale of vendor populations that enterprise organisations actually manage.
Continuous Monitoring Is Now Table Stakes for Critical Vendors
Annual questionnaire cycles cannot detect a vendor breach that occurred three months ago. Continuous monitoring programmes — using threat intelligence feeds, dark web monitoring, security ratings services, and automated scanning of vendor-facing infrastructure — provide the ongoing signal that periodic assessments cannot. The security ratings platforms that emerged over the last decade — BitSight, SecurityScorecard, RiskRecon — have matured into enterprise-grade tools that can monitor external security posture signals for large vendor populations at scale.
Continuous monitoring does not replace deeper assessments for critical vendors. What it does is provide the signal between assessments that allows a risk team to detect deterioration and trigger an out-of-cycle assessment when the evidence warrants it — rather than discovering that a vendor's security posture declined significantly only at the next annual review.
Contractual Controls Are the Foundation Everything Else Rests On
The technical controls that monitor third-party risk have limited value if the contractual framework does not give the organisation the rights it needs to act on what monitoring reveals. Contracts with critical vendors should specify minimum security standards by reference to recognised frameworks, audit rights that allow the organisation to verify compliance rather than relying solely on attestation, breach notification obligations with timelines that allow the organisation to respond effectively, and liability provisions that create financial incentive for vendors to maintain the security posture they have committed to.
Most organisations' vendor contract templates have evolved incrementally from agreements that predate the current third-party risk environment. A systematic review of critical vendor contracts against a current security contractual standard — with targeted renegotiation for the highest-risk relationships where the current terms are inadequate — is one of the highest-return activities a CISO or procurement team can undertake in the current environment. It does not require deploying new technology. It requires legal and commercial will to use the leverage that most organisations have but underutilise at renewal.
