The modern company rarely holds all of its own data in one place. Customer names may sit in a customer relationship management platform, payment details may be processed by a merchant vendor, employment records may be stored in a payroll system, medical or insurance information may be handled through a specialty portal, and marketing lists may be synchronized across multiple analytics tools. This networked model allows businesses to scale quickly, but it also creates a hard legal and commercial question when something goes wrong. When a software provider is breached and customer data is exposed, who pays? The answer is rarely simple. The vendor may have caused the breach, but the business that collected the data may still face customer anger, regulatory inquiries, notification duties, operational disruption, and reputational harm. In many cases, the cost of the breach moves through the commercial chain like falling dominoes.
The “vendor data breach cascade” is the sequence of losses, obligations, claims, and disputes that follows a compromise at a software provider. It begins with the intrusion itself, but it does not end when the vendor announces that unauthorized access occurred. A breach at a vendor can trigger forensic investigations, customer notices, call centers, credit monitoring, regulatory reporting, contract indemnity demands, insurance claims, class action litigation, public-company disclosure analysis, and board-level governance review. Each participant in the chain tries to determine whether the loss belongs to someone else. The vendor may argue that its contract limits damages. The customer may argue that the vendor failed to provide reasonable security. Insurers may dispute whether a policy covers third-party breach costs. Regulators may examine whether either party misled consumers or failed to maintain appropriate safeguards. The affected individuals may not care who hosted the data; they may only know that the company they trusted allowed their information to be exposed.
The first and most important point is that data responsibility and data custody are not the same thing. A software provider may possess or process data, but the business that collected the data from consumers often remains accountable to those consumers. In privacy law, contract law, and public perception, the company with the direct customer relationship is usually the first place people look for answers. This is why a vendor breach can be so damaging to the vendor’s customers. The customer company may not have operated the compromised system, written the insecure code, misconfigured the storage environment, or ignored the alert. Yet it may still be the entity whose brand appears in the notice letter, whose employees answer the phone, whose customers demand reassurance, and whose executives must explain why a third party was allowed to handle sensitive information in the first place.
That distinction between possession and accountability is one reason vendor contracts matter so much. The contract is often the first document lawyers review after a breach. It may define confidential information, personal information, security obligations, audit rights, notification deadlines, cooperation duties, indemnity rights, limitation-of-liability clauses, insurance requirements, and procedures for handling regulatory inquiries. If the contract is strong, it may require the vendor to reimburse the customer for notice costs, forensic costs, credit monitoring, legal fees, regulatory fines to the extent legally transferable, and third-party claims caused by the vendor’s failure to meet its security obligations. If the contract is weak, the customer may discover that its recovery is capped at twelve months of fees, that consequential damages are excluded, or that the vendor’s duty to indemnify applies only to narrow intellectual-property claims rather than privacy or security failures.
The practical problem is that breach losses often exceed the value of the vendor contract. A business may pay a software provider a few thousand dollars a year to host a database, but the breach of that database may expose hundreds of thousands of customer records. If the contract caps liability at fees paid, the customer may be left with losses far beyond what it can recover from the vendor. This mismatch is especially common with small and mid-sized businesses that accept standard online terms without negotiation. Those terms may be written to preserve the vendor’s recurring revenue model, not to make the customer whole after a large security event. In that setting, the legal answer to “who pays” may be very different from the moral or business answer. The vendor may have been at fault, but the customer may still bear the largest portion of the loss.
The Federal Trade Commission’s Blackbaud matter is a useful example of how regulators view vendor security. Blackbaud provided software and data services to organizations that relied on it to store sensitive information. The FTC alleged that security failures allowed a hacker to access personal data belonging to millions of consumers, including highly sensitive information. The agency also alleged that Blackbaud delayed telling customers and misrepresented the scope of the data involved. The final order required, among other things, data deletion and security measures, reinforcing the point that a vendor can face direct regulatory consequences when its own practices contribute to a breach. ¹ The case is important because it shows that vendors are not invisible middlemen. They can be treated as independent actors with independent duties, especially when they collect, maintain, process, or secure personal information at scale.
At the same time, a regulatory action against the vendor does not automatically solve the customer’s problem. If a nonprofit, hospital, school, retailer, or professional services firm entrusted data to the vendor, that organization may still have had to communicate with its own constituents, analyze state breach notification laws, determine whether protected categories of information were involved, and manage the reputational fallout. The vendor’s regulatory exposure may be real, but it does not necessarily reimburse every affected customer for every downstream cost. The cascade therefore includes two parallel tracks: public accountability imposed by regulators and private cost allocation governed by contracts, insurance, and litigation.
The notification stage is often where the cascade becomes visible. Once a vendor discovers or confirms unauthorized access, it typically has a duty under contract to notify its business customers. Those customers then determine whether they have legal obligations to notify individuals, regulators, consumer reporting agencies, business partners, or other stakeholders. The timing can become contentious. Customers want prompt, detailed information so they can meet legal deadlines and communicate accurately. Vendors may be reluctant to provide definitive statements before the forensic investigation is complete. Early notice may be incomplete, but delayed notice may create legal risk. A poorly drafted contract can leave this tension unresolved, allowing the vendor to provide vague updates while the customer’s statutory clock keeps running.
Even when the law technically places notification duties on the vendor, the customer often has a strong business reason to participate in the notice process. Customers may expect to hear from the company they know, not from a software provider they have never heard of. The notice must also be accurate. If the vendor understates the categories of data involved, the customer may repeat that understatement in its own communications and later face claims that it misled consumers. If the vendor overstates the breach, the customer may create unnecessary alarm. In a vendor breach, accuracy is not merely a technical issue; it is a liability issue. The party that communicates the wrong facts may become a target even if it did not cause the intrusion.
Public companies face another layer of analysis. The Securities and Exchange Commission’s cybersecurity disclosure rules require public companies to disclose material cybersecurity incidents under Item 1.05 of Form 8-K, generally within four business days after determining that the incident is material. ² A vendor breach may create difficult judgment calls under that rule. The affected public company must assess whether the incident is material to investors even if the compromised system was operated by a third party. The analysis may include the type of data involved, operational disruption, remediation costs, litigation exposure, regulatory risk, customer impact, and reputational harm. A company cannot assume that a breach is immaterial simply because the intrusion occurred outside its own network.
This is one reason cyber risk has moved from the IT department to the boardroom. A vendor breach can expose weaknesses in vendor selection, procurement, contract review, information governance, and incident response planning. Directors and officers may ask whether the company knew what data the vendor held, whether the vendor’s security controls were reviewed before onboarding, whether the contract required prompt notice and cooperation, whether the vendor had adequate insurance, and whether the company had an exit plan if the platform became unavailable. These are governance questions, not merely technical questions. When the breach occurs, it may be too late to build the structure that should have existed before the vendor received the data.
The financial cost of a breach can be substantial. IBM’s 2025 Cost of a Data Breach Report placed the global average cost of a data breach at $4.44 million, while also emphasizing that breach costs vary significantly based on factors such as industry, response speed, data type, and security maturity. ³ Average figures do not predict the cost of any specific incident, but they help illustrate why cost allocation matters. A single vendor breach can produce legal fees, forensic fees, public relations expenses, customer support costs, technology remediation, ransom-related issues, lost productivity, lost customers, and higher insurance premiums. Even when no regulator imposes a fine and no lawsuit succeeds, the internal cost of responding can be significant.
The vendor’s costs are different but equally real. A breached software provider may have to investigate the intrusion, preserve evidence, patch vulnerabilities, rebuild systems, notify its own customers, respond to regulators, defend lawsuits, pay for credit monitoring, negotiate with insurers, and manage customer termination demands. If the vendor serves many businesses, one security incident may generate hundreds or thousands of customer-specific disputes. Each customer may demand customized information, indemnification, and written assurances. The vendor may also lose future sales because prospects will ask about the incident during procurement. In the software market, trust is part of the product. A breach can damage that trust even after the technical vulnerability is fixed.
The customer’s costs are often less visible but more personal. The customer may have to divert employees from normal work to handle breach response. It may need outside counsel to analyze state, federal, industry-specific, and contractual obligations. It may need to prepare customer notices, scripts, website postings, regulatory submissions, and internal talking points. It may need to answer questions from banks, business partners, auditors, investors, and insurers. If the affected data belongs to patients, students, employees, donors, or financial customers, the communications may require special care. The customer may also face a credibility problem. Saying “our vendor was breached” may be true, but it may not satisfy customers who believe the company should have chosen a safer vendor.
Individuals whose information was exposed may suffer anxiety, time loss, identity-theft risk, financial fraud, account takeover, phishing, or targeted scams. In litigation, plaintiffs often argue that the business and the vendor both failed to use reasonable security and that both benefited from collecting or processing the data. Defendants often respond that no concrete injury occurred, that the data was not misused, that the vendor was the responsible party, or that the customer’s claims are barred by contract. The result depends on the facts, the jurisdiction, the data involved, the theory of harm, and the available evidence. But from a practical standpoint, individuals usually sue the entities they can identify and connect to the data relationship. That may include both the software provider and the business that hired it.
Indemnity is the contractual mechanism most directly aimed at answering “who pays.” In a well-drafted data security agreement, the vendor agrees to defend and indemnify the customer for losses arising from the vendor’s breach of confidentiality, violation of law, failure to maintain required safeguards, unauthorized disclosure, or security incident caused by the vendor’s acts or omissions. But indemnity language varies widely. Some clauses cover only third-party claims, meaning they may not reimburse first-party response costs such as forensic investigation, notice letters, call centers, or credit monitoring. Some clauses exclude regulatory fines or penalties. Some clauses require a final adjudication before indemnity applies, which can delay reimbursement for years. Some clauses are overridden by limitation-of-liability provisions unless privacy and security claims are expressly carved out.
Limitation-of-liability clauses are often the battleground. Vendors understandably seek predictable exposure. They do not want one incident to threaten the company’s survival. Customers understandably want meaningful recovery if the vendor mishandles sensitive data. The compromise is often a separate liability cap for privacy and security claims. For example, a contract may provide a general cap equal to twelve months of fees but a higher cap for data breaches, confidentiality breaches, gross negligence, willful misconduct, or indemnity obligations. The strongest customer-side contracts may exclude certain data breach obligations from the cap entirely, though vendors may resist that position. The key is clarity. If the parties intend to cover breach-related notice costs, regulatory costs, and third-party claims to be recoverable, the contract should say so before the incident happens.
Insurance is another major source of payment, but it is not a cure-all. A vendor may carry cyber liability insurance that covers incident response, legal defense, notification, credit monitoring, business interruption, extortion, and certain third-party claims. The customer may also carry its own cyber policy. After a vendor breach, both sides may tender claims. Coverage may depend on policy wording, exclusions, waiting periods, retention amounts, definitions of computer systems, definitions of dependent business interruption, and whether the incident occurred at a third-party service provider. Some policies cover breaches involving data held by vendors; others may limit that coverage or require specific endorsements. Insurance can fund the response, but it can also create disputes over which policy pays first and whether a particular category of loss is covered.
Subrogation adds another layer. If the customer’s insurer pays for notice, legal fees, or other losses, the insurer may seek to recover from the vendor if the vendor caused the breach. That recovery effort may depend on the customer’s contract with the vendor. If the customer agreed to a low liability cap or waived consequential damages, the insurer may be bound by those limitations. This means procurement decisions can affect insurance recovery later. A business that accepts weak vendor terms may not only limit its own recovery; it may also limit its insurer’s ability to pursue the responsible party. For that reason, legal, procurement, IT, and risk-management teams should treat data security terms as part of the company’s insurance strategy.
The question of fault is also more complicated than it first appears. Not every vendor breach is solely the vendor’s fault. A customer may have configured the software insecurely, failed to enable multifactor authentication, granted excessive administrative privileges, uploaded unnecessary sensitive data, ignored security updates, or allowed former employees to retain access. Some software platforms operate under a shared-responsibility model, where the vendor secures the infrastructure but the customer controls users, permissions, integrations, and data retention. If the breach results from a compromised customer credential or an insecure customer configuration, the vendor may deny responsibility. The contract should therefore define which party is responsible for which controls.
Data minimization is one of the most effective ways to reduce the cascade before it begins. If the vendor does not need Social Security numbers, dates of birth, medical details, bank account numbers, driver’s license numbers, or historical records, the customer should not provide them. If data is needed only temporarily, it should not be stored indefinitely. The FTC’s Blackbaud order is notable in part because it addressed retention and deletion, underscoring that keeping unnecessary personal information can worsen the consequences of a breach. ¹ Data that is never collected, never uploaded, or timely deleted cannot be exposed in a later vendor incident. In practice, however, many businesses send vendors more information than necessary because it is easier to export a full dataset than to create a limited one.
Vendor due diligence should also be proportional to the sensitivity of the data and the importance of the service. A vendor that processes public marketing content does not present the same risk as a vendor that stores payroll records, patient information, financial data, legal files, or authentication credentials. Due diligence may include reviewing security certifications, penetration testing summaries, SOC 2 reports, incident history, encryption practices, access controls, vulnerability management, backup procedures, subcontractor use, data location, and breach response procedures. But due diligence should not be treated as a one-time checkbox. Vendors change systems, add subcontractors, update products, experience turnover, and face new threats. Ongoing review is especially important for vendors that host sensitive or regulated data.
The broader threat environment makes this issue more urgent. Verizon’s 2025 Data Breach Investigations Report treated third-party involvement as a major feature of the breach landscape, reflecting the reality that organizations now depend on outside providers for core operations and data custody.⁴ A company’s security posture is therefore only partly determined by its internal systems. The company may have strong internal controls and still suffer a major event because a trusted vendor, integration partner, file-transfer tool, analytics provider, or managed service provider was compromised. The supply chain has become part of the attack surface. That does not mean businesses should avoid vendors; it means they should govern vendor risk as a central part of cybersecurity.
Incident response planning should expressly address vendor breaches. NIST’s incident-response guidance emphasizes preparation, coordination, detection, response, and recovery as part of an organized incident management capability.⁵ For vendor incidents, that preparation should include knowing who receives vendor notices, who decides whether outside counsel is engaged, who contacts the insurer, who communicates with the vendor, who preserves evidence, who drafts notices, who approves public statements, and who tracks deadlines. The plan should also identify critical vendors and the types of data each vendor holds. A company that first tries to build its vendor inventory during a breach is already behind.
Communication is one of the most important and most mishandled parts of the cascade. Vendors often want to centralize messaging to avoid inconsistent statements. Customers often want direct answers tailored to their own data and legal duties. Regulators and plaintiffs’ lawyers later examine the words used in emails, notices, FAQs, press statements, and investor disclosures. Overpromising can create liability. Under disclosing can damage trust and trigger enforcement concerns. A careful response explains what is known, what is not yet known, what the company is doing, and what affected individuals can do to protect themselves. It avoids speculation and avoids blaming others before the facts are established. Even when the vendor appears responsible, the customer should communicate like an accountable steward of data.
The role of subcontractors should not be overlooked. Many software vendors rely on cloud hosts, analytics tools, support platforms, offshore developers, data enrichment services, or other subprocessors. A customer may think it gave data to one vendor, but that vendor may have passed the data through a larger chain. If the breach occurs at a subprocessors, the dispute becomes even more complex. The customer looks to the vendor, the vendor looks to the subprocessors, and the subprocessors looks to its own contract limitations. Strong vendor agreements require disclosure of subprocessors, flow-down security obligations, restrictions on onward transfer, and prompt notice of subprocessors incidents. Without those terms, the customer may have little visibility into where its data actually went.
Regulated industries face additional pressure. Healthcare entities may have obligations under HIPAA and business associate agreements. Financial institutions may have obligations under privacy, safeguarding, and regulator-specific rules. Educational institutions may face student privacy requirements. Lawyers, accountants, and other professionals may have confidentiality duties that apply regardless of where the data is stored. Employers may have obligations involving employee personal information. These duties may not disappear because a vendor was involved. In many regulated settings, vendor management is itself part of compliance. A breach can therefore expose not only a security failure but also a governance failure in selecting, contracting with, and supervising the vendor.
The damages analysis can become highly fact-specific. Direct costs such as notice letters and call centers are usually easier to identify. Business interruption may be harder to prove, especially if the vendor’s system was unavailable but the customer continued operating. Reputational harm can be real but difficult to quantify. Lost profits may be challenged as speculative. Regulatory fines may or may not be indemnifiable depending on law and contract. Credit monitoring may be expected by customers even if not strictly required. Attorneys’ fees may be recoverable only if the contract says so or a statute applies. The result is that the party writing checks during the emergency may spend months or years trying to recover those payments from another party.
The parties’ conduct after the breach can influence who ultimately pays. A vendor that promptly investigates, preserves logs, shares facts, funds notices, and cooperates with customers may reduce litigation and regulatory risk. A vendor that delays, minimizes, withholds information, or gives inaccurate assurances may turn a security incident into a trust crisis. Similarly, a customer that responds carefully and transparently may reduce downstream claims, while a customer that ignores notices or communicates inaccurately may create independent liability. In breach response, the cover-up or confusion can become as damaging as the intrusion.
Negotiating leverage also matters. Large enterprise customers may have security addenda, audit rights, higher liability caps, cyber insurance requirements, and dedicated vendor management teams. Smaller customers may have little more than online terms of service. Large vendors may resist customer-specific obligations, while smaller vendors may accept terms they cannot realistically satisfy. The best contracts match obligations to operational reality. A vendor should not promise impossible response times or unlimited reimbursement if it lacks the resources to perform. A customer should not accept generic assurances when the vendor will handle sensitive data. Clear, realistic, enforceable terms serve both sides because they reduce uncertainty when speed matters.
The ultimate answer to “who pays” is that payment usually comes in stages. First, someone must fund the immediate response. That may be the vendor, the customer, an insurer, or all three. Then the parties determine contractual responsibility. The customer may demand indemnity from the vendor. The vendor may invoke liability caps and exclusions. Insurers may accept or deny coverage. Plaintiffs may file claims. Regulators may investigate. Business partners may demand assurances or reimbursement. Over time, the cost is allocated through settlements, insurance payments, contract negotiations, litigation outcomes, and sometimes unrecovered loss. The first payer is not always the final payer.
For businesses that use software providers, the lesson is not to avoid outsourcing. Outsourcing is unavoidable in modern commerce. The lesson is to govern outsourcing with the seriousness it deserves. Before sharing sensitive data, a company should understand what data is being provided, why the vendor needs it, how it will be protected, how long it will be retained, who else will receive it, how quickly the vendor must report an incident, what cooperation is required, what costs the vendor must reimburse, what liability caps apply, and what insurance stands behind those promises. Those questions are far easier to answer during contract negotiation than during a breach.
For software providers, the lesson is that security is part of the product. Customers are not merely buying features, uptime, and convenience. They are trusting the vendor with data that may carry legal duties and personal consequences. Reasonable security, accurate representations, prompt breach notice, disciplined retention, and cooperative response are not optional extras. They are central to the value proposition. Vendors that invest in security and contract clarity may reduce both breach risk and dispute risk. Vendors that overpromise, underinvest, or hide behind narrow terms may win short-term sales but create long-term exposure.
The vendor data breach cascade is ultimately a problem of trust under pressure. Data moves quickly through commercial relationships, but accountability moves more slowly through contracts, statutes, insurance policies, and lawsuits. When a software provider leaks customer data, the cost does not stay neatly in one place. It spreads to the vendor, the customer, affected individuals, insurers, regulators, and sometimes investors. The best time to decide who pays is before the breach, in the architecture of the relationship: limited data sharing, careful vendor review, strong contract terms, realistic insurance, and practiced incident response. Once the breach occurs, the cascade begins, and every ambiguity becomes expensive.
This article is intended for general informational purposes and does not constitute legal advice. Specific obligations and remedies depend on the governing contracts, applicable law, industry, jurisdiction, data involved, and facts of the incident.
Contact Tishkoff
Tishkoff PLC specializes in business law and litigation. For inquiries, contact us at www.tish.law/contact/. & check out Tishkoff PLC’s Website (www.Tish.Law/), eBooks (www.Tish.Law/e-books), Blogs (www.Tish.Law/blog) and References (www.Tish.Law/resources).
Sources:
1- Federal Trade Commission, “FTC Finalizes Order with Blackbaud Related to Allegations the Firm’s Security Failures Led to Data Breach,” May 2024, together with the FTC complaint and final order in In the Matter of Blackbaud Inc. https://www.ftc.gov/news-events/news/press-releases/2024/05/ftc-finalizes-order-blackbaud-related-allegations-firms-security-failures-led-data-breach
2- U.S. Securities and Exchange Commission, “Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure,” Final Rule, Release Nos. 33-11216 and 34-97989, July 2023; SEC Division of Corporation Finance statement regarding disclosure of cybersecurity incidents, May 2024. https://www.dechert.com/knowledge/onpoint/2023/8/sec-finalizes-cybersecurity-disclosure-rules-for-public-companie.html
3- IBM Security, “Cost of a Data Breach Report 2025,” prepared with research by Ponemon Institute. https://expel.com/annual-threat-report/?utm_source=google&utm_medium=sem&utm_campaign=26Q1+-+2026+Annual+Threat+Report+-+NA&utm_content=&utm_term=cybersecurity%20insights%20report-p&_bt=798327790499&_bm=p&_bn=g&_bk=cybersecurity%20insights%20report&gad_source=1&gad_campaignid=23601243250&gbraid=0AAAAADKblJ4vQyX44b0Y-nw8CO2aFNiYS&gclid=EAIaIQobChMI-bfXqIzclAMVlnJ_AB14PwBfEAAYASAAEgJdnPD_BwE
4- Verizon Business, “2025 Data Breach Investigations Report.” https://www.ibm.com/reports/data-breach
5- National Institute of Standards and Technology, “Special Publication 800-61 Revision 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management,” 2025, superseding NIST Special Publication 800-61 Revision 2. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r3.pdf