Washington vendor data incident contract review: DPA, cost allocation, indemnification, and liability cap carve-outs
When a vendor or processor in your data chain has a security incident, the contract you signed before the incident usually determines how much of the resulting cost lands on you and how much lands on the vendor. Washington's data breach statute, RCW 19.255.020, requires the vendor to notify you promptly on discovery and leaves the consumer-notice and AG-notice obligations with you as the data owner. The contract narrows or expands that allocation: a tight DPA notice window, a forensic-cost allocation that defaults to the responsible party, an indemnification that reaches third-party claims, and a carve-out from the contractual liability cap for breach-related costs are the four levers that decide the matter. The review framework below is what I look at when a customer or vendor sends a contract for written attorney review after an incident.
Lever 1: notification timing
- Definition of "Security Incident" or "Data Incident" and the trigger that starts the vendor's notice clock. Loose definitions (any anomaly) over-trigger; narrow definitions (confirmed exfiltration) under-trigger.
- Vendor's notice window to the customer: typical ranges are twenty-four, forty-eight, or seventy-two hours from discovery. Compare against the statutory floor under RCW 19.255.020 ("prompt").
- Content requirements of the vendor's notice: data categories, time frame, root cause (interim ok), containment status, contact information. Generic "we identified an incident" notices do not let the customer comply with RCW 19.255.010 on the customer's own thirty-day clock.
- Update obligation: vendor's duty to provide updated facts as the investigation matures.
Lever 2: cost allocation
- Forensic investigation: who runs it, who pays. Tighter contracts default to the responsible party; weaker contracts split or allocate to the customer.
- Consumer notice production and mailing: who drafts, who prints, who mails, who staffs the call center.
- Credit monitoring and identity-theft protection: term length, vendor selection, who pays.
- Regulator submissions: who drafts and files the AG and other regulator notices, with cooperation duties.
- Public-relations and crisis communications: separate line item or rolled into forensic spend.
Lever 3: indemnification scope
- Third-party claims arising from the incident: consumer claims, regulator enforcement actions, business-customer claims that flow through to the vendor.
- Knock-out exclusions: gross negligence, willful misconduct, breach of confidentiality. These often unlock uncapped exposure.
- Duty to defend versus duty to indemnify; written notice and cooperation requirements; control of defense and settlement.
- Mutual indemnities: common but rarely useful. The cross-cancellation does not actually allocate breach risk; it just preserves it for litigation.
Lever 4: liability cap and carve-outs
- Standard SaaS liability caps frequently sit at twelve months of fees paid. Without a carve-out, that cap also caps breach-related cost recovery.
- Common carve-outs that pierce or replace the cap: breach of confidentiality, breach of data-security obligations, breach of privacy obligations, indemnification, gross negligence, willful misconduct, infringement, and fraud.
- Super-caps: some agreements set a higher (often two or three times annual fees) cap for breach-related obligations rather than full carve-out.
- Insurance requirements as a parallel: minimum cyber and tech E&O limits with the customer named as additional insured where appropriate.
Cross-cutting issues
- Audit rights and security questionnaire compliance: who audits whom and on what frequency.
- Subprocessors: notification, customer consent or objection, and cascading allocation.
- Cross-border transfer: relevant when the breach implicates EU, UK, or other jurisdiction data protection regimes.
- Termination: termination-for-breach triggers, transition assistance, return and deletion of data.
Why a generic indemnity is not actually allocation
Mutual breach indemnities in SaaS agreements are common, are usually drafted before any specific risk analysis, and almost never produce the result either party actually wants in a real incident. The customer wants the vendor to absorb the forensic, notification, credit-monitoring, and third-party-claims costs when the breach occurred inside vendor systems. The vendor wants its liability capped and its cooperation duties narrow. A reciprocal indemnity that says each party will indemnify the other for breaches caused by its own conduct preserves both positions for litigation without resolving either. A useful breach-allocation clause names the categories of cost, sets the trigger for each category, identifies the carve-outs from the cap, and provides a cooperation framework that actually works in the first seventy-two hours.
What I review when you send a vendor incident contract matter
When you send the master service agreement, the DPA, the security exhibit, and the incident timeline, I walk the four levers against the specific facts and tell you where the contract supports the cost and indemnity posture you actually want, where it does not, and what the negotiation lever looks like for the next contract. The output is a written evaluation, not a sales pitch.
Primary sources
- RCW 19.255.010: consumer notice, AG notice, encryption safe harbor.
- RCW 19.255.020: processor and vendor notice obligations.
- RCW 19.255.040: consumer protection section; AG enforcement and consumer civil action for damages and injunctive relief, with the carve-out from RCW 19.86.090.
This page is an educational resource. Sergei Tokmakov is a California attorney (CA Bar #279869) currently seeking admission to the Washington State Bar.