A Q&A with Michelle Visser of Ropes & Gray LLP
The recent ruling that Massachusetts’ Attorney General can move forward with its suit against Equifax portends a new era in data breach litigation and regulation. To find out more about this case and what it means for corporate risk, I spoke with Michelle Visser, a Massachusetts-licensed attorney with the global law firm Ropes & Gray LLP.
I think the Equifax decision and the suit generally does highlight the attention regulators have paid to patching practices—in many cases, they may not fully appreciate the burden associated with them and can focus on isolated issues which may not be sufficient to actually result in legal liabilities.
How is the Equifax case different from other data breach cases? Are there any trends we should be aware of?
The main difference here is simply the fact that this case occurred. Historically, in the attorney general context, the pattern has been consistent: A large data breach would be widely publicized and the attorney general might open an investigation—they wouldn’t jump straight to suing the company. We’ve also seen it with Uber at the same time. These two cases represent a dramatic shift from the historical practice of a decade or so ago. In terms of trends, we can only speculate, based in part on what we’ve seen with breaches and the comments regulators are making. I think in both instances the sheer number of individuals involved and early reports about what occurred in connection with the breach—the allegations made about the response of the companies and the alleged lack of preventative measures—were the cause of the AG taking action here. As to whether this will be the way things are done from now on, certainly the fact that the case was allowed to proceed may encourage other cases going forward.
Do you see any issues with the “failure to patch open source code” part of the ruling?
One potential issue is that Massachusetts regulations around patching are not as broad as the court’s ruling. In particular the Massachusetts regulation only applies, on its face, to operating system patches and patches for security software which were not the problem with Equifax. To the extent the Massachusetts regulation could be construed to have a general requirement that companies reasonably update software, Equifax nonetheless may have an argument that this was a single isolated failure, which in and of itself did not violate the regulation.
The ruling states that Equifax “owned” the personal information: Isn’t the exact opposite argument being made now in various Facebook cases, that the customer owns their data?
In this context, whether the customer actually owns the data is not determinative of the legal obligations or regulations in play. There’s no question it would apply to a company that owns or licenses customer data. In the Facebook example, the terms of service state that the customer owns the data but expressly state that Facebook has the license to use the content. Here, with the Equifax decision, what was key is that Equifax is not a customer-facing company so the issue of whether customers own their data is one or more steps removed.
Could the other 49 state AGs try to mimic or adopt similar positions laid out by the Massachusetts AG?
When we talk about the idea of simply filing suit we’ve already seen that in practice. West Virginia filed suit against Equifax and the AG from Pennsylvania has sued Uber. We’ve also seen cities such as Chicago, San Francisco and Los Angeles file suit following the Uber and Equifax data breaches. But not all states have the same level of resources dedicated to cybersecurity and privacy matters and not all states have the same resources to take action. Historically, we have seen multistate groups in an investigative context and we will continue to see that. In terms of the allegations Massachusetts was a bit unique—it does have the data security regulation the court relied on in the ruling which does set forth quite specific requirements for what companies should be doing with respect to security. Other states don’t have the statutes to rely on to the same degree. Possibly they could assert that the type of conduct alleged in this case violates more general potential obligations for “reasonable security.” Whether and to what extent such obligations apply in many states remains to be seen.
What advice would you give to corporate risk managers looking to mitigate future cyber risk exposures?
I think the Equifax decision and the suit generally does highlight the attention regulators have paid to patching practices—in many cases, they may not fully appreciate the burden associated with them and can focus on isolated issues which may not be sufficient to actually result in legal liabilities. But it is a focus regardless, so making sure there is a robust patching process should be part of every information security program, even if a company may have good legal arguments that such a program is not required. Along similar lines, I mentioned that Massachusetts is the only state with a data security regulation that specifically lists components of an information security program so using that regulation as a guide for controls is a good way to reduce exposure. Finally, I would advise companies to be very careful about the statements they make publicly about their cyber security—weigh the risks and benefits and, especially if there’s not a specific benefit, the best practice is to say nothing at all.
In summary…
We would like to thank Ms. Visser for her insights into this matter. The cyber risk insurance community is especially concerned about the issue that Michelle highlights—the relatively aggressive posture of various state AGs jumping right into lawsuit mode. I also like her comment about the need for system patch management, and its many associated challenges (e.g., backporting) that might not be fully appreciated by the enforcers. Patch management makes perfect sense as a security tactic, yes, and it sounds straightforward, but it also requires significant management vigilance and resources. And even then, problems can still arise due to the many third and fourth party dependencies that are now a reality in most corporate network ecosystems.
