Third-Party Breaches Doubled — How to Build a Real TPRM Program

The Numbers Are Unambiguous

The Verizon 2025 Data Breach Investigations Report documented a structural shift in how breaches occur: 30% of all confirmed breaches now involve a third party — doubled from 15% in the prior year's report. This is not a statistical anomaly. It reflects a fundamental change in the attack surface that organisations must manage.

SecurityScorecard's 2025 Global Third-Party Breach Report found that 35.5% of all breaches in 2024 were third-party related, rising to 46.75% among Fortune 500 companies. IBM's 2025 Cost of a Data Breach Report measured the financial impact: vendor-related breaches cost an average of $4.91 million — 12% higher than the overall average — and took 267 days to identify and contain, nine days longer than direct breaches.

The software supply chain tells an even more alarming story. Sonatype's 2024 State of the Software Supply Chain report identified 512,847 malicious open-source packages, a 70% increase year-over-year. Supply chain attacks grew 431% between 2021 and 2023. Synopsys's 2024 Open Source Security and Risk Analysis found that 74% of commercial codebases contained open-source vulnerabilities, with 91% running components ten or more versions behind the latest release.

The pattern is clear: attackers have recognised that compromising a single vendor can provide access to hundreds or thousands of downstream organisations. The economics of supply chain attacks favour the attacker overwhelmingly.

The Incidents That Proved the Point

The past two years have produced a series of third-party incidents that demonstrate the scale and variety of supply chain risk:

These are not exotic attack scenarios. They represent the operational reality of modern technology dependencies. The MOVEit attack exploited a vulnerability in a widely used file transfer tool. The CrowdStrike incident resulted from a faulty software update, not a malicious attack. The Snowflake breach exploited stolen credentials and the absence of enforced multi-factor authentication.

Each incident demonstrates a different dimension of third-party risk: software vulnerabilities, update mechanisms, credential management, and domain supply chain integrity. A comprehensive TPRM programme must address all of them.

Why Traditional Vendor Assessments Fail

Most organisations still rely on annual questionnaire-based assessments as their primary TPRM mechanism. The data suggests this approach is fundamentally inadequate.

Prevalent's 2025 Third-Party Risk Management Study found that only 9% of organisations have achieved advanced TPRM maturity. The study also found that 94% of organisations cannot assess all the vendors they would like to — a direct result of the resource intensity of manual assessment processes. The average organisation manages 286 vendor relationships while spending 37.4 hours per week on third-party assessments.

The problem is not effort. It is methodology. Annual questionnaires capture a point-in-time self-attestation. They do not detect the configuration change made in March, the unpatched vulnerability discovered in July, or the credential compromise that occurred in October. Between assessment cycles, organisations operate with a false sense of assurance.

Ponemon Institute and Black Kite's 2025 research found that 47% of organisations suffered a data breach caused by a third party in the past 12 months, with 63% of incidents attributed to overprivileged access to sensitive data. This suggests that even when assessments occur, they fail to identify the access control weaknesses that lead to actual breaches.

The Deloitte DORA European Survey (2025) found that only 8% of financial institutions consider themselves compliant with DORA's third-party risk management requirements — the lowest confidence level across all five DORA pillars. ENISA's NIS Investments 2025 report found that 37% of organisations identify supply chain risk management as the most challenging compliance area.

The gap between what regulations require and what organisations actually do is vast.

What the Regulations Now Require

Three major EU regulations now mandate structured third-party risk management. Together, they create a comprehensive regulatory framework that makes annual questionnaires legally insufficient.

NIS2 — Supply Chain Security (Article 21, Measure 4)

The NIS2 Directive requires essential and important entities to implement security measures addressing vulnerabilities specific to each direct supplier and service provider. The directive's Implementing Regulation (EU 2024/2690), adopted in October 2024, provides further technical details for digital infrastructure providers.

Organisations must consider the overall quality and resilience of products and services, the cybersecurity practices of their suppliers (including secure development procedures), and the results of coordinated security risk assessments of critical supply chains conducted under Article 22.

ENISA published its Technical Implementation Guidance in June 2025, providing detailed advice on implementing all Article 21 measures, including supply chain security. This guidance makes clear that supply chain risk management is not a documentation exercise — it requires active assessment, monitoring, and contractual enforcement.

DORA — ICT Third-Party Risk Management (Articles 28-44)

DORA imposes the most prescriptive third-party risk management regime in any EU regulation. Financial entities must:

Maintain a Register of Information (Article 28) documenting all ICT third-party contractual arrangements. The register templates are standardised through Implementing Regulation (EU) 2024/2956, and the next reporting window runs from January 1 to March 21, 2026.

