We Get Privacy for Work — Episode 12: Managing Competing Priorities: Data Breach Notification Laws and Trade Secrets

Transcript

Joe Lazzarotti
Principal, Tampa

Welcome to the We get Privacy for work podcast. I'm Joe Lazzarotti, and I'm joined by my co-host, Damon Silver. Damon and I co-lead the Privacy, AI, and Cybersecurity Group at Jackson Lewis. In that role, we receive a variety of questions every day from our clients, all of which boil down to the core question of how we handle our data safely. In other words, how do we leverage all of the great things data can do for our organizations without running headfirst into a wall of legal risk? How do we manage that data without unnecessarily hindering our business operations?

Damon Silver
Principal, New York City

On each episode of the podcast, Joe and I talk through a common question that we're getting from our clients. We talk it through in the same way that we would with our clients, meaning with a focus on the practical. What are the legal risks, what options are available to manage those risks, and what should we be mindful of from an execution perspective? 

Joe, our question today is, one of our employees downloaded trade secrets; should I be worried about a data breach?

There is a lot to unpack with that one. Maybe, a place to start is with the question that seems to be implied here, whether the trade secrets themselves trigger any type of breach notification or reporting obligation? If the answer is no, is that the end of the inquiry, or is there more to think about? What is your way of framing that issue when a client brings it to you? I know it's one we get quite a bit. People are focused on the trade secret issue, and the potential data breach is something that may be an issue that has been flagged by someone, but it is not the predominant focus.

Lazzarotti 

Obviously, it's a really difficult time for a client. You put trust in an employee, and you find that maybe they downloaded some information, forwarded it to themselves, or something like that. Oftentimes, there's some pretty important information that's being shared. The starting point for me is just talking to clients about when it happens. Also, thinking about whether it happened, just in terms of language, it probably makes sense not to even refer to it as a breach at that point. You might have a breach of the system in the sense that someone got in, or someone accessed information that they shouldn't have accessed. However, the term breach of system security or breach in all 50 states in certain statutes has a meaning. If you're using that term, it might later be viewed as you reaching the conclusion that you've had a breach, meaning you have a situation that requires a notification of some kind. We like to just say, look, you've had an incident or something other than a breach. 

Damon, you're right. You really have to look at that issue because, at least I tend to find that, and this is still the case, a lot of clients that I speak with only view breach in the context of personal information, like Social Security numbers being disclosed. That was the case for a while. However, at least in terms of statutory or regulatory requirements, there is an increasing number of situations where business information could be considered a breach, even as lawyers. There are ethical rules that may get you to that place. There are insurance regulations that may get you to that place. In other words, you have access to information that's not personal information, and you might still have a notification obligation. 

Then, it doesn't stop there because you might also have contractual obligations that don't limit notification obligations by contract to just personal information. At the same time, in the heat of the moment, you have this issue with the trade secret. It's going to hurt the business. We have to focus on that. 

Damon, that's something to think about – how do you try to balance those two things? It's like what we see in an incident when we're dealing with a traditional ransomware attack, with a company saying, hey, we have got to get the business running. It's about the business, but it's also about the fact that there has been data affected. What do we do with that? What kind of strategies do you think are helpful for companies that have that situation where they must balance the business piece of the theft of the trade secret, and then think through, is it a breach for notification purposes?

Silver

Fortunately, pursuing those two lines of inquiry is not mutually exclusive and in lots of ways, you're really paddling in the same direction on both. A starting point for that is you really do want to understand the scope of what was taken and the scope of what was accessed without authorization. Both from a defending your trade secret confidential information perspective and also from exploring whether there's a “breach” perspective, you need to understand the scope. A lot of times it's broader than expected. Maybe we are aware of one email that got forwarded from the employee's business account to their personal account, or we see one instance where they uploaded a number of files to their personal box account. Oftentimes, though, when you look into it, it turns out this has been going on for days, weeks, or months. There are many other instances of stuff being taken. Maybe they synced their entire company email box to their personal email box, maybe there is a whole bunch of different files that they uploaded at different points in time, or they brought their personal laptop in one day and downloaded directly to the local hard drive a whole bunch of your data. You really want to, regardless of whether you're just focused on the trade secret issue or whether you're focused on the potential data breach issue, you want to understand the scope of it. 

The other thing that I'll often talk about with the client is that we can pursue parallel paths in tandem. We can reach out to the former employee, send the demand letter, gear up to go to court and try and get a temporary injunction if that's necessary. While at the same time making sure that we're preserving forensic evidence, engaging a forensic vendor if we need one and getting the process started on that investigation. It's very similar to the ransomware analogy you brought up, Joe. We know forensics can take a while. Also, if you don't take the right steps right at the front end, you may lose forensic evidence that you can never get back. You do want to keep your eye on the forensics and broader investigation ball, while at the same time, obviously, your immediate focus is probably going to be on how do we get this data back, and stop the former employee from taking this to our competitor? Both of those things can happen in tandem. If you don't think about the potential data breach issue until later in the process, you may lose out on the opportunity to get evidence that you'll ultimately need. 

The other thing, and maybe you can speak to this, is I find it can be very helpful if we're in negotiations with a former employee to resolve the theft of trade secrets and potential non-compete and non-solicit type issues to raise the issue of, can we get a declaration from this person that they deleted all the data they took of ours and that they didn't further disclose it anywhere? Joe, maybe you can speak to this, because if you're able to get that, it can change the trajectory of your assessment of whether you had a reportable breach, which is one you have to notify people about.

Lazzarotti 

