Cathie Brown, Vice President, Consulting Services, Clearwater, speaks with Ryan Higgins, Partner, McDermott Will & Emery, about what a HIPAA Security Rule Risk Analysis (HSRA) is and what it means to conduct an “OCR-compliant” risk analysis. They discuss how an HSRA relates to other security assessments, suggestions for organizations to follow when conducting an HSRA, and the risks of failing to conduct an HSRA. Ryan recently co-authored an article on this topic for AHLA’s Health Law Weekly. Sponsored by Clearwater.
To learn more about AHLA and the educational resources available to the health law community, visit americanhealthlaw.org.
Cathie Brown, Vice President, Consulting Services, Clearwater, speaks with Ryan Higgins, Partner, McDermott Will & Emery, about what a HIPAA Security Rule Risk Analysis (HSRA) is and what it means to conduct an “OCR-compliant” risk analysis. They discuss how an HSRA relates to other security assessments, suggestions for organizations to follow when conducting an HSRA, and the risks of failing to conduct an HSRA. Ryan recently co-authored an article on this topic for AHLA’s Health Law Weekly. Sponsored by Clearwater.
To learn more about AHLA and the educational resources available to the health law community, visit americanhealthlaw.org.
Support for ALA comes from Clearwater, the leading provider of enterprise cyber risk management and HIPAA compliance software and services for healthcare organizations, including health systems, physician groups, and health IT companies. Their solutions include their proprietary software as a service-based platform, IRM Pro, which helps organizations manage cyber risk and HIPAA compliance across the enterprise and advisory support from their deep team of information security experts. For more information, visit clearwater compliance.com.
Speaker 2:Well welcome everyone to our podcast on tips and traps of conducting a risk analysis. And thank you for tuning in. Um, this is an important topic since according to ocr, their phase two audit report. Most of the covered entities and business associates that were audited, failed to implement the HIPAA security rule requirements for risk analysis and risk management. And similar findings were in phase one audits. So my name is Kathy Brown. My current role is Vice President of Consulting Services at Clearwater. I have 25 plus years of experience in IT, healthcare and security. I would also like to introduce Ryan Higgins. Ryan.
Speaker 3:Hi, good day. This is Ryan Higgins. I am a partner at McDermott, Will and Emory. I sit in the healthcare practice group, um, and my practice focuses on, um, health information privacy and security matters, um, including, uh, compliance program building and design to, uh, data strategies to, um, ongoing, uh, myriad compliance matters. Um, responding to incidents or breaches interfacing with OCR or state authorities regarding investigations. So the, uh, whole matter of, uh, data privacy and security, uh, compliance issues. And, um, you know, Kathy, you, you mentioned OCRs face due audit report, um, that, uh, talks about the importance of conducting a security risk analysis. And I can, I can tell you, you know, I haven't done a government audit, but in the, um, you know, sample size of, uh, you know, the not so small sample size of organizations that I see in my practice, um, particularly in the, um, acquisition target, um, you know, transaction due diligence, um, it is a, is an issue. It's a poorly understood, um, I think requirement that is not, um, assiduously adhered to. And so, um, I would echo OCRs audit finding just based on my own practice.
Speaker 2:Yeah, and Ryan, you know, HIPAA has been around a long time. The requirement for risk analysis has been there from the very beginning. And here we are some, you know, almost 20 years later. And this is still an area that is not well understood. So, you know, could you kind of give us a primer on, you know, what you see the HIPAA security risk analysis is and what it means to conduct a HIPAA security risk analysis that is actually OCR compliant?
Speaker 3:Sure, sure. Absolutely. So, um, you know, as folks may know, the, um, uh, HIPAA rules are organized into, um, four different baskets. You have your privacy rule, security rule, breach notification rule, and your enforcement rule. The security rule is where the security risk analysis requirement comes out of. Um, and as folks may know, the security rule, um, requires, um, certain types of safeguards, and those are administrative, physical or technical safeguards. The security risk analysis requirement comes out of not just the security rule, but more specifically the administrative, um, safeguards requirements. And what it, what it actually says in a security rule is that organizations that is both covered entities and business associates have to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of electronic protected health information held by the organization. And that's all it says. That is the language of the regulation in the HIPAA security rule. So, um, you know, if you are just an organization looking at the regulation, um, I'm not quite sure what that actually means, right? Uh, accurate and thorough assessment of the potential risks. Um, that sounds pretty pretty elastic. So, ocr, um, promulgated some guidance, um, regarding the conduct, uh, conducting of a security risk analysis. And that actually gives a little bit more specificity in what OCR is looking for. It identifies, um, six elements that a HIPAA security real risk analysis, um, you know, must address.
Speaker 2:Well, and, and to that point, um, you know, the guidance that OCR has put out actually list the scope of the analysis. So defining the scope of PHI and where that PHI is, and that's something that I see that organizations definitely struggle with, um, understanding where the PHI is within their environment. The next element is to identify and document the potential threats and vulnerabilities. And I think that is also an area that can be a little daunting for, um, people. The next one is the potential impact of the likelihood of the threat, the impact if the threat were to occur. And that helps to define the level of risk, and then there's the requirement to finalize that documentation. So it, it's not enough to really go through the exercise. It has to be documented, has to be well thought out, and it has to encompass everywhere that there is PHI in the environment.
Speaker 3:And I should say, I'll add Kathy, now, it, as you say, those, um, elements, it OCR describes this as foundational in achieving compliance with the hip security rules. So you can obviously understand it's foundational to understand where the E P H I is in the first place. Right,
Speaker 2:Right, right. Exactly. So Ryan, um, what relation do you think the hip security rule risk analysis has to other types of security assessments? You know, is there synergy or overlap?
Speaker 3:Um, there can be, um, one common mistake I see actually is that folks will conduct, um, some of these other types of assessments, which I can get into that they think is a security rule, risk analysis, or they think may satisfy the requirement, but it actually does not. Um, for example, we, um, the most common deficiency that I see, um, and this comes up, um, mostly in the context of due diligence and a transaction of a, you know, an acquisition target, um, you know, we'll ask and due diligence to see a copy of their HIPAA security world risk analysis. And, um, you know, assuming we get something that is responsive to that request, you know, again, they may not have done anything, but if we do get something, um, quite frequently it looks like what I've come to call in my practice a HIPAA security rule, compliance gap assessment, rather than a risk analysis. And what I mean by gap assessment is, you know, the organization, um, will have looked at, um, you know, each of the elements of the security rule, you know, each of the safeguards and security implementation, um, specifications, um, that they need to do. And it'll be, you know, maybe even a chart that'll have the requirement and it'll say yes or no, Have we done it? If not, you know, how do we need to improve? Um, so that is a, what I call compliance gap assessment, because you're looking at the elements of security rule and identifying whether you have compliance gaps that is not actually a security risk analysis in the way that, um, ocr, um, has described in its guidance. Um, you know, as Kathy said, you have to go through and identify where your E PHI resides the various risks, and then ultimately, and you come up with a risk rating. Well, the compliance gap assessment, um, is not a security risk analysis. Um, and so that's commonly, you know, one common trap that I see is, um, you know, representing and or believing that a gap assessment is a, uh, is a risk analysis. But, um, you know, to your question, Kathy, you know, what, what synergies, um, may exist with some of these other types of assessments. But if you have, um, you know, or an organization, um, you know, a vendor that is helping you with your security risk analysis, that vendor such as Clearwater is gonna be asking a number of questions around, um, you know, where your E PHI resides, um, how are you safeguarding that E P H I, what are the particular risks to it? Um, and so the, that type of, of organization vendors already, you know, well positioned to maybe actually do a compliance gap assessment as well, not as a replacement for risk analysis, but actually also do a compliance gap assessment or, um, security risk analysis process can also have synergies with, uh, what I would call technical assessments such as a vulnerability scan or a penetration test, um, or even a comprehensive cybersecurity risk assessment. Um, which is different than a HIPAA risk analysis. Um, even, um, the high trust, um, common security framework, um, includes, uh, domain 17, which is called risk management, which requires and includes, uh, risk assessment, risk management, and risk mitigation requirements. And so it's possible that a HIPAA security world risk analysis could be done in such a way to satisfy, um, that domain in the, uh, high trust certification requirements. So there are, um, there are a lot of synergies here with other types of assessments, but we have to be very careful not to supplant or replace or think we've done a security risk analysis if we've done one of those others, um, and not, you know, followed what OCR says in its guidance is a security risk analysis.
Speaker 2:And, and that is a really good point, Brian, because I have seen organizations that are high trust certified, or another one that I see is a SOC two type two, and they misunderstand that those certifications by themselves don't actually fulfill the HIPAA security risk analysis or even a P
Speaker 3:Or even A P C I dss. I get sometimes in response to this request, which is, you know, paint macr industry, um, data security standard. It's not, it's not the same thing, but it, if it has the word security, it has the word assessment in the tables. Sometimes organizations, um, you know, get confused.
Speaker 2:Yes. And, um, you, you made another good point too, because at Clearwater, um, we do the security risk analysis that meets OCR requirements, but we also do technical testing. So we do vulnerability scanning and penetration testing, which is part of hipaa. They require technical assessment. They also require the gap analysis, what you talked about, and we frequently refer to that as a non-technical assessment. So it, I think it's important that, um, organizations understand all three are a requirement of hipaa. It's not just the security assessment, right? It's also that technical testing as well as the gap assessment or the non-technical piece of this.
Speaker 3:Yep, that's exactly right. The, the security risk analysis is required. We can't deviate from it. We have to make sure we're not doing another type of assessment. But again, OCR says that's just the foundation of compliance. Um, how do you know what policies you need to have? How do you know where to apply your technical test or safeguards if you first don't know where your E PHI is and what are the particular threats and vulnerabilities, um, to your E P H I at that location? So it's truly, truly foundational. Um, so I, I'm, I'm curious, um, when you do a security risk analysis for a client, um, you know, the, the HIPAA security rule, um, is not clear. And even the OCR guidance is not clear as to how frequently those assess those analyses have to be done. Um, OCR uses this word continuous quite frequently. You know, security risk analysis is a continuous process. Um, but I'm, I'm always asked the question, you know, how, how frequently do I need to do one? And there's not a perfect answer. Um, so I'm curious as to what, um, you know, what you see at Clearwater, you know, with respect to your clients.
Speaker 2:Yeah, that's a really good question because I think, um, there was an understanding or maybe an unspoken rule that you needed to do a security risk analysis annually. And so a lot of organizations put that on their roadmap and had that in place to meet that requirement. And that's good. However, you know, the output of a risk analysis are understanding what your risk are. And so the next step is risk remediation or what Clearwater refers to as risk response. So once you've gone through that risk analysis process and you've identified what your risks are, the next step, of course is to remediate those. So this is a continuous circle, and clearwater's been working with our customers along the way to, um, you know, we do a risk analysis, we follow that by risk response. We come back and do the risk analysis, we come back and do risk response. Now, many organizations and many of our customers have, um, lots of phi cuz we work predominantly in healthcare. And I know that's where your focus too. So, um, Clearwater takes the approach that we need to look at all of your systems that have, you know, that create process, transmit or store phi. Well, if you're an organization that has thousands of systems or applications in place, it's, it's hard to do all of that at once. So, you know, we, we take the approach to tier your applications and do your most important ones first, in terms of risk analysis, when we come back and do the risk response, we have likely highlighted some risk that are gonna be downstream. And so if we fix those in your next risk analysis, you're gonna become more mature with your program, if that makes sense.
Speaker 3:Yep, yep. Um, that's, um, that's an important point. So you have your risk analysis and then you have coming out of that, the risk management process
Speaker 2:Exactly.
Speaker 3:Going to work to remediate those to, you know, reasonable and appropriate levels. Um, those two requirements are actually right next to each other in the HIPAA security rule. Um, but they're, but they're separate. They're separate. I think it's separate Romans, they may be separate laus, but, you know, whatever the, the lead in is, it's separate. Um, yes, and I, and I typically, um, here's a, here's a tip for the audience. I typically, um, would separate those two documents. Um, yes, some, some vendors do'em together, and that's not necess, you know, that's, that's, that's not terrible. Um, but I typically would have two separate documents. So, um, you know, if a state or federal regulator, you know, for example, OCR order to request a copy of one, you're not necessarily obligated to give the other, um, the risk management plan, for example, may have, um, some phraseology in it, um, that, uh, would note non-compliance essentially with a, with a HIPAA standard. Um, and why, why include, that's that type of omission or statement in, in a, in a compliance artifact that you don't have to, um, so I typically do them separately, and of course you have to provide, um, you know, what is requested of you, but, um, the way that these OCR requests work is they'll request one and maybe not the other. And so you could just, um, obviously respond, um, to the request appropriately without providing more than what's been asked for. And the same thing with respect to, um, customers. Customers may sometimes ask for an organ organization security risk analysis, you've com. If you've combined that with your risk management plan, um, you're kind of stuck, um, providing, um, more information than has actually been, uh, requested. Um, another tip, um, is some of these other assessments that we're talking about, particularly what I've referred to as a compliance gap assessment that goes through the HIPAA security role. And, um, you know, identifies whether an organization is compliant or non-compliant, that is not necessarily an exercise that is required by the HIPAA security rule. Meaning the HIPAA security rule requires an organization to comply with its requirements, of course, but it doesn't require an organization to generate, um, you know, a menu of its compliance or non-compliance. Um, meaning to generate an artifact that could be requested, um, by, um, a government regulator, um, describing organization's compliance, non-compliance. Now an organization does have some compliance interest in doing such a line by line review of the security rule, right? Cause you know, that's, that's the way to determine whether you're compliant or not. Um, so we will often do those types of assessments, um, under privilege, um, in, um, anticipation of, um, uh, litigation or, um, just from a general compliance improvement posture because again, you know, the HIPAA security rule does not require that type of gap assessment, but it's still, um, still, you know, a good idea and a, and a helpful, helpful exercise.
Speaker 2:Very good. Very good. You've got some good tips. Back to the elements of the HIPAA security risk assessment or risk analysis. I think that something I often see is organizations will tell me I don't have a good inventory of my systems and I have no idea where all of my PHI is. It's just everywhere in our environment. So, um, can you help me find my phi? Right?
Speaker 3:Yeah.
Speaker 2:And one of the ways that we have done that, um, or that we help our customers do that is using a business impact analysis. Because when we start talking to the organizations about what their main processes, Cesar, we ask them, What systems do you use to carry out that process? And do those systems contain phi, pii, pci, You know, we collect what type of data, um, those systems use. So at the end of that engagement or that exercise, we actually are able to provide our customers with, um, a good inventory of their systems and their phi.
Speaker 3:That's great. And there's, there's, um, there's also, I would note a little bit of an art in that process of how you describe the, the systems that contain E phi. Cuz you have to, um, you have to be, um, narrow enough in how you categorize a type of asset to be able to hit on all the relevant threats and vulnerabilities of that asset. Um, but without being so granular that you're, you know, repeating yourself in a chart, you know, risk analysis chart that becomes thousands of pages long. So the art might be, you know, for this organization, maybe you can group analytically, um, uh, flash drives, um, and, uh, other writeable removable media. Um, and so because the, there are a lot of common threats to those, right? They, they're, they're small, um, they can be, um, uh, stolen. Um, so they're some common threats to those. So maybe it makes analytical sense to analyze them together as just a, you know, quote, uh, you know, uh, removable media type of asset. Um, so you've got, you know, the, the interest in getting granular, but not so granular that you're gonna have an unwielding or, um, excessively duplicative security risk analysis as you go through each, each of these assets. But your asset categories can't also be so broad that you lose those important nuances. You know, for example, you wouldn't just group, um, as I said, you know, uh, writeable media, um, or flash drives with, you know, um, uh, uh, portable devices, um, you know, cell phones, laptop, laptop computers, et cetera. You know, you may think that they're all small devices and they're both equally vulnerable to, to theft cuz you know, they can, they can all walk out the door quite easily. Um, but computer and a phone are different and that they have operating systems and have different, um, you know, uh, vulnerabilities with respect to, um, you know, executable heart, um, software and whatnot. Um, so you've gotta get your category small, um, so that they are useful, um, but not, and, and, and not so large that they are. Um, you know, you're not capturing, uh, nuances in the threats of vulnerabilities from across the different categories. And there's a little bit of, little bit of an art in there, I think, at least I've, I've, I've observed.
Speaker 2:Oh, I think so too. And it, it does make sense if, you know, if you manage all of your servers, for example, one way to have servers be a specific category and you do a risk analysis on that category, not necessarily on each and every server. Mm-hmm.<affirmative>. Right.
Speaker 3:Right.
Speaker 2:Um, I have another question for you because I, I do hear this often. Um, so if, uh, organization has the NIST CSF framework for their security program and they do an assessment against the NIST CSF and HIPAA has adopted nist, is that sufficient for HIPAA security risk analysis?
Speaker 3:I think, um, I think it probably is, although I would want to separate out, um, any other NIST aligned, um, analysis or assessment from just the bear components of the risk analysis piece. Um, just so again, if you're getting an OCR request or a customer request to see a copy of your risk analysis, you're not including, um, an assessment against any other, um, you know, NIST standard or, or NIST regime. So just at least make sure that it's separated out. Um, and I've, I've never seen, um, an OCR enforcement action against an organization that did a, a risk analysis that I thought was aligned to NIST, or in fact was aligned to nist. Um, cause it's, it's so substantially similar to the, to the OCR guidance that, um, I don't think there's much of any daylight between the two.
Speaker 2:Yeah, I think it's, um, so a tip just to be careful that it's not a gap assessment, that it is actually a risk analysis. I think, I think you're right. I I would agree with you.
Speaker 3:Yeah. Again, that's the biggest trap that I see is, uh, organizations will do a gap assessment, whether if it's against, um, the HIPAA security rule n or some other sort of, um, cyber security framework, um, rather than the actual, um, analysis of the threats and vulnerabilities to particular assets or, um, or categories of assets
Speaker 2:Mm-hmm.<affirmative> and also the likelihood and the impact,
Speaker 3:Right? Right,
Speaker 2:Right. You have those threats and vulnerabilities, but you have to also consider the likelihood and the impact. Yeah.
Speaker 3:Which, so it's a, it is a lawyer. I don't actually, I don't actually do the security risk analysis. You know, I may direct it, um, on behalf of a client under privilege, but I'm typically engaging, you know, a third party vendor. Right. Or coaching the client through doing it. I'm, I'm curious about how, um, you know, do you have a, a bank of, you must have a bank of threats, um, that you pull an update from on a, on a periodic basis. I'm, I'm curious how that process works for you.
Speaker 2:Yes. Um, that's a little bit of an art too because threats and vulnerabilities change pretty often. Right? Um, Clearwater uses a software product, it's called RM analysis, and within that software, we keep the threats and vulnerabilities populated, so we don't have to go back and, and think through that every single time. Um, depending on which types of assets you choose, the most likely threats and vulnerabilities are, are populated for you to work with. Um, now we update those on a regular basis just looking at the threat landscape. And, um, that's one of the benefits of being able to automate your risk analysis process because trying to keep all of those in a spreadsheet is, is very difficult. It doesn't scale well.
Speaker 3:It can be an unwielding process for organizations to, to undertake, um, themselves. And we, we try to coach them through it if they're, if they're doing it themselves. Um, but, uh, you know, these, these third party tools that can help you do it, um, maintain live sets of you information and update periodically. Um, those are, I think there's terrific benefit to those. Um, so yes, you know, we think about, um, you know, where do we, where do we mostly see these issues arise? Um, I do a lot of healthcare m and a. So as I said earlier, you know, I typically interact with security risk analysis, um, in the transaction due diligence context, although I do have, you know, ongoing clients that also, um, you know, do security risk analyses and, you know, seek input and, uh, legal insight on that. But most of what I see in terms of the volume security risk analy are in the context of a, of a transaction. As I said, a lot of those, a lot of those fall short. Um, when you're interacting with not the security risk analyses, you know, that, that you're doing, um, you know, on a, you know, yourself an ongoing basis, you know, what do you, what, what do you see out there, um, you know, in the marketplace from other vendors and what organizations are doing themselves and how are they falling short?
Speaker 2:I think the, um, the primary way that I see organizations and other vendors fall short is the fact that, um, they do an assessment and not an analysis. So it, it's back to that gap assessment. Um, or they might do, uh, a hybrid, but it doesn't cover the full scope Got it. Of what needs to be covered. Right? Yeah. Um, you know, you would think that a smaller organization, you know, like a physician's office, um, may fall short, but actually they can do a really good job because their scope is fairly narrow. They don't have as many, um, applications or assets. Yeah. It's like a, a hospital system. Yeah.
Speaker 3:Right. And OCR actually has on its website at risk analysis tool, um, which scales pretty well for a small organization, and it's yes, you know, pretty, pretty good inic of compliance, right? If OCR is investigating or auditing and you provide its own tool back to it, you know, that's a pretty good indic of compliance, but it doesn't really, really scale up very well for medium or large size organizations, at least I find in my practice.
Speaker 2:I would agree. Yeah, I would agree. Um, so Ryan, what, what do you see the risk are of failing to conduct, uh, HIPAA security risk analysis?
Speaker 3:Um, well, there are a lot of risks. That's, um, you know, the obvious risk would be, um, if you're subject to an OCR investigation or audit, um, you don't stand up. Well, um, there are potential for penalties or settlements, um, that are attached from that. Um, you know, the penalties or settlements OCR publishes on its website, um, a list of all of its settlement agreements with, uh, with organizations or, um, uh, civil monetary, uh, civil monetary penalties. Um, and what you'll see is that, um, there's very rarely, um, a penalty for just having not conducted a security risk analysis. Because if you haven't done one, you know, how does OCR necessarily know that unless they're engaged in the context of some other issue? For example, a large breach that you've reported, if you report a breach to ocr, um, and it, and it affects more than 500 individuals, that triggers, um, an automatic OCR investigation and for breaches, um, that relate to electronic protected health information, um, the ocr, um, information request that you'll receive almost universally ask for a copy of your HIPAA security rule risk analysis. Um, and so in the course of that investigation, OCR y are determined that you have or do not have a compliant, um, HIPAA security world risk analysis and, um, you know, may, um, assess penalties or seek settlements. Now, the, it's, it's not likely that, you know, the, the settlement will be, or the civil monetary penalty will relate to just, um, you know, failing to have a security world risk analysis. Um, it's typically one element among, you know, many deficiencies that OCR would identify and, um, you know, discuss in the settlement agreement or the, um, uh, civil monetary penalties, um, uh, press release. So it's, it's usually one element of many non-compliant elements, um, you know, within a OCR investigation that, you know, is most typically going to attach following a, um, a breach report or a patient complaint, although it's rarer that a patient would complain about security rule issues, patients typically complain, um, you know, about privacy rule issues. You know, for example, you know, my information was disclosed to, um, you know, a friend or neighbor without my consent, somebody snooped in my record. Those types of complaints are common. Um, or I didn't get access to a copy of my protected health information. But again, those types of complaints arise under the privacy rule. Um, security rule complaints and investigations typically come from, um, I find, uh, uh, breach reports. So since, um, you know, I took a look back at the, uh, you know, OCR website to see what the, uh, penalty numbers were like for, um, settlement agreements, uh, civil monetary penalties in the last couple years. So, and they, and they really run the gamut. Um, but again, um, failure to have a security risk analysis is just one element of non-compliance, um, typically cited. Um, and those, as I said, you know, they run the gamut. Um, there is, uh, a settlement agreement, um, with respect to a, uh, clinical lab, um, that was for$25,000. And again, one of the el alleged areas of noncompliance was security risk analysis all the way up to health insurer, um, where the settlement was five$1 million. Um, and again, one element of that was failure to have a security risk analysis. And so it runs the gamut and it's often lumped in with a bunch of other things. And so it's hard to know, you know, what the penalty is for just not having a security risk analysis. Um, as I said, there's, it's often one of many things. So that's, that's the obvious, you know, OCR investigation, potential OCR liability. They're also, um, uh, you know, risks with respect to business relationships your customers may request who have audit rights, um, for your compliance materials. And if you're not able to produce a compliance security risk analysis, that would be a reputational, perhaps even a contractual risk with your customers. Um, and then in a transaction context, um, you know, there would be due diligence, right, uh, by a buyer of a seller. And if you don't have a compliant risk analysis, that would be a noted deficiency, um, in a, you know, transaction due diligence context that, um, you know, may not, um, kill the deal, so to speak. Um, but there could be covenants to, to cure that not in compliance before or after closing. Or there could be, um, an indemnification construct whereby, you know, the sellers, um, you know, retain some liability for failure to have a security risk analysis, um, you know, for a certain period of time while a buyer can get one done. Um, so those, those are, those are just some of the risks of, uh, not having a compliant security risk analysis.
Speaker 2:So I think we've kind of laid out some tips and traps. Do you have any final words of wisdom?
Speaker 3:Um, I think I would just emphasize again that security risk analysis is a foundational requirement. Um, make sure, as we said, many times, don't conflate that requirement with, on, with some other, um, security aligned assessment. A security risk analysis is truly an asset by asset or asset category by asset category assessment of threats and vulnerabilities, um, related to that asset and coming up with, um, impact and, and risk risk ratings. Um, and again, um, there are a number of risks of, um, non-compliance, um, OCR investigations, penalties, reputational transactional risks.
Speaker 2:Great. Thank you so much, Ryan.
Speaker 3:Thank you very much.
Speaker 1:Thank you for listening. If you enjoyed this episode, be sure to subscribe to ALA speaking of Health Law wherever you get your podcasts. To learn more about ALA and the educational resources available to the health law community, visit American health law.org.