Why Your Security Risk Analysis is Probably Wrong
Find out the dangerous difference between a gap analysis and a true Security Risk Analysis (SRA).
Find out the dangerous difference between a gap analysis and a true Security Risk Analysis (SRA).
Are you assuming your IT provider has your cybersecurity handled? Does your website proudly claim you are "HIPAA Compliant"? In Part 1 of our conversation with Donna Grindle, CEO of Kardon and co-host of the Help Me With HIPAA podcast, we are delivering a massive reality check to small business owners.
We break down the dangerous difference between a gap analysis and a true Security Risk Analysis (SRA), why developers and compliance officers speak completely different languages, and how to use the "CREMATE" method to finally figure out where your sensitive data actually lives.
"If you put on your website that you're HIPAA compliant, immediately I'm concerned... Even the Office for Civil Rights in charge of enforcing it will not tell you that. There is no designation that they recognize." — Donna Grindle
Key Concepts:
SRA (Security Risk Analysis) -The foundational step of a compliance program. A true SRA must evaluate likelihood, impact, risk, and strategy.
Gap Analysis - Often mistakenly called an SRA. It simply identifies what is missing, but does not calculate the actual risks or strategies to mitigate them.
CREMATE -A practical data-mapping framework for small businesses to track PHI. It stands for: Create, Receive, Maintain, and Transmit.
Business Associate (BA) -A third-party vendor. The reality check: If you are doing something unauthorized on the network and it would be considered a cyberattack/data breach, you are a Business Associate.
HICP 405(d) - Health Industry Cybersecurity Practices. A framework with specific technical guides designed to get everyone (small, medium, and large entities) speaking the same security language.
Links:
Kardon: https://kardonhq.com/
Help Me With HIPAA Podcast: https://helpmewithhipaa.com/
HHS Website: https://www.hhs.gov/about/agencies/asa/ocio/cybersecurity/security-awareness-training/index.html
HICP 405(d) Guidelines: https://405d.hhs.gov/
00:00 – Why a "HIPAA Compliant" Badge is a Red Flag
01:26 – Understanding HIPAA Covered Entities & Obligations
02:14 – The Difference Between Awareness Training and Security
03:18 – Why Your SRA Might Just Be a Gap Analysis
04:40 – Building an Inventory: You Can’t Protect What You Don’t Find
06:22 – Using the "CREMATE" Method for Data Mapping
08:21 – Why IT Cannot Be the "Department of No"
09:40 – Standardizing Communication with the HICP 405(d) Framework
10:41 – How to Document Your Policies (and Use AI to Help)
12:39 – The Easy Way to Tell if a Partner is a Business Associate
13:50 – Business Associate Red Flags
Donna Grindle: If you've put on your website that you're HIPAA compliant—immediately, I'm concerned.
Jen Stone: Yes! Exactly.
Jen Stone: Hello, and welcome back to Practical Cybersecurity. We are very excited today to have Donna Grindle on with us. Some of you have met her before; some of you have not. Please give us a little background on who you are and what you do.
Donna Grindle: Well, I am the co-host of the Help Me With HIPAA podcast, but the way I actually make a living is my company, Kardon. I am the “Don” of Kardon. And we’re a lean, mean fighting machine, but we're there to help those small and medium businesses. And it's not only healthcare. Now we're getting more and more coming to us because they have to have a written, prove-they're-paying-attention-to-cybersecurity program—whether it's an accounting firm or even some small businesses that just want to get cyber coverage because of what they do. You can't get it anymore unless you're willing to prove that you're taking it seriously.
Jen Stone: At what point does a small business need to start worrying about HIPAA? Like, what triggers that obligation?
Donna Grindle: The easiest definition is you provide some sort of healthcare delivery, and it also applies to insurance companies. We're not talking about them because those are usually not a small business. So, a healthcare delivery organization that files electronic claims for payment of services.
Jen Stone: That's it in a nutshell. And so if people are listening, you're saying, "Oh, that's me." Maybe we should pay attention to it, but it doesn't even matter how small you are, right? But I know for sure that there are challenges that small organizations face with it. But the larger—like you just said, we're not worried about the larger organizations. They have the staff. But when you work with these smaller organizations, what are some specific challenges that you see them dealing with?
Donna Grindle: Across the board, it's actually understanding what HIPAA means. It's been around so long, everybody assumes they understand it because they've sat through so many training classes. And the problem is those only apply if you're the one doing other work and you're supposed to follow HIPAA. The other staff—the people in charge of building and managing the programs and being able to prove that you're doing it—that’s not included in the standard HIPAA training. Not at all.
So still to this day, when we say, "What training has your Security Officer/Privacy Officer/Compliance Officer had?" the number of times we get, "Well, they read the Security 101 on theHHS]] site"
Jen Stone: Yeah, that's just not the same thing as building a program. So, from that perspective, what do you see as the most common gaps in HIPAA programs?
Donna Grindle: Security Risk Anaylsis (SRA). An enforcement initiative started a while back, but it's the number one thing everybody does wrong. And if you do that wrong, your entire cybersecurity program that's supposed to do the security stuff is wrong. It's all wrong because all of it should be based on that.
Jen Stone: Right. That's actually what the regulation says: do this risk analysis and then build your program. And we don't see that.
Donna Grindle: I read things and it's like, "Well, we did an SRA. But our risk analysis doesn't include likelihood, impact, risk, or strategy”. And I'm like, then it's by definition not a risk analysis. More than likely it's what's called a gap analysis. And that's the number one gap—is a gap analysis is all they have.
Jen Stone: So if we're talking about the compliance strategy, it starts with having a program of some kind. And it starts with having a risk analysis of some kind. But if you were to tell a small business, "This is where you start," what's that starting place feel like for most of them?
Donna Grindle: Believe it or not, I tell them: you need to know everything you have. That's it. Just figure out everything you have. So here's your inventory for computer systems. Okay? Here's your inventory for network infrastructure. And we had to separate them because we used to try to get them on the same one, and all we would get were the computer systems.
Jen Stone: Yeah, because a lot of times they have that and they completely disregard everything else in the environment.
Donna Grindle:. They just think of the computer systems. But you have to know what software is on all the systems. And now you also have to know what cloud applications—SaaS, IaaS, whatever you're using. You need to be keeping up with them as well, because you're putting PHI in them. And people are like, "What do you mean? Those are just handled because..."
That doesn't... there's this idea that if we hire an IT company, then cybersecurity is handled. And if we use a cloud application, then that security is handled. And that's not the case.
In a big organization, they all have a data map. It's a thing. You have a data map. And that is just impossible to do—a real one of those—in a small environment. I've tried, and I am not going to torture people any more than I have to. So, instead, you ask people: where do they use things? So we created Cremate—create, receive, maintain, transmit.
And we're like, sit down and tell me everywhere you Create PHI. What are you using to create it? Is it a scan? Where's it coming from? Then Receive—if you're receiving it from other offices, from hospitals or whatnot. Where do you Maintain it? Meaning what do you do with it when you get it? And who do you Transmit it to and how do you do it? Because if you do that, then you make sure that you put everything on the list right. Putting everything on the list, makes sure that you consider all the things that could go wrong and how you're going to deal with them. And that's an SRA.
Jen Stone: But you know what's really crazy is that a lot of groups know one piece of that, but not other pieces of it. Like you said, IT knows the IT piece, but they don't know how the information gets in. They do "maintain" maybe, but they don't know how it gets in there.
Donna Grindle: And that's the other thing—”IT does an SRA”. Then it’s not an SRA. It’s a part of one. I'll take what they've done and incorporate it into a big one. But that is a piece of one area that we often get a "deer in the headlights" look: what are the security settings in your EHR? And how do you have it configured?
Jen Stone: Yeah, that is part of it.
Donna Grindle: And IT says, "We never touched that."
Jen Stone: And it's really hard sometimes getting your internal IT team or maybe a third party to talk to the people who are doing the processes that intake the information in the first place. They have different focuses and they talk in different ways.
Donna Grindle: IT cannot be the "Department of No" anymore. That's why people do things that you don't want them to do—because you're not saying, "You need to do this; how can I give you the ability to do it securely?". If there's no understanding, then communication didn't happen. I have had to work on it, and it's still really hard because I can hear names come out that I don't know.
Jen Stone: You don't even know that you're speaking a different language or that what you're asking is unreasonable because you don't know enough about how they work.
Just a couple weeks ago, I was talking to a customer about password length. And they said to me, "Including the developers?". And I said, "Yeah, this includes the developers". They said, "Are you sure?". So I said, "Look, I understand if any group is going to yell at me, it's going to be the developers, but it's because I don't speak their language clearly enough".
In any situation, you can think that you're doing the best job possible, but if you don't know the specific language that the other group is using, you have to be aware of it.
Donna Grindle: That's why we have things like these frameworks. If everybody learns that, then we have the same language around it and we all know what it means. I'm on the HSCC Cybersecurity Working Group and been part of the 405(d) where we wrote HICP. It has a general guide to get everybody on the same page. Then there's a technical guide for small entities, and a technical guide for medium and large. I worked on the small entity one. You would not believe the disagreements that everybody would have trying to figure out how to say something in a way everybody w ould understand it.
Jen Stone: What would you say is maybe a good place to start for the "must-haves" for a limited budget? Some security controls that absolutely have to be there?.
Donna Grindle: Well, actually, I would start before that. You need to have a policy and procedure about policies, procedures, and documentation. If you just start implementing things, but you don't have a plan for who's managing it, who's making sure it's actually working as intended, and who has these responsibilities—how am I going to prove that five years from now that we were com. If I don't have a plan for all of that, I really haven't gained anything but the control.
Jen Stone: And nobody likes to do documentation. But it's critical to laying that groundwork.
Donna Grindle: AI gives you a tool because you should be treating it like a really smart but not infallible assistant. In that documentation world. It’s great because I can give it bullets and it'll write it up, and then you just have to be sure to read it. You can tell it to make changes, but you need to treat it like it's an employee doing it. You're making the decisions. All you have to do is write them down or dictate them. If you don't have that plan to document it, it doesn't matter how much money you spend; you're going to end up wasting it.
Jen Stone: And then this gets into vendor management and BAAs. How do we leverage that to make sure everything's being done that we think is being done?
Donna Grindle: That's a huge piece. It's also that area of people realizing they're actually Business Associates. If you provide a service that requires you to potentially have access... "Oh, we don't ever look at the EHR or PHI ". Yes, but you're in charge of the entire network and can break into it and do whatever you want. The line there is: if you were doing this and not authorized to do it, would it be considered a cyberattack and a data breach?. Then you're a Business Associate. You're outsourcing the liability somewhat, but not the responsibility.
Jen Stone: So when we're talking about third parties, what are some red flags that you have seen with organizations where maybe they're not the right fit in a healthcare setting?.
Donna Grindle: If you put on your website that you're HIPAA compliant, immediately I'm concerned.
Jen Stone: Exactly. Because according to whom?.
Donna Grindle: Who decided that?. And by the way, even the OCR in charge of enforcing it will not tell you that. They won't give you that designation, and there is no designation that they recognize.
Jen Stone: That's a nice segue into this topic, which is: I don't want to scare people, but man, maybe I do. What happens when things go wrong? What happens when you have a breach and have to report it to OCR?.
.svg)