Written Information Security Programs, commonly referred to as WISPs, are critical plans to have in place – not only to efficiently and effectively respond to ransomware attacks and data breaches when they occur – but to maintain compliant privacy practices for your organization.
Transcript
INTRO
Written Information Security Programs, commonly referred to as WISPs, are critical plans to have in place – not only to efficiently and effectively respond to ransomware attacks and data breaches when they occur – but to maintain compliant privacy practices for your organization.
On this episode of We get privacy for work, we discuss the key safeguards WISPs provide, and the potential costs to your organization in the absence of a program.
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 should employers consider when creating and implementing a WISP, and how does that impact my organization?
CONTENT
Joseph Lazzarotti
Principal, Tampa
Thank you, Alitia, and welcome to the We get Privacy podcast. I'm Joe Lazzarotti, and I'm joined by my co-host, Damon Silver. Damon and I co-lead the Privacy Data and Cybersecurity Group here 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 do we handle data safely? In other words, how do we leverage all the great things data can do for our organizations without running headfirst into a wall of legal risk? How can we manage that risk without unnecessarily hindering our business operations?
Damon Silver
Principal, New York City
On each episode of the podcast, Joe and I talked through a common question that we're getting from our clients. We talk through it 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 for today is what is a WISP and do we really need one? Just to tee up the discussion, at a very high level, WISP stands for Written Information Security Program. It's basically going to be the set of policies, procedures, and other documents that lay out what you're doing from a data security perspective.
Joe, just for those who may not be familiar, what are some of the key areas that you seek to address within a WISP when you're working with a client to develop?
Lazzarotti
In a word, I would say yes. Most, if not all, organizations probably need a WISP. The requirement for a WISP or the recommendation for a WISP comes from a lot of different sources. It might be statutory, contractual, or industry guidelines that are generally accepted and anticipated that your organization would have one. It might come from multiple sources at the same time. Certain types of information might trigger that obligation, depending on what type of data your organization maintains or collects.
Wherever it's coming from, whatever the obligation is, more than likely it's going to have certain areas that it has to address regarding, typically, personal information. Although not always. If you have trade secrets, you have obligations to protect those trade secrets and having a WISP might help you do that. The point is, what are those sections? That's your question.
Where I see clients developing a WISP, what those sections look like typically fall into administrative safeguards, physical safeguards, and technical safeguards. Sometimes organizational safeguards like agreements with third parties are carved out that way, although that might be administrative.
Damon, those are the areas that I typically see in a WISP. We can flesh that out, but that's what I'm thinking on that.
Silver
That's typically how I see them organized as well. Joe, it would be helpful to zoom in. Administrative safeguards, what are some of the policies and procedures you typically see within that section of a WISP?
Lazzarotti
From an administrative perspective, the first thing is the allocation of responsibility. Do you have a privacy or security officer? Who are the people who are going to be charged with having authority to implement the document, make changes and whatnot? That may involve a lot of different stakeholders. Dealing with access management is an important administrative function.
At the administrative level, it's interesting to think about administrative versus technical, because sometimes it seems like you're talking about the same thing, but maybe it's a little different. One illustration of that is good in the area of access management. From an administrative perspective, you might try to draft the WISP to determine who should have access. Whereas, from a technical perspective, you might use role-based access management tools to implement that decision. Access management certainly fits in the administrative realm. Things like training, security awareness, maybe even an incident response plan, things like that.
Any other thoughts on that topic on your end from an administrative perspective?
Silver
That covers most of what I typically see. A couple of others just to throw out the minimum necessary. We've done some extensive discussion in prior episodes about this idea that people should only collect and use the minimum amount of data necessary for a particular purpose. Oftentimes, within the WISP, that's one of the first policies, because it really is foundational, and it trickles down to everything else that is covered within a WISP.
One other area is data classification. You touched on this a little bit when it comes to why an organization might have a WISP. The types of data that it maintains, the industry it operates in, and what it's agreed to in its contracts are going to dictate whether there is a WISP obligation and what that obligation looks like. For many organizations, getting a handle on all of those areas and obligations is going to start with understanding what types of data they have and what either legal or contractual obligations those data types are subject to. That's another administrative area that I like to touch on with clients.
What about physical safeguards? What would you typically see in that section?
Lazzarotti
It's often easy to get caught up in electronic data and the types of things we think about, like encryption and whatnot, and we'll get to that. We still have paper that still has some sensitive data on that, whether it's personal or business confidential. There are also physical things you can take, and physical policies and safeguards you can put into effect, like a facility security plan. What is a particular facility? What types of risks does that particular facility present to the type of data, the equipment, and the systems that are maintained in that facility? Again, an important point about just having a WISP is that part of that ought to be going through that risk assessment process. Thinking about that facility and about what the particular risks are. You may have 10 different facilities across the country. Each one may have a lot of different considerations, and that part of your WISP might take that into account by providing a plan for assessing that risk and then taking steps to deal with the physical nature of that particular location.
Locks on doors, alarm systems, and taking steps to make sure people who are moving around or getting access to the facility are documented somehow. Even if they're repair persons or visitors, you often see that when you go to a facility that you're asked to sign in. Those types of things from a physical perspective. As well as just understanding what devices and equipment you have. If you're trying to conduct an investigation to figure out which systems are compromised, if you don't have a starting point of knowing exactly which devices you're thinking about in the environment, it gets harder to do that investigation. That's a physical issue, not necessarily a technical issue.
Silver
That point is huge. We did a prior episode on data mapping. One of the areas where data mapping can get really challenging is when you move away from the applications where maybe you expect employees to be storing data, like on some of the laptops, phones, and other devices that perhaps you didn't expect them to store data on.
Then, even setting aside what employees might do if you're using printers or fax machines, those types of devices might be storing data on them as well. There have been instances where companies have gotten in a lot of trouble, ended up with litigation, or with big regulatory fines because they disposed of a printer without first wiping the data on it. That's definitely something to think about as well.
In the employment context, if you have employees using personal devices or company-issued devices, there are a lot of considerations related to how you are tracking what data is where and how you're making sure that information is secured. To your point, if there is a data incident, you're doing some internal investigation or you're responding to a subpoena, making sure that you have access to the devices and the data on the devices that you need in order to comply with your legal obligations.
Joe, that then brings us to the last category, which I think is the one that people traditionally think of first when it comes to data security, which is technical safeguards. What are some of the most important technical safeguards from your perspective for a client who's trying to prevent data breaches and put themselves in the best position to respond to them if they do have?
Lazzarotti
We touched on that a little bit anyway in terms of access management. Role-based access management is important. One way to control that is by defining who should have access and then trying to enforce that through some type of role-based management through the system. Validating those individuals through some type of multi-factor authentication. Talk to anybody these days, if you don't have MFA, multi-factor authentication, it's pretty much one of the key standards for securing an environment. It's not foolproof, but it certainly goes a long way toward preventing things like phishing attacks, at least helping to stop or minimize those.
Encryption at rest and in transit is another important way to protect from a cyber incident. Another type of practice that may also kind of spill over into physical records is data minimization and backup, document retention, and destruction. They all work together to minimize the footprint of the organization, both with respect to physical electronic records, so that even if you do get hacked, there's less there for the threat actors to get.
Those are three things that come to mind that I think are pretty important for organizations.
Silver
Retention and backups are a particularly important area to think about for a couple of reasons. One, say you have a ransomware attack or you have some other type of incident. If you have regular backups, you're going to be in a much stronger position in terms of how you respond to that incident, because you're going to be able to hopefully restore from those backups pretty quickly, get your systems back up and running. You're also going to have more leverage in deciding whether you have to pay the bad actor.
Then, to your point, Joe, if you're thinking about data minimization. If you are regularly doing backups and you're moving data, say, into archives out of your active systems, that is going to give people a lot more comfort in having shorter retention periods. We talk all the time to clients who say, I understand the risk of keeping all data going back 20 years. The problem is, every once in a while, we need some email or other document, like we need to find a contract. It makes us very nervous for that data to just be gone. This is an intermediate step. It's not gone; it's been archived. It does take longer and it's more expensive to recover from archives than from your live systems, but the archive tends to be a more secure repository. It's a way for, if you do have a breach, potentially being able to keep a lot of your older data outside the scope of the incident.
Joe, you talked a little bit before about some of the reasons why you might need to have a WISP. There might be a specific legal requirement. Some states, like California, Massachusetts, or New York, whether they call it a WISP or something else, effectively require you to have a WISP or something like it.
There are then a bunch of other states that say you need to have reasonable safeguards in place, which is generally understood to mean a WISP. If we look beyond these technical requirements that have a WISP, though, what are some of the practical impacts of either having or not having a WISP on things like getting cyber insurance, responding to government investigations or litigation? Where are you seeing clients use their WISP or suffer for not having a WISP if that's the case?
Lazzarotti
Some interesting stuff there. You're right. One of the things we see is companies we talk to a lot of times, businesses say, look, we're doing all these things. Doing them, writing them down, and documenting them are really important. As you mentioned, if you wind up in an investigation by a federal or state agency, the first thing they're going to ask you, if you've had a data breach, you reported it to them, and they want to find out what happened, is to show them your policies and procedures. Show us your WISP. Having that goes a long way toward getting out from under that investigation without having any penalties.
The same is true if you happen to be a service provider and want to get that big contract with a customer. Increasingly, customers are asking for that information to feel comfortable doing business with you because they'll see that you have developed a policy and a set of procedures to safeguard their data.
There have been some stories out there where, following an investigation, entities provided their WISP to the agency investigating them, and the WISP still had company in brackets throughout because the company must have downloaded it and never actually implemented it. They had one, but it wasn't really tailored to them. It wasn't really thought through; instead, it was basically just downloaded and saved. The agency said, hey, guys, you need to fill that out and actually use the WISP. You may have employees who violate a policy or cause a breach, and it's a lot harder to enforce a culture of security and privacy policies and procedures if you haven't really written them down and you can't point to anything.
It helps you to have better hygiene, do things regularly, and have something to point to and guide you as you build that culture of security and privacy in your company or organization. Those are, to me, some of the things that come to my mind when thinking about what we don't really have: we're not really heavily regulated, we don't have a particular WISP requirement, and we don't have contractual obligations. Every organization is going to have some personal data or some sensitive information that they have to protect. Thinking about that and writing that down makes a lot of good sense.
Silver
I totally agree. I love the point you made around the value of going through the process. We talked about this in the context of incident response plans. The document itself, whether it's a WISP or an incident response plan, there is value in having it. You may be legally required to have it, but the more important thing is going through the process. I've worked with so many clients where they may have a WISP, like one of the ones you mentioned, that's very templated, or we're working with them to develop one. As we go through the various areas of administrative, physical, and technical safeguards, they have realizations about gaps in the way they're doing things or about things that they're doing that actually are perhaps good, but they haven't been documented anywhere. Going through that process is extremely valuable from the standpoint of making sure that your program is in a good place.
Also, you mentioned government agencies coming back and saying, it's clear you didn't implement this because companies in brackets. I've also seen them come back and say, you say that you have this robust backup program or encryption, and we'd like to see evidence of it, audit controls, or logs. It was a template, so no one ever looked at whether these policies were actually consistent with what was being done. If there's inconsistency there, you created a lot of risk from a government regulation perspective, from a litigation perspective, and it could even be from a client perspective. There's value in having the document and going through the process of creating and updating the document.
Joe, if you don't have anything else to add, maybe that's a good place for us to wrap.
Lazzarotti
One thing I want to ask you before that, Damon, is to get your thoughts. I see this question come up, and it's also more practical. Sometimes clients develop a WISP or someone shared one with them, and it can be a lengthy document. They wonder, do we have to share this whole thing with employees? We have a handbook; it has something in there, but there are a lot of policies in the handbook. Then, there are things in the WISP. What do you recommend? How do you approach one, whether you have to share that document or that WISP with the organization or some people in the organization? Two, how do you reconcile and keep consistent the handbook versus the WISP?
Silver
That's a great question. Just to build on the question a little bit, clients sometimes ask, can we just incorporate this or pertinent portions of this into the handbook? There's a lot of value in keeping them separate. One, just because a WISP is a pretty extensive document, and your handbook is also a pretty extensive document. It can get just overwhelming in terms of page count.
Also, an important concept in the data security space is that your policies, procedures, and program are supposed to be role-based. There are going to be different aspects of that WISP that apply to different types of employees. A lot of your employees are going to have very little to do with your technical safeguards, other than the fact that they might have to log in through MFA or enter their password. They're not going to be the ones deciding what the technical safeguards should be, nor implementing the technical safeguards. However, they are going to be involved in a lot of the administrative safeguards. They're the ones who have to spot the phishing email, think carefully about whether they're complying with the minimum necessary requirements before they make a disclosure to a vendor, and check to make sure that the vendor has been vetted and you have a contract with them.
In thinking through what should be shared with employees and also how to conduct training, I do recommend not going crazy, but making it somewhat tailored to the specific roles of the various members of your workforce. That's what's going to be most effective in getting them to actually do what you want them to do to better protect your data.
Lazzarotti
Absolutely, that's a really good point.
Silver
Thanks everyone for joining us. If you have any questions about today's program and suggestions for topics we should cover in the future, please email us at Privacy@JacksonLewis.com. We hope you join us again on another episode.
OUTRO
Thank you for joining us on We get work®. 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 to on Apple Podcasts and YouTube. For more information on today's topic, our presenters and other Jackson Lewis resources, visit jacksonlewis.com.
The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.
