AHLA's Speaking of Health Law
The American Health Law Association (AHLA) is the largest nonprofit, nonpartisan educational organization devoted to legal issues in the health care field with nearly 14,000 members. As part of its educational mission, AHLA's Speaking of Health Law podcasts offer thoughtful analysis and insightful commentary on the legal and policy issues affecting the health care system. AHLA is committed to ensuring equitable access to our educational content. We are continually improving the user experience for everyone and applying the relevant accessibility standards. If you experience accessibility issues, please contact accessibility@americanhealthlaw.org.
AHLA's Speaking of Health Law
What Constitutes OCR-Quality Risk Analysis
Jon Moore, Clearwater, and Iliana Peters, Polsinelli PC, talk about what type of risk analysis the Department of Health and Human Services Office for Civil Rights (OCR) expects for compliance with the HIPAA Security Rule. The podcast discusses why it’s important to perform risk analysis at the information system level and the implications of not performing a comprehensive, enterprise-wide risk analysis. The speakers also make practical recommendations to help organizations evolve their approach to analyzing and responding to information security risk. Sponsored by Clearwater.
New Health Law Daily Podcast Coming in January 2025
Coming in January 2025, AHLA’s popular Health Law Daily email newsletter will also be available as a daily podcast, exclusively for AHLA Premium members. Listen to all the current health law news from the major media outlets on this new podcast! Subscribe Now
Support for A H L A comes from Clearwater, the leading provider of enterprise cyber risk management and HIPAA compliance software and services for hospitals, health systems, and their business associates. Our solutions include our proprietary software as a service-based platform, I R M Pro, which helps organizations manage cyber risk and HIPAA compliance across the enterprise. An advisory support and manage services provided by our deep team of information security and compliance experts. For more information, visit clearwater compliance.com.
Speaker 2:Hello, I'm John Moore. I'm Chief Risk Officer at Clearwater and, uh, also senior Vice President of Consulting Services. And I am, uh, delighted to be here today to talk about what constitutes OCR quality risk analysis. And joining me is IA Peters. Ia. Would you like to introduce yourself?
Speaker 3:Thanks, John. Yes. This is IA Peters. I'm really excited to be here with you as well. I'm a shareholder at Polson pc, which is a national AM Law 100 law firm. Um, and we do a lot of work with, uh, clients on HIPAA issues, including risk analysis under the HIPAA security role.
Speaker 2:And IA I think might be important for folks to, to, uh, understand some of your history as well. Uh, Eliana's a former acting deputy director at HH s's Office for Civil Rights, and of course, if you're not familiar with the Office for Civil Rights, they are the primary enforcement agency for hipaa. So I think, uh, perhaps that experience will come into play here as well, Leanne, as we have this discussion nicely. So
Speaker 3:I, I hope so,
Speaker 2:<laugh>. Yeah, I hope so too. So, Eli, you know, I have a, I have a few questions today that I, I'd like to discuss with you and, and, uh, I, I think that, um, that they will be helpful, uh, to folks out there who are trying to understand, you know, what really is OCR R looking for when they, you know, look to risk analysis under the HIPAA security rule and, and some of the challenges that organizations face. So it's okay with you. I'll just start, uh, going down my list of questions that I have, uh, that I'd like to discuss with you and we'll get started.
Speaker 3:Absolutely.
Speaker 2:So number one, why does a lack of or insufficient risk analysis continue to show up as a HIPAA violation year after year? And this is a, this is a great question because I think on average, as we've been keeping stats in this area, it's, it's ranged from about 85 to 90% of the, the, uh, settlements and civil money penalties related to security rule violations seem to include, uh, risk analysis, uh, shortcomings. So what, what are your thoughts on that?
Speaker 3:Right? Yeah, John, I I think you're right on, um, and I app always appreciate Clearwater statistics on this, um, because I think they're really, uh, illustrative for the industry in terms of the fact that this really is, in my mind, the largest area of legal risk for an entity is risk analysis and risk management under the HIPAA security rule from a HIPAA perspective. And I think that the fact that this keeps coming up as a potential violation, um, is, is, you know, really due to the fact that entities, number one, and we'll talk about this, I know John, um, is that entities really, really don't understand what this requirement is. Um, that the requirement is very comprehensive. And so entities tend not to get the scope right, even if they do actually understand what it is. And that, um, OCR actually expects you to do this over time. So, um, not only is this the first thing they're going to ask you in any security rule investigation, so any security law investigation related to breaches, complaints, referrals from other agencies, et cetera, this is the first thing in an, in the OCR data request that you get that the OCR is gonna ask you for is, is for your risk analysis. In many cases, they also asked for that risk analysis over a period of years. So it's not just that, you know, folks don't understand it, which is true, they don't get the scope right, which is also true, but also that they end up getting asked for a very comprehensive set of risk analysis that is those that have been done over a six year period and they don't have them to produce to ocr. Um, maybe they've never done one, maybe they've only done one for the last two years. Um, maybe the scope isn't right and maybe they've done an audit instead of a risk analysis. So I think that the, given what is provided to ocr, there continues to be, again, an identification by ocr. This is a major issue, particularly because this is really meant to be the cornerstone of your HIPAA security role program. So you really, it's really difficult to get the rest of your HIPAA compliance program with regard to the security rule, right? If you don't have this piece to start with. Um,
Speaker 2:Yeah, I, I mean, I think, I think you nailed it right from the get-go. And as much as, um, there's a continues to be, and I'm not, well, I have some ideas as to why, but there continues to be a misunderstanding of what exactly is expected for risk analysis under, uh, the HIPAA security rule. There. Some of that blame, I think, uh, falls to the, the cybersecurity, uh, consulting industry who, uh, you know, p who pedal many things that are called risk analysis and, and under normal, normal circumstances may be considered risk analysis. But in terms of the expectations of OCR r and OCR r specific guidance around this risk analysis do not, uh, do not meet that guidance. Uh, you know, to, to your point, there's other things like, uh, technical testing and, and um, uh, gap assessments and control checklists and other things that, uh, organizations and audits and other things that organizations, um, believe to be risk analysis. And, and they may address some of the other requirements under the HIPAA security book, but they're not risk analysis, at least not in OCR R'S mind. And I think that's, uh, that's just continues to be, uh, to your point of, of ongoing problem. I think, uh, I think another, uh, concern that, that or issue that we see is that, uh, many organizations have limited, uh, funds to apply towards cybersecurity. And, and a lot of times, um, there's decisions that are made to, uh, apply those funds that don't include necessarily doing risk analysis. And, and that's unfortunate for reasons which we'll probably explore, um, more going forward. But I, but I'm, I think we're aligned in sort of our experience with this and why this continues to be a, a problem. Uh, so, uh, kind of kind of working on that, uh, notion of how, uh, risk analysis of is often misunderstood for other, uh, types of assessments that are done or evaluations that are done. Um, what's the difference in your eyes between risk analysis and, and controls assessment and, and what are some of the limitations of a, of a controls gap assessment or a controls checklist in managing cyber risk?
Speaker 3:Right. Yeah, no, I think that's a great question. And I think, you know, John, your, your team at Clearwater is particularly good at, uh, assessing out this question for clients too. Um, and, and so I know that you deal with this a lot as well. Um, and I think the issue here really is that, um, entities get often get confused between, again, what you're, what, what we're calling a risk analysis and what the, what the regulator and the HIPAA space calls a risk analysis and, and something that in many other industries, they call it enterprise risk assessment and a controls assessment. Um, and the controls assessment to your earlier point is, is still very important. It's, you know, it's an important part of your larger, um, assessment of your, you know, your entity's ability to, uh, meet legal obligations, certification obligations, you know, other, other obligations under Seder federal law or, you know, credit card requirements, for example. But, um, but it's not a risk analysis because it doesn't ultimately determine the risk to your data. Um, and I think that's what the regulator's looking for. And so what OCR asks you for is a, a risk analysis that includes inventories and data, um, workflows and asset inventories, the data inventories and asset inventories, that, that really make clear where the data is so that you can really understand the threats, um, uh, to the data and the vulnerabilities associated with the applications and devices that you use to hold that data. And if you don't do that, if you rely on a controls assessment that is sort of a controls checklist, we have these controls in place, you miss, um, the, the vulnerabilities and the threats to data where it lives. And so ultimately, a controls, uh, assessment really only gets you part of the way, because it's not just about assessing which controls you may have in place in certain areas of your enterprise, it's about understanding the risk to the data so you can figure out what controls are appropriate and then implement those controls wherever they are appropriate, given the risks to the data. So if you don't actually start with the data and you start instead with the controls, then you're going to miss, um, you're going to miss data, um, you're going to miss risks, um, and you won't implement the right controls and then you're gonna have a breach. And that's essentially what always happens is that, um, uh, you know, OCR is looking at the risk analysis and what they end up doing is identifying the place where the entity did not appropriately identify the risk to data and didn't implement the right controls, and then they had a breach of some kind.
Speaker 2:Right. I, you know, I think, and, uh, certainly everyone should recognize the value of, um, controls or safeguards, and I use those terms interchangeably, the, of the sort of, uh, catalogs of controls and, um, how helpful they are in understanding and securing an, uh, an organization and their information assets. And I think of things like the, um, FSMA baselines, whether that's a low, um, medium or high baseline control sets, or the C cis top 10 or top 20, and there's others as well out there from other different, uh, controls catalogs. And those can be extremely valuable to our organization and establishing that baseline, that that baseline of controls or safeguards that, uh, they have in place. But to your point, Leon, it only gets you part of the way there. And, and, and we see that specifically in the, um, guidance on, on risk analysis from ocr, where, where controls assessment is part of that guidance, one of the expectations that you, that you do a controls assessment. But to your point, uh, there's, you also need to be looking at, um, the assets that are, are in scope, those systems are components that, uh, are in scope of the risk analysis and those reasonably anticipated threats and vulnerabilities and, and then making a determination of what's gonna be the impact if this threat acts on this vulnerability, uh, or the likelihood that this threat acts on this vulnerability given those controls or safeguards that are in place. And what's the impact of that to our organization to understand, uh, whether there's additional safeguards or controls that we, that we should be putting in place, uh, to manage that risk or to reduce that risk to an acceptable level for our organization. So, uh, again, you know, I think that, that we're, we're saying the same thing. There's obviously, controls are important and control assessments can be extremely valuable, and understanding control baselines can be particularly helpful, but it doesn't get you all the way there to necessarily understanding where those risks exist, uh, within your organization. You know, I, I, another thing that I'll, that we sometimes see, and, and maybe you've seen this as well, is the, um, the, the level at which that risk analysis or that analysis in general, depending on what they've had an organization has done, uh, is performed at. So oftentimes we'll see it done at like a corporate level or a very high level, um, in that evaluation instead of really looking at those, at that information system or component level. Uh, why do you, why do you think it's important or why do you think that that OCR has that expectation that the evaluation will be done at an information system or component level?
Speaker 3:Right. Um, it's a great question, Don. And I think that really the idea is that, um, it is so important to understand where all of your data is. It, it, it's just so common when I talk with clients about this requirement and really what's expected, um, and what the regulator's looking for in that many times they, they really do honestly think they have a good idea of where all their data is. They think it's, you know, in these parts of the organization and it's flowing to these vendors, et cetera. And then when they start digging into it and they start talking to team members and vendors, um, and, and really trying to get a handle on where all of the data is flowing, they find that there's a whole lot of data flowing to places that they didn't actually expect it to be. And so that's why I think it's so important to really sort of get in the weeds on this in terms of your data flows, the data inventories, and the asset inventories to your point is to really understand where the data is, because then you can accurately understand the risk to it. But if you don't even know that this vendor is getting this data or this, that this application is maintaining this data, then you can understand the risk to it. And so it's really about having detailed, again, in the weeds conversations about where all the data is so that you can ensure that you get to all of the risks. Because again, from what I see, not only, um, when I was at HHS as the regulator in charge of this enforcement, but also now when I'm working with clients in the, in the private sector, is that the breach happens in an area of the enterprise where the, um, entity just didn't know there was as much PHI or the kind of PHI that there was there. So they didn't anticipate the risks to that data and didn't appropriately implement the right safeguards.
Speaker 2:Right. And that's a very good point. And you know, another thing I think that sometimes we see is when you, when you're not, uh, doing that evaluation that, or, or taking that look at the information system level, you'll we'll see organizations that they'll capture the global control, so they understand sort of globally, they think they understand at a global level what controls are in place, but then it turns out that, uh, that isn't necessarily so when you get to the system, um, or, or component level. So I'm trying to think of a good example. So for example, uh, they may say that that OE have multifactor authentication, and they do, but they don't have it necessarily for all of their systems. And so there's, you know, there's these differences in controls that exist at the system level that sometimes we miss, uh, weaknesses that exist or risks that exist because of those differences in controls at the component level. So it's a certainly another area to, uh, uh, of, um, exploration when deciding at the level of, uh, what level to perform the risk analysis. So, you know, we've talked a bit about that. So in order for organizations to understand, okay, I, you know, I understand kind of what I need to do for a risk analysis, but what if I don't do it? What are the implications of not performing a, a comprehensive enterprise-wide risk analysis, uh, as required under the HIPAA security rule for an organization?
Speaker 3:Right. And, and again, I think the, the first, as you say that, we've talked about it a little bit. The first implication is the fact that you're very likely going to have a security incident involving the area that you've missed. So if, if you're, if risk analysis isn't comprehensive, it's not enterprise wide, um, you know, it doesn't get to a particular application, for example, um, that holds phi, then it's very likely that that application is vulnerable for all of the reasons that we've just said. You're gonna have a security incident involving that application, and it will very likely rise to the level of a breach. Um, so that's sort of the immediate consequence. The, the long-term consequences obviously are that the state and federal regulators are going to be very interested in the fact that you don't have a comprehensive enterprise-wide risk analysis. And that could result in not only, um, you know, a burdensome investigation from those regulators, potential corrective action that is, you have to do one anyway. Um, and on a specific timeline, but also potentially settlements and civil money penalties.
Speaker 2:Yeah, I, uh, I, one of our CISO customers at a very large healthcare organization, um, said to me once, and we were talking about, you know, why do the risk analysis said, uh, obviously I want to be in compliance, and that's important, and I, you know, wanna avoid, uh, any potential fines or penalties associated with the HIPAA violation. But perhaps more importantly, uh, risk analysis helps me avoid, uh, those unnecessary or stupid breaches. You know, it's gonna catch the many of the things that, that are just, um, the result of oversight or, or, um, you know, some of those simple misconfigurations and other things that exist. There's no guarantee or no way that we can, uh, reduce risk to zero for an organization unless we've, you know, buried under concrete somewhere. But, um, but we can avoid a lot of those unnecessary breaches. And a good way to do that is by understanding, uh, where your risks are within your organization so that you can make well-informed, uh, decisions about where to invest your security dollars. And, and, uh, that's I think, uh, for, for most of our customers where they really see the, the value of performing the risk analysis. But, you know, we've, we've talked about a a bit about why organizations maybe don't meet these requirements, but let's, let's go a little deeper. So what are some of the challenges that, that you think that organizations have, if they do choose to perform the risk analysis? And what recommendations would you have to help them perhaps evolve in, in performing or understanding or responding to, uh, information security risk?
Speaker 3:Yeah, really good question. I, I think that the real issue that I can con that I continue to see with risk analysis is that, um, many organizations sort of think that this is a one time exercise. You know, we did it two years ago, or we're gonna do it this year, and that's it. Um, and that's really not, not only what the regulations anticipate, but also not what is the best for the organization in terms of understanding the risk to their data and protecting it, um, against breaches of all types. And so I think really, because this is such a heavy lift trying to keep, um, entities sort of focused with their eyes on the prize in that, yes, you do this once, but you have to continue to update it, so you don't necessarily have to do it over again next year, but you really do need to be diligent about over the next year identifying changes in your enterprise, um, and assessing those changes. And then updating the risk analysis. So trying to sort of have that conversation with clients about how this is, um, sort of an evolving process and it's not a one and done process that this is really something that has to continue to grow with the organization and has to constantly be sort of on the list of things to do because it's never checked off, you're never done with your risk analysis. Um, I think that that's a challenging conversation and it's a, it's a challenging, um, issue for entities that, again, have limited resources and don't necessarily want to have to keep devoting resources to updating, uh, risk analysis and risk management plan.
Speaker 2:I think that's really, uh, a really helpful insight. Uh, and you know, we kind of see sort of two different ways that, uh, some of our customers look at risk analysis. Some people see it as a compliance, exclusively a compliance exercise. And in those cases, uh, I I think they tend more towards the, uh, I just want to check the box and, and move along. And, and that's unfortunate because you miss a lot of the value of the exercise of the purpose behind the exercise itself. For those organizations that have kind of be gone beyond that embrace the true purpose of risk analysis, they tend to, uh, it tends to be more of an ongoing operation for them. So they'll even, uh, they'll even be looking at systems during the acquisition process before they've even, uh, implemented them in their own environment to understand risks. And as changes, to your point, as changes occur within their environment, um, they're looking at the, the risks that, uh, are introduced through those changes on an ongoing basis. So that's a very good, uh, very good point. And I, I'll go back to another that you raised earlier too, that, uh, we see often is a struggle and this one happens right out the gate, and that is understanding the scope of the analysis and, and more specifically, um, understanding, uh, you know, what information systems or information assets do we have or components that we have. And if I'm looking at this from a HIPAA compliance perspective, which of those actually are used to create, receive, maintain, or transmit E P H I? And, and many, many organizations don't have a real good handle, uh, on their information system inventory, their component inventory, et cetera. Um, and, and that's, if you don't have that, if you don't know what you have, it's particularly difficult, uh, to do a risk analysis on those things. So oftentimes that's a, you know, kind of an initial activity that we see organizations have to engage in is, is to really understand that scope. Uh, one of the other things, and, and we'll talk a little bit about more about risk response, I wanna talk to you more about that, but, uh, one of the things we also see is that, um, oftentimes organizations will do the risk analysis, but then they don't act on on those risks, or they're, they don't manage those risks. So, you know, we, you come back the next time and they're in the exact same place they were before. And, and unfortunately, I think in many cases, uh, that's the result of, of not having good governance in place. Uh, you know, oftentimes the, the folks who are doing the risk analysis, maybe you're doing it for more compliance purposes and don't have the, or aren't empowered, uh, sufficiently in the organization to make sure that the right people get the information on those risks and that actions are taken accordingly. And so that's another, um, area that we tend to see organizations struggle with, uh, on an somewhat regular basis, although that's, that's changing fortunately. Um, so kind of going to down that theme on, on, uh, risk management or following up on that risk analysis, Eliana, once risks are identified, are there ways to better manage the process of responding to them, uh, that you've seen organizations be more effective?
Speaker 3:Yeah, you know, I think that's a really good question. I don't, I don't, I haven't necessarily seen a best practice other than making sure that there's someone responsible on a certain timeline. So, you know, so once you've identified a risk, you really need to make it someone's responsibility to take care of and whatever that means, maybe it's transferring the risk, maybe it's a certain set of safeguards or a different set of sc safeguards or, you know, working with a group to figure out what the next steps are, whatever the, the next steps are. Someone needs to be responsible for getting there and on a particular timeline. So, you know, in, in terms of, of managing the process, it, it, it never helps, I think, to have it all on one person because it's frankly just too much, in my opinion, for one person. And it really needs to be a team effort. And beyond that, um, the, the entities that I think do this most successfully are the ones that leverage a team to make sure that everybody's sort of tasked with getting the different pieces of the, the next steps done. Um, but, you know, beyond that, I think it's, it's, it's just a really, um, important undertaking that has to sort of be a focus area for the enterprise.
Speaker 2:Yeah, I think in, in my experience anyway, what I've seen is there's, there's, it's a bit of a maturity, uh, situation where I think organizations that do the best in managing risk have spent, um, time upfront in what we might call and what NIST might call risk framing. And, and, and what I talk about risk framing, I'm, I'm really talking about defining as an organization how we're going to engage in risk management. Uh, so what's the process we're gonna go through for risk analysis? And, and, and in this context, more importantly, what's the process that we as an organization are then going to go through in order to, uh, treat the risks that have been identified? And what's the governance structure for doing that? Um, such that, um, decisions about risks are being made at the appropriate level within the organization, and that, uh, the appropriate folks in the organization, to your point, are, are holding folks accountable for those risk treatment decisions. So if, if for example, uh, you know, a decision is made to mitigate a risk through the introduction of additional controls or safeguards, who's responsible for that? What's the timeline for that? Uh, what's the budget associated with that? Uh, when, you know, what's the, and, and, uh, how will we, how will that progress in mitigation be reported, uh, within the organization so that folks can be held, held accountable for it? So it's really, it's almost like, you know, that kind of formalized governance and program project man management approach, I think when applied to risk management tends to be, uh, the, the most effective for organizations that, that we work with. And, and, and by a effective, what I mean is a, um, we're documenting everything so that if we have an incident, um, and, and the OCR R comes in asking for our risk management plan, we're able to produce something, um, we're able to produce evidence that, um, we are engaged in risk management activities. And, and that's maybe something wanna ask you about too, Aliana. Um, and, uh, and also that, that we're making informed decisions about how we're managing risk at the appropriate levels within the organization. Um, so k kind of stepping back for a second, and cuz this is another good question and that I don't see talked about quite as much, but, uh, you know, what Eli, what's your experience with the expectations of OCR around documentation associated with, uh, risk management following the risk analysis?
Speaker 3:You know, it's, it's very similar to the expectation with regard to the risk analysis that we talked about before. And that is, you know, if you do a risk analysis, um, they're gonna be looking for documentation of that obviously over a six year period. Similarly, they're going to be looking for documentation at risk management over that six year period as well. And so what they're looking for is, um, documentation over time that shows that, you know, if you, um, document it in your risk analysis four years ago that you had a specific risk, um, they expect that to have been resolved over that period. So your risk management plan now should not reflect the same level of risk that you had, um, four years ago with regard to that issue. There should have been implementation of mitigation strategies in the interim to take care of that risk or to transfer the risk or to explain why the risk still exists. So if you've identified risks in your risk analysis over the years, whatever, whatever that looks like, if it was four years ago or two years ago or this year, then OCR is going to look for, and the state ags as well are going to look for documentation that addresses those risks, again, over a specific timeline and, you know, to be resolved. So if it's, you know, within three months you've made this progress, then you would document at three months, within six months, you've made this progress you would document at six months because the regulator is really looking for the progress that has made to reduce those risks that you've identified to a reasonable and appropriate level. And so ultimately that's why you're doing the risk analysis and that's why you have a risk management plan is to, you know, not only identify those risks, but then reduce them to a reasonable and appropriate level. And if you can't prove to the regulator that you've done that both through documentation and evidence of implementation, then the regulators consider that to be a potential violation. So it's about making sure that you have the right documentation, and it can be in a, you know, entities do this in a whole bunch of different ways in terms of the form and format of that, but it's about being able to prove to the regulator that you recognize the rest identified and that you implemented the appropriate controls to reduce the risk. And whatever that documentation looks like, you need to have that, um, in a way that you can hand it to the regulator. So I think, you know, obviously there are, you know, ways that Clearwater does that, that are very straightforward and, you know, really help clients with that, that process and that analysis. But ultimately, you know, there's no requirement in the security rule that it look a certain way or that it be called a certain thing, but it has to be able to prove to the regulator that you've identified the risks and that you're managing the risks in a reasonable way.
Speaker 2:And there's a, uh, again, really good point. I mean, I, I think we, at least my experience has been that a lot of organizations are a little even hesitant to do risk analysis because they feel like as soon as, uh, they have risks that are identified, there's a, they're immediately obligated to do something about'em. And, and that's not necessarily true. Uh, you know, there's, there's a recognition by OCR R that there's, you know, we're all out here and trying to do the best we can. We all have limited resources. What the expectation is, is that, uh, you're, once those risks are identified is that we put a plan in place that's gonna be reasonable and appropriate for our organization, uh, and that we're gonna work to that plan. And at least in my experience, to the extent that we can show that we've done that and that we are continuing to do that, uh, typically organizations are okay. So ia, thank you very much. It has been an absolute delight to talk with you, as it always is. And, and I always enjoy it and always learned so much and I'm, I'm sure the folks listening today learned quite a bit as well. Um, any last thoughts before we go?
Speaker 3:No, I mean, likewise, I always enjoy talking to you too, John, and I just, you know, I, I hope that folks find this helpful and that they really will take these requirements seriously and, and work with a great vendor, including Clearwater. Um, and you know, that we can really raise the bar in the industry on this.
Speaker 2:Well, thank you very much again. I'm, uh, John Moore, chief Risk Officer at Clearwater Compliance and the senior Vice President of Consulting Services. And, and I was here with IA Peters talking with you today. And, and thank you all for listening and we look forward to, to, uh, talking with you all again sometime soon. Thank you.