Speaker 1:
You're listening to Your Practice Made Perfect, support, protection, and advice for practicing medical professionals brought to you by SVMIC.

J. Baugh:
Hello everyone, and welcome to this episode of Your Practice Made Perfect. My name is J. Baugh, and I'll be your host for today's episode. We're going to be talking about security incident responses, and to help us talk about this very important topic is Justin Joy. Justin, welcome to the show.

Justin Joy:
Thanks very much J. It's great to be here.

J. Baugh:
Well, thank you for taking the time to talk to us about a very important topic such as this. Before we get into the topic itself, perhaps you could share a little bit about yourself with our listeners.

Justin Joy:
Thanks J. I am a lawyer in the Memphis office of the Lewis Thomason law firm. For the past many years a primary focus of mine has been in the area of data privacy and cyber security. Those areas go very much hand in hand. There are some distinctions between the two, but I spend a lot of time in that area with healthcare groups. Obviously HIPAA plays a very large part in this, and there are three parts of HIPAA that I deal with on a very frequent basis.

Justin Joy:
There's the HIPAA Privacy Rule, which hopefully everyone is familiar with. There's the HIPAA Security Rule that covers the handling of electronic protected health information. And then finally, I think what part of our focus today is going to be on, is the HIPAA Breach Notification Rule. On the balance I do spend most of my time helping medical practices with investigations of data security incidents and helping them make the legal determination as to whether or not that data security incident is just a security incident or it is a data breach.

J. Baugh:
Well thanks again, Justin, for being with us today and talking about a topic that I know is of utmost importance to our listeners. Cybersecurity is more important now than it ever has been, but we also know that it can feel overwhelming for our medical practices out there. You are responsible for information that many people consider some of the most important information about them. Unfortunately, we too often hear about this protected health information as the target of cyber criminals. We have covered a few episodes over the last few months on beginning the process of getting your cybersecurity program up and running and secure with a security risk analysis. We also covered some of the aspects of utilizing the technology you have to keep your system secure.

J. Baugh:
If you have not had a chance to listen to those previous cybersecurity episodes, please do so. We'll be sure to link those episodes in the show notes as well. Even with an effective cybersecurity program in place however, it's generally recognized that it's not a question of if an incident might happen impacting your patients' data, but rather it's a matter of time until when such an incident will occur. Now, we would like to round out our cybersecurity series with a discussion covering the points of what you should do if, or as Justin would say when, you experience a security incident or data breach. Justin, let's kick this off with the basics. First of all, what is a security incident?

Justin Joy:
J., that's a great place to start because I think there's a lot of confusion out there among medical practices about the distinction between a security incident and a data breach. And I hope one takeaway of our listeners today will be an understanding of that distinction between a security incident and a data breach. I think we'll be talking some more about that over the course of this episode. But to start off with a definition of a security incident, you need to turn to the definition in the HIPAA Security Rule. I'm actually going to read that just so we're very clearly on the same page here. But a security incident means the attempted, and I reinforce attempted there, or successful, unauthorized access, use, disclosure, modification, or destruction of information, or interference with system operations in an information system. Now, that's a mouthful.

Justin Joy:
But again, that is the black and white definition in the HIPAA Security Rule that I am looking at when I get a phone call from a client who has had an incident and I'm walking them through this investigation process. Because that definition, legally speaking, is much broader than a data breach. At the end of this episode today, I would like to talk, and not to get too far ahead of ourselves, but I would like to talk at some point about a incident response plan. But to wrap this back into this first point here, J., an incident response plan needs to define what a security incident is for your particular medical practice, and perhaps obviously that needs to be based in large part on the HIPAA Security Rule definition.

Justin Joy:
But there's some other definitions out there. For instance, NIST, which is the National Institute for Standards and Technology, they also have a definition of security incident, and that is more policy driven where a policy has been violated. But whether there's a variation or a flavor of the NIST definition perhaps combined with some other definitions, it really needs to be based on the HIPAA Security Rule definition for medical practices. So a very long-winded answer to what a security incident is. But again, the bottom line is it's a very broad definition that covers not only successful incidents that result in data breaches, but much more broadly, attempted incidents that could result in unauthorized use or access of EPHI.