That's a great point, Damon. I was thinking of something similar because oftentimes there's a desire to make the strongest case. If you are going for that TRO, you are trying to take some action to stop the employee from using it or to send the message that that data is important and you want it back, or you want to delete it. You want to try to make the employee feel like there's some real harm here. You might say you've breached our systems or our data, and now you've put that data at substantial risk. Then, when you turn back to the question of whether you've had a reportable breach, in many states, not all, you can avoid notification if you can reach the conclusion that there's not a significant risk of harm to the individuals. Well, if you've advanced these arguments in a way that you're saying or alluding to a potential for major risk, it might be harder to come back and say, the risk was over here, but not over here. So, you're right. You want to be thinking about these things simultaneously to try to understand what's really going on, what position we need to take, and whether there really is risk. If so, that will drive the decision on the data breach, but you don't want to hurt your position in terms of how you react on the other side with the trade secret theft. Those two things have to be thought through carefully and managed because you also don't have a lot of time in either situation. On the one hand, you have some significant business implications, but on the other hand, you have potential notification obligations. 

Damon, can you speak to that just in terms of discovery? One of the things from a data breach perspective is, when did you discover that there was a breach? That may not be the point at which you learned that the employee was sending emails to themselves. In terms of timing and going through this process, can you talk a little bit about how that's important from the data breach notification perspective?

Silver

A lot of data breach notification laws will say you have X days, like 30 or 45 days from the date that you discovered the “breach” to provide notice and submit your reports to government agencies. You do want to be careful about boxing yourself in. If you put in that demand letter that this former employee took your PII, you're putting out there that as of the day of that letter and probably earlier, you were aware of a compromise to your PII, which may not be the case. It may be the case that you do some forensic analysis, and there is no PII in there. Even if ultimately there is, you don't really know until you look into it further. 

I certainly will avoid saying there's PII in the data set, but I don't even go into the specifics of what type of information I think it might be. I will certainly flag the fact that we are aware of you exporting our data or forwarding emails to yourself on these dates or on multiple occasions, but I won't commit the client to what specific type of data it is. That does become important later because, like I mentioned a little bit earlier in the episode, it can take a while to do a forensic investigation. Even when you have the findings, if there are quite a few impacted individuals in different jurisdictions, you then have to work through your analysis of whether this qualifies as a breach in different places. Is there reporting required to government agencies? You have to prepare the notices, you have to prepare the reports, and all those things take time. If you have committed yourself to a very early discovery date before you really had enough information to move the ball on a lot of those subsequent steps, you can put yourself in a tough place from the standpoint of meeting the requisite deadlines.

Lazzarotti

It's interesting because one thing I know we talked a little bit about this at the beginning, but some of the things you said made me think of something important, and that is, at least I've seen this happen from time to time. Not sure if you have Damon, maybe you have some thoughts, but there's an assumption sometimes with a situation like this, where people are thinking that data breach notification is only really required when there's Social Security or credit card numbers. When they begin to think about this incident that happened and what this employee took, they're like, well, it's all business information. There are no Social Security numbers in that data, and they just proceed down the road of the trade secret issue. What they don't realize sometimes is that states have, over time, amended and expanded the definitions of what type of data could trigger a notification obligation. Now, it could be medical information or non-personal information. 

Any thoughts on that in terms of how to try to avoid that issue when it comes up so that, to your point, you may not have completed the data mining, but how do you make sure that you're not missing or moving too fast forward on the trade secret, which again is important but that you miss an obligation of a data breach notification that you have to make sure you've addressed.

Silver

That's a great point. I do try and flag in the initial discussion with the client when they come to us with the issue that PII extends beyond what people traditionally think of. It certainly includes Social Security numbers, driver's license numbers, financial account information, and credit card information. However, it also includes stuff like online account credentials or medical information, as you mentioned, and in some states, date of birth or digital signature. I try and put that out there. Sometimes I'll mention to the client that if they'd like, we can share a list of elements that might be PII. If there's a chance that some of the data might be protected health information under HIPAA, either because the client is a covered entity or they're a business associate and we're dealing with health plan data that might be a self-insured plan. I will point out that from a HIPAA perspective, the definition is extremely broad. It can really be just someone's name and the date they went for their appointment. Something as seemingly innocuous as that can be PHI. That's a great point. There is this inclination that if socials or credit card numbers weren't impacted, there's probably nothing further to see there. That is definitely no longer the case; it's definitely the trend that these laws keep broadening the definition of PII. 

Also, for some of our clients that have international operations, the GDPR or other non-U.S. laws may apply, which, similar to HIPAA, have very broad definitions of personal data. It is important to think about that at the front end, both in terms of understanding the importance of doing that investigation, but also when you're working with, let’s say, a data mining vendor. Some data mining vendors do this all the time; they understand the scope of review that's necessary, but I've worked with quite a few clients that brought in a firm that really is more focused on e-discovery, maybe they're branching into data mining, and they have these very short lists of what qualifies as PII. It may be the case that they've already started doing some discovery, and maybe that protocol for doing the discovery needs to be broadened because the initial programmatic review was way narrower in scope than was really appropriate for a potential data breach investigation.

Lazzarotti

That makes sense. It definitely is a tough spot for companies, no doubt. It certainly is important to make sure you have the right team to consider both the business implications of the trade secrets and how to address that, but also look out for potential data breach notification obligations. That's a good place, Damon, to stop unless you have any other thoughts.

Silver

That's a great place to wrap. Thanks to everyone for joining us. As always, if you have any thoughts on future episodes, any questions or thoughts about this episode, you can email us at Privacy@JacksonLewis.com.