Third-Party Data Breaches: What You Need to Know

Why third-party breaches are on the rise, who is being affected, and what you can do about it.

Decorative image

A third-party data breach occurs when malicious actors compromise a vendor, supplier, contractor, or other organization to gain access to sensitive information or systems of the victim’s customers, clients, or business partners.

Third-party data breaches are becoming increasingly common as technology makes it easier for businesses to connect and as global supply chains grow in complexity. Third parties are now involved in 48% of data breaches, a 60% increase over the prior year, according to the 2026 Verizon Data Breach Investigations Report.

What’s more, third-party breaches are among the most expensive for organizations to recover from. The global average cost of a data breach reached $4.99 million in 2026, up 13% from the prior year, and breaches took an average of 247 days to identify and contain, per IBM’s 2026 Cost of a Data Breach Report.

In this article:
  1. Why Third-Party Data Breaches Are Increasing
  2. Financial and Operational Fallout of Major Third-Party Data Breaches
  3. Examples of Prominent Third-Party Security Incidents
  4. How to Respond to a Third-Party Data Breach
  5. Best Practices for Preventing Third-Party Security Breaches Throughout the Vendor Lifecycle
  6. Third-Party Data Breaches: Common Questions
  7. Next Steps for Preventing Third-Party Data Breaches

Why Third-Party Data Breaches Are Increasing

The last decade has seen many large organizations investing heavily in information security. No system can be entirely secure, but heavy investments in cybersecurity make it far more difficult for malicious actors to compromise well-resourced organizations. Hackers are increasingly incentivized to target smaller subcontractors to bypass robust, well-funded cybersecurity programs. Compromising a small HVAC contractor and using that organization as an unwitting Trojan Horse is far easier to accomplish than directly compromising a Fortune 500 company with a fully staffed Security Operations Center and several layers of security controls.

Small businesses have consistently lagged in adopting robust information security practices even though 43% of attacks target them. This enables malicious actors to compromise smaller third parties and either steal data entrusted to them or hijack their access to sensitive systems at larger organizations. Third-party data breaches can be extremely damaging and result in millions of dollars in fines, legal fees, and penalties — along with inordinate reputational damage.

Financial and Operational Fallout of Major Third-Party Data Breaches

The repercussions of a major third-party data breach extend far beyond the initial compromise, striking organizations where it hurts most: their finances, operations, and reputation. When an attacker uses a trusted vendor, supplier, or technology partner as a springboard, the ripple effect can disrupt the entire supply chain—and the numbers speak for themselves.

Financial Consequences

Organizations impacted by third-party data breaches regularly face soaring costs related to incident response, forensic investigations, legal action, regulatory penalties, and customer notifications. In especially severe cases, these costs represent a significant percentage of annual revenue, sometimes tallying in the millions. Insurance claims often pale in comparison to the true financial toll, which includes lost business, diminished market value, and long-term contractual fallout.

Operational Disruptions

A compromised vendor can bring production to a standstill, force the suspension of critical business operations, and derail major projects in a matter of hours. It’s not uncommon for companies to pause manufacturing, close customer-facing platforms, or cut off network access with partners—even if just as a precaution. For manufacturers and logistics-heavy enterprises, even a short disruption can threaten vital profit margins and erode supply chain resilience.

Data Exposure and Reputational Harm

These breaches frequently result in the unauthorized exposure of sensitive information—think employee details, customer data, medical records, or financial credentials. Public disclosure can severely undermine trust with customers, business partners, and regulators, incurring irreparable reputational damage that lingers long after the breach is contained.

Long-Term Effects

Beyond immediate costs and disruptions, third-party data breaches can open the door for subsequent attacks. Compromised credentials or exposed intellectual property may remain active for months or years, thereby increasing ongoing risk and necessitating further investment in remediation and monitoring.

As the risk landscape evolves, it’s clear that the financial and operational impacts of third-party data breaches warrant the same focus and rigor as direct cyber threats. Organizations must act decisively to strengthen controls not just in-house, but across their extended network of partners and suppliers.

Examples of Prominent Third-Party Security Incidents

Third-party data breaches have become far more common in recent years. As the world economy becomes more integrated, data often flows throughout supply chains with little regard for its protection or how it is managed. This has resulted in a “wild west” approach to applying information security controls, as many organizations have little to no idea where their data is throughout the extended supply chain, much less what security measures are being taken to protect it.

Common Third-Party Breach Patterns