J. Baugh:
Now in the news we often hear about information regarding data breaches, and we know that that's not a good thing. And I think that you mentioned earlier that there's a difference in those terms, so maybe you could tell us what the difference is between a data breach and a security incident.

Justin Joy:
J., a data breach is actually a legal determination, at least as I see it. And just like we started off with the HIPAA definition for security incident, I am going to go to the HIPAA definition for a breach. This definition is found in the HIPAA Breach Notification Rule. A breach is the acquisition, access, use or disclosure of PHI, protected health information, in a manner that is not permitted under the privacy rule. And here's really the kicker here, which compromises the security or the privacy of that protected health information, that PHI.

Justin Joy:
I emphasize that part at the end, because there is a presumption anytime that you have one of these uses, or accesses, or disclosures of information that's not permitted by the privacy rule, there's a legal presumption that you have a data breach on your hands. And under the HIPAA Breach Notification Rule the burden is on the medical practice then to demonstrate that that improper use or disclosure did not likely result in a compromise of that patient's privacy. And there's a number of specific factors that would have to be analyzed to get to that point. But the bottom line is, again from a legal perspective, the definition of a data breach under HIPAA is much more narrow than it is when you're talking about a security incident, so the two are different.

J. Baugh:
Well, that's great. Thanks for clearing up the difference between those two terms. You know, I think it might help if we had some examples. So do you have any examples that you could give us of security incidents?

Justin Joy:
I sure do, and they can come in a variety of different flavors. Some of these we hear about. Unfortunately, some of these may have been experienced by medical practices. But one example is the unauthorized attempt to gain access to a system, whether that's an email system or a network system. And as I said earlier with the definition of security incident, that does include an unauthorized attempt. I think at this point, J., probably important for me to point out that every single incident does not have to be investigated, and we may talk about that a little bit more. But there are situations that even the unauthorized attempt, where it's not successful, to get into a system may have to be investigated.

Justin Joy:
Another example is the installation of malicious software or malware, also known as a computer virus. Another example is ransomware, which is a variety of malware that can do all kinds of bad things, and we're certainly hearing a lot about that in the news these days. The theft or the loss of a device containing data. And it's not necessarily EPHI but data, can be a security incident and then you have to investigate to determine whether or not that device contains EPHI and take it from there in making that legal determination as to whether or not a breach has occurred. Then also an incident involving the unintended disclosure of information. For instance, you have someone sending an email to the wrong recipient and that email unfortunately contains an attachment with a lot of PHI in there. Well, that's a security incident, and that certainly can become a data breach.

J. Baugh:
Well, it sounds like you had several examples of what could be considered a security incident, so let's talk a little bit about frequency. How many security incidents happen every year?

Justin Joy:
J., the short answer is, no one knows. And frankly there's really no way to know, especially if you look at this from the perspective of those attempted incidents that are not successful. But from one way of looking at this, if you take the number of publicly disclosed data breaches, and I'm including not only HIPAA breaches, but all the data breaches that are disclosed, at least by one measure last year that was just over a thousand. There's different ways of measuring that and different reports say different things, but from one measure it's over a thousand. But then you drill down from there and you look at the number of breaches that happen that are small HIPAA breaches. By law that's defined by less than 500 individuals. Now, those are not publicly disclosed typically.

Justin Joy:
They do have to be reported to HHS. That number in 2019, which is the most recent data that we have, that number was over 60,000, and those are all breaches. Again, the concept is that a security incident is much larger than a breach. So in other words, every security incident is not a data breach, but every data breach is a security incident, if that makes sense. So we're now at 60,000 and to be sure a lot of those smaller breaches are not cyber breaches. They're not email disclosures. A lot of those are on paper still, but that's still a very large number. They keep going up from there. J., the next level would be the number of reports to the FBI's Internet Crime Complaint Center, also known as IC3. In 2020 that number was nearly 800,000. Now, all of those are not security incidents, but some of them may be.

Justin Joy:
Probably most of those are because most of those are resulting from a malicious attempt to get access to a computer system, or at least trying to fool someone like in a business email compromise through a social engineered attempt to steal money. So we're now at 800,000. There was a report about five years ago from the FBI with an estimate that only 15% of the nation's fraud victims reported crimes to law enforcement. So if you take that 800,000 round number and you take the 15% that's only reported, that gets you to over five million. So we're obviously talking about a very, very large number. When you talk, again in the context of those unsuccessful security attempts, it's I think much larger than that. The point here is, regardless of the number it is everywhere affecting medical practices every day of all sizes, and it's something that every medical group needs to be aware of.

J. Baugh:
Yeah. That is really a high number of security incidents. I think several of our listeners will be surprised to hear numbers that are that high. So now a big question for our listeners would be, what exactly does a medical practice need to do if they think they have had a security incident?

Justin Joy:
Well J., that's a great question, because I think like I was mentioning earlier, I think there is some confusion about the similarities, but more importantly, the differences between a data breach and a security incident. But along with that, I also think there's a bit of a misunderstanding about a medical practice's obligation to investigate a security incident. I think there is some notion out there that if it's not a data breach and there's not an actual indication that data has actually been stolen, then a medical practice doesn't have anything to worry about or they don't need to do anything.

Justin Joy:
That is not what HIPAA says. HIPAA is actually quite clear that anytime you have a security incident it must be investigated. Because what you're investigating, and as I mentioned at the beginning of the episode today, I spend a lot of time helping groups with these investigations because you're looking into whether or not you've got a data breach, which again is a legal determination. Where it gets a little tricky is the question that becomes very quickly confusing. Well Justin, you said earlier that every attempted unsuccessful security incident is a security incident.

Justin Joy:
Does that have to be investigated? The answer to that is no. And this is where it does get technical, it does get confusing. But this is actually a nice segue into I think what we'll talk about in a minute when it comes to incident response plans. A group needs to define what is going to trigger their obligation to investigate a security incident. For a quick example, if you have just a run-of-the-mill computer virus that is known to be relatively innocuous, is not causing any system harm, there's certainly no data being encrypted or data being exfiltrated, it's just a run-of-the-mill computer virus that may pop up, it's quickly quarantined and eliminated, that probable does not need to be formally investigated.

Justin Joy:
You need to make sure the nature of that virus and it doesn't cause more harm, but you don't need to launch a formal investigation into that. Now, contrast that to someone who has had their account credentials compromised, and someone has gotten into the system, that certainly is a security incident warranting, and I would say required, investigation. Because at that point, you know that you've got an account compromised. Did it last for five seconds, 15 seconds, 15 minutes, or 15 days? And until you have that investigation you don't know, and you can't make the determination as to launch, you have a data breach on your hands.

J. Baugh:
Let's look at this from just a slightly different angle in regard to preparation and to working to avoid an incident. And the question there would be, what can a medical practice do to prepare itself to respond to one of these security incidents?

Justin Joy:
J., the best way that I advise medical practices to get ready for when, and again not if, but when they have one of these incidents, is to have an incident response plan in place. It's a document that requires some thought. There are maybe some forms out there that groups can start with. But no matter if you start with a blank sheet of paper or you start with a template maybe found online somewhere, it's important that each group work through this process as I mentioned earlier, defining what a security incident is. They can copy and paste the definition from the HIPAA Security Rule. That's a great place to start, and it needs to incorporate that definition but it might be broader. It also needs to define what type of incident is going to require an investigation, what type of incident is going to trigger the incident response plan. It needs to be thought through.

