The Long Arc of Data Breaches: 2006-2026

Try to recall your privacy practice 20 years ago, in May 2006. The California breach notification statute, the first one in the country, had become effective on January 1, 2003. The California Online Privacy Protection Act (CalOPPA) had gone into effect on July 1, 2004. In retrospect and certainly compared to the California Consumer Privacy Act (CCPA), the website privacy notice requirements were rudimentary, with a generous 30-day cure period to remediate any deficiencies. The FTC was ramping up data breach enforcement. Across the pond, the 1995 Data Protection Directive, with the implementation deadline of October 24, 1998, was still front and center, from a data protection compliance perspective, with corresponding compliance terms included in contracts between customers based in the European Union and vendors based there or elsewhere. In May 2006, I was in-house counsel for a travel technology software provider. With customers in the EU, the 1995 Data Protection Directive was quite topical. If these were the halcyon days of data privacy, they were even more so for cybersecurity, more than four (4) years before Massachusetts published its seminal cybersecurity regulations (201 CMR 17.00). More sophisticated customers would ask vendors for their cybersecurity policies, which in turn were developed on the fly and augmented considerably after version 0.1.

Needless to say, contracts evolved over time, with privacy and cybersecurity provisions in, for example, 2016, looking quite different from ones in 2006. By May 2016, most states had data breach notification statutes. Data breach enforcement actions had provided guidance to businesses. But it would still be another two (2) years before the General Data Protection Regulation (GDPR) became effective, and almost another four (4) years before the CCPA went into effect. Fast forward another 10 years, and the landscape is different yet again, fueled by the emergence of artificial intelligence technologies and myriad new laws and regulations. In many customer-vendor relationships, contracts are signed and then filed away for posterity. Thus, if there is a privacy or cybersecurity contractual dispute, and given the increased stakes in 2026, there seem to be more of these, the parties will find themselves interpreting, and sometimes litigating, language that is 15-20 years old, from a different time, literally. As such, revisiting these provisions, from time to time, may be sensible.

Let’s delve into one of those privacy and cybersecurity provisions. Under various state breach notification statutes, a business can have a data incident, a data breach, or a notifiable data breach. I use “business” generally, and not as defined under the CCPA, which includes revenue and other thresholds. A data incident could involve the unauthorized disclosure of personal information, but where said information does not include, for example, first initial, last name, and a social security number, or any other enumerated elements under the relevant state breach notification statute. A data breach would be the same, except that it would include, for example, first initial, last name, and one or more of those enumerated elements. But, as with any definition, there are wrinkles. Somes states bake a risk harm assessment into the definition of data breach. For example, the relevant Massachusetts statute provides: “‘Breach of security’, [means] the unauthorized acquisition or unauthorized use of unencrypted data or, encrypted electronic data and the confidential process or key that is capable of compromising the security, confidentiality, or integrity of personal information, maintained by a person or agency that creates a substantial risk of identity theft or fraud against a resident of the commonwealth.” Mass. Gen. Laws ch. 93H § 1. If there is no “breach of security,” then notification is not required. Some states do not permit a risk of harm assessment. California is one of them. Lastly, some states do not bake the risk of harm assessment into the definition of data breach, but, once a breach has been determined, permit the business to perform a risk of harm assessment to determine if notification is required.

As may be apparent, in all cases, the business will need to determine if there has been a data breach, if notification is required, and then to whom. If a contract provides that the vendor will reimburse the customer for all data breach notification costs and expenses, then it is not hard to see how the customer will be left  holding the bag if the incident is a data breach, but not one that is notifiable, or the incident is not determined to be a data breach. Thus, from a customer’s perspective, for the reimbursement of first-party costs and expenses, a data incident trigger is better than a data breach or notifiable data breach trigger.

Now, assuming there has been a notifiable data breach, let’s drill into “costs and expenses,” which typically must be reasonable and documented. Presumably, these would include printing and mailing costs, as well as the costs of credit monitoring, which even if technically not required by a given state breach notification statute, would still help mitigate litigation risk and potential damages. Where credit monitoring is required, it is usually twelve (12) months for most states, with eighteen (18) and twenty-four (24) months for Massachusetts and the District of Columbia, respectively.  But, even with credit-monitoring products, perhaps to the surprise of some, there are still choices, including 1B or 3B (one bureau or three bureau) monitoring, and thus opportunity for disagreement between the customer and the vendor. What about the costs and expenses to assess whether a breach occurred and, if so, whether notice needs to be provided? These are first-party costs and expenses. A traditional indemnity provision, premised on the assertion of a claim by an unaffiliated third party, would be useless here.

Questions invariably follow notification, including from impacted individuals. A regulator may decide to investigate. Someone, or perhaps more than a few individuals, may decide to file a class action. This, then, brings into contrast the costs and expenses that arise from a third-party claim or investigation.

There are other first-party costs and expenses, including, as a precautionary measure, disabling a server or system that has been compromised, testing and bringing online the patched version, and re-entering data after the patched server or system goes back online. A customer may need to rely on a different provision in the agreement to be compensated for these costs, as they have nothing to do with data breach notification and are not premised on any third-party claims. Put otherwise, a holistic view is warranted.

A robust cyber insurance policy may cover many of these first- and third-party costs, assuming exclusions do not exist that torpedo coverage. That said, it seems that most customers would prefer to look to their vendors to make them whole, rather than to insurers, to deductibles, and to possibly increased premiums. In turn, the insurers would likely have subrogation rights against the vendor, and thus, the same bridges will need to be crossed.  

There are two other issues worthy of a brief discussion. First, customers and vendors can usually agree that, because of increased financial exposure, the baseline limitations on liability should not apply to the section of the agreement corresponding to data breaches. A super-cap is typically agreed, sometimes tied to the vendor’s cyber coverage (per incident and aggregate) limits, assuming those are sufficient. As an incident response and privacy class action defense practitioner, it is certainly not a fool’s errand to estimate these costs, and based on experience, in many cases they are considerably lower than those in the headlines. Put otherwise, having real numbers in hand makes the conversation with the vendor much less theoretical (and more productive). Second, it is possible that, while there was a data incident, it was not due to the vendor’s failure to implement reasonable security procedures and practices appropriate to the nature of the personal information to protect the personal information from unauthorized or illegal access, destruction, use, modification, or disclosure. Or, maybe it was, but the vendor will not admit to this (to avoid precedence or for another conceivable reason) and/or the customer was partially responsible. In that case, as a practical matter, the customer will do what it needs to do, and deal with the vendor on the back end. As the expression goes, all rights reserved. Until next month.

About the Author

John Pavolotsky is a partner in Stoel Rives’ AI, Privacy & Cybersecurity group. He advises clients on data incidents, breach response, and related regulatory and litigation matters, as well as cybersecurity contracting and compliance. Explore our AI, Privacy & Cybersecurity Law capabilities.