Compliance Unfiltered is TCT’s tell-it-like-it is podcast, dedicated to making compliance suck less. It’s a fresh, raw, uncut alternative for anyone who needs honest, reliable, compliance expertise with a sprinkling of personality.
Show Notes: Why Would One Use PCI as a Framework to Comply with HIPAA?
Quick Take
On this episode of Compliance Unfiltered, Adam’s multiple decades of experience are on full display as the CU guys cover how to utilize one of the most prescriptive certifications out there (PCI) and use it to accomplish compliance against one of the least prescriptive certifications, HIPAA.
Curious how they align? Wondering how much of the duplicate work can actually be avoided? Is Cert-Mapping something that can work for your team?
If any of these questions piqued your interest, then this episode of Compliance Unfiltered is for you!
Read Transcript
So let’s face it, managing compliance sucks. It’s complicated, it’s so hard to keep organized, and it requires a ton of expertise in order to survive the entire process. Welcome to Compliance Unfiltered, a podcast dedicated to making compliance suck less.
Now, here’s your host, Todd Coshow, with Adam Goslin.
Well, welcome in to another edition of Compliance Unfiltered. I’m Todd Coshow, alongside the gravy to your grandma’s compliance spaghetti Bolognese. Mr. Adam Goslin, how the heck are you, sir? Man, I can’t complain. I certainly cannot. Today, we’re going to talk about something that’s a little maybe out of the ordinary for folks when you look at it on the surface, but as you dig a little deeper, it makes a ton of sense.
And that is, why would one use PCI as a framework to comply with HIPAA? So to start, let’s talk about what’s PCI? Well, PCI is the payment card industry data security standard. It’s often short form to just PCI. It is a standard that’s used in the payment space for all of the various players in the payment spectrum, if you will. There’s all the folks that are subject to compliance with effectively the credit card standards that need to be compliant, and prove out their compliance, etc. So there’s actually a number of different standards under the entire framework, but the most common ones that are used are our self-assessment questionnaires as well as reports on compliance ,it just kind of depends on how big of an organization is, that’s going to kind of go through the process. The PCI DSS, boy it’s been around for a long time, and it’s a very prescriptive standard. It’s got a lot of detail in there about you know various sections targeted use per se, those various sections cover a wide range or a myriad you know of different arenas and they’re focused into group, so you know as I go through the overall certification, the latest version of the PCI DSS they’ve reached up to PCI v4. So when I started, I actually started working in the space before PCI even existed, and then, I’ve been able to see the kind of progression from PCI version 1 you know 1, 2, 3, and now we’re at PCI version 4. Effectively the standard is broken up into various realms of focus. There’s 12 different requirements focused on installation and maintaining of network security controls, as well as secure configurations for system components protection of stored card data, or account data protection of the cardholder data when it’s being transmitted, protection of the systems from malicious software developing and maintaining secure systems and software, as well as restriction of access to people that need to know identification of users and authentication when it comes to you know accessing various systems, physical security logging and monitoring security of both the systems and the networking, and then just a you know the last section is overall supporting information security with organizational policies and programs so that has a wide variety of afflictions. It’s a very, very, prescriptive standard in the grand scheme of things you know, which makes it have some certain advantages shall we say well.
You’ve mentioned in the past that HIPAA by contrast is a much less prescriptive cert. Tell us more. So yeah. HIPAA was initially put out to provide a framework for those that were in the medical space it is you know, it’s a law that you know organizations in the medical space have to adhere to, and it’s very directional. HIPAA was originally designed for gosh everybody from the single practitioner all the way up to health care systems. So, kind of the applicability of the control sets for HIPAA were thereby made a lot more directional in terms of their statement, and implementation. Directional certifications, let me let me slow it down a little bit. To give this a measure of perspective, when you have a directional cert, it’s giving you a general direction that you need to go ahead and adhere to. Where the prescriptive cert is going to say, okay, this is your objective and here’s the whatever, 48 things that you’re gonna go do to ensure this particular thing. And so, a directional cert, it leaves a lot of room that’s open for variability of approach, for implementation, which allows the facilitation for the single practitioner, up to the healthcare system. But it’s a double-edged sword in the grand scheme of things. Are you, because of the way that you’ve chosen to approach the objective, are you meeting that objective appropriately? Are various third parties going to be accepting of your approach? What level of risk do you have for your organization? What level of risk do you have, having somebody perceive your approach as substandard? Maybe you’ve got a consulting firm or something in place that’s doing some oversight, might work for all you guys, but then you go have a meeting with a big client and they’re questioning how you approach the resolution of a particular element and feeling like you didn’t meet muster.
So, a lot of the standards and certs, they’ll range in their prescriptive nature. PCI is kind of on the very prescriptive and HIPAA is on the very directional end. And the other ones generally fall in between those two. And as a result, PCI as a prescriptive standard, it’s a good idea to leverage, because you end up with having clean mappings to those less prescriptive standards in the space. It means that you’re leveraging kind of common industry standard approaches for controls to meet the objectives or criteria. And so it makes it a lot cleaner when you’re starting to then map against those less prescriptive standards.
So, it’s safe to say you’ve been in this space for a couple of decades. What did you decide to do when it came to TCT? Well, I mean, for TCT, we have very little in the way of actual kind of card exposure, certainly not as part of our main line organization, but we do have a ton of sensitive data on our system. Certainly, personally identifiable information, but, you know, kind of client sensitive data as well, just because of the nature of the information that we have on our system. So, when we decided to head down our approach for how can we assure that we’re managing and maintaining with a high level of rigor, given the expectations of the client base of TCT. You know, we decided to leverage PCI, You’re going to see in the PCI standard, all sorts of different references to, you know, card data or card holder environment and things along those lines. There’s a few specifics, specifically for PCI, but generally speaking, 99% of the, you know, of the various requirements of PCI DSS, they aren’t specific to the credit card industry. And so, what I did is I took an approach of leveraging PCI DSS, but instead of using card data, or card holder environment, I just switched it to sensitive data, and our production environment, if you will, and then applied the same controls across our organization. And that way, I knew that we had a series of very prescriptive controls in place for the protection of the sensitive data of the environment, which allowed us to be able to really present a strong stance from a security perspective, to the target organizations. A lot of the folks that we interact with in some way, shape, or form are typically heavily involved in the PCI space. How’s that been received? Thank you. Thank you. It’s been received very, very well. You know, the nice part about doing it this way is because the standard is so prescriptive, it actually eliminates a lot of questions that folks would have about, well, how did you do this, and how did you do that? I really want to understand more, etc. A lot of those types of questions naturally go away because they know precisely what you did, precisely what you implemented. They know the control set that you’re leveraging. So it eliminates a lot of ambiguity as you’re having those discussions. I mean, TCT as an organization, you know, we have been vetted by dozens of different audit assessment firms, that do this for a living and pass with flying colors.
I like it. I like it. Now, what types of things does the approach of PCI as a framework not cover when compared to other standards? We get a lot of people talking about your SOC 2s and things along those lines. Where does PCI fit in, and what does it cover, what doesn’t it? Well, it’s an interesting standard from this perspective. Keep in mind the backdrop of, well, what was the objective of PCI? Well, the objective of PCI was to dramatically increase the security and protections of the, receipt, storage, processing and transmission of credit card data. And, as a result, more generically termed account data. When you go and you look at something like an ISO or a SOC, you know, style standard, those standards, there are a couple of areas generally speaking where PCI doesn’t focus as much on. The interesting part about it is that I guess, the way that I put it to people, PCI doesn’t care as much about whether you can actually put your business back together after some type of a holy moly event, as they’re just making sure that the data and information that’s there is securely stored. So, that said, there are certainly some elements, like physical equipment maintenance. You go back in the day, I’d say back in the day because you know in the good old days, everybody had either their own server rooms, or they had a cage or a colo space, etc. And more recently with that moving into the cloud, the physical equipment maintenance is often, left off to the side. But that said, it’s often readily attributed to your vendors, especially with those kind of cloud-based systems, but PCI doesn’t care as much about whether the physical equipment maintenance is done. So, to whatever, testing your generators and, doing redundancy testing, things along those lines, that’s something that’s typically left off to the side. Backups, you know, there’s some minor coverage in PCI for backups, basically, hey, if you’re going to go put the sensitive data off onto your backups, make sure it’s encrypted. That’s where it ends. It doesn’t make sure that you’ve backed up all the things you should have backed up, your backup approach provides an appropriate amount of redundancy and risk aversion for the target organization. So, do I have how many days, weeks, months, how many quarters, and how many years backups? That type of thing. They don’t care as much about that. The third arena that kind of comes into play is disaster recovery. Really, the ability to recover from a number of different, you know, disaster scenarios, again, PCI is less concerned about that where in ISO and SOC. You’ll see a much stronger stance, you know, with these three different arenas.
So with those missing elements, what can an organization heading down this path plan to do? Well, you know, what I would say is, go ahead and get plans in place to get these items addressed. The concerns, that your prospects may have in terms of how you address these things that are sitting left off to the side. When it comes to TCT, we actually focus specifically on addressing each of those areas, the physical equipment maintenance side, our backup strategy and approach, as well as our disaster recovery, so that we provided the coverage for those areas of the certifications that would otherwise kind of be missing. It ended up being a good approach to do it that way. We literally have put together documentation around each of those areas describing generically how we’ve gotten those addressed, what are the types of controls that we have in place, you know, etc. That way, I can allay the concerns and the fears. There’s a lot of organizations where they will go in and I don’t know, I almost call it like the zombie walk, right? We always ask everybody for a SOC 2, you know, type of a thing. And that’s just what we do, you know, it, okay, that’s cool, I get it. But, you know for TCT, when we’re having those discussions, when they can see the prescriptive nature of PCI DSS, when taken in a context of sensitive data, as well as the fact that we’ve covered, you know, all of those edge cases, but all of the types of controls that would otherwise be prevalent in an ISO or a SOC. We’ve been very successful with having those discussions, having those dialogues. It’s funny when you’re on the phone and you’re talking to somebody and the folks, that are listening to the pod, that have been in the space for a minute or three, they’re all chuckling because, you know, you can tell instantly when you get on the phone with somebody,
if they know what they’re doing, if they know what they’re talking about, man, it just shines through the the phone, through the computer, whatever you happen to be talking through. You can just really tell the difference between somebody that’s been here, done that, knows their stuff and has it together. Where it becomes readily apparent, the opposite becomes readily apparent as well. So, you know, being able to walk into those conversations, having both your documentation for PCI accessible, as well as being able to have, the other supplementary elements documented, and in place and ready for their consumption, becomes a really effective approach for organizations that have to go down that path, you know. So, it’s just a really cool way to go about doing it.
Indeed, indeed. Parting shots and thoughts for the folks this week, Adam. Well, with a very prescriptive standard, you know, like PCI, it carries a lot of advantages when you’re mapping to those less prescriptive standards, especially when the focal point of this discussion was HIPAA, especially when you’re talking about those, kind of more directional standards. The cool part about doing a PCI mapping, down over top of a HIPAA, you’ve got a lot of advantages where, you’re just going going down that path, you’ve got, when you take a PCI and do an overlay, what you end up with is, you end up with the vast majority of the administrative, technical, physical safeguards, and end up being capable of being entirely covered through the use of a prescriptive standard like PCI. Now, don’t get me wrong, there’s going to be some specifics for HIPAA. As an example, your business associate agreement, well, that’s not going to get covered anywhere under PCI, quote unquote. So when you’re doing this approach, the net result is a couple of different things. One is you have an easy motor mechanism for the mapping to those secondary standards. When you go in and you approach your annual engagement, you can basically say which of the items am I going to end up having covered through my prescriptive standard against HIPAA, and which are the items that are going to sit off to the side that I need to address separately, like the business associate agreement. That way, you can kind of depend on the inheritance from the prescriptive standard, and perform the activities and actions you need to against HIPAA. But one of the best parts, you know, kind of going back to a conversation we were having earlier, which was, you know, around the, am I sure I’m going to have this objective criteria covered in a way that’s going to be acceptable for everybody? Well, when you take a strong prescriptive standard, like PCI, I can map that out against SOC, I can map that out against ISO, I can certainly map that out against HIPAA. Because of the fact, that these are strong control that you’re now leveraging, to push down to either a criteria-based standard, or a directional standard like HIPAA. It just gives you a really, really clean way to be able to walk in with a high measure of assurance that you’re not gonna have objections, you’re not gonna have people saying, but what about this, or whatever it may be. You’re just answering a lot fewer questions on the one side. And the other, which is probably more important, you are taking active steps to proactively protect your organization. When you’ve got companies that have several standards to meet, such as an ISO and a SOC and a HIPAA, etc, there’s some huge benefits to being able to get those kind of clean mappings from the prescriptive standard. You also have a different thing that you could do, which is, if it’s just PCI and HIPAA, maybe you don’t need to go down this path, but if your organization needs to go up against PCI and ISO and SOC and HIPAA, then now you’ve got a new opportunity, that new opportunity is, you know, instead of having the complexity of dealing with these four different standards separately, managing and mapping and blah. If you’re leveraging the TCT Portal, you now have an added capability. Now, keep in mind, the TCT Portal, yes, has mappings between these standards, but if you’re doing like four, then in all likelihood, your assessment firm is going to have some type of a request list style approach. Instead of facing you with a thousand items for this standard, and 500 for this standard, etc, they’ll typically boil it down to go get me these, just making a number up, 328 things. When you go get these 328 things, now we’ll have all of the compendium of evidence that we need to be able to meet all of your target standards. Well, we can take that kind of request list approach, and load that up and into the TCT Portal, we can then map that down to all the secondary standards. So you can go in, and look at your request list, your consultants or assessors can be looking at the target resultant standards with all of the mapped evidence, inheritance, etc.
So, it really, really ends up working out really, really well. As I like to say, you know, TCT was formed to help make managing compliance suck less and we do take that very seriously.
And that right there, that’s the good stuff. Well, that’s all the time we have for this episode of Compliance Unfiltered. I’m Todd Coshow. And I’m Adam Goslin. Hope we helped to get you fired up to make your compliance suck less.