Conduct due diligence (Article 29) before entering ICT arrangements and maintain ongoing monitoring of provider performance.

Include mandatory contractual provisions (Article 30) covering at least fifteen specific areas:

• Service level descriptions with quantitative and qualitative performance targets
• Incident reporting obligations and response support commitments
• Audit and access rights, including unlimited access for competent authorities
• ICT security measures including encryption and data location requirements
• Business continuity provisions and exit strategies
• Subcontracting provisions requiring prior approval for material changes

Delegated Regulation (EU) 2025/532, applicable from July 2025, adds further requirements for oversight of ICT service subcontracting chains, including mandatory identification of all subcontractors in critical service chains.

The oversight framework for Critical ICT Third-Party Providers (Articles 31-44) became operational with the ESAs' designation of 19 CTPPs in November 2025. These providers now face direct EU oversight with potential penalties of up to 1% of average daily worldwide turnover.

CRA — Software Supply Chain Obligations

The Cyber Resilience Act (Regulation EU 2024/2847) addresses supply chain risk from the product side. Manufacturers of products with digital elements must:

• Generate and maintain a Software Bill of Materials (SBOM) in a commonly used, machine-readable format, documenting at minimum top-level dependencies
• Report actively exploited vulnerabilities within 24 hours (early warning), with full notification at 72 hours and final report within 14 days of a corrective measure becoming available — effective 11 September 2026
• Deliver products without known exploitable vulnerabilities
• Implement cybersecurity requirements at every stage of the value chain

For organisations that consume software products, the CRA creates a right to expect supply chain transparency that did not previously exist at the regulatory level.

Building a TPRM Programme That Works

Based on the regulatory requirements and the operational evidence of what actually reduces third-party breach risk, here is a structured approach to building an effective TPRM programme.

Step 1: Build a Complete Vendor Inventory

You cannot manage risk you cannot see. The starting point is a comprehensive inventory of every third-party relationship that involves access to your data, systems, or networks.

This inventory should capture: the vendor name and primary contact, the services provided, the data types accessed or processed, the systems integrated with, the contractual terms and renewal dates, and the criticality classification.

DORA's Register of Information provides a useful template even for organisations outside the financial sector. The structured format ensures consistency and enables systematic analysis.

Step 2: Classify Vendors by Risk

Not all vendor relationships carry equal risk. A tiered classification model enables proportionate allocation of assessment resources:

Critical (Tier 1): Vendors with direct access to sensitive data, critical systems, or whose failure would cause significant operational disruption. These require the most rigorous assessment and continuous monitoring.

Important (Tier 2): Vendors with limited data access or whose services support important but non-critical functions. These require periodic assessment and event-driven monitoring.

Standard (Tier 3): Vendors with no data access and minimal integration. These require baseline assessment and contract-level controls.

The classification should consider both the inherent risk of the service and the volume and sensitivity of data involved. A cloud infrastructure provider and a payment processor are both Tier 1, but for different reasons.

Step 3: Implement Risk Assessment Beyond Questionnaires

For Tier 1 and Tier 2 vendors, assessment must go beyond self-attestation:

• External attack surface monitoring: Continuous scanning of vendors' internet-facing infrastructure for vulnerabilities, misconfigurations, and exposed services
• Security ratings: Quantitative risk scores from platforms that aggregate multiple data sources
• Evidence-based validation: Request and verify actual configuration evidence — MFA deployment screenshots, EDR coverage reports, backup test results — rather than accepting checkbox attestations
• Certification verification: Confirm ISO 27001, SOC 2, or equivalent certifications are current and cover the services you consume
• Incident history review: Assess the vendor's track record of security incidents and their response quality

For critical vendors, consider on-site assessments or detailed technical reviews of their security architecture.

Step 4: Embed Security in Contracts

Contracts are your primary enforcement mechanism. Based on DORA Article 30's comprehensive requirements, contracts with critical vendors should include:

• Security standards: Specific technical controls the vendor must maintain
• Incident notification: Defined timelines for notifying you of security incidents (align with your own regulatory reporting obligations)
• Audit rights: The right to audit the vendor's security controls, directly or through independent assessors
• Subcontracting controls: Requirements for prior notification and approval of subcontractors handling your data or services
• Exit provisions: Clear data return, deletion, and transition support obligations
• Service level commitments: Quantitative availability and performance targets with consequences for breach

Step 5: Establish Continuous Monitoring

The shift from periodic assessment to continuous monitoring is the single most important capability improvement in TPRM. Continuous monitoring should include:

• Real-time threat intelligence: Automated alerts when a vendor appears in breach databases, threat reports, or vulnerability disclosures
• Attack surface changes: Detection of new services, expired certificates, or configuration changes in vendor infrastructure
• Financial and operational signals: Monitoring for indicators of vendor instability that could affect service continuity
• Regulatory compliance status: Tracking vendors' compliance with applicable regulations, certifications, and standards

