Name: Compliance Isn’t a Checklist, It’s a System
Uploaded: 2026-04-01T20:16:06.940Z
Duration: 52 min 40 s
Description: Compliance Isn’t a Checklist, It’s a System

Transcript for "Compliance Isn’t a Checklist, It’s a System": Alright. Howdy, folks. I am so glad you're here. We're gonna give it one quick minute, while people keep funneling in, but we're happy you're here. We'd love to hear any shout outs in the chat if you've got questions already or if you wanna share where you're calling in from or just kinda shoot shoot the stuff with us. We're we're here. So one more one more quick second, then we'll we'll get into it. Alright. Welcome, everyone. Thanks so much for joining us. Today's conversation centers on a simple but super important idea, and it's that compliance is not a checklist. It's a system. In many organizations, compliance starts with good intentions. I mean, a typical flow that we tend to talk with folks through looks something like a customer asking for a SOC two report. A regulator comes in and, like, introduces new requirements to the shop. The security team and the IT team respond to that somehow. Controls get documented. Evidence gets gathered. An audit hopefully gets passed, and then maybe that cycle repeats. But the companies that scale successfully, we found time and again, tend to build resiliency over time, and they typically approach things very differently than just kind of a one and done situation. So they design it as part of how the operation, how you how their organization actually operates, and it's not like a recurring project. So that is what we're unpacking today. I'm joined by Cain McGladry, who brings extensive experience in governance and cybersecurity strategy, and my fantastic colleague, James Sorenci, who works closely with teams implementing and scaling compliance programs, in real environments of all sorts. So, Cain, you wanna give us a quick intro? Yeah. Thanks for having me on today. Super excited for today's conversation. I am a a two time CISO. First time was in the defense industrial base, doing manufacturing. Second time was at a a GRC startup, actually. I'm also a senior member of the IEEE, and I have my first book coming out being published by CRC Press from Taylor and Francis in October, I believe, of 2026. They we're finalizing dates, but it's about the myth of cyber risk and what to That's do about that's October sounds far away, but we all know how quick that'll happen. So exciting. Yep. James, what about you? I do not have a book coming out, but I'm excited for yours. I'm the strategy and community lead here at Rippling IT, working closely with customers and the broader IT community. Before that, I spent a number of years helping organizations implement and run their technology and, of course, compliance. And there's a pretty consistent pattern. Getting through an audit is one thing. Making it work day to day is where things get harder. Carter? Awesome. No. That's perfect. Thanks for joining, gentlemen. Well, let's talk about, like, the checklist trap. Kane, I I think we'll start with you for sure. When when you hear an organization describe compliance as, like, a check the box type of exercise, what does that signal to you? Lack of maturity? Think more than anything else, I think it's a lack of understanding associated with the value of compliance more than more than anything else. You spend a lot of time working with boards and executive teams. What's the biggest misconception leadership tends to have about something like SOC two? Oh, boy. There are so many. I think the and you you might say this is pedantic or semantic, but I think the first one is SOC two is a certification. It's not. It it it's a certification. It's, it sorry. It's not a certification. AICPA doesn't issue certificates. Right? It's an attestation. It's a report. It's not a certification. People get hung up on this. I think I verbally got hung up on that myself. Right? It also it doesn't have like it's not pass fail. It's not like you did it or you didn't do it. Its auditors give you an opinion, and those are those could be unqualified. They could be qualified. They could be averse. I think there's also this magical thinking that, like, SOC two is security. Right? It doesn't say you're not gonna get breached. Like, having one document from one little guy from the AICPA doesn't say you've got perfect security. Or there's the thought that it's like a a one and done. This is an annual cycle. It has to be continuously monitored. Or the idea I've heard some people ban to this about this as legal requirement. This is voluntary. Like, you could see it contractually from a, I don't know, business partner, from a customer. They might have it as a contractual clause, but this is way different than something like HIPAA or GDPR or SOCs. And my final one, people say, well, I got a SOC, SOC two, and then it's a type one. Not type two. Right? Okay. Cool. So type one is a is it's a snapshot of some point in time you proved you had writing on a piece of paper. That's neat. But that is not what people want. Enterprise customers, they increasingly don't want a type one. They wanna type two. And then they think, well, this is only for a tech company. Any service organization. That could be like health care, could be finance, could be professional services, could be a managed service provider to to really have some principles based, non prescriptive set of controls that are gonna meet some criteria. And the last one finally is like the idea that there's just this SOC two in a box or that there's this magical, like, universal SOC two checklist. There is no such thing. Right? This is a six to twelve month observation period. Right? It's not a one and done. There's no definition, and you can't go create your evidence retroactively to say, oh, yeah. We totally have that. Uh-uh. No. You you cannot do that. I think one of the things you just said is worth kind of going back to is like that there is a meaningful difference between like passing an audit and actually being secure. You want to, like, pinpoint on that for just a sec? Yeah. Yeah. No. It's it's definitely not the same. Compliance is not security. SOC two does not guarantee you won't have a data breach. It doesn't guarantee you won't have any vulnerabilities. It doesn't even guarantee that your controls are gonna work against new or novel attack vectors, like your your future security posture. That's not contemplated as part of SOC two type two. And the other thing is like your third party vendors, they could be totally insecure. That's not in scope. Right? It's, it's a, it's a point in time. It's a limited period of time. And if you think about that from a security perspective, if you read the news, stuff happens every day. That's gonna happen during your audit period. It's gonna happen Mhmm. After your audit period. You're gonna get new vulnerabilities. You're gonna get new exploits. Of course, those are covered in there. And the other thing is like, if you have manual human operated controls, like where controls again, people, processes, then technology, that's usually how I look at it. If you have manual human operated controls and you have staff turnover or better yet, you decide, well, we we don't need those staff. We're just gonna have an AI agent do that. Right? That'll be fun. That can also weaken your control strength between audits because you get control drift. Like, there's a I could go on, but I think the last thing I'll I'll say on this one is that there's the design of how your controls are operated, and then there's the actual reality. Like, I've seen a lot of instances where there's a paper tiger is what I'll call it. Like, there's a policy that exists, but it's not followed consistently. Right? You could have your controls be be written down. They could be documented, but they could be poorly implemented and your staff or your AI agents might just go ahead and skip it anyway. Right? That that is inherently problems associated with SOC two and saying that it's security. It's not security. It is a very nice piece of paper, but it's just a qualified opinion from an auditor. It's not a proof of security. That's some perfect starting points for us. I know we're gonna come back to Drift in particular. But James, I know you're chomping at the bit to get on in on this. An operational from an operational perspective, what do you think, like, audit season looks like in companies that tree compliance cyclical rather than continuous then? Well, first of all, audit season is gonna start with a link to this webinar because that intro was fantastic. I had had to explain so many of those bits before I even got to the need of it with so many different orgs and have this space to see and fun. So thank you. I will be bookmarking this. But audit season, usually, it feels like a scramble. Teams are pulling screenshots, exporting logs, trying to reconstruct what happened over the last few months and make that pinpoint time be shown somewhere. And a lot of that work isn't hard. It's just scattered. So the challenge is that the system wasn't designed to produce that evidence continuously, and you end up rebuilding the story after the fact every time that cycle comes around. And the control drift that was important also because you'll do it the same time every time that cycle comes around. Yep. I think that is a good point to make for sure. Well, where do you where do you see, like, programs begin to struggle after the first year, James? Is is is there a commonality there? I mean, definitely. Well, year one year one like I say, it's easy. It's not easy, but year one is very goal oriented. You're trying to pass, gain that nonexistent certificate at first year. Right? So year two is their reality, like, set in. Controls exist, but not always connected to how people actually do their work, so you start to see that drift. Access reviews, they get delayed. Off boarding isn't as tight as it should be, and evidence collection becomes inconsistent. So it's not that teams don't care. I know they care. It's not the system requires constant manual effort to stay in shape when you you build things that way. I want to come in on the end of what you just said there, Janice, as well, because the the the thing I've also seen happen is the not my job. Right? It's the compliance team's job to do the compliance thing. I'm just a little guy. I'm a DevOps guy or I'm the HR person or no. Honestly, if compliance can prove that the controls were operated by the people who did the thing, but they're not doing the thing. Like, I've seen this conflation that somehow that, compliance people should be doing DevSecOps code reviews. I'm sorry. What? Like, who went and got an MBA or became an auditor and thought, yeah, I wanna go figure out how GitHub works? No. That's not reality. And and that's that problem. And in year two, there's that if it's not been established well, if it's not a part of somebody's job, then it gets neglected and then it gets thrown back to the compliance team who it's undoubtedly their fault for wanting to have compliance. It's almost like anything that's been implemented in, like, a fragile or superficial way will absolutely come to light within that that first three hundred and sixty five days, it seems like. Mhmm. Any any any comments to wrap that that part of it up, James? Yeah. You know, I'll pick on one control just to, like, snapshot this. This may not be the most common, but it's what I see happened a lot. So access control. It's one of those really important details because people who have access to things, the people who we have the job to do the stuff that are pulling their reports for in the different silos we just chatted about. Like, on paper, it might look solid. There's a policy that we're just saying, and there's an approval flow and maybe even, like, periodic review. But underneath that, the identity data isn't always clean. We have those one offs and the exceptions and roles that aren't clearly defined, especially when orgs get people with all the different hats on. And then x decisions end up being more ad hoc than they should be. So the control is this, but it's not actually enforcing anything, at least not consistently. Yeah. So, folks, what we're talking through is, like, a pattern where compliance receives maybe, like, really hyper sharp focus before an audit or, like, during an audit and then starts to fade into the background. So, Kane, what if what about an approach like that creates long term risk? I mean, it it it seems like you have to start thinking about it as a system from the get go almost. Yeah. And I I do think that that means that the organization has to be ready for an audit every day as opposed to the idea of, oh, this is the Super Bowl today. We're gonna do the audit. We're gonna spend four weeks getting ready. No. That drives people absolutely crazy. We need to test compliance as part of our daily operations. This is not a one and done. And as I said earlier, controls have to be a part of your existing workflows. They're not some separate process. And to James' point, like, we should be monitoring our controls continuously and preferably using automation rather than doing it as part of some magical audit window. Like, if your evidence collection is happening real time and not retroactively, you have a far better a far better sense, proof that you're actually doing the things that you say you're gonna be doing. But the only way you get there, each control needs to have a control owner. Right? That's one of those basic things. And I said this earlier, compliance is part of a job description. Like if you talk to your HR person, this is in the JD. This is not a bonus. This is not a a side project. This is part of your day job, folks. And your executive sponsorship needs to establish that you have to have a regular recording up to leadership so that they're not blindsided by anything, as well as having really clear escalation if you have a control failure. Right? I I mentioned security, for example, DevSecOps before. Security reviews should be part of your development life cycle. And I'm not saying this because we're selling something like, oh, we've got the DevSecOps problem. This is a basic human thing. Like, can you do a code review? Can you check for security problems? Do you have compliance as part of your change management for your product? Is security training part of your new employee onboarding? Is vendor management and your procurement? Is that doing that evaluation? But again, don't do this manually. It's crazy making. Automate wherever possible. James mentioned access reviews. Why are we doing this in Excel? This is this is nobody wanted this. Nobody when they were building Excel out of what Lotus one, two, three or Quattro or whatever it came from, Nobody ever thought, ah, that's that's a good access review mechanism or a vulnerability scan. Why are we doing this stuff manually? Like, let's go ahead, collect the evidence that it got done, show it to the people, put everything that you've got in one system. Don't put it in like 27 different scaffold trial folders on your thing. And then you get the ability to say, instead of showing me when my audit deadline is coming up and start panicking, start looking at control drift. Like if a control is starting to no longer operate and reduce whatever risk it was associated with or whichever regulatory control or so on and so forth, that's where you can take action. You could take it a lot sooner than when the auditor shows up and, hey, sit, show me the evidence that you did the thing. You go, oh, well, we don't actually have that. And then you find out, oh, it's actually not been working for six months because that's just going to be a bad time for everyone involved. We have to frame compliance as a, I don't know, it's a kind of a risk management. It's not a checkbox exercise. And because it's part of people's job descriptions, I'm not saying this should be performative, but we should reward people adhering to the controls. They're doing their job. It's not how fast you did it. It's not that you did it because it was a bonus. It's you did your job. Cool. And the last thing I'll say before I get off my soapbox. Sorry. That's why you're here. I think of a lot of the litigation that's happened in the past few years, especially around government contracting. And it's not so much for SOC two, for other entities. But we can take a lesson from that. If you've got a control failure, somebody should feel the comfort to say this control failed, And it's not their fault. They shouldn't get blamed. Like we should not shoot the messenger because you're reporting a control failure. But again, if we don't have that culture, this is just a normal thing that we all do. And, and, and good compliance is just an artifact of normal work. You can't say, hey, we have a control failure early on. But if you don't, you get that risk of, well, you might not get your SOC two, you might lose contract associated with that. And depending on your level in the organization, you might have personal liability associated with false statements, which, again, bad time, not recommended for anyone. Yeah. Totally. That makes me no. Go ahead, James. I need I need to balance on that because that's a 100% true. The goal isn't a piece of paper. It's the actual process. But then, I mean, not this isn't in theme, but there's also the risk you get from falsifying that stuff isn't just like, you know, your job. It's like people have a lot of money spent on all the cyber cyber security insurance and those types of things. But when you falsify your checklist, when you make a flag that isn't true, they don't give you the money afterwards. You think you're safe and you're not. So yeah. I was talking to James earlier today about how my very first, like, round table x security exercises, you know, they didn't scare me, but I was like, oh gosh. Do we really gotta do this? And then I kinda, like, looked at them differently because, like, you know, that at the time, we were I was at a really secure place, and we had everything on lock. So then it became, like, a more confidence building thing. And anytime we had a new person join IT or join security, we would we would run through a new scenario again, and they became really fun because of that. Because it's like, no. We got it unlocked. Let's see how we trust each other and, like, let you know how things are working here. Yeah. And I will just say to your audience as well, that is not a hard thing to do. I actually keep copy of this on my desk. I love it so much. Backdoors and breaches, just go ahead and buy yourself a copy. Used to give this as, like, holiday gifts. It's a card game. A little card game. Wanna do it yeah. If you wanna do tabletop exercises. I'm not affiliated with the publisher, but I do like board games. Oh, awesome. Drop that in your break room if you've got a return to office motive. Like, have people play it and just walk through the scenarios. It's super fun, and it does help people understand how incident response could happen as a result of a compliance breach or a security breach or so on. Yeah. I want my teams to be, like, confident in any kind of that moment. Right? So anyway Yeah. Shifting gears a little bit. There's a tendency to treat, like, SOC two, ISO 2,701, NIST, like, as totally separate initiatives. But I think, you know, the three of us certainly understand that a little differently. What what do you feel about, like, organizations that tend to make looking at these things more complex than they are? If they're gonna get one and then start to, know, say, oh, I I actually need more than one of these, or I don't know what I need to to be pursuing. Oh, boy. I'd say they make it a lot more complicated by treating the frameworks as competitive or competing initiatives, rather than seeing them as, I don't know, it's a seven layer dip. Right? It's, it's, it's eventually going to be delicious. You just have to get the ingredients right. You need to have a unified security program. If you've got one, it satisfies those three with maybe, I don't know, 20%, 30% more work. Because the frameworks all are basically saying the same thing. There's a lot of core overlap. All three of those ones you listed, like, their goal is to protect information assets and manage security risk. But there's a lot of overlap. If you think about access management or incident response we were just talking about or about risk assessments or about vendor management. But what's crazy making is you see people, organizations, implement the same controls for multiple frameworks and go, oh, this one's different. No. It's not. Like, SOC two, you go talk to your CPA. It's not a certification. It's got trust service criteria. It's not prescriptive, and people don't understand that. But it's also US centric. Right? You go to the EU and they go, why are you showing me this thing? And then you go to something like ISO 27,001. That's an actual certification. There's an accredited body and it's prescriptive. Like, go look at Annex A. There's 93 controls in there. It's not like, how do you feel about your controls? This is the stuff you gotta do. And it's required in a lot of regions. It's an internationally understood standard, but it's also a three year certification with an annual surveillance audit. Right? And then you mentioned NIST. If you think about, like, NIST 853, that's also a framework, and it comes from the US government. I find it mostly happens in either the public sector or where the CSO is a veteran, and they just go, oh, this is looks this looks normal. I would not wish 853 on anyone. Yeah. Right? It's it's not intended for commercial entities unless you're going for FedRAMP and yeah. That's that's not easy. But you can map these. All three of these because they're saying the same thing. 853, SOC two, ISO 27,001. It is not hard. Please don't use Excel to map the three of these together and say, where do these overlap? Where can we reuse the existing evidence from another control and not overcomplicate it by treating this as a, you know, you've got your separate project. You don't need to have a parallel control set with duplicate documentation and duplicate evidence collection and then duplicative audit cycles. I I have friends who are auditors who, like, have said they've had people come to them and say, why did you ask me for the same control 17 times in the same day? Like, why couldn't I just send it to you just one time, my guy? Because it's the same thing. It's a screenshot of the firewall. It's not hard to do, but people overcomplicate this because of a lack of understanding or sometimes because of business striation and how they're organizationally structured. Yeah. Good insight. James, care to elaborate on any of that or make it more concrete in any way? I mean, a lot of time people just pour in there. I do know I have to use Google Sheets instead of Excel while I'm sending him documents because he hates Excel, so that's fine. But but honestly, it's yeah. The the heart of it really is you're trying to make things better for a reason. Right? You're trying to, like, be secure. You're trying to get contracts. You're about to have partnership. You're trying to make things better. Right? So if you're doing theater, you're actually making things better. So I think the best advice there is to make sure those controls you're implementing are not very different between the different matrices. Like, because you might be like, you know, like, one might be about physical security about this and more access controls in this area, but, like, they're kind of the same question. And if you can kind of understand why you're being asked these questions, you can provide proof that actually qualifies multiple frameworks simultaneously because you're just doing your job all the time, staying in compliance. And then when you have that contract that's, you know, not gonna go like, hey. I want to do work with you. Do you have this series of letters and numbers? Like, yeah, you're 90% there. Like, right? You just you just get more things, and, you should have been doing them anyway, but you just didn't have to or it's expensive, and now you can prove So Faster you do the dishes, the sooner they're done, the better you get all this unlocked, the better you sleep at night. I don't know. I see. I see. But I I also see a really good point that you're making there is that there's this confusion between why would I choose SOC two or why would I choose ISO or why would I choose NIST? It's a business decision, guys. It's not the security thing. It's a business decision. What are your customer requirements and what is the market you serve? If you are in The US, you probably wanna start with a SOC two. It's a very nice entry ticket. If you're in international markets, go look at ISO 27,001. They're the Europeans are gonna look at your SOC two and go, why? What is this fiction? And if you're working with the federal government, first of all, good luck. Second of all, go with NIST. Don't even think about going with something else. They will ask you to explain it to them ad nauseam as to how it maps to NIST. Just start with NIST in that level. So is it is it safe to say that to kinda sum that little part of our talk up is that instead of stacking frameworks to build core controls that apply across the ones you need or suspect you will need? I think that's fair. It it's if you can design your controls, like, you know you're gonna eventually need multiple, design your controls to satisfy those frameworks concurrently. Right? Document it once, how it's gonna be, and then you can reference it across the frameworks. And typically, the evidentiary requirements are the same so you can centralize all of that. And then if you really wanna be smart about it, stagger your audits so you avoid staff burnout. Right? And if you can, and this this one varies. Like, sometimes you can use the same auditor where possible. Like, so sometimes you'll be able have an auditor who's gonna do your ISO and your SOC two, which tends to be cheaper, as well as auditors are people like us. They put their pants on in the same way every morning like us. Right? They're not different. And you can become friends with auditors. You can actually like an auditor. You don't have to adversarial relationship with an auditor. Having the same audit firm can help in that regard. Less friction overall. Yeah. They are your adversary and neither is your other teammates at your org that you're trying evidence from. So, yeah. Oh, there's that word again. I've heard it a couple times in the last few sentences. So let's talk about evidence then. I think many teams collect evidence for, I mean, for auditors and for their own, you know, just purposes. But more mature organizations always seem to generate this evidence, right, as part of their day to day and as part of their normal operations came from a governance standpoint. What's the difference between those two approaches where, you know, I'm I'm fielding this one at a time or in preparation of an auditor seeing my stuff versus I'm continually generating good data, good evidence? Yeah. I think I think the the core of it is that that if you're taking an event based approach, the Super Bowl approach, the auditor is coming approach, that's just documentation for auditors. It's not proving anything. Right? Continuous evidence collection is proof that your controls actually work. And the difference then is, is compliance a project or is it a part of your normal operations? Like if you think about evidence when the auditor requests it, right? Means your controls might not be continuously being followed between audits. You could have a higher risk of evidence gaps or inconsistencies. You're going to probably spend a hell of a lot of time trying to figure out how to go get evidence. And the evidence question quality could be questioned like the the timestamps of stuff, like when things were collected. Oh, wow. Was all collected last Tuesday. What if you're doing evidence sampling, where's the rest of the six month period? Right? Yeah. In in cases where it's like that, you can tell compliance is a separate initiative. It's not part of normal business. Whereas if it's operations driven, compliance is just a part of like your normal workflow. You collect evidence year round and you get lower audit prep. You might see, well, let's say two or four weeks as opposed to six months. And because your evidence has been timestamped at the time that it was collected, as well as there's a source associated with it, you can have an owners attributed to it. If the auditor wants to do control sampling, which is just looking through a corpus of evidence to see adequacy and sufficiency, they're not gonna have questions on why did it all show up last Tuesday when you knew I was coming, my guy. Right? And that gives us as CSOs or senior cybersecurity professionals, you get a higher degree of visibility, which gives us better risk management rather than that, that nagging skepticism of, Oh, I think maybe the controls are operating, but I couldn't prove it to anybody if I was asked for it. I I yeah. I don't wanna eat at a restaurant that's only cleaning its kitchen before the health inspector comes. Mhmm. Right. Like It's a good analogy. I like that. So, like, how frequently then and that's in as, like, I feel like it's the same kinda kinda talk then. Whether or not you've gotten to that spot where you're in a continuous a continuous moment, how often should you be, like, bringing in, like, executive leadership to to talk about this or review compliance posture? Like, it only when changes are necessary once you've got everything running on full? Or should there be periodic meetings and talks otherwise? I mean, I think about it how often companies talk about their finances. I I think that's that's something that's just a normal thing. So I'd say, operational review monthly, just hands on ops, how we doing. Quarterly strategic reviews that and that that's where you're looking at, like, larger systemic problems or control drift failures. And then having that annual external validation. I think that's the way to do it. It should be a standard, like compliance is an agenda item at a leadership meeting. It's not some separate thing. And your control owners, they should report directly up, not just to the compliance team so we get visibility, and we should have operational metrics that aren't just audit focused. Like, how well are we doing? And again, if we drive to that, we get to that two to four weeks for audits of prep as opposed to, like, six months of crazy making. The other thing I'd say is this, if you've got controls that are intended to reduce risks, and a lot of controls are intended to reduce risks, It'd be sure nice if you could, like, link those to your key risk indicators, your KRIs, and then show like, hey. We had a control exception. So this risk is now increased, and this is our justification for wanting to go fix the thing or maybe go replace the thing, whatever it might be rather than this abstract. Oh, we had a control that's going askew and people go, and why do I care? Because they won't. Because they won't have context. So make it very simple and digestible at a dashboard level so that an executive who's busy or a board member can understand how you're making progress. And if you do have those control exceptions, please track your remediation progress. Like, people know it was broken. We fixed it. Or it was an audit finding. We fixed it. Don't just leave it out there as a lingering doubt of like, oh, it's still a problem. Because people will ask you because they won't know if you don't tell them. Yeah. We fixed it one time. It might happen again. James, I think that kinda goes to what you see and talk to people through a lot. What where does automation have the biggest impact in shift in shifting this from being periodic to a continuous thought? Well, automation is definitely gonna help most where there's repetition. So, I mean, the normal things, the onboarding, offboarding, access changes, the device compliance. These are things that happen all day every day. And if these workflows are structured properly, evidence becomes a byproduct of doing the work, not something you have to go collect later. And we established earlier that our auditors are not members of our DevSecOps teams. Right? I'm pretty sure I was paying attention. But that also means that there's earlier in the process, you're getting data if you're doing this automatically and over time. So if your code reviews are happening automatically, you're getting a fast feedback loop right where the product's being built, where it's cheapest to solve the problems. Like, you want the issues to be spotted earlier, not at the end of the process. Got it. Totally. Well, One other thing I wanna come in on on just on the end of that is that if you've there are exceptions to every rule, and I love automation a lot. I love not asking people, hey. Did you do your job today? Because that feels insulting, especially if it's just an API call to show that the control operated normally. But I would say there if you've got a major security incident Mhmm. Run a spot check on all your controls. It's not fun, but you'll find things that way. Hopefully, you'll find that everything's fine, but you might find that something's not. The thing is, second thing is if you do a major system change or a major system migration, again, check that your control coverage is still there. Don't assume that because you've switched platforms that the controls will work the same because often they don't. And then if you're like going into a new regulatory jurisdiction or a new market or you get a new customer contract that has audit requirements, like do look at at how you're operating your controls and say, is my evidence collection comprehensive so that we can continue to attest to this? Yeah. I have to just definitely agree with part of that. There's a sampling you have to do in a new automation process to make sure it's happening. Like, so your factory is saying is what you're I'm gonna steal from a I'm gonna steal from a buck. What's his name? Like, Andy. So the breakfast factory analogy where you have a you have a machine that's building breakfast sandwiches for you, and this is a block machine. You can't see what's happening, they come out. They come out. They come out. You have to, like, have inspection points built into your system so you can see what's actually happening. So the automation is gonna be replacing your repetitive tasks, but the human has to both verify to put those changes into effect. And the human also has to know how to look into the black box of your machine to see how things are happening. And then if it actually is a problem, really take a look at your process and they made the changes to point to look at it. So yeah. Yeah. Definitely appreciate that. Did you just also say the breakfast machine? But yeah, the Breakfast Factory on Andy, think the breakfast factory. Where do I get one? You Andy Grove Breakfast Factory. He did a he did a it was an analogy in a bucket of breakfast. Love it. I would go to a restaurant called the breakfast machine just put them out 100%. Alright. Well, I I think evidence that I think that that all sounded pretty good. Let's shift maybe to ownership. I think this is often where compliance efforts mature or stall out, it seems. So, like, in a well functioning organization, I think you talked about you mentioned it at the very beginning of our talk today, Kane, but, like, who truly owns compliance at the end of the day? You know, I'm a startlingly boring person despite all evidence to the contractor. Contrary, I love me some racy charts. And Mhmm. Having racy charts in this in the compliance space really helps because according to me and most folks now are taking to this thought, compliance, that's owned by the business unit that's creating a risk. Right? Compliance, the the job function is gonna help and monitor it. That's the consultant and inform. But the people who do the work, they're they're only in the controls. Right? Going back to my DevSecOps example, if a developer writes in secure code, that is not a compliance problem. That is an engineering problem. The compliance team, they just make sure that there's a a team to process, that that there's a team and a process to go figure it out. So your board, right, they ultimately own stuff. They set the tone and the the risk appetite. And I guess your CEO and CFO are ultimately gonna be accountable for any contractual obligations under SOC two. But a compliance failure, it's a business failure. It's not just some IT failure. And if I were king of the world, I'd say executive compensation would be tied not just to revenue, but are you doing the things you said you were gonna do? That's your control effectiveness. And then if you go down a level, the control owners, like I said, they own their first line of defense. So like HR owns access reviews. Why does IT own access reviews? IT has no idea what the heck people do on a good day. Right? HR should own access reviews. Engineering, not the compliance team. They own our control, our code reviews and control owners. They're part of a functional team. They're not the compliance department. Right? They do the stuff daily. They generate evidence normally, and they're responsible hopefully for fixing something that goes wrong. And then people like security teams, CISOs, so on. We're the second line of defense. We can do advisory work. We can do monitoring work. We can make sure that the controls map well. We can coordinate audits and maybe be good friends with our auditors, but we don't execute the controls. We don't own the risks. And where you see these failures is the compliance team says, well, we're gonna own everything. That's where the compliance team is now the bottleneck where nobody wants in the line of business says, well, compliance isn't my job. It's your job. Right? And that's where audits then become a compliance team problem. Right? It's your problem to go fix. It's not just normal business. Might be the CISO's job to communicate that sometimes often. What would you say is, like, the best way for CISOs out there to to make sure that, like, when they're having to talk about compliance maturity or things that have to get done to a board or to the rest of their executive team, like, in a way that's clear and strategic and not overly technical? Like, do you have any recommendations for CSOs in that moment? Like, how to get everybody on the same team, so to speak? I mean, I I say the boards board members, what do they care about? They care about risk. They care about reputation and revenue. Wow. There's three r's. Reading, writing, risk, reputation, revenue. Right? And so translate your compliance into those terms that they're gonna actually understand. Show them the trends, admit if there are any gaps, and make sure your controls are tied to business outcomes. A really good example I had is a friend of mine had somebody come into her office and say, hey. Look. We need to cut some some money out of the budget. So we're gonna just this million dollars worth of controls, we're gonna get rid of them. Is that cool? So she hadn't done the full exercise, but went back to her team and said, what are these controls for again? Put it together. Put it together, the business case, and went to back to the executive the next week. This is before the board meeting and said, look, do you like a billion? That's with a b on it. Do you like a billion dollars? Well, yeah. I like a billion dollars. Why? Well, that's what that million dollars in controls buys us because that's our FedRAMP program. So if you'd like us to leave the federal market, which is x percentile of their market share, sure. Let's get rid of that million dollars in controls, but you have to tie it to a business outcome. These controls are enabling the business. They're not there because they're fun. They're not there because they're a neat technology. They're actually enabling the business to do something in a lot of cases. And we have to talk to boards in that way of here's how much revenue these controls support. Here's how much revenue or how much market share we could lose. I don't like going negative, but sometimes you have to, to say, here's how much we could lose if we don't do this thing. Is that above our risk tolerance? And then it's a business decision, right? It's, this is math. This is not emotion. It's, do you like a billion dollars? No, we could lose a billion dollars. Cool. Let's shut that off. Fine. No harm. No foul. Yeah. But that's a that's a level we have to have at that. That sounds like it'd be another reason just to have, like, you know, a baseline of education up for someone in that position because, like, like you're talking you mentioned earlier, like, GDPR and HIPAA are a bit of a different beast when it comes to, like, regulatory exposure compared to the others and the accountability that you you have to have for those. Right? 100%. I think that's also just a lack of understanding between SOC two and, other regulatory regimes. I think there is personal liability. Article, don't quote me on this, 82 or 90, think I in GDPR says, look, y'all make a misstatement and you're in trouble. But the big shift there is like, just to go other ones is like SOC two, again, it's voluntary, guys. This is this is a contractual obligation. Do you want the contract? Cool. Do SOC two. If you don't do GDPR, you're gonna pay fines of 4% or I think it's $2,025,000,000, somewhere in that Euro. Right? If you don't do it, and if you got HIPAA, like, you're gonna pay up a $50,000 of violation, and you could face criminal charges. It's involuntary. I think that's the level of education we need to have. James, do you see James, you've been really quiet. Yeah. I was about to I was about to ask James if he sees do you see, like, people underestimate, like, what that lift looks like to get the high like, the regulatory compliance stuff in place? Well, first of all, why I didn't really join the conversation. So thanks. No. I mean, to get the compliance in place. I mean, the lift is hard hardest because people don't know what they're lifting. It's like it's like going to, like know, you I've been to the gym before. I'm really jacked, obviously. But, like, you know, I I've seen some of these machines. I don't know how they work. Right? So you walk into a gym the first time, someone just show you how it works. I'm like, oh, the weights are just there. They're locked in. I know what I can lift. I push this. Right? That might have taken you, like, your entire life to get to that point, and then there's just repetitions. So, yeah, the lift is really hard before you understand what you have to lift is kinda my point there. So yeah. Alright. So if compliance becomes structural and continuous, it stops being a disruption. It starts becoming part of how the company actually runs. Maybe we'll talk I know we have a lot of interest from the folks on the call specifically about SOC two and how that fits into, like, kind of a broader landscape. So maybe Kane, is is SOC two the the floor or the ceiling of of of taking a look at all this? I'm gonna say it's not even the floor. I'd say it's a it's an admission ticket. Like, it proves that you've taken security seriously enough to be audited. Right? But if we want true security maturity, that means you have to build a program that's not based on the audit requirements, but actually based on the risks faced by your business. And I say business risks, not cybersecurity risks, because those are fiction. But also you have to build and be willing to be changing faster, slightly than this modern threat landscape. You have to have it be responsive to what's happening in the world. Because again, SOC two is the minimum standard. Who's gonna go to the the health going back to your, idea about health inspectors going to restaurants, who's gonna go to the place that's got a d in front of it? Right? It's the minimum SOC two is the minimum standard for trust. It is not a mark of excellence. And if you go read enterprise RFPs, they're gonna reject you if you don't have a SOC two. But just because you got a SOC two doesn't mean you win the deal. That proves your controls were work working for like six months. Not that they're good. Not that they're gonna work tomorrow. Right? It's gonna ignore it ignores business risks like brand reputation or supply chain, and we can still have breaches. And this is why we see enterprise vendors in contracting ask for additional attestations or additional proof of security. This is where we get into security questionnaire hell where you get, you know, a 300 question questionnaire because you just said, well, we've got SOC two. We're good enough. Right? No. No. No. No. You you just bought a price, a ticket to get into the door, into the conversation, but it doesn't mean that you're unhackable. It doesn't mean that you're secure. And it doesn't mean that you're gonna win every deal. Yeah. Well, then perfect. Perfect then to ask, I guess, when does ISO 27,001 become like, is there is there an investment moment where you say that's I need to, like, take a step past SOC two or I need to look at additional stuff? Yeah. Yeah. Just on on ISO 27,001, other than the European and international market, in general, I've seen contracts, I'd say above $1,000,000 or definitely above $5,000,000. They're gonna be asking like, hey, if you got ISO 27,001, and they might even ask for additional controls. Like, do you do pen testing? Do you have a a third party risk management platform? And and if you don't, expect additional questions, which nobody wants to spend time on because that drags down your deal velocity. James, any thoughts on kind of the the floor or the ceiling? I mean, I mean, the floor to ceiling. I again, I truly believe you just wanna have good practices, like, the business risks being the issue. Like, like, your business gains, your business risks are why you do this stuff. But I'm gonna, like, bring that framing closer in the floor and ceiling. It really because this is what always happens when you're in the room, whether it's a good reason or not. It's always because of what contracts you can get, how you wanna look for for your what your brand to look, what you wanna put on your website, like that's your floor and your ceiling. What doors do you want open and what checks do you want handed to you? And that's what's gonna get you to those frameworks. Now us in the practitioner space and other side of it, we want things to be running well, but that's what opens the door. That's what makes it worthwhile. So if you're in global markets, you're probably gonna want ISO. You're having high dollar, you know, high dollar contracts in front of you. You're going to have to have these already because you're not gonna start when there's a whole slew of people but similar sounding solutions to you, and you are in the process of getting that certification versus one that's had it and has proven their ability over time, like, yeah, you got in the door, but you were just a, you know, a characteristic point to bring down the cost of that contract for the other person. Perfect. Awesome. Well, rather than accumulating certifications, I think based on our talk today, the smarter path certainly seems to be designing a cohesive system that can support a multiple standards simultaneously, but also just building building trust and the idea that your entire business could sleep at night because you're not just winging everything. So maybe let's close by making this, like, really practical. Kane, my question is to you then. If a CISO is on the call right now and wants to move from his current checklist thinking to system design in the next quarter, what's his very first step? What's their very first step? For a CISO? Maybe also for a CIO. Actually, depending on the size of the company, they might not have either. I don't think this is a an IT manager and Yeah. I don't think this is gonna be tied to a a specific role. I think what we need to tie is what are the business outcomes y'all are looking for? Right? More than anything else, like, what is the thing why are we doing this? Because SOC two is voluntary. So once you figure it out, cool. So this is gonna give us market share, deal velocity, something else. First step, figure out your scope and your ownership. Like, I've don't start building your controls. Remember my RACI chart? So boring. Don't build controls before you define who's gonna own them. And then what's the business risk that it fixes? Because if you do, you just get a checklist and you're wearing to this checklist product problem again. We need to be audit ready every day, not during audit season, but that assumes people own these things and they internalize that ownership. Only other thing I'd say SOC two has got trust service criteria. They all look really cool. Like some of them are really comprehensive sounding. It doesn't mean you need to do them. Right? You can choose which ones matter to you, which ones are in scope, and which ones are out of your scope. Like, if you don't do, you know, processing transactions like financial stuff, why would you include that? Yeah. You don't need to. Perfect insight. Thank you so much, Kane. James, what about you? What's an operational change that you think would immediately improve maturity of of a business? Alright. So let's give them that that leg up. Alright. So I look at, like, one workflow that's currently manual and high frequency. I said access before. It could be onboarding, offboarding. Like, a manual task you're doing is high frequency. Alright? Because in general, audits become a forcing function for good process and action. So you end up correcting problems as you collect, which, of course, slows things down. But, also, it shows you that you have been less than compliant since the last time you were forced to check on those things. So instead of just documenting it better, actually structure it so it runs the same way every time. Use that documentation as a map to good automation. If you can make one of those flows predictable, you'll improve both your security posture and your audit readiness immediately. You'll also benefit from happier techs and a more productive use of time. Awesome. I really appreciate it. Then to wrap things up, I think three three actions folks can take for from my end is maybe, like, map your core controls across frameworks, eliminate duplication, align clear ownership at a leadership level, talk to folks, get on get in good. Third, convert at least one manual evidence process into continuous monitoring. That'll give you at least a starting place, because compliance shouldn't interrupt how your operation, how your organization operates. Right? It should shape how your how everything about your day to day functions. So awesome. Kane, James, thank you so much for the conversation. Folks, thank you for joining us today. I hope you found some worth in our words. I appreciated the conversation. Thank you. Good afternoon, everyone. Thank you for joining us. I am a new face behind the curtain this week as our normal emcee is out on paternity leave as his daughter was born two days ago. So if you want to extend congratulations to Michael Hendrix, I'm sure he would enjoy a nice little message. Quickly wrap up our session today. I wanted to let you know about next week's session, which is with Nella Juma, head of technology at AC Disaster Consulting. AC Disaster Consulting is an existing Rippling customer, and they'll be walking us through how they moved away from their MSP and built an integrated IT environment using Rippling. After that, we will be taking our Rippling on the road show to New York City at Conveen 30 Hudson Yards. That is a two day session on April. For those folks really interested in IT and meeting some of the IT folks here at Rippling. We will be on-site on the fifteenth, and we would love to see you. Make sure to stop by. Say hello to James and myself. My name is Nick Price, and you'll also see Ben Pollock and a few other folks of our on our team there. We'd love to have you join us. The next one towards the end of the month on Wednesday, April 29, we have a session with Productive who is another Rippling customer. They will be walking us through how they achieved zero touch deployment. They are basically onboarding and offboarding all of their employees using one click, so we are very excited about that session. The last oops. I stopped sharing. Nope. We're still sharing here. The last thing is the winner of today's raffle. I know you're all excited for this. And, Mark, I see your, comment there in the chat. Jimmy Turo from our team, should have reached out to you yesterday. I would just check your inbox. If you don't see anything, please don't hesitate to reach back out to us. And, Mark, I can also email you separately. You'll see an email from n price, as well. So, the moment everybody has been waiting for, today's winner of the Bose QuietComfort Ultra headphones. Today's winner is Robert Ports, HR manager at Bo Robotics. Congratulation, Robert, and thank you so much for joining us today. And to everybody else who joined today's session, we really appreciate your time, your energy, and your effort with joining us. We look forward to seeing you at our future sessions. Have a great rest of your day, everyone.