Can a SaaS vendor be held liable for a customer's data breach?

Yes. If you host or process data on behalf of a customer, a regulator can pursue you directly, and increasingly does. Your liability cap, your indemnity clause and your carefully negotiated master services agreement govern the relationship between you and your customer. They do not bind a state attorney general, a privacy commissioner or any other enforcement body, because none of them signed your contract.

This stopped being theoretical in October 2026, when the New York and Connecticut attorneys general secured $2.7 million from Boston Children's Health Physicians and its IT company, XTIUM, over a 2024 breach. Both the health provider and the technology firm were held liable, and the settlement came with a corrective action plan covering data security improvements.

Why the contract does not protect you here

Founders tend to think about breach exposure in contractual terms: what we owe the customer, capped at twelve months of fees, with carve-outs for confidentiality. That framing covers one of the three ways a breach costs you money. The others are regulatory enforcement and the cost of remediation someone else orders you to perform.

A corrective action plan is the part people underestimate. It is a multi-year obligation to build and maintain specific controls, with reporting to the regulator. You lose discretion over your own security roadmap, and the work is not reimbursable by anyone.

Who answers if a regulator writes to you directly?

Most incident response plans at a 20 to 200 person SaaS company assume the customer is the data controller and the first point of contact. That assumption breaks the moment an enforcement letter lands in your own inbox. Read your plan again and check for these specific gaps:

• Named owner for regulatory correspondence. One person, with a backup, who receives and routes anything from a government body. Not a shared support alias.
• Counsel on retainer before you need them. Privilege decisions get made in the first forty-eight hours. Finding a lawyer during that window is a bad plan.
• A clear rule on who speaks to the customer and when. Parallel inquiries from a regulator and your customer's legal team can produce two inconsistent accounts of the same event.
• Evidence retention. Logs, access records and change history need to survive long enough to support your version of events. Thirty day retention will not.

What to fix this quarter

Start by writing down which customers are in which jurisdictions, and what categories of data you hold for each. Health data, children's data and financial data carry the sharpest enforcement attention. Then check whether your business associate agreements and data processing agreements actually match what your systems do, because a mismatch is the easiest finding a regulator can make.

After that, look at your control evidence. A SOC 2 report does not prevent an inquiry, but a clean report with documented access reviews, encryption and logging gives you something concrete to point at. The alternative is reconstructing two years of practice from memory while under investigation.

The pattern worth planning around is this: enforcement follows the data, not the contract. If the data sat on your infrastructure, assume you are in scope. Building your compliance programme on that assumption costs far less than discovering it later.