Continuous monitoring does not replace periodic deep assessments. It fills the gaps between them, ensuring that risk-relevant changes are detected when they occur rather than months later.

Step 6: Coordinate Incident Response

When a vendor suffers a security incident, your response time depends on how quickly you are notified and how prepared you are to act. Incident response coordination should include:

• Pre-established communication channels with critical vendors' security teams
• Defined escalation procedures within your organisation for third-party incidents
• Pre-drafted notification templates for regulators, customers, and affected parties
• Tested containment procedures for isolating or restricting vendor access when necessary

Under NIS2, you must report significant incidents within 24 hours. Under DORA, the initial notification window is 4 hours. These timelines leave no room for improvisation.

Fourth-Party Risk: The Hidden Layer

Your vendors have vendors. The CrowdStrike incident illustrated how a single update from a security vendor could cascade across millions of endpoints globally. The Polyfill.io compromise showed how a domain change in an open-source CDN could affect over 100,000 websites.

Fourth-party risk — the risk introduced by your vendors' own supply chains — is the fastest-growing blind spot in TPRM. DORA addresses this explicitly through its subcontracting provisions, requiring financial entities to identify and oversee the subcontracting chains of critical ICT services.

Practical steps for managing fourth-party risk:

1. Map critical subcontracting chains. For Tier 1 vendors, require disclosure of subcontractors that handle your data or support critical services
2. Include subcontracting controls in contracts. Require prior approval for material subcontracting changes, as DORA Article 30 mandates
3. Monitor concentration risk. Identify where multiple vendors depend on the same fourth party — this creates correlated risk that may not be visible at the individual vendor level
4. Require SBOM transparency. For software vendors, request SBOMs documenting the open-source and third-party components in their products. The CRA will make this a regulatory requirement for products on the EU market

The Regulatory Convergence Advantage

One of the most significant developments in the TPRM landscape is the convergence of regulatory requirements across NIS2, DORA, the CRA, and the AI Act. While each regulation addresses different sectors and risk types, their third-party requirements share common elements:

Organisations that build their TPRM programme against the strictest applicable requirements — typically DORA for financial entities, NIS2 for other in-scope sectors — will simultaneously satisfy most requirements across all four regulations.

International frameworks reinforce this approach. NIST SP 800-161 Rev. 1 and the CSF 2.0 C-SCRM Quick-Start Guide (SP 1305, October 2024) provide implementation guidance that aligns with EU regulatory principles. ISO/IEC 27036 (updated in 2022) offers a structured standard for supplier relationship security. Building on these frameworks creates a defensible, auditable programme that regulators recognise.

From Compliance to Resilience

The data is clear: third-party risk is no longer a secondary concern. It is a primary attack vector, a regulatory mandate, and a board-level governance issue.

The organisations that will manage this risk effectively are not those with the longest vendor questionnaires or the most elaborate spreadsheets. They are the ones that have built systematic, continuous, evidence-based vendor oversight into their operational fabric.

The regulatory framework is converging. The threat landscape is escalating. The question for every organisation is whether their TPRM programme reflects the reality of 2026 — or the assumptions of 2020.

Sources

Primary Breach Data

• Verizon — 2025 Data Breach Investigations Report
• IBM — Cost of a Data Breach Report 2025
• SecurityScorecard — 2025 Global Third-Party Breach Report
• Ponemon Institute / Black Kite — Third-Party Breach Report 2025

Supply Chain Research

• Sonatype — 2024 State of the Software Supply Chain
• Synopsys — 2024 Open Source Security and Risk Analysis Report
• ENISA — Threat Landscape 2024

TPRM Industry Data

• Prevalent — 2025 Third-Party Risk Management Study
• Deloitte — DORA European Survey, 2025 Edition
• ENISA — NIS Investments 2025 Report

EU Regulatory Sources

• NIS2 Directive (EU 2022/2555) — EUR-Lex
• NIS2 Implementing Regulation (EU 2024/2690) — EUR-Lex
• DORA Regulation (EU 2022/2554) — EUR-Lex
• DORA Subcontracting RTS (EU 2025/532) — EUR-Lex
• Cyber Resilience Act (EU 2024/2847) — EUR-Lex

Guidance and Frameworks

• ENISA — Technical Implementation Guidance for NIS2 (June 2025)
• ENISA — Good Practices for Supply Chain Cybersecurity
• NIST SP 800-161 Rev. 1 — C-SCRM Practices
• NIST SP 1305 — CSF 2.0 C-SCRM Quick-Start Guide