Justin Joy:
It does not necessarily need to be overly technical, but it needs to be specific for that group. Also, once that plan is in place, everybody who's going to be involved in implementing that plan, whether it's internal folks only, in a smaller group that might just be one or two people. Say the HIPAA security officer, and maybe even if it's an outside contracted IT person, that might be the incident response team. If it's a larger group, there may be a number of folks involved. In addition to the HIPAA security officer and IT resources it could be somebody from PR. If you've got a large data breach, you're going to have to notify the media, and having someone on the marketing and public relations side on that team would be important. Obviously, someone to make executive level decisions, legal counsel, folks along those lines to help triage this incident to figure out what to the next steps are.

J. Baugh:
You've been talking a little bit about a security incident response plan. I'm wondering if you could provide us with some of the basic components of what that type of plan would contain.

Justin Joy:
J., again, it's got to contain a definition of what a security incident is, and I think we've covered that to some extent. But I can't repeat enough how important that is because that's the triggering event. If you have a computer incident or a data incident that meets that definition, then you move on down through your plan. You need to identify who in your organization is to be notified when one of the workforce members identifies a security incident. The HIPAA Security Rule requires that everybody in the workforce know about security incidents and have an idea as to what they are. And perhaps most importantly, know about their obligation to detect and then notify someone within that organization.

Justin Joy:
It's often the HIPAA security officer, could be the privacy officer, could be IT, about something that they see on their screen, some unexplained system behavior. But in any event, that plan needs to specifically identify who in the organization is going to be notified when a security incident is discovered. We talked just a minute ago about the importance of that incident response team. Those team members need to be identified in that plan, again, whether it's internal only or whether external resources are also going to be involved.

Justin Joy:
And certainly for SVMIC policyholders it needs to be clear in that plan that SVMIC needs to be one of the first calls, if not the very first call, that is made when a group thinks that they have a security incident on their hands that potentially triggers their cyber coverage. Something else that would need to be in a plan is any type of documentation or internal reporting requirements. Part of the requirement to investigate a security incident is to document that security incident. One reason for that is that you can learn from what happened, learn from those near misses that hopefully are not data breaches. But if you don't document that, that knowledge can be lost six months, 12 months later, when you go through the security incidents over the course of a year.

Justin Joy:
I would suggest, if possible, to include a form or two. It does not need to be complex or lengthy. But some basic information about what happened, the nature of the incident, how it was responded to, what was done to mitigate any considerations. Then finally, I've seen some plans that are on the more lengthy side. But there can be some other considerations in there such as assigning a severity level to the incident. There we're talking about things like ransomware that obviously would require an immediate response or something that is more of what I would characterize as an annoyance that may not require an immediate drop-everything type of response, but still would warrant some investigation just to confirm that there's nothing going on.

J. Baugh:
Well Justin, this has been great, and I think this information has been very helpful. Before we wrap up this episode I'd like to ask you if you have any last-minute tips or advice that you would like to leave our listeners with.

Justin Joy:
J., I can't emphasize enough the importance of that incident response plan and spending some time being thoughtful and developing that plan. I work with clients in putting some of those together. It's interesting seeing the light bulbs go off in thinking through some of these scenarios that may come up and someone says, "Well, yeah. I guess we haven't thought about that, and maybe we need to figure out what we're going to do when that happens." I keep emphasizing when, not if, because that really is the reality with our technological world today. So everyone needs to be familiar with that plan. And I would suggest having your instant response team go through that plan at least once or twice a year to make sure that it's still current, makes sense, and maybe needs to be changed because those threats change every day out there.

J. Baugh:
Well Justin, once again, this information has been very helpful, and we want to thank you for taking the time to share all this with us today.

Justin Joy:
J., thanks very much for having me.

Speaker 1:
Thank you for listening to this episode of Your Practice Made Perfect. Listen to more episodes, subscribe to the podcast, and find show notes at svmic.com/podcast. The contents of this podcast are intended for informational purposes only and do not constitute legal advice. Policyholders are urged to consult with their personal attorney for legal advice as specific legal requirements may vary from state to state and change over time. All names in the case have been changed to protect privacy.