Confused about all the jargon and buzzwords in the cybersecurity world? Regulation, security, governance, compliance ... What's it all mean, really? Justin Beals, CEO and Co-Founder of Strike Graph, joins Sam Oberholtzer, Director of Sales Engineering to discuss these terms (plus, #videocast!)—what they mean, how they're connected, and the importance each provides when building a valuable cybersecurity posture for your company.

Please enjoy a transcription of the audio recording: 

Hi there, Sam. Welcome to another video blog. I think that's what we're calling I think we have some official marketing terms for whatever this is that we do once a week now.
I loved when you call the video cast, okay. Heard of that because I kept calling it up podcast, but it's not it's such a video cast, I love that
I can't tell if that's like a new term I've invented and I'm very young in nature, or that's an old MySpace, showing my age.
You know, it's kind of funny, because if we're talking about videocast, it's really like streaming right? Like, or just like your zoom, because everyone just says, oh, let's zoom. But technically, isn't that a video
is a video cast technically, and actually funny that you should mention technical terms. Today, we're going to try I think, to cut through some of my biggest complaint about, you know, this space is the jargon. I mean, it has been tough for me, as the Chief Technology Officer, in the past two deals with a lot of highly technical information. There's acronyms all over the place, there's weird names for the way we do stuff, none of it quite make sense. And I found, like the audit and security's face to be littered with the same types of problems. So I really appreciate you suggesting today that we cover some of these terms, some of these practices, so that we can kind of understand what they actually are, because I probably use them very poorly and interchangeably. make tons of mistakes. Yeah,
yeah, absolutely. I am so happy on this conversation. Because, you know, a lot of the times coming from the audit world, I would just, like hear people just use all these buzzwords that, you know, might not make the most sense, but everyone just like lets it slide or, or really, that they truly just like think it all means the same thing. And, and so just happy to have this conversation and kind of go through potentially some real life examples, or whatever can help our audience actually learn a little something.
So I'm assuming because of our title, that there's probably a difference between regulation, security, governance and compliance, right?
Yeah. And, and the reason why we start that, like, how we start with regulation is because it really is a hierarchy. And that's kind of the relationship between each one. Um, and so, you know, I'm just gonna, I'm just gonna go ahead and give like the definition so that it is easy to follow when we actually do this Congress. Yeah. Okay. So regulation, um, a lot of times people may think it's a law, or a certain guidance or standard, whatever you may call it, because that can use on terminology. But essentially, it's just a set of requirements that have to be met. And typically, there's consequences when they're not. And so that's, that's the easiest kind of to remember, if you kind of just associate with law, like that would be a nice little example of that. Governance is essentially the oversight or the structure of your processes within your organization, that kind of govern your objectives that fit a certain regulation, it doesn't have to be completely related to regulation, but a lot of the times in the audit world it does. And then security, of course, like we all that's, that's kind of, you know, our part, we're here to form your controls around your, your security measures. So it's really the protection of your assets and assets mean, intangible and tangible. So we're talking about your people and your systems and physical, physical, actual objects that meet those certain are sorry, that you implement. And so typically, Security does include controls because again, we associate controls risk you put, you put security in place to mitigate that risk, and it's typically through a control. And then so and then the last part is, is basically the the thing that comes after you kind of set all of these is compliance, and so compliance is in place to protect assets to meet that those regulatory requirements and sorry that that regulation or set of requirements, so you kind of see the hierarchy and how each would kind of be relevant or relate to each other.
Okay. So you know, it's interesting because I always thought of regulation as a law but you know, it's I love that the consequence concept rightly maybe it's hard to imagine regulation without As a consequence, and so I could see where we were, we think about certain standards as being revenue gatekeepers, you know, it's not like a country's regulation. But if I'm trying to sell my product into Airbnb or LinkedIn, let's say they have a regulation require a sock to audit before they can take on a vendor. Right? So that's a form of regulation, right? It just comes from a Yeah, sector, I might not perceive that way normally,
or in general, if we think about just vendors and customer relationship, you a lot of customers. And again, this kind of pertains around the trust assets that we help our customers achieve, but customers force vendors to, to prove that their set of requirements are being met. And then the consequence in that situation is no revenue, no partnership, no trust, right. Um, and, and so the consequence aspects is kind of important. Because if we think about it, that's, that's almost, um, why compliance is in place, like, why would you comply to regulation, or requirement, if, if there's no consequences, and you know, even the consequences could be a breach of data, it could be a hack, it could be a consequence that you don't have security, the enough controls in place to mitigate that risk. So definitely a full circle.
So then when we think about like, governance, like I have this regulation, and I'm not going to earn revenue, if I don't, you know, pass one of these critical audits, you know, government governance sounds a lot to me, like a product roadmap, right, like, so strategically to overcome these consequences from regulation. I'm going to achieve an audit in q2 of 2022, let's say, right?
So and let's actually, let's take that little example, that you had to around the roadmap. Yeah. So, um, this also is perfect, because this is kind of an extension off of our policy verse control, optimization, because you're got, so we have the standard, which is your regulation we that that person wants to achieve. And we have the governance, which is the policies, your almost blueprint, your set of potential that you want your processes to follow, then you have your security, which is the actual protection. So that's your processes, manual, automated, that's also your configurations within that, that that actually operationalize the policies that are governing those security controls. And then compliance is essentially your assessment, like making sure that there's no gaps, making sure that the security controls suffice. The governance and the governance suffices the regulation, yeah,
there's a symbiotic relationship between the control design and the types of governance that need to be put in place, and vice versa, right, like, absolutely times a governance need can drive you to write a set of controls, or a set of controls can be like, Hey, we don't have a good governance asset to distribute how these controls should be organized.
Yeah, yeah, absolutely. And it's kind of funny, because like the government aspect, I not only think immediately have, like the design and formal documentation by think about the appropriate people or department, because that will also help help exploit if there's any gaps in, in your processes that you're trying to form. So if somebody and that's kind of where the compliance aspect is, like, if there's no one actually monitoring that process, then your design is failing, and that your controls are actually failing part of the security aspect.
Well, this is my favorite pitch for guide them lately is that, you know, security, that habit of securities, it's if you leave it up to a robot or some automated process, you are leaving it up to failure without notice a lot of times. And so really, you know, both our solution and the way I think about it, it tries to ingrain in both how do we work technologically, taking advantage of automation that helps provide security but not making automation, the focal point of security all together, right? There's, to me as a technologist, there's a big difference between saying, hey, I want to, I want to make sure I have a good scope to my security practice, and then allowing that to bleed into and that scope is actually the execution as well. That's it. That's a problem because my my dev SEC ops team, my, my systems administrators, my CTO, they have to be engaged on some level scalable, but engaged, right like to really deliver on it. Well. So now we get to do a video cast first, which is reference our prior episode controls and policies. Yes. If you're a little curious about our discussion about controls and policies, you can look at the episode we, we published before this one.
Yeah, and let me let me ask you, so when you're thinking about these four words, do you think they can all act independently? Or like, what are your thoughts on my, like, um, on that statement?
Well, I definitely think that they they're interconnected in a way, right? And we probably, you know, I, in my ham fisted way, use a lot of product and technology development terms, to describe very similar things. Like, when you describe, you know, just like we were developing a product, you know, regulation to me is almost like a, like an opportunity, or what we would call an epic, which is a big story, like, oh, I want to be able, you know, if we were thinking very simply, an epic might be something like users should be able to be identified within the system. Now, there's a whole bunch of design governance, into how we put users in the system. And there's a lot of security, what's the login screen look like? What's the signup screen look like? And some of those, like we call them controls, you could call them a user story, like, the control is a simple statement about, you know, how we're governing, whereas similar user story is like, the user should be able to provide a username and password. And then compliance is quality assurance, all that stuff is symbiotic. Right? Like, you can't test effectively, if you don't understand the larger problem you were trying to solve, and how you discreetly decided to solve it. And so I, I love how you break it down and kind of this symbiosis, right, like, these things feed on each other. And, and if you now that you've separated the major concepts, you can kind of make sure you're paying attention to them in the right way.
Absolutely. And, um, you know, when, as I was like, looking through this, and just like thinking to myself, I'm like, it really would not. And this is why compliance is so important. And this is also why that, um, that we, there's so much stress, or I guess, so much focus on that, especially, you know, over the last couple years, it's that we have these regulations out there, we have, for the most part know a lot about security controls, but it's just like, how are we making sure that the security that the controls and the governance actually meet the regulation? It's like, what is the point of having a psi requirements if you're not actually assessing if anything is confined to that? And, and so that's why I think it's just so important that, um, it is becoming a bigger stress, especially the fact that, you know, there's more hackers, there's more and more breaches, or there's or there's, there's just a lot more consequences, as there's more technologies that are developed and just, I guess, more knowledge to
Yeah, you know, the other thing that this highlights for me is that a lot of people have tried to skip a couple of these, I think, right, like, let's go from regulation directly to compliance. And I think that while it seems like you're taking a shortcut, what actually happens is, is that you built an incredibly overburdened compliance problem, because you didn't take the time to scope down security and governance, just like if I were building a product, I wouldn't say, hey, yes, we want to be able to identify users in the system, ie we have a regulation, and it'd be like, oh, and let me know when I could just test it. Oh, I don't know what you're gonna build. I don't know how you're gonna build it. Or, or even, I'm not considering that you're building it on post it notes, which won't actually work. What I'm doing right now. Yeah, there's, there's, you know, to coin a common phrase, it's the underpants known problem of business, right? Like, it's, you can't like jump from here, all the way into here and claim profit. Yeah, without having done the security and the governance portion to get to be able to test it effectively.
Absolutely. It's like how do you go from regulation to compliance without even understanding anything, and that's why it's so important. To take the steps, the necessary steps and a lot of the steps is just kind of seeing your order. mutation as a whole, and seeing what actual processes are consistent or standard, and then kind of working from there, but then also keeping in mind regulation. And of course, a lot of regulations have similar base, foundational, you know, requirements. So that's, that's also what the most important thing is that just kind of start somewhere. Um, but I did want to just give like kind of a breakdown of an example. I know, I kind of did a little bit of a high level example, but something that might stick home especially, you know, since we, I guess, especially since a lot of people are alive, organizations within, like the health care, health tech environment are starting to realize that them as a SaaS provider that they need to be HIPAA compliant, I kind of thought it'd be a great time to give an example of like, what actually what, what is what in when we're thinking about, like the audit,
um, break it down for us, Sam? Okay, awesome.
Okay, so we're gonna start with the regulation, because we're thinking about the hierarchy of it. And so regulation would be the HIPAA, and I'm talking specifically about security role right now for business associates. And so what can they do to just start working towards that governance, governance is literally the organization's HIPAA policies. So starting to design those processes that fit that law that fit that regulation, and then next security. So what do they have in place to protect their assets to protect especially electronic health information, or Ph i. And so I broke that down even further for the safeguards. So the security aspect of it is, you're within a ministry of safeguard, let's just think of your access controls writing like password settings, your technical safeguards, is your encryption controls, like that's a good example. And yes, I'm just giving an example of VHS, we're gonna stay here for days. And then, and then organizational. So this is very policy heavy as well. But it's not just about policies. It's about the actual review the contract review, making sure that we have a control that sticks and not there's just the design. Yeah. And then And then lastly, what do we always think about afterwards is actually compliance, you can't just assume that you're HIPAA compliant, you need to actually make sure that you assess the implementation. So design implementation, and then also the actual operations of it. So operationally, effectiveness of your internal controls. And so typically, when I see like your organization's that just, you know, slap on HIPAA compliance on their websites, right, and then they actually did not do anything towards that. It's just kind of, I guess, almost surface level, or just like to, you know, put a sticker on and say that, but you actually should be documenting this. And if we're thinking about just like audit language, it should be like appropriate tests. So like, yeah, you know, inquiry, observation, inspection. And so, you know, with thinking about all of that, I think, you know, someone that is in this industry, or is our the industry or is confused, I think if you kind of break it down by those aspects, it could help them understand how each relate to each other and how they're definitely not interchangeable terms.
I mean, when you think about the compliance side is something like HIPAA, and we're in a little bit of a rabbit hole here. The thing that I find intriguing about it is there are some standards that have dictated a compliance or assessment methodology. It's part of the standard, HIPAA doesn't. And so you kind of like, I have worked with organizations or bought vendors that were like we're HIPAA compliant. And I'm like, oh, okay, great. What does that mean? And they're like, oh, we'll just send you a letter from our CEO stating that we're HIPAA compliant. But there's no true assessment or independent verification. And I think that I know, for our health tech customers, because it's really not, I mean, if you're doing all this good security work, why not make it a marketable asset? Right. And so we have teammates that are Certified Information Systems, auditor ers, and that gives us you know, I like to use the term assessment, I perform an assessment with from an independent Sisa against that particular standard, we can at least produce some verification of the practices, the design the control operation. Yeah,
absolutely. And to your point, our our product, actually is a system of record. So it's very important and I know we're getting down like a little bit to the nitty gritty of like, hid by itself, but, you know, you're supposed to keep all this evidence and make it just easy, accessible, that If a patient were to reach out or if you're covered entities, that you're providing the service to reaches out, you're able to produce that evidence pretty quickly. Right? And so even if it's not like formal documentation of saying, like, all these controls are in place, the law is in place, at least there's a system of record that, you know, where you're holding the evidence where it's housed. And that you and you can probably have a pretty good assessment right there without having that like, formal report. Right. But, but yeah, I because I, you know, to your point, I think, I think it's still a very gray area, and that's why I kind of use it as an example because I, I've seen it and i chi and you know, it, I'm curious, when companies do have that or when they assume HIPAA compliance, a lot of times, they'll see my firm their covered entity, and not think of themselves or their organization as appropriate for it. When that could be, you know, that cannot be more wrong. Yeah.
Well, these conversations are enlightening. As always, Sam, I super enjoy them. I know we have a three day weekend coming up. So yay, yeah. I hope you enjoy your MLK holiday and we're gonna actually get some sunshine here. The Pacific Northwest. I'm definitely getting outside finally.
Wow. Good for you. That is not the case here.
Thank you so much, Sam. Have a awesome day. And I'll see you next week when will chew up another 20 minutes? Yeah,
absolutely. Always a pleasure. It's always a great conversation from two sides. Good. Okay. Bye bye.