Welcome to Jackson Lewis's podcast, We Get Work. Our podcast identifies issues that influence and impact the workplace and its continuing evolution and helps answer the question on every organization's mind. How will my business be impacted? Many federal and state laws require companies to have reasonable cybersecurity safeguards in the event of a data breach, but do not specify what protections are actually required.
On this episode of We Get Privacy for Work, we discuss where organizations should start when creating legally compliant cybersecurity policies that can withstand regulatory scrutiny. Today's hosts are Damon Silver and Joe Lazzarotti, co-leaders of the firm's Privacy Data and Cybersecurity Group and principals, respectively, in the firm's New York City and Tampa offices. Damon and Joe, the question on everyone's mind today is, What are reasonable safeguards?
How can my organization implement them? And how does that impact my business? Welcome to the We Get Privacy podcast. I'm Damon Silver and I'm joined by my co-host, Joe Lazzarotti. Joe and I co-lead the Privacy Data and Cybersecurity Group at Jackson Lewis. In that role, we, along with the rest of our team, receive a variety of questions every day from clients. All of which essentially boil down to the core question of how do we handle our data safely?
In other words, how do we leverage all the great things that data can do for our organizations without running head first into a wall of legal and other risks? And how can we manage that risk without unnecessarily hindering our business operations? On each episode of the podcast, Damon and I are going to talk through a common question that we get from our clients. And we're going to talk it through in the same way we would without clients.
What that means is with a focus on being practical, we're going to touch on legal risks, other types of risks, options that may be available to manage those risks, and what we should be mindful of from an execution perspective. And so on today's episode, we're going to talk a little bit about reasonable safeguards, right? That lawyer term that no one really knows what it means.
And if you think about, right, different frameworks, you may think, well, there's, you know, the New York Shield Law, or there's HIPAA, or there's Gramm-Leach-Bliley, and all these different statutes, federal, state, many of them refer to a company must have reasonable safeguards to protect data. And that isn't always clear and the statute doesn't really lay that out.
And so there's a lot of questions and if you're trying to figure out and you're compliance minded, you say, well, okay, is this reasonable? I don't know, is it? Damon, what do you think? Yeah, it is a challenging question. There's not a clear answer to it, which in some ways is beneficial because it does build some flexibility in.
And it seems like the intent of the reasonable part of reasonable safeguards is to account for the fact that there's a lot of variance, organization to organization, in terms of its resources, in terms of the data-related activities it engages in, the technologies it uses, how much data it processes, what types of data it processes. So part of this exercise of ensuring that you have reasonable safeguards in place is getting a handle on... those types of questions.
What data are you processing related to how many people? What are you doing with it? Are you disclosing it to other parties? Are you in an industry such as healthcare or financial services where there are specific requirements around your handling of data? And so, I think in some form or fashion, a starting point for the exercise of figuring out if you have reasonable safeguards, making sure you have reasonable safeguards in place. is doing a data security risk assessment.
Really going through and starting to wrap your head around what your data risks looks like. And Joe, maybe you can talk through this a little bit. I know you've worked with a lot of clients in the healthcare space, a lot of clients that aren't necessarily subject to an industry-specific regulation. What are some of the key things that you're looking for as you go through the process of doing a risk assessment with a client?
So you said You said healthcare and risk assessments and, you know, before getting into that, I think it might be helpful to kind of put things in some kind of perspective. We have this term, reasonable safeguards. One of the things that I know I've kind of talked to clients about, certainly clients that have a lot of different operations where they're trying to figure out, they have different standards or frameworks that they're trying to figure out, you know, what do they do with that?
And when you start to look at it, When you start to look at this issue, you realize that, I'll use the term that pass, that common threads that go through all of these frameworks. eh And so, you know, it's helpful, I think, to think about things in terms of, and this is not something that I've created. mean, I this is just different standards that have evolved and have been enacted into law have kind of set forth.
And that is you have, you know, administrative safeguards, you have... physical safeguards, right? Locks on doors and file cabinets, for example. You have technical safeguards, which is really where the IT team is strong. And then you may have organizational safeguards, like agreements and stuff like that. And risk assessments tend to be, you know, part of, you might consider them part of administrative because risk assessment could be something that is technical. It could be administrative.
It could be physical, but I think it's an administrative function in terms of thinking about, you know, it's like if you're going to get insurance for a building, you got to have to know, all right, like Damon was saying, you know, what data, where is it? Is the building made out of paper? Is it made out of brick? Do you have sprinkler systems? oh How easy is it to get out of the building? And that gives you an assessment of risk.
What are the threats and vulnerabilities that you have in your organization? Do you have a lot of locations? Are employees working remotely? Do you interact with consumers? Are you more B2B? And so it's a process where I think you have a collaborative, maybe a cross-functional team that starts to look at how is our data, what threats are there to that data? What vulnerabilities do we have in our systems? So you kind of gather all of that and then look at what do we do?
What do we do to address those threats and vulnerabilities? And then say, is what we're doing sufficient to kind of manage that? it's kind of like, okay, typical measure of risk is what's the likelihood that something's gonna happen? And if it does happen, what's the impact on the organization? And you start to look at those things and then you start to say, are our safeguards that we have sufficient, assuming they comply with law, and do we need to do something else?
And the way I like to sum it up, Damon, is to say, you know, would I feel like I have a good story to tell if I had to stand before a judge and explain what this organization is doing? Because as we both know, it's like, if you have a breach, well, how could your safeguards have been reasonable if you had a breach? And that's like a tough spot to be in. Yeah, I think that's a great way of looking at it, Joe.
And you know, that's certainly the argument that plaintiffs make in the data breach class actions that our team handles, but that's not actually the case. The mere fact that there was a breach doesn't mean that your safeguards were unreasonable or inadequate. mean, we've seen the top levels of government, the top levels of the private sector, all kinds of organizations that have extremely sophisticated safeguards that huge amounts of money is invested in. Those safeguards are not infallible.
bad actors have a lot of motivation to find new creative ways to get in. So, you the fact that the breach happened does not, it's not the spots on the question of whether you had reasonable safeguards. Well, I mean, I think, you know, the way you teed it up, Joe makes a lot of sense. Like if you do have an incident and you end up having to say notify, let's call it 10,000 people, which would still be on the smaller end and say it's a healthcare.
entity that has to report to OCR or a different type of entity that has to report to state AG. And that agency is investigating the breach. And then you get some class action litigation related to the breach. How are you going to feel about the safeguards that you had in place? And equally importantly, are you going to be able to demonstrate that you had those safeguards in place?
Because we work with a lot of clients where if you have a discussion with them, certain members of organizations say, we have safeguards in place to address this, that, and the other thing. Then you ask for any documentation demonstrating those safeguards and there's nothing, or it's very piecemeal. Someone has put together a word document on this particular area at this point in time and when you pull all of that together, it doesn't make a very impressive showing for OCR or state AG.
It doesn't look great in discovery and litigation. And the truth is, Oftentimes the absence of the written policy is an indication that the safeguard probably isn't in the place that the organization may have thought that it was. know, going through the process of developing the policies and procedures help you both in the standpoint of one, it's legally required. Two, it's what's going to allow you to most effectively push back on the investigation or defend yourself in litigation.
It can also be helpful just in day-to-day business. We see increasingly that parties that your organization may do business with, want to see your written information security policies as evidence that you have a good program in place. But also having to go through this process of doing the risk assessment and then developing policies and procedures, committing to writing what you're doing.
Oftentimes that has the side benefit of helping you see that maybe things are not where you thought they were. It helps you to plug some of those gaps and to think through. what makes most sense in terms of how to protect yourself going forward. So, David, flesh that out a little bit more. One thing you said made me think about something is a good place to start, right? Because I think some people listening may say, well, all right, guys, that sounds all nice, but what do I do, right?
What do we do? And I think a good place to start is to say, OK, if you're in regulated industry, or maybe you're in New York or Massachusetts or a state where they have fleshed out, right? Maybe you start with that, right? What is that set of rules or that industry guideline or whatever it is, start with that. Maybe talk about you do that, but is that all you do? Right?
In other words, because you comply with the state law or a federal law that governs you, number one, that state law or that federal law may only apply to a certain part of your data. It may not apply to all of the data that you have that requires safeguarding. And what's the thinking around, do we need to do more than what a particular statute that regulates us requires? Yeah, it's a great question.
starting with one of the points you mentioned, it can very often be the case that there are different legal frameworks that are going to apply to different types of data that you maintain. So probably the easiest example to illustrate this is you're a hospital, your patient data is subject to HIPAA, but you also have employees.
Your employee data is generally not subject to HIPAA, but it is likely subject to state law that says you need to have reasonable safeguards in place to protect, say, an employee's social security number or their bank account information. And there is an understandable tendency to try and paint with a broad brush and say, you know, this is our program that's going to apply to everything equally.
But maybe at the end of the day, you do for administrative simplicity purposes want to have some overarching set of policies. But the starting point has to be looking at it in a more segmented way and making sure that you understand what are the standards that apply to us. And then to your point about, you know, is just doing what the standards say enough. You know, a lot of times the standards, mean, HIPAA is somewhat detailed.
A lot of times the standards, for example, the Massachusetts regulations, the New York Shield Act, they're pretty high level. They tell you, generally speaking, the types of stuff you're supposed to do, but they don't get into the level of detail that you're going to need to get into as an organization to actually have those safeguards in place. So they may say, you you need to have an access management policy. But what does that actually mean?
Like how are you actually going to go through the process as an organization of determining what types of employees should have access to which databases and making sure that when an employee leaves that access is cut off or if an employee changes position that access is cut off. So you really do need to think about it in a way that's tailored to the way that you are doing business because while there are certainly principles that carry over from organization to organization.
for any of this to be effective, it has to be mapped on to what you're actually doing. And on that point, Joe, how is that something you try and help clients think through? Like what is the way to jump from what the standards may be under a legal framework or best practices to what makes sense for this particular client's business? Well, I think there's a couple of things that come to mind, Damon.
One is, You know, talked on a number of occasions about, you know, cyber insurance and how important that is. You you may think about, well, what if we went out to get our policy updated and what would the requirements be of a carrier? What makes us a more attractive insured? Even though you comply with that standard.
Well, for example, right, New York doesn't require multifactor authentication, but we all know that multifactor authentication is a pretty well-established control that people would expect you to have. Does it having it, does it mean you're negligent? I don't know. That's not for us to decide. But it might be something that's important and valued by a carrier for underwriting purposes.
So you might look at that and say, well, if we want to be a better insured, let's make sure we have that particular control in place. You might look at what your clients require. Some clients will say, you need to comply with all laws. Thank you. That gets us back to the same place, right? Reasonable safeguards. But then you may want to go beyond that, right? And say, well, what does that mean? Well, that means you're going to do an annual risk assessment.
You're going to have an incident response plan. We talked about that, right? You're going to have multifactor authentication. And that's listed as specifically in the agreement. And so now you kind of know, all right, if I want to get business from this company, I'm going to have to do these additional things beyond that which my state law requires. m And then I think it's like, you know, if, you know, people say, well, look, I want to sleep at night, right?
Data breaches can be pretty disruptive. They can be pretty upsetting and scary in some cases. And, you know, it's difficult to get through that. And people don't want to go through that. And no system is perfect. But if you start to look at your environment, as you were suggesting at the outset in terms of what kind of data, how much of it, how sensitive is it? And you start to say, you know, maybe we really need to tighten it up.
Maybe we need to have encryption at rest and in transit and put some more, you know, locked down in terms of what employees can do and access and, you know, VPN, having that certainly required and have not just having MFA, but forcing people to be using it. Like there are things that you can really tighten up, but that's a matter of risk, I think. And so really understanding your risk.
and then reacting to that in a reasonable way because then I think the reasonableness also plays into and this isn't HIPAA and it's in other laws, right? What's the cost of that? Can you feasibly incur that cost to implement and maintain these higher level controls? It's a real factor and we don't want to ignore that as we go through. But those are the things that I would try to think about in deciding what steps to take beyond a particular framework.
Yeah, Joe, I think that makes a lot of sense. Maybe we can wrap up on this point. We did on a prior episode discuss this in the context of incident response plans. It's equally important in the context of having reasonable safeguards in place. And that is you can do the risk assessment, you can have your written information security manual, but then there's the part of actually being able to execute on it.
And that really does come down to employee training, having that employee training be role-based. In other words, having training that is tailored to specific types of employees based on what they are doing with respect to processing your data, with respect to helping make sure your safeguards are in place. Because we have worked with many clients where they have a very impressive looking 120-page WISP. written information security program, but no one has looked at it in years.
a number of the frameworks we've talked about, like HIP and the Shield Act specifically, say you have to regularly train your employees on these policies and procedures, help them understand what their role is. Joe, maybe to close this out, do you want to talk a little bit about what we do when we're working with clients on providing this type of training? Well, you know, it depends on obviously what the client wants, what they feel.
is helpful for their team and who they feel needs to be trained. But there's really two approaches I think we take. One is to just educate employees about the risks and the kinds of things to be mindful of and what the laws are and what's required under the laws that that particular company and that particular group that we're talking to faces.
And then as Damien was saying, he used the term role-based because each employee may serve in a particular role and certain policies may apply to that employee. so the idea is it's not what should any company do in the event of a breach, for example, to use that. It's what we say, what the company's determined that they want to do. And that's really the training part, right, is helping the employees to know this is what this company has established as the safeguards we want our employees.
to follow. It's one thing to just talk about, know, HIPAA requires access management policy. It requires incident response plan. It requires uh this, that, or the other thing. But that's not necessarily how the company has brought that into its organization and operationalized that particular requirement for that particular group. Right?
So, that's a little bit more of a detailed training where we would, in a case with a client, Damon, we would want to understand first before we can train on it, we'd want to understand, well, what are you doing? What's the policy? What does it say? What should we focus on? And then really talk about, you know, this is what the company requires. Let's go through it. Does anybody have any questions? Then we'll go to the next one. Yeah, Joe, I totally agree with all that.
And just one thing to layer on there is we found it's been very helpful in a lot of these trainings to have hypotheticals to work through with the audience. Because in addition to making sure that the discussion of policies aligns with what the organization is actually doing, we want to make this information accessible to the attendees of the program.
And a lot of times, if you talk about a certain concept, say data minimization or access management or getting authorizations for disclosures or spotting phishing emails, It can be a little difficult for people to understand how that is going to come up for them in their day to day. And also just hard for them to absorb the information.
But we found that when we work through hypothetical specific scenarios that employees in that particular group are likely to face on a somewhat regular basis, all of sudden people's eyes sort of light up. They remember that happening or they could see that happening. and they understand why the policy exists and they understand what they're supposed to do in the event that they find themselves in that scenario. Yeah, well, look, I think that's exactly right.
And I think at the end of the day, all the things we're talking about, this idea just to kind of bring us back to what's reasonable, really depends on a lot of factors and what's right for the organization. Sometimes it's good to talk about that with people who are outside the organization who can help you. determine, hey, look, you may think this makes sense, but you know, you may have a tough time defending that and getting you to what might be more likely to be objectively reasonable.
So just to kind of close this one out, hope everybody's being reasonable. So thanks for listening. think I think this is a helpful topic. If you have any other topics that you'd like us to cover, you can email us at privacy at Jackson Lewis dot com privacy at Jackson Lewis dot com. Damon, always a pleasure. presenting with you. Yeah, same. Thanks, Joe. Thank you for listening to Jackson Lewis's podcast, We Get Work.
Focused solely on workplace issues, it is our job to help organizations develop proactive strategies, strong policies, and business-oriented solutions to cultivate a workforce that is engaged and stable. Please tune into our next program where we will continue to tell you not only what's legal, but what is effective. We Get Work is available to stream and subscribe on your streaming platform of choice, including Apple podcasts, Spotify, and YouTube.
For more information on today's topic, our presenters, and other Jackson Lewis resources, visit JacksonLewis.com. As a reminder, this material is provided for informational purposes only. It is not intended to constitute legal advice, nor does it create a client lawyer relationship. between Jackson Lewis and any recipient.