The incidents below follow a small number of repeatable patterns. Each one maps to a control that a vendor risk program can test for.

Pattern Example below What attackers gained Control that addresses it
Stolen credentials at a small contractor Retail HVAC contractor (2013) Network access, then payment card and customer data Least-privilege vendor access, network segmentation, MFA
Compromised software update or management tool SolarWinds (2020), Kaseya (2021) Access to thousands of downstream customer environments Fourth-party visibility, patch and update governance, continuous monitoring
Exploited vulnerability in a widely used component Log4j (2021), MOVEit (2023) Remote code execution or database access across many organizations Software inventory, rapid vulnerability triage, vendor attestations
Stolen OAuth tokens in a SaaS integration Sales-engagement platform (2025) Customer CRM data and embedded credentials Integration inventory, token rotation, scoped permissions
Compromised partner API Credit and identity verification provider (2025) Records for 5.8 million individuals API governance, partner security requirements
Supplier outage Automotive parts supplier (2022) Production halted at downstream manufacturers Business continuity planning, supplier concentration analysis

Current event, October 2026: PHP Vulnerabilities

Last updated October 22, 2026.

On October 21, the PHP Foundation (2026) released fixes for two critical vulnerabilities in PHP’s core. CERT-EU (2026) says both can allow unauthenticated remote code execution, that every PHP installation serving web requests is at risk, and that proof-of-concept exploits had begun to circulate. The UK’s NCSC (2026) says organizations using any version of PHP are affected.

This is a third-party problem because, according to CERT-EU (2026), many commercial and open-source products use PHP as a backend technology, so exposure can sit inside software you did not install yourself. The NCSC (2026) advises organizations to:

  • Identify PHP systems across the infrastructure, internet-facing ones first, and not only outdated versions.
  • Update to the latest PHP release, or apply the PHP Foundation’s temporary mitigations if they cannot.
  • Consider taking a system offline if neither is possible.
  • Monitor vendor security updates for bundled PHP, including appliances and services.

2026 Third-Party Data Breaches

Aesto Health

Aesto Health, a Birmingham, Alabama company that provides data migration, EHR exchange, and legacy data archiving services to medical practices, confirmed in 2026 that an unauthorised actor may have accessed and/or acquired data. Aesto reported to the U.S. Department of Health and Human Services that 9,540,683 individuals were affected, according to the HHS Office for Civil Rights breach portal, and its notice of data security incident describes the incident. The exposed data included Social Security numbers, driver’s license numbers, financial account numbers, and medical and health insurance information. One vendor held the records of at least two dozen provider clients at once, which is the concentration risk that third-party breaches exploit.

Vimeo and Anodot

In April 2026, Vimeo disclosed that an unauthorized actor had accessed certain Vimeo user and customer data through a breach at Anodot, a third-party analytics vendor. According to Vimeo’s incident notice, the accessed databases mainly held technical data, video titles and metadata, and in some cases customer email addresses, and did not include video content, valid login credentials, or payment card information. Vimeo disabled all Anodot credentials, removed the integration, and notified law enforcement. For Vimeo’s customers, Anodot was a fourth party: a supplier they had no direct relationship with.

2025 Third-Party Data Breaches

700Credit Data Breach

In December 2025, 700Credit, a provider of credit and identity verification services for automotive dealerships, disclosed a data breach caused by unauthorized access to a third-party API. The incident, traced to a compromise of a partner system in July 2025 and identified in late October, allowed attackers to access the 700Credit web application and copy records from the 700Dealer.com application layer, affecting dealership customers who rely on its verification tools.

The breach exposed personal information for approximately 5.8 million individuals, including names, addresses, dates of birth, and Social Security numbers. While 700Credit stated its internal network was not compromised, the incident required extensive notifications and 12 months of credit monitoring for affected individuals. The event highlights the inherent risks of interconnected vendor ecosystems, reinforcing that security weaknesses in third-party systems can bypass internal controls and create widespread downstream impacts if API access and partner security are not tightly governed.

Sales-Engagement Platform OAuth Token Theft

Between March and June 2025, attackers tracked as UNC6395 accessed a sales-engagement vendor’s source code repository account, then reached the cloud environment behind the vendor’s chat integration and exfiltrated OAuth tokens that customers had issued. Between August 8 and 18, the attackers used those tokens to query customers’ CRM instances, pulling data from objects such as Cases, Accounts, Users, and Opportunities and searching it for credentials including cloud access keys, passwords, and data warehouse tokens. Those credentials created a risk of further compromise well beyond the CRM.

On August 20, the vendor and the CRM provider revoked all active access and refresh tokens, and the CRM provider removed the integration from its app marketplace. Tokens for the vendor’s email integration were also abused to reach a very small number of corporate email accounts. No official count of affected organizations has been published; researchers described hundreds of CRM tenants as targeted. Customers were urged to rotate credentials and review logs for misuse. The incident underscores how third-party SaaS integrations and OAuth connections can become high-value attack vectors, reinforcing the need for tighter vendor oversight, credential hygiene, and proactive monitoring.

2023 Third-Party Data Breaches

MOVEit Managed File Transfer Vulnerability

On May 31, 2023, the software vendor behind MOVEit Transfer disclosed a vulnerability that enables unauthenticated actors to access the MOVEit Transfer database and execute SQL statements to alter or delete information. MOVEit Transfer is managed file transfer software that consolidates file transfer activity into one system.

Since the disclosure, the cybercriminal gang Clop has exploited the vulnerability to target organizations across multiple industries and geographies, including HR software provider Zellis, the BBC, the government of Nova Scotia, and many others.

London Metropolitan Police

In August 2023, the London Metropolitan Police experienced a breach from an apparent ransomware attack against an IT supplier, Digital ID. The sensitive information of nearly 47,000 law enforcement officers and staff, including undercover and counterterrorism cops, was exposed. The compromised information included sensitive data, such as officer’s and staff’s names, photos, ranks, vetting levels, and identification numbers.

2022 Third-Party Data Breaches

LastPass Data Breach

On December 22, 2022, password management company LastPass announced that an unknown threat actor leveraged information obtained during an August 2022 security incident to access a third-party cloud-based storage service that LastPass uses to store archived backups.

Kojima Industries Supplier Attack Halts Japanese Auto Production

On February 28, 2022, a major Japanese automaker announced it would suspend 28 production lines at 14 plants in Japan the following day because of a system failure at Kojima Industries, an automotive parts supplier. Other affiliated manufacturers also reported disruptions. The cause of the failure was reported to be a suspected cyberattack that prevented the supplier from communicating with its customer and from monitoring production.

Past Third-Party Data Breaches

Log4J Vulnerability

In December 2021, security researchers discovered CVE-2021-44228, an Apache Log4j Java-based logging library vulnerability. The Log4j vulnerability allows unauthenticated remote code execution and server access—a complete takeover of vulnerable systems. Log4J opened up a massive risk throughout the third-party software ecosystem.

Kaseya Ransomware Supply Chain Attack

Remote Monitoring & Management software attacks have become a primary concern for many IT teams and Managed Services Providers. On July 2, 2021, Kaseya announced that attackers had taken advantage of a vulnerability in the company’s VSA software to stage a ransomware attack against Kaseya’s customers. Dozens of IT service providers and hundreds of downstream customers were affected, resulting in significant damages.

Like the SolarWinds Orion breach and other recent third-party cyber security incidents, this is another example of the potential exponential impact of supply chain attacks on the extended supply chain.

SolarWinds

The SolarWinds supply chain breach, first reported in December 2020, reached roughly 18,000 organizations that installed a compromised update of the Orion network management product, according to SolarWinds’ SEC filing. The SolarWinds supply chain breach continues to wreak havoc on Orion customers worldwide as they continue to identify and mitigat its risks. The list of impacted companies includes major US government agencies:

  • Department of Energy

  • Department of the Treasury

  • Department of Commerce

  • State and local governments

  • Department of State

  • Department of Homeland Security

  • National Institutes of Health

  • The Department of Defense

This security incident dealt a major blow to US national security, revealing major cybersecurity defense flaws.

Target

In 2013, the major retailer Target was hacked in a seminal third-party breach. One of Target’s HVAC contractors fell victim to a phishing attack, and attackers used the contractor’s stolen network credentials to reach Target’s corporate network.

The hackers installed malware on Target’s POS devices, which collected payment card data for roughly 40 million cards between November and December of 2013, along with personal information for up to 70 million customers. The Target breach provides a clear example of how even the best-funded information security programs can be compromised through security exposures in third-party products and services.

How to Respond to a Third-Party Data Breach

Respond to a third-party data breach by confirming what the vendor holds on your behalf, cutting off its access, and starting your own regulatory clocks the moment you learn of the incident, not when the vendor finishes its investigation. The playbook below gives each phase a window and an owner. The phases overlap in practice, so run them in parallel.

Phase Window What to do Owner
1. Triage First 4 hours Get the vendor’s notice in writing. Identify which of your data, systems, and services the vendor holds or touches. Open an incident record and preserve every vendor communication. TPRM lead, Security
2. Contain Hours 0 to 24 Rotate or revoke vendor credentials, API tokens, and integrations. Invoke the contract’s notification and cooperation clauses. Request the vendor’s indicators of compromise. Security, Legal
3. Classify and notify Hours 4 to 72 Decide whether the incident is major under DORA or significant under NIS2, and whether personal data is involved. File the notifications that apply and brief executives. Compliance, CISO, Legal
4. Investigate Days 3 to 30 Obtain the vendor’s forensic findings and a written scope statement that names its subcontractors. Monitor for your data on leak sites. File intermediate reports where required. Security, vendor
5. Report Within one month Submit final regulatory reports. Notify affected customers or individuals where the law requires it. Compliance, Legal
6. Remediate Days 30 to 90 Reassess the vendor’s risk tier, close contract gaps, update your vendor inventory, and decide whether to retain the vendor or offboard it using a vendor offboarding checklist. TPRM lead, Procurement

Teams that already run an incident management process can map these phases onto the preparation, detection and reporting, and lessons-learned steps in Mitratech’s third-party incident response management guide.

Notification Deadlines Under DORA and NIS2

Under DORA, a financial entity must file an initial notification within four hours of classifying an ICT incident as major, and no later than 24 hours after becoming aware of it. The deadline attaches to the financial entity even when the incident began at an ICT third-party provider, which is why contracts need to force fast vendor notice. DORA has applied since January 17, 2025; Mitratech’s DORA guide covers its third-party requirements in full.

Regulation Initial Intermediate Final
DORA, Article 19, with Delegated Regulation (EU) 2025/301, Article 5 Within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware Within 72 hours of the initial notification Within one month of the latest intermediate report
NIS2, Article 23(4) Early warning within 24 hours of becoming aware; incident notification within 72 hours Only when the national CSIRT or competent authority requests it Within one month of the incident notification

NIS2 is a directive, so the operative deadlines sit in each member state’s transposition law. Confirm them for every country where you operate. DORA is a directly applicable regulation and does not need transposition.

What a Vendor Contract Should Say Before a Breach Happens

A vendor contract should set a fixed notification window shorter than your own regulatory deadlines, require cooperation with forensic investigation, and flow the same duties down to subcontractors, the fourth parties covered in Mitratech’s guide to fourth-party vendor tracking. It should also grant audit rights, define data return and deletion, and allocate the cost of notification and remediation. DORA Article 30 requires ICT service contracts to address incident assistance and the conditions for subcontracting, so financial entities already need most of these terms.

Best Practices for Preventing Third-Party Security Breaches Throughout the Vendor Lifecycle

Effectively managing risk throughout the extended supply chain can be difficult, particularly for large organizations. However, there are several steps you can take to better understand your risk environment and mitigate the impact of potential third-party risk. Here are Mitratech’s recommendations to help mitigate the risk of a third-party data breach throughout the vendor lifecycle.

Consider Information Security During Sourcing and Selection

As your IT infrastructure becomes increasingly integrated with third and fourth parties, it is critical to consider information security during vendor sourcing and selection. When considering vendors with a high degree of profiled risk based on their access to your organization’s sensitive data and systems, give precedence to those with demonstrable information security maturity. It is worth asking:

  • Does the vendor work with other enterprise clients with complex information security needs?
  • Does the vendor have the necessary security controls to comply with requirements that would flow down from your organization? (e.g. HIPAA, CMMC, GDPR)
  • What is the vendor’s information security track record? Do they have multiple publicized data breaches or compliance violations?

Consider leveraging third-party risk management software or vendor risk intelligence networks to inform your sourcing and selection process with preloaded cybersecurity risk data.

Set Clear Contractual Expectations for How Data Is Stored and Transferred

Many organizations fail to build their vendor contract management processes with vendor risk management in mind. Your organization should have clear company policies regarding when personal information, customer data, or other sensitive information can be shared with third parties. For example, you might want to consider including clear stipulations regarding when confidential information can be shared with fourth parties and beyond.

Conduct Continuous Monitoring of Third Parties with Access to Sensitive Data or Systems

Vendors should be monitored for unauthorized access to personal data or other proprietary information. Even if the vendor isn’t acting maliciously, their IT systems could have been compromised, resulting in malware spreading to your organization’s systems. Any vendor with access to your IT assets should be monitored for the duration of the access.

In addition, you should practice proactive, external third-party monitoring for all vendors that deal with your confidential information. Organizations change their information security programs over time, and what was originally reported on their vendor risk assessment questionnaire may not hold true a few months later. Additionally, a proactive monitoring approach can help you to catch potential data breaches before they happen. By monitoring the dark web, Pastebin, and other areas where stolen credentials are posted, you can learn if one of your vendors has been compromised.

Pay Attention to Regulatory Requirements

Information security and data privacy regulations have multiplied over the past decade, including GDPR, CCPA, NY Shield Act, and dozens of other compliance requirements. It is highly likely that regulatory scrutiny will continue to mount as new third-party breaches emerge.

Require Vendors to Independently Verify Their Information Security Practices

Third-party risk assessment questionnaires can be enormously helpful in determining whether vendors are taking appropriate information security measures. However, in some cases, you may want to consider requiring potential vendors to become certified against an information security standard. For example, the Department of Defense’s Cybersecurity Maturity Model Certification (CMMC) program requires contractors to be certified at one of three levels, determined by the type of information the contractor handles.

Your organization can take a similar approach in dealing with vendor cybersecurity concerns. For many vendors, particularly those not dealing with large amounts of confidential data, a simple vendor risk assessment questionnaire might suffice. However, for vendors that need access to proprietary data and systems, you might want to consider requiring compliance against an outside standard such as SOC 2 or NIST CSF.

Get Visibility Into the Extended Supply Chain

The first step of any cybersecurity program is to get visibility into IT assets. The same is true for third-party risk. You need to understand not only which third parties are used across the extended enterprise but also who makes up their supply chains down to fourth and Nth party vendors. As a rule, the more critical the vendor is, or the more data they have access to, the more visibility you need into their extended supply chains. The Kaseya and SolarWinds attacks are illustrative examples of how the security practices of fourth parties can have ripple effects throughout the supply chain.

Audit Your Offboarding Process

Effective vendor offboarding is one of the most essential elements of a third-party risk management program and is essential to preventing third-party data breaches. Most organizations have some form of an offboarding process for third parties and contractors, but in a busy corporate environment, it can be overlooked. Make an effort to routinely audit offboarding processes across multiple departments for third-party vendors. Ensure that permissions and access are fully revoked across departments to comply with corporate policy and government regulations.

Third-Party Data Breaches: Common Questions

What is a third-party data breach?

A third-party data breach is a security incident at a vendor, supplier, or service provider that exposes your organization’s data or disrupts your operations, even though your own systems were not breached. The 2026 Verizon Data Breach Investigations Report found third parties involved in 48% of breaches.

How quickly must a vendor breach be reported under DORA and NIS2?

Under DORA, a financial entity must file an initial notification within four hours of classifying an incident as major, and no later than 24 hours after becoming aware of it. An intermediate report is due within 72 hours of that notification, and a final report within one month after the latest intermediate report. NIS2 Article 23 requires an early warning within 24 hours and a full notification within 72 hours.

How should we respond when a widely used component like PHP is found to be vulnerable?

Treat it as an inventory problem first: list every vendor, hosting provider, and appliance that bundles the component, because the exposure often sits beneath products you did not install yourself. Ask each vendor for its patch status in writing, then apply vendor fixes or compensating controls and watch for signs of compromise. If patching is not possible, the NCSC advises considering taking the system offline.

What should a vendor contract say about breach notification?

A vendor contract should set a fixed notification window shorter than your own regulatory deadlines, require cooperation with forensic investigation, flow the same duties down to subcontractors, grant audit rights, define data return and deletion, and allocate notification and remediation costs. DORA Article 30 requires ICT service contracts to address incident assistance and the conditions for subcontracting.

What are the first steps after a vendor reports a breach?

Confirm what data and services the vendor holds for you, then start your own regulatory clocks. Within 24 hours, activate your incident response team, preserve vendor communications as evidence, invoke the contract’s notification and cooperation clauses, rotate shared credentials, and identify which regulators and customers you must notify. Ask the vendor for a written scope statement that names any subcontractors involved.