---
title: "Third-Party Data Breach: Causes, Costs, and Prevention"
date: 2026-09-08T17:05:01Z
modified: 2026-09-08T17:05:01Z
permalink: "https://www.venn.com/learn/third-party-data-breach/"
type: knowledge
status: publish
excerpt: ""
wpid: 7549
featured_image: "https://www.venn.com/wp-content/uploads/2026/09/shutterstock_2734672685-scaled.jpg"
parent: ""
ancestors: []
children: []
timestamp: 2026-09-08T17:05:01Z
tags:
  - Third Party Risk
---

## **What Is a Third-Party Data Breach?**

A third-party data breach is a security incident where an organization’s sensitive information is exposed because of a vulnerability or attack on an external vendor, supplier, or partner. The company that owns the data didn’t get hacked directly; its vendor did, and the vendor’s access or systems became the way in.

Two things make vendors an attractive way in. Vendors often have less security control than the primary company, and contractors and service providers frequently receive direct entry to internal networks and cloud storage. Up to 30% or more of all data breaches now trace back to an outside third party.

This is different from a typical breach in one important way: the affected company often has little visibility into the vendor’s security posture until something goes wrong. A payroll processor, a managed file transfer tool, a contractor’s personal laptop, or a SaaS integration can all serve as the entry point. The data compromised is still the company’s data, and its customers, employees, or patients still bear the consequences, even though the company’s own network was never touched.

**Common attack methods:**

- **Stolen credentials:** Hackers steal vendor login details through phishing, then reuse them against every connected system they can reach.
- **Cloud misconfigurations:** Poorly secured storage buckets or APIs on a vendor’s side leak data with no attack required.
- **Malicious software updates:** Malicious code is injected into widely used vendor software tools and reaches every organization that installs it.
- **Vulnerable file transfer and integration tools:** One unpatched flaw in a tool that moves data becomes a shortcut into thousands of downstream organizations.
- **Unmanaged contractor devices:** Vendor work on personal laptops the company does not control exposes everything those devices touch.
- **Over-privileged and orphaned access:** Broad vendor permissions, stale contractor logins, and standing OAuth tokens stay active long after anyone is watching them.

**Prevention and response:**

- **Limit access:** Use strict network segmentation and multi-factor authentication for all partners, with least privilege as the default.
- **Tier your vendors:** Rank vendors by the data and systems they can reach, and concentrate scrutiny on the riskiest few.
- **Continuous checks:** Monitor vendor security posture in real time rather than relying on annual surveys.
- **Isolate unmanaged devices:** Keep third-party work inside a company-controlled enclave on the contractor’s own laptop.
- **Contain fast:** Isolate affected systems immediately upon discovery while preserving logs for forensic experts.

**This is part of a series of articles about third party risk \[coming soon\].**

Secure Company Data on BYOD Laptops

Unlock the 4 essential assets you need to secure company data on unmanaged laptops – without VDI.



 





![](https://www.venn.com/wp-content/uploads/2025/10/toolkit-group-A.png)







## In this article:

- [What Is a Third-Party Data Breach?](#h-what-is-a-third-party-data-breach)
- [Third-Party, Fourth-Party, and Supply Chain Breaches: How They Differ](#h-third-party-fourth-party-and-supply-chain-breaches-how-they-differ)
- [How Common Third-Party Data Breaches Are: Key Statistics](#h-how-common-third-party-data-breaches-are-key-statistics)
- [How Third-Party Data Breaches Happen](#h-how-third-party-data-breaches-happen)
- [Recent Third-Party Data Breaches and What Caused Them](#h-recent-third-party-data-breaches-and-what-caused-them)
- [The Cost and Legal Fallout of a Third-Party Breach](#h-the-cost-and-legal-fallout-of-a-third-party-breach)
- [Who Is Legally Responsible When a Vendor Is Breached](#h-who-is-legally-responsible-when-a-vendor-is-breached)
- [How to Respond When a Vendor Reports a Breach](#h-how-to-respond-when-a-vendor-reports-a-breach)
- [Best Practices to Prevent Third-Party Data Breaches](#h-best-practices-to-prevent-third-party-data-breaches)
- [Conclusion](#h-conclusion)



## **Third-Party, Fourth-Party, and Supply Chain Breaches: How They Differ**

These terms get used interchangeably, but they describe different layers of exposure.

A third-party breach involves a vendor your company has a direct relationship with, such as a software provider, staffing agency, or contractor. A fourth-party breach is one step further removed: it’s a breach at a vendor’s vendor, a subcontractor or supplier your company never signed a contract with, but whose failure still puts your data at risk. Supply chain breaches are the broadest category, covering any compromise that moves through a chain of interconnected vendors, software dependencies, or hardware providers to reach the ultimate target.

The practical difference is visibility. Most companies can name their direct vendors. Very few can map the vendors those vendors rely on, which is exactly why fourth-party risk tends to go unmanaged until an incident forces the question.

## **How Common Third-Party Data Breaches Are: Key Statistics**

Third-party risk isn’t a niche concern anymore; it’s become one of the dominant ways breaches happen.

- Third-party involvement in breaches roughly doubled year over year, according to IBM’s 2025 Cost of a Data Breach [Report](https://www.ibm.com/think/x-force/2025-cost-of-a-data-breach-navigating-ai), climbing from about 15% to 30% of incidents.
- Breaches involving vendor and supply chain compromise now average $4.91 million to contain, among the costliest attack vectors IBM tracks.
- Those same breaches take longer to catch: 267 days on average to detect and contain, largely because they exploit the trust between a company and its vendor rather than a direct attack on the company’s own defenses.

The pattern behind the numbers is consistent: attackers have learned that the easiest way into a well-defended company is through a less-defended vendor. Vendors often have less security control than the primary company, while contractors and service providers still receive direct entry to internal networks and cloud storage. That combination is what turns a single weak link into a route past the defenses of every organization behind it.

## **How Third-Party Data Breaches Happen**

Third-party breaches tend to trace back to a handful of recurring failure points:

- **Stolen or reused vendor credentials.** Vendor employees and contractors reuse passwords across personal and work accounts. Once one account is compromised through phishing or an unrelated leak, attackers test those credentials against every connected system they can find.
- **Vulnerabilities in third-party software and managed file transfer tools.** File transfer and integration platforms sit between companies and their data by design, which makes a single unpatched flaw in one of these tools a shortcut into thousands of downstream organizations at once.
- **Malicious code injected into vendor software updates.** Attackers compromise a software vendor’s build or update pipeline so that malicious code is injected into widely used vendor software tools. Every organization that installs the signed update inherits the compromise, which is what makes this route so efficient: one poisoned release reaches every customer at once.
- **Cloud misconfigurations in a vendor’s environment.** Poorly secured storage buckets or APIs leak data without anyone needing to break in. Because the misconfiguration sits in the vendor’s cloud account rather than yours, the company whose data is exposed usually has no way to see the gap and no way to close it.
- **Contractor and vendor access from unmanaged personal laptops.** Contractors and outsourced teams frequently work from personal devices the company doesn’t control. Without a way to isolate business activity on those laptops, one infected or poorly secured device can expose everything it touches — a risk covered in more depth in Venn’s guide to[ BYOD security best practices](https://www.venn.com/wp-content/uploads/wp-mfa-exports/knowledge/byod-security-best-practices.md).
- **Over-privileged and orphaned vendor accounts.** Vendor accounts are often provisioned broadly to avoid friction, then never revisited. Accounts for contractors who left months ago frequently stay active, giving attackers a door nobody is watching.
- **Compromised SaaS integrations and OAuth tokens.** Connected apps and API tokens grant standing access between systems. If a vendor’s environment is breached, any OAuth token or integration it holds becomes a second path into every company it connects to.

## **Recent Third-Party Data Breaches and What Caused Them**

A few incidents illustrate how differently third-party breaches can unfold, and how far the damage can spread from a single point of failure.

### **MOVEit File Transfer Exploitation (2023)**

The CL0P ransomware group exploited a SQL injection flaw in Progress Software’s MOVEit Transfer application, a managed file transfer tool used by thousands of organizations to move sensitive data between systems. According to CISA’s [advisory](https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a) on the campaign, the flaw let attackers access underlying databases without needing valid credentials. Because MOVEit sat inside so many organizations’ data pipelines, a single vulnerability rippled outward to a long list of downstream companies whose data passed through vendors using the tool — including many that had never heard of MOVEit before the breach.

### **Change Healthcare Ransomware Attack (2024)**

A ransomware attack against Change Healthcare, a claims-processing vendor that sits between insurers, pharmacies, and healthcare providers, disrupted prescription and billing operations across the U.S. healthcare system for weeks. The attackers reportedly gained access through a remote-access login that lacked multi-factor authentication. Because so many healthcare organizations relied on this single vendor to process claims, the resulting outage and data exposure became one of the most disruptive healthcare incidents in U.S. history – despite none of the affected patients’ own providers being breached directly.

### **Snowflake Customer Account Compromises (2024)**

Rather than breaching Snowflake’s own infrastructure, attackers used login credentials stolen through unrelated malware infections to access customer accounts on the cloud data platform. The accounts that were compromised shared one thing in common: none required multi-factor authentication. From there, attackers extracted and extorted data from a range of well-known companies that used Snowflake to store customer records — a reminder that a breach can originate entirely from customer-side security gaps in a vendor’s platform, not the vendor’s own code.

## **The Cost and Legal Fallout of a Third-Party Breach**

### **Direct Costs, Regulatory Fines, and Class Action Litigation**

Beyond the cost of investigation and containment, a third-party breach typically triggers regulatory scrutiny, mandatory notification costs, and often class action litigation from affected customers or employees. Because the data was entrusted to a vendor, companies frequently face the added expense of contract disputes over who bears liability — a question that’s rarely settled quickly or cheaply.

### **Operational Disruption and Loss of Customer Trust**

The disruption often outlasts the breach itself. When a vendor that supports a core process goes offline, so does the business that depends on it, as the Change Healthcare incident showed at national scale. Longer term, customers and partners remember whose name was on the breach notification, regardless of whose systems actually failed.

## **Who Is Legally Responsible When a Vendor Is Breached**

### **How Regulators Assign Accountability Between Controller and Processor**

Most data protection frameworks distinguish between the company that decides how data is used (the controller) and the vendor that processes it on the company’s behalf (the processor). In practice, this means the company that collected the data is usually still accountable to regulators and customers even when a vendor’s failure caused the exposure — outsourcing the work doesn’t outsource the liability.

Some frameworks now hold processors to direct obligations of their own. GDPR, for example, can fine a processor directly for failing to maintain adequate security or for missing its own duty to notify the controller once it discovers a breach. But that doesn’t relieve the controller of its reporting and remediation obligations — regulators still expect the controller to have vetted the vendor before the breach, not just responded well after it. Indemnification clauses can shift who pays for damages between the two companies, but they don’t shift who a regulator or a court holds responsible in the first place.

### **Breach Notification Deadlines Under GDPR, HIPAA, SEC, and DORA**

Notification clocks start the moment a breach is discovered, and they don’t wait for a company to finish investigating:

- **HIPAA:** covered entities must[ notify](https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html) affected individuals and HHS without unreasonable delay, and no later than 60 days after discovery — a deadline that applies just as much to a breach at a business associate as to one inside a covered entity’s own walls (see Venn’s[ HIPAA compliance](https://www.venn.com/wp-content/uploads/wp-mfa-exports/knowledge/hipaa-compliance.md) guide for the full requirements).
- **SEC:** U.S. public companies must disclose on Form 8-K within four business days of determining an incident is material.
- **GDPR:** companies must notify the relevant supervisory authority within 72 hours of becoming aware of a breach.
- **DORA:** the EU’s framework layers on its own multi-stage reporting timeline for financial entities.

None of these clocks defer to one another. A company subject to more than one framework has to satisfy each deadline independently, even when the underlying breach happened inside a vendor’s environment.

Secure Company Data on BYOD Laptops

Unlock the 4 essential assets you need to secure company data on unmanaged laptops – without VDI.



 





![](https://www.venn.com/wp-content/uploads/2025/10/toolkit-group-A.png)







## **How to Respond When a Vendor Reports a Breach**

When a vendor discloses a breach, the first hours matter as much as the first days:

1. **Confirm the incident and get written facts from the vendor.** Get specifics in writing — what was accessed, when, and how — rather than relying on a verbal summary that may change later.
2. **Suspend vendor access and contain exposure in your own environment.** Disable or restrict the vendor’s credentials and connections until the scope is understood, even if that temporarily slows down work. Isolate affected systems immediately upon discovery while preserving logs for forensic experts, since containment that wipes the evidence makes the next two steps far harder.
3. **Determine which records and systems were affected.** Cross-reference the vendor’s disclosure against your own logs and data flows; vendors don’t always know what downstream systems they touched.
4. **Notify regulators, customers, and internal stakeholders.** Once scope is clear, trigger the appropriate notification timelines and keep legal, security, and communications teams aligned on a single account of events.

## **Best Practices to Prevent Third-Party Data Breaches**

### **Tier Vendors by the Data and Systems They Can Reach**

Not every vendor deserves the same scrutiny. Rank vendors by the sensitivity of the data they touch and the systems they can reach, and put the most rigorous controls around the small number that carry the most risk.

A workable tiering model usually needs no more than three or four tiers, sorted by the sensitivity of the data a vendor touches, whether it can reach production systems, and how deeply it’s embedded in a critical process. A payroll provider with access to employee bank details and Social Security numbers belongs in the top tier next to any vendor with standing access to customer records or source code; a vendor that only receives an anonymized marketing list belongs several tiers down. Once vendors are tiered, let the tier set the requirements automatically — top-tier vendors get security questionnaires, audits, and contractual audit rights, while low-tier vendors get a lighter one-time review.

### **Write Security, Audit, and Breach Notification Terms Into Contracts and DPAs**

Security expectations that live only in a slide deck don’t hold up during an incident. Put audit rights, minimum security controls, and specific breach notification timelines directly into vendor contracts and data processing agreements before access is granted, not after.

Specificity matters more than length here. A DPA that simply requires a vendor to maintain “reasonable security measures” gives a company almost nothing to enforce after a breach; a contract that spells out encryption standards, access control requirements, subcontractor approval rights, and a notification deadline measured in hours rather than vague language gives the company a concrete basis for both prevention and recourse.

### **Isolate Third-Party Work on Unmanaged Devices Using a Secure Enclave**

Contractors and offshore teams usually work on personal laptops the company doesn’t own, which makes it hard to trust the device itself. One organization facing this exact [problem](https://www.venn.com/wp-content/uploads/wp-mfa-exports/blog/addressing-contractor-security-a-200k-laptop-spend-or-blue-border.md), after discovering signs of compromised contractor accounts, weighed spending roughly $200,000 to issue and manage company laptops instead. It chose a different path: isolating business activity in a company-controlled secure enclave on the contractor’s own device, protecting company data without taking over the whole machine or the cost and logistics of a hardware rollout. Blue Border™ by Venn works this way by design.

Installing Blue Border on a Mac or PC creates a company-controlled secure enclave directly on that device: business apps and data run inside it while everything outside stays private and inaccessible to IT. That means a phishing email opened in a personal browser tab, or malware picked up from a personal download, never has a path to company files, credentials, or SaaS sessions, even though the device itself was never touched, managed, or wiped. Compared with a $200,000 hardware rollout, a secure enclave protects the business side of the device without the cost, provisioning delay, or logistics of shipping and recovering laptops for every contractor engagement.

### **Replace Annual Questionnaires With Continuous Vendor Monitoring**

A security questionnaire answered once a year tells you almost nothing about a vendor’s posture the other 364 days. Continuous monitoring and ongoing[ data loss prevention](https://www.venn.com/wp-content/uploads/wp-mfa-exports/knowledge/dlp.md) controls catch drift and new exposure as it happens, rather than at the next scheduled review. Monitor vendor security posture in real time rather than relying on annual surveys, so a lapsed certification, a newly exposed service, or a change in subprocessors surfaces when it happens instead of at renewal.

Continuous monitoring works because it looks at signals a questionnaire can’t capture on its own: newly exposed services, expired certificates, leaked credentials appearing on dark web forums, security ratings pulled from external scans, and changes in a vendor’s own subprocessor list. None of this requires the vendor’s cooperation to detect, which is exactly the point — a vendor under pressure to look compliant on a self-reported questionnaire has an incentive that continuous, externally sourced monitoring simply removes.

### **Enforce Least Privilege, MFA, and Time-Limited Access for Vendor Accounts**

Every vendor account should start with the minimum access needed and nothing more. Multi-factor authentication should be non-negotiable — its absence is a common thread running through several of the largest breaches on record — and access should expire automatically rather than depend on someone remembering to revoke it. Use strict network segmentation alongside multi-factor authentication for all partners, so a vendor account that does get compromised can only reach the systems it was provisioned for and not the rest of the environment. Purpose-built[ endpoint DLP](https://www.venn.com/wp-content/uploads/wp-mfa-exports/blog/endpoint-dlp.md) controls make it possible to enforce these policies on vendor-owned devices without managing the device itself.

Time-limited access closes a gap that least privilege alone doesn’t: even a correctly scoped account becomes a liability if it stays active after the engagement that justified it ends. Provision vendor and contractor accounts with an expiration date tied to the contract or project timeline by default, and require an explicit renewal — rather than an explicit revocation — to keep access alive, so the burden falls on justifying continued access rather than on someone remembering to remove it.

### **Map Fourth-Party Dependencies Behind Your Critical Vendors**

Ask critical vendors to disclose the subcontractors and platforms they rely on, particularly for any vendor that touches sensitive data or a core business process. You can’t assess a risk you don’t know exists.

In practice, this means adding a specific clause to vendor contracts requiring disclosure of material subcontractors and any change in that list, not just a one-time questionnaire answer. For vendors in the top risk tier, ask which cloud provider, payment processor, or infrastructure partner they depend on for the service you’re buying, and whether that dependency is single-sourced or redundant. This won’t produce a complete fourth-party map, but it surfaces the handful of concentrated dependencies, such as a shared cloud region or a common subcontractor across several of your vendors, that would otherwise stay invisible until one of them has an incident.

### **Audit the Offboarding Process to Revoke Access and Recover Data**

Offboarding a contractor or terminating a vendor relationship should trigger an immediate, auditable process: revoke credentials, confirm data deletion or return, and close out any lingering integrations or API tokens. Orphaned access left over from a relationship that ended months ago is one of the easiest problems to fix and one of the most common to overlook.

Build offboarding into the same system that tracks vendor onboarding and access grants, so ending a contract automatically triggers a checklist rather than depending on someone remembering to loop in IT. That checklist should cover every system the vendor or contractor touched — VPNs, SaaS applications, shared drives, API keys, and any secure enclave or workspace used for the engagement — not just the primary system most people think of first.

## **Conclusion**

Third-party data breaches keep growing because most companies still manage vendor risk the way they did a decade ago: a security questionnaire at signup, broad access, and little visibility after that. The breaches covered here — MOVEit, Change Healthcare, Snowflake — didn’t succeed because attackers found a novel technique. They succeeded because a vendor relationship carried more trust and access than anyone was actively managing.

None of the fixes require trusting every vendor completely or managing every device they use. Tiering vendor risk, enforcing least privilege and MFA, monitoring continuously instead of annually, and isolating business activity on unmanaged devices all shrink the number of ways a vendor’s bad day becomes your breach notification. If contractor and vendor access on unmanaged devices is the gap you haven’t closed yet, that’s exactly where Venn’s Blue Border™ is worth a look.

 Securing contractors and remote employees doesn’t have to be a pain. For years, IT teams were stuck choosing between virtual desktops that are slow, complex, and expensive. Or buying, locking down, and shipping laptops across the globe. Thankfully, there’s a better way. Introducing Venn, a breakthrough in remote work security. Venn creates a secure enclave on any unmanaged PC or Mac used by contractors and remote employees. No VDI, no need to fully manage the device, and no compromise on security and compliance. Work applications run locally within the enclave, visually indicated by Venn’s blue border, protecting and isolating work from personal activity on the same computer. Both browser and installed apps run locally, natively, and securely. No hosting and no virtualization whatsoever. This approach preserves full app performance and user experience, while ensuring your organization’s DLP policies are always enforced. No file transfers, copy paste screenshots, or any other actions that could lead to data loss or compromise. Ready to see the future of remote work? Well, on behalf of all of us at Venn, we invite you to step inside the blue border. Find out more at Venn dot com.