Episode 11: Unveiling Onboarding Insights: A CISO's Eye-Opening Revelation

Hello, hello. Some folks are sliding in here, so it looks like, looks like they got the message. We're going to apologize to all of you who got that last-minute schedule change. You can tell that, that the regular accountability guy, Mr. Kyle Christianson, is not here today. So there may be—

this is what happens.

Yeah, when, when, when Dad's away, things go sideways. If somebody could just throw something in chat and let me know that chat's working, you can yell at us for, for our terrible scheduling today. But we'll apologize because we were supposed to be on at 2 o'clock and somehow We got some calendar mismatch here and wound up being an hour late. So I apologize that all you guys got that 1 o'clock invite. I'm wondering if chat's working. Stephen's raising his hand. I think he's telling me that chat's not working. So now I have to find that button. Yep.

Well, while you're getting that going, I'll let you focus on that for a minute and say thanks, guys, for joining. It's great to see you all.

We were—

we apparently we had a time conflict that I was not aware of and But those things happen. So thanks for joining us today. And this is going to be a fun discussion. We're going to really dive into onboarding and we're going to talk about what that looks like from a security point of view. Looks like chat's working now, so that's good and should be a lot of fun. So we can't wait to get your guys' thoughts and feedback and jump into some deeper collaboration as we get through this. It should be, should be a lot of fun. I think we're going to dive into some meaty stuff.

Yeah. And if you're listening to this late because you just got the recording, again, we apologize. Kyle's away and you can tell I am not Kyle Christensen, but I am at the controls. And Kyle's fancy pretty multi-window thing is not here today. So you can tell who the smart guy is that makes all this happen and who's here just to be the pretty face that adds some color and some commentary as we go along. But, but yeah, as Wes Spencer said, we're going to kick in and jump off. Two weeks ago we talked about onboarding. If you didn't catch that webinar, it is out on K7's YouTube page. It's a fantastic webinar. We talked through what that onboarding process looks like and we gave away some documentation that might help you kind of walk through onboarding and remember all all the steps that go into this complicated process. Because onboarding really is the thing that kind of sets you up for success over the long haul for that customer. But as we stepped away from that webinar, we kind of had the conversation with some of you that were on the webinar going, hey, we didn't really talk about the security part of onboarding. So we thought no better than, than a CISO to come in and talk to us about all the things that, that you might not think about as you're onboarding a new customer. And Wes, the first thing that I thought about when we scheduled this webinar was what happens when I onboard a customer who's already been breached and has a bad guy dwelling on their network. And I'm sure that'll come up as we go today. But that was the panic thing that went through my brain that said, yeah, we got to bring Wes on here. We got to talk about this. We got to have this conversation. So let's jump in.

Well, let's do it.

Yeah. For those of you who don't know us, my name is Alex Farling. I am not Kyle Christiansen if you're looking at that little thing right there with my name on it. But Alex Farling, I was one of the co-founders over at Lifecycle Insights, and I was an MSP for a long, long time, long enough to tear out all my hair here. And, and I'm joined today by my good friend Wes Spencer. And Wes, I'll let you introduce yourself real quick here.

Yeah, for— yeah, so if, if I haven't met you, um, really good to be with you today. I'm a cybersecurity nerd at heart, um, came out of banking. So this world of like being a security practitioner, boy, I don't want to say it's getting stale, it's been a few years, but, um, it's been, it's been a bit. But I was also, um, the co-founder of Perch Security, was the CISO there and one of the co-founders helping build that. And I've done all kinds of stuff in the MSP Channel for quite some time and have landed now as their, um, as the, as the founder and CEO at Impact Cyber, helping MSPs grow in cybersecurity and kind of that mission of turning every MSP into a cybersecurity talent factory. So it's been good to be with you.

Absolutely love it. Absolutely. Joe, I'm sorry that my, that my Star Wars collection is not here. I promise you it's getting on a moving truck very soon and it will be joining us in a, in a Tampa, Florida house near you. So I went, I went full official, you know, grown up today and put on a shirt with sleeves. But I do own a Florida tank top now. So things are getting real down down here, but I am in the process of a relocation. So the old office as you know it will be back, and hopefully the echo of an empty room will quickly go away.

Looking sharp in that pink though.

You know, I like this pink. This is a, this is, this is pretty. But then somebody told me that I looked like a Miami Vice dude when I was at one of the trade shows in it with my white blazer, and I was like, oh, how's that? Cool enough to be Miami Vice? I don't think I'm that cool. Those guys had better hair. But so, so today we're gonna, we're gonna walk through and really talk about the fact that onboarding really isn't complete. Until we've done a few, a few extra things. We're going to talk about assessing that security landscape, right? That thing that kind of put me into a panic when we, when we started talking about this topic, establishing that baseline security. And Wes Spencer, one of your favorite slides of mine ever, is the must be this tall to ride this ride, right? You've got to have some, some basics in place before you really meet what we consider to be baseline security. And every MSP probably has a different baseline where you say that you got to be this tall to be my customer. You got to have this much in your stack. We're going to talk about navigating compliance requirements. We'll talk about communication and transparency. The folks from service leadership really believe that this onboarding is the most important time to start the conversation about what your relationship looks like over time. And they even give us some numbers to say that MSPs who have the conversation early get way better interaction at quarterly business reviews. They get better attendance. They get folks showing up, and consequently, they're more profitable. If part of your onboarding is, hey, here's what we expect from you. This is your part of this relationship. And then we'll talk about that big scary nebulous thing called incident response planning. And, and we'll touch on that just a little bit. And then we'll probably, Wes Spencer, you know, you were talking about this, you and I were having a conversation about this, about an incident response planning workshop at some point. Like, this is one of those really big scary things that probably warrants more than, you know, 3 slides in a, in a conversation like this. But I'd love to hear from the group. Number 1, if any of these 5 topics warrant a whole lot more exploration with you as Kyle and I continue to do these webinars bring in wonderful guests. Is incident response planning or any of the rest of this something that you'd like to see us dive deeper into? Because we're always looking for that next piece of content that adds value to you. So let's kind of, kind of jump in and talk here, Wes. You know, security landscape, very much, very much your wheelhouse. What do you think of when you, when you think of onboarding a brand new customer where we get into vulnerability management and, you know, kind of, kind of tailoring what security land, what security management looks like over time, especially especially as we're just getting started.

You know, when you think about how we've traditionally done new client acquisition, what, what is, what is, what is, what have you been taught for years? You've been taught if it's just purely managed IT that you begin the relationship with some kind of like IT assessment, right? Like whether you drop the Network Detective 500 pages on their desk, um, yeah, yep, the FUD fact. We, but we've taught, we've been taught by every MSP coach out there, you don't start an relationship without an assessment because you got a level set. And that's good advice. I think with security, it does dovetail and follow that. Now it's laden with way more risk and way more issues than IT, which we'll, we'll get into in a minute. But it follows and dovetails that same discussion because you don't— the reality is you don't know where that client is at. And there's a really good chance the client doesn't know where they're at. It could be anything from they actually have an active incident and there's an actual beacon calling back to a bad guy. All the way to some really, really bad security hygiene to maybe they actually have a lot of things ducks in a row, but you don't know it. You don't know it until you do the assessment. And if you don't know this, when you begin to bring that client in and bring guards up and shields up with them, you're now— the second you sort of go into engagement with the client, if you've not done those things, there can be a world of hurt that's coming for you because you're not ready for it. I'll give you an example of this. One, one time I see Roberto Chaffee that's on the call right now. He and I and the Huntress crew, Chris Laird and some others did a— at Write a Boom, we did a deep dive on incident response. We kind of did sort of like a tabletop test. And wouldn't you know it, one of the big things that we were driving at with the tabletop that we didn't release, we didn't let it be known overtly, was that the image MSP in this fictional but nonfictional scenario was so aggressive on getting this new client with billable hours that they grabbed him too early. And because they grabbed them too early and the shields weren't fully up and an incident occurred, they weren't able to determine— did the incident— was it already active before they got the new client and finished acquisition of that client, or did it happen through the middle of this? Regardless, the MSP suffered many, many, many thousands of dollars in this tabletop scenario because they were not prepared and they hadn't done the work to assess. They were just so hungry to get the client. And so that's what we're going to talk about. Yeah.

I mean, that's an easy thing to get excited about, especially if it's a good-sized client or if it's a client that comes with a lot of billable work or a lot of billable hours. But I want to unpack something you said at the beginning. Let's, let's take a step back. You, you, you talked about the difference between security and IT and you kind of glossed over it. And I want to make sure that we unpack that for a second because at least our customers, think those are all the same thing. And I think a lot of IT providers struggle to really differentiate between the two. Unpack that for me for just a second.

Let's do it and let's do it by crowd for a minute. So I know there's only like 15 of us on since we messed up our time zone difference. Sorry about that. But with those of you that are on, I want you to open up chat and I want you to tell us, give me 1 or 2 or 3 things that you should not cover under like the normal managed IT relationship when it comes to cybersecurity? Let me give you an example. Reimaging a machine. Should that be done under IT service delivery if there's some kind of cyber incident, or should it not? Now, there's not necessarily a hard and fast right and wrong to this answer of this question, but I want to know from you guys in the audience, what are some things that should be outside the scope of managed IT, what things should you say, I'm not doing that bundled into your, your all-in seat price? Why, why should I pay extra for that?

Are we talking about specifically if there is an incident or are we talking about just in general?

I think just in general, but, but it could specifically be an in— I mean, it could, it could be either way. So give me some thoughts back. I know you guys are thinking and typing. Let's take Mr. Roberto in here. I got to get the R rolling. Recovering from any cyber incidents. This is why we're starting to mandate that they have a policy. Very well said. Right. So, so we're going to really unpack that through today's call. But incident response and all the elements inside incident response should not, must not, cannot be part of managed IT because you can't control those costs. It might be an hour, it might be 10,000 hours. Jesse Miller checking in. Oh, go ahead.

Yeah, well, I was just going to say everybody's kind of hitting on this incident response thing, right? And but I think if we take it a step back further, right? There's probably some of those detect things that are, that are not really covered under incident— that aren't as far, as far to the right as incident response, right? If we back up into detect, you've probably got some things like SOC services, maybe compliance, compliance management or compliance deployment or whatever you want to call it. That, that whole process of becoming compliant with a cybersecurity framework probably is not something that's just covered under your basic managed services. And we talk about this a lot. It's just as— not just as much, but it's a lot of work to get a 2-person shop CMMC compliant, where it's not a whole lot more work to get a 20 or 30 or 40-person shop CMMC compliant. So for your 150, 250, 350 a seat, you can't do compliance in just your regular managed services agreement. That's got to be billable above and beyond.

Yep. Well said. So Jesse checking in, multiple machine reimaging. Yeah, right. So if you have a significant ransomware event or you suspect that a bad guy or you have evidence that a bad guy has gotten access to multiple machines through lateral movement, what does that take? There's a lot of costs that's baked into that. Even knowing which machines may have been compromised and which weren't, that gets nasty. Good incident response will tell you if a bad guy got all the way into your domain controller, it's time to blow away the entire domain. So what about that? How do you handle those things? Kevin saying remediation of the incident. I absolutely agree. It's exactly what Robert was saying. Same, same exact thing. And then Jesse saying we also have to have clear vulnerability management and patching definitions. I really agree with that too, right? Because, you know, some of those things should be baked into normal IT service delivery costs. But what happens if, you know, like you mentioned, zero days, maybe some huge sprawl, maybe there's some challenges because it's a line of business application. You're sitting on hold with the, with the vendor doing this for the client. And, you know, there are things like that you really want to spell out. So this brings up the next question I was going to ask. How many of you would say— and it's okay to say no on this, right? How many of you would say your terms of service, your MSA, your managed service agreement, very clearly articulates the things that you're responsible for and not responsible for as part of your managed service when it comes to security? Let me say that again. How many of you know for a fact very clearly that you're comfortable, your MSA dictates what should be covered for cybersecurity and what should not be covered under your managed service. And Alex, why is that so important?

Well, because at the end of the day, at some point, if this happens, and we hear that we hear kind of horror stories about this, God forbid there is a breach, right? We're going to get hauled into court. And even if our customer loves us and says, Wes, I love you, I'm not taking you to court. His insurance company who had to pay out is going to say, I don't care how much you love Wes, and I don't care that your kids play soccer together. You know, this breach cost me $300,000. And I'm going after my pound flesh from somebody, and he's the first one I can put my, my sights on. So when we walk into court, this is defensible positioning. This is about having that contract that says very clearly, I was responsible for this much and here's where my responsibility stopped. Yep.

And it's that way you get to say, and I'm more than happy to help you and we'll do this, but we're billing on the side for this. And oftentimes you mentioned cyber insurance, the carriers, depending on the carrier, depending on the nature of the incident, sometimes the carriers are okay to bring you as the MSP in through the incident response process.

Process.

You're probably not going to lead the IR because you're not on panel with them. There's a bit of fox guarding the henhouse, but a lot of the operational mechanics of getting recovered is great. So you hear these horror stories of like, what does this look like if we just have a typical MSA that we've had for 15 years that say we take care of all things IT, and then the big cyber incident happens and the client says, you said you take care of all things, so I'm sorry that you're going to spend 400 hours reimaging machines and all this other work, but that's on you. Those are the kinds of things that can get really, really nasty. And so love to see some of those folks that are doing this, they're rethinking their agreements.

Well, and it especially gets scary when our marketing gets out in front of our contract, right? How many of you have a website that says we'll take care of IT while you take care of your business? Well, guess what? Your customer doesn't know the difference between we'll take care of IT and we'll take care of security. And so that's just an important talking point. And I would be careful with your marketing that it doesn't project something that, that your contract can't back up or vice versa. Person.

So can we do a quick— so again, I love what Jesse said there. Might be a bit of an uncomfortable conversation, but you got to have it, right? So can we role play that a little bit, Alex, of like how to actually have that conversation? So let's say I'm going to make you the MSP. I'm the client. We've been working together for 15 years, really like you guys. We've had a couple close blows and some things you guys have had to help us with, some viruses that have been triggered and things like that, maybe some email weirdness. Um, but now you need to talk to me about why I need to re-sign a new MSA with you that actually says that you're responsible for How do you get me? How do you have that conversation?

Yeah, first let's point out the difference here, right? We're not onboarding in this conversation. We're actually working with an existing customer. And with our existing customer, we just have to go back and explain to them cybersecurity is not what it used to be. Hey Wes, look, I need, I need to make sure you understand this. And I'm sure you watch the news. I'm sure you've heard of the SolarWinds breach and the Target breach and some of these other things that have happened. There's a different breach every day. This is because cybersecurity has gotten way more complicated. And Wes, unfortunately, cybersecurity and IT support are just not the same, the same skill set and the same function. And so while your contract includes unlimited IT support, it doesn't include unlimited cybersecurity. And let's talk about what that really looks like, and here's how we break those out, right? And then I'm going to sit down with Wes Spencer, show him what's included and what's not. And either I'm bringing him my cybersecurity package that includes more of those things, and I'm showing him all the new things that we're adding that go above and beyond. Or I'm introducing him to my trusted partner who does cybersecurity, right? I may be bringing in an Orbital Fire or somebody like that. If I'm a sub-$1 million shop and I don't have those resources on hand, I'm coming in and saying, let me introduce you to my guy. Hey Wes, I got a guy and, and I'm going to show you what he does that's different from what we do, right? And then that guy can sit down with me and help me draw that line and show me that, that line in the sand and where things are different. Yeah. Now with a new customer, it's easier, right? Because my new customer didn't start back with me in 1982 with, with, you know, some, some Symantec and a firewall and, and we called it good, right? We weren't swapping out tapes in the backups and this guy hasn't been with me through all those iterations. I can just sit down and explain, here's my standard IT support offering, here's my security offering. I think you need both. Here you go.

Well said.

Was that, was that the role play we were looking for? That's the role play we're looking for. You totally threw me under the bus there. Okay.

Yeah, I know, I know. But, but the conversation I think required, I you could handle it, right? And so I do, I do. I implore everyone to take the advice of Kevin and Robert. Make sure you've had qualified legal counsel that understands cyber, not just I'm a business lawyer, but somebody that really understands cybersecurity, an attorney. Review your MSA for these things because I'm telling you, you need to do it now before something happens.

So let's step back just this, this category as a whole. Let's kind of wrap it up. We're doing a couple of things here, right? We're from the, from the really high level. We start everything from an assessment. And I always talk about the assessment as establishing status quo. Status quo. If I don't know what status quo looks like, number one, I can't protect it. And number two, I can't explain to my customer what better looks like. So really what we're doing is laying the groundwork for what do we own, where does our data live, how do we protect that data, how do we protect the network, what exists on the network, what are we comfortable protecting, and what do we have to go outside of our normal boundaries to— oh, they got this weird CNC machine in the corner that is not, not something I'm used to looking at and have to deal with a little bit different. So during that assessment, we'll identify where the critical data lives and exactly what's out there. And then we'll start to build a vulnerability management and response process around that. And our client needs to be involved in that, right? They own the network ultimately. One of the great conversations I like to have with MSP owners is a real simple math problem. How many clients do you have? And I'll let a couple of you throw that number in the chat. I just want you to think about it. How many clients do you have under full managed services? I don't care about the break fix or the folks who aren't full all in. In. And then how many techs do you have? Now, every time I get on an airplane, and I watch the Southwest steward stand in front of me and clip and unclip their little seatbelt and show me how to blow into the little thing, it reminds me of incident response. I think about the fact that there's 3 flight attendants on my plane and 150 people. And if the plane goes down, nobody's going to come to my seat and go, Mr. Farling, please come with me. And I'm going to show you how to get off the airplane. Right? You're on your own. If you've got 100 clients and 7 techs, every one of your— and 10 techs, because I'm bad at math— every tech has 10 clients they have to restore in a complete breach scenario. If you lose your RMM tool and lose all your clients, think about what that looks like. This is why your client has to be part of the process. They have to understand their own incident response plan. They have to know what part of it they're responsible for, and they have to understand what your division of labor is going to be on the back end. Right? And Rob could probably talk to us for days about this. But this is a real-world thing, and it's something you have to be prepared for. Like, right? Let's prepare for the worst and, and hope for the best. Alright. Let's, let's move on from that one. We already made everybody sad with that conversation. So let's, let's hopefully go find ourselves a better, happier topic. So Wes, baseline security. This is, this is, I, this is my favorite slide. It's a little kid in front of a, in front of a theme park ride and it's, you know, must be this tall to ride this ride. But that, that's exactly what we're talking about here, right? What are the, what are the basic baseline security things that, that come to mind to you when we start talking about this?

Yeah. You know, one of these things, one of the truths in this world is that we don't have grips over anything unless we have it under a baseline. For example, I'm working on my pool right now. Couple little small issues with it being off on its salt levels. It's not under baseline. So I know that I don't have control of the pool, which If the salt levels are off, then what does that mean for its, its chlorine production? Right. So it all sort of snowballs. Baselines are a happy place. We operate businesses off baselines. We operate relationships off baselines, and we operate cybersecurity off baselines. Baselines keep us within the means of the norm, and that's really important for us to think about. So when it comes to cybersecurity baselines, I encourage you to think through Do you actually have a well-defined documented baseline or is it sort of fly by the seat of the pants? It can be okay to have a baseline that is a little bit different from one client to the next based on their industry, their size, the risk profile. That's okay. But you do need to have, as you mentioned, Alex/Kyle, the very bottom baselines. What is the minimum threshold that we cannot get by without. And so that's an important thing to think about. And so one of those things I think about when you're, when you're kind of working through this is to say what, you know, a lot of times MSPs have a number of things that they can offer. And I'll very commonly when I'm teaching a course or like a workshop, especially in cyber insurance, and we show those minimums, things like, you know, immutable backup, security awareness training, EDR, managed EDR really now, and, you know, MFA everywhere and vulnerability management You know, those are like the 5 minimums. And I'm not saying that should be the baseline minimum, but I ask MSPs, how many hands in the room have solutions to handle this? 100% of the hands go up. I say, how many of you have 100% of your clients using 100% of these services? Zero hands go up. And I'm like, I'm not hating. I'm just saying, do you see the discrepancy that exists here? So that, that brings up this discussion of what actually is the minimum. A lot of MSPs say two things. They'll say, If we don't hit the minimum, then I make you sign a waiver to get out of it. Or they say, if you don't hit the minimum, you're not a good client for us. Let me help you find somebody else that is. I'm not here to dictate to you which of those two you should fall into, or maybe both. But I am here to say you got to set the foundational minimums. And so to me, the min— there's a minimum underneath the minimum, Alex. And what I mean by that is there's a certain level minimum that will keep you out of the negligence lawsuits. So for example, cyber insurance. Insurance, those 5 things that I mentioned. If anyone wants the list, I can get it. I can link you in from Fifth Wall. They've got a great list for those things. That's the minimum of the minimum. That's the things that are going to say, well, at least they're eligible for cyber insurance and they're not going to get their claim denied. But then I think there's a reasonable minimum that comes in even above that, that I think all intelligent people need to put in place. And so the question is, what are those things and how do you set them into motion?

I suppose we could talk about some of those things, but, but before we, before we dive into those too deep, let's, let's peel this back just a little at At this point, you probably came to your customer during your sales pitch, right? We're onboarding a new customer and having this conversation. You probably came to them during your sales pitch and said, hey, here's our minimum, and these are the things we're going to deploy when we onboard. You sign here, and you're going to include all that. But I want to go back to Wes Spencer's question about the contract. How many of your contracts actually explain to your customer that the minimum will change over time? Right? I remember when I rolled out ThreatLocker at my MSP years ago, and I'm just using them as an example. No referrals, references, whatever. Just, it's a product we used. And when we launched it, we, we We went and talked to all of our customers about it at a quarterly business review. And I went to all of my medical clients and said, thou shalt buy ThreatLocker right now. And I went to my, my smaller nonprofits and folks who weren't in quite as sensitive industries, didn't, unregulated industries, and said, I'm not telling you you needed to buy it today, but I'm telling you this new technology exists. We should be watching it. And one day I'm going to come tell you it's not optional anymore. Anymore. Today it's a, it's a nice to have. But I think your contract should say, should, should spell out, number one, what your minimums are, but also spell out that minimums will change over time in accordance with cybersecurity industry best practices. And now I'm letting you know, Mr. Customer, that, you know, the minimum today won't be accept— the acceptable minimum a year from now or 2 years from now. And we just go right back to the story about tape backups and a Symantec antivirus client and, you know, a Cisco ISR router out in front of your network, right? Day, that would be considered gross negligence if that was all that you were running.

So what are you preaching in that mantra? You're preaching the message that security is not a journey that I begin on, I go through, and I complete. Security is not this finish line that I get to and all is good. Clients have got to understand that it's not that security is this willy-nilly moving target in an area that we're just not sure of. No, security is a reactionary endeavor that we have to continue to follow and put in process. It is truly a process that doesn't end. And so it is important for clients to understand that while we may— like, I love what you said there, Miss Client— with the things we're doing now are up to best practice and standards, but just like in a lot of things in this world, we have to keep up to date. We have to stay— just like your business has to stay up to date with the latest in innovations, making sure that you're staying up to date with your competitors, making sure that you're doing all the right things to be survivable. And 5 years ago, that looks different than now. Cybersecurity is no different, Ms. Client. And it's our job to let you see those things that are happening as minimums now and looking into the future of the things we need to start thinking about and budgeting for. And Rafi, I love what they— what Rafi said there is, you know, allow for change in the process.

Yeah. And explain this to your customer just like in a way that they really understand. Mr. Customer, cybersecurity is warfare, period. End of conversation. And today the US military does not go to war with muskets and cannons. There was a day when we did, and that was, you know, top-of-the-line arms in, in that day, right? Today we have stealth bombers and drones and really fancy technology. And guess what? There's going to be a day where I'm talking to you about AI as your security tool, and that day probably isn't that far away. So just understand that as the bad guy gets a cooler toy, I can't go after his stealth bomber with my musket, you know. I have to have the modern Tools of the day.

So let's pull the audience again then. How many of you feel like— or not feel— how many of you do have an established minimum that is either referenced in your MSA, documented in your MSA, or some other documented place that is very clearly articulated what the minimums are? I'd love to know yes or no. Robert, if I could ping you for some comments from chat. So you said yes, and I'm glad to hear that. And I know it might take some time to type in, and so we can wait for this and come back to it. But I'm curious to know, like, how you built that. You know, I think a lot of people want to know what is it. And I'm less interested in knowing what's in it and more about how you got there, you know, how you started building those things out, because I do think it's really important for us to establish those baselines.

Yeah, totally agree. And guesswork at first. This is where it starts, right? And then, you know, I would encourage all of you to go pick a framework, right? Whether it's CIS or NIST or whatever is appropriate for your industry. CIS IG1, right? There's a huge influence right there as Robert's typing it as I said it. We are not— this goes back to being defensible in court. Hey, Robert, where did you get your best practices, those things that you use to defend this customer? Oh, well, I learned them from some bald guy and some dude with glasses on the internet. That's not a defensible position, right? Gumball machine, equally indefensible position. The fact that I can say, hey, I use these industry guides, guidelines for my best practices. And we started at the bottom and worked our way up, and we only got through IG1 with this customer because we can't move a mountain in a day. But this is the best practice we were following, and my customer was looped in the whole way. That is a defensible position, right? I winged it and bought the latest shiny thing at a conference and deployed it thinking I was going to be safe is not the appropriate way to go about this. And I think in our careers, all of us may be a little guilty of that, me included. I bought me some ThreatLocker and went, hey, I'm going to go roll this out and my folks will be safer. They probably were, but I still was not in a defensible position. So let's just think about that as we talk through this baseline thing. Wes, you want to wrap it up and we'll move on to the next one?

Let's just wrap it up on Rafi's comment here. I think it's super insightful, this idea of safe harbor, right? And that is a financial concept that anyone deals with this understands. What am I doing the bare minimums to make sure that I have the safe harbor, the safe journey into knowing that I've done the minimums, the negligence thing isn't going to come up. I'm not going to be legally responsible, right? Haven't done a great job in security of defining safe harbor in most industries, but Rafi's exactly right.

That's, that's starting to come up in our industry, right? There are some states that have, that have applied state-level legislation that says if you're following CIS guidelines, um, then you as an MSP have some, some safe harbor, uh, that your customer may have some safe harbor, uh, and not be able to be sued by their customers if they lose data or things like that. So this is starting to come up. It's starting to be a thing, at least in state legislation. Legislation. Don't wait for federal legislation. They will never get there. But follow your insurance company's guidelines and pay attention to what your state is doing that's different or what the state that your customer is in is doing that may be different, right? Because you may have customers out of state for you. All right. Let's jump in and take a look at— this is a logical kind of leap into compliance requirements, right? So we're going to roll out something like CIS Implementation Group 1 for, for a bunch of our customers, for ourselves internally. We're going to start to build up to this, but then we're going to have clients clients. And I mentioned this, I worked with some medical clients, I had a mental health client who was my largest client, I worked with them for 16 and a half years, the whole time I owned my MSP. And they had to be HIPAA compliant. We're hearing more and more clients who have to be CMMC compliant and things like that. So Wes Spencer, compliance comes up and you come out of the banking world originally. So compliance is probably in your blood. What do you think of when you think about onboarding a new customer and having this conversation about whether or not they're up to speed. Most clients probably are not. And what the conversation looks like today to set up the journey for the next 6 months, 12 months, 2 years, however long this relationship is going to happen.

You know, there's— we could talk for a long time on this. So let me kind of get to some succinct statements here. First of all, compliance, of course, is both your sword and shield. It should be this way, right? It is your sword to carve out, hey, there's some things that we need to be doing to put in in place that we just have to do. You don't have an option. It's our shield to go to Rafi's point about defensibility. We've done the right things and the minimums. The challenge, I think, comes twofold. First, for the MSP, are we really an expert in that world of compliance for the client we're negotiating, working with? That's the reality you got to ask yourself. Do you truly understand it? You'll know that you understand it when you can really communicate it well, when you can document it, we can trace your controls that you're putting in place and your risk assessments that are directly tied to it. You'll know that you you know it well when you start having those motions and it feels like it's been a well-oiled machine. The second challenge though, I think comes in place, and let's take FTC safeguards as an example of this. What happens when you talk to a client and they say, that's cool that you said that to me, but I'm just gonna go run my business, so see you later. CMMC.

Nobody's ever been sued for HIPAA. I'm good till they come after my money.

Yeah, exactly. And you're like, uh, that actually—

No dentist has ever said that to anybody in this room, right?

Yep. Yep. Or CMMC. Great example. I can't tell you how many folks I hear, you say, it's cool that you say this thing, but it's not for me, dog. I'm just not gonna do it. Sorry. Maybe if I get, you know, some kind of mandated requirement that comes in for my prime and they actually gonna find me or like, you know, give me a cease and desist or like a show cause and they're gonna actually stop the contract.

Maybe they're my contractor.

But the reality is most of them call the bluff and they say, yeah, no, I'm the only guy that makes this in the entire country. So just not gonna do it until I'm forced. I'm gonna call your bluff. Right. So that's a reality. And the workshop that we just did with 7 Figure SP a couple of weeks ago, we dealt with this with FTC safeguards. How do you handle a conversation like that? So I think part of it is at the end of the day, I cannot get a client to move on something if they choose not to. They're the ones that sign the checks and they're the ones that, that deal with this. And so I think part of this is understanding, confidently knowing the regulations, confidently knowing what they need to do, confidently showing them their gaps and where they need to go with this. But at the end of the day, when the metal hits the meat, Alex, what are you going to do when the client says, no, not going to take— I'm not going to do this.

That same 7 Figure MSP group, we did a really interesting exercise with them a year or so ago where we literally had them sit down with their— with a couple of columns on a spreadsheet and say, hey, this is a thing that my client— that, that I'm responsible for, this is a thing that my client's responsible for, and this is the thing that we have some shared responsibility for. And we stepped away from it. A bunch of stuff was in that my client owns this column. And I just asked one question and the room was dead And I said, how many of you think that your client understands how much of security they actually own? And the room was just silent because everybody went, holy crap, no, my clients think I own all that, right? And so this is where we start to have that conversation to say, hey, Mr. Customer, here's, here is who owns these things. You can buy a product from me. But if you, if you, number one, or you can choose not to, but if you buy a product from me, that doesn't, that's not where security ends. Security ends with you having the culture to use the product and not try and bypass it, not try and find workarounds for it. You know, I can sell you the most secure file storage gizmo widget thing, whatever. And if your, your employee decides to just email themselves files at home and go work on them from home, then my, my widget thing is no longer secure and taken care of your network, right? And so this has to become a culture of security. Compliance has to be part of that culture of security. And implementation only goes so far as the user and the employee and the, and the, the actual end, end data point and making sure that we keep those in compliance. Yep. So I, I'd ask all of you just to think about that. How many of you, if she, as you go through your products, really believe that your customer knows how much of security security belongs to them.

And, and this goes full circle, doesn't it? All the way back to why the MSA has to protect ourselves from our clients. It's both a two-way street here.

Yep, 100%. Anything else on this, or we can, we can move forward?

Yeah, the last thing I'll just say is get good at risk assessing, get good at risk management. You know, a lot of times people like, yeah, but how? Like, how do How do I help them navigate the compliance requirements? Well, if you don't have a good risk assessment program in place, this is going to be difficult. If you have a really good one in place, let's just take FTC safeguards for a minute, right? If your risk assessment doesn't have good attention to detail on safeguarding customer information, you're going to have a hard time here. So now you have to think through, well, what does my risk assessment process look like? What are the tie-ins to the questions I'm asking when I'm doing the risk assessment? How does it tie into those regulations in particular? So you got to think about that. Make sure the flavor of that compliance requirement mandate comes down into your risk assessments. Otherwise you're going to have a hard time. So you can't just go online. Here's my point. You can't just go online and search default risk assessment IT and then download the first one. They might be helpful if you download 10 or 15 of those to really kind of figure this out. But you got, you got to make sure that it, it is relating to the, the requirements in hand. And, and sure, every one regulation is similar to another, but then again, there are differences in terms of safeguarding patient health information, safe regarding credit card information, PCI, payment information, customer information, banks, on and on.

CUI, etc., etc., etc., as we go through each of these, right? And so we're going to talk about 7-figure MSP just nonstop here, because the other, the other thing that they're really good at— Chris Weiser has this statement that he makes that he talks about the risk sandwich. And he just says, at the end of the day, who's going to eat the risk sandwich? And when you're onboarding a customer, you may have done a risk assessment as part of your pre-sales process to let them know where they stand. When you onboard the customer, you're deploying all these tools and you're really getting under the hood of their network. You're probably gonna find things you didn't know about, especially as it relates to some of these compliance requirements. You might find data somewhere you didn't even know existed. You might find users behaving in a way that you didn't know was a thing, right? Remote access or God knows what, BYOD or whatever. And what we're gonna find out is that now there's new risk that we uncovered to cover? And what happens if you know about that risk but you never tell your customer? And Chris talks about the risk sandwich. He's like, you don't want to get stuck owning the risk sandwich. Well, if I find risk when I'm, uh, uh, onboarding my customer, the first thing I want to do is take my risk sandwich, put it in a little brown paper lunch bag, and slide it across the counter and go, Mr. Customer, let's look at the risk assessment together. I want to show you the risk that you now own, and I want to pass it right back to you and make sure that you are aware, because I'm not going to get stuck holding it. And so this is where that risk assessment again is super powerful, and then it lets you go back to your customer and say, here's the risk that exists. Rafi brings up a great question, and we can unpack this here real quickly, but it might be a whole tabletop exercise conversation for another time. And Wes Spencer, you might steal this one to go unpack in your little education platform over there. But I'm wondering if you have, if you have to codify shared responsibility, just, just how exactly do you make that clear to the customer? What does it look like? And how do you, how do you spell out shared responsibility.

Yeah, I, I think we're— Rafi, I saw that quote too, by the way. I've been chatting back to everyone in, in chat, and then I realized I can only do host and panelists, so that's why I've been dark with you guys. I'm like adding laughing emojis. No, it's okay, don't, don't worry about fixing it. But I just realized that, um, yeah, so Rafi is exactly right. Um, I think the day is coming. We do need to have a shared responsibility matrix. I think we can steal from what the bigger guys like Amazon are doing. Like, we can still pass on some of the same things that they're not responsible for should, in a sense, be the same things that we are not responsible for as we shift shift downward, right? So things that we should be responsible for would be control effectiveness. You know, are we monitoring the controls that we say that we're monitoring, that you're paying for? But at the end of the day, you know, the client desire to make those changes, the client desire to, you know, buy into those things. You know, there's a number of things I think we should build into that. We could probably even steal from SOC 2, you know, some of the things that SOC 2s talk about that say sort of outside the scope of this, this report, there are probably some things that we can borrow in from that too. But yeah, I do think a shared responsibility matrix makes sense.

Yeah. Yep. Absolutely. And, you know, when you identify something that's shared, I think it's important not just to be able to say this is shared, but to actually spell that out and go document it for your customer and give them some sort of a, hey, this is the part of it that we own, and these are the things that are out of our control and fall back on you. So I would say, Rafi, and, you know, this is, this is the, the defensibility thing again, just document yourself into a position of responsibility. All right, communication and transparency. This is my favorite. You know, this is where we get to sit down with our customer and really kind of continue to build the trust that caused them to want to do business with us in the first place. This is, this is kind of one of my favorite topics because I spent a lot of time talking about what a good sales process looks like as an MSP, but also what good account management and CIO work and these things really look like as we have a conversation with our customer. So Wes, interested to hear your thoughts about, you know, communication, especially early on to help our customer understand not just security, but all the expectations that come with it.

Yeah, let's, let's talk about this. You know, I think there's, there's room for freedom here, but I think you also need to have that the freedom sort of combined with consistency and again baselining, you know, like what is that? So for example, let's say that, you know, you really move towards saying we're going to, we're going to shift our QBRs into this. So if your QBRs are currently, you know, dealing with how many printers ran out of ink and, you know, how many IT tickets were solved, you're missing the, you're missing the basics, right? Not the basics. You're missing the essential reason why the client wants to meet with you. They don't care about that data. You can give them—

you're missing the value prop, right?

That's what I meant to say. Yeah, that's the word I was going for, the value prop, right? Because the client's like, you can just email that to me later. Those are just numbers that I do care about, but ultimately I'm paying you for it, so I really don't want to have to worry about it. Really, in fact, I don't want you to even talk to me about it unless we're like way off the norm and you need to— we need to talk about why. So now that gives us the freedom to shift the conversation into something far different, right? And so again, if you don't have a good risk-driven relationship with the client, you're going to be stuck on this one because you're not going to have the things to be talking about in terms of a roadmap, in terms of best practices, in terms of alignment. You're not going to have those things. And So this, you can't jump ahead. Anybody that tells you, oh, you should have QBRs that are security aligned, you're talking high-level cybersecurity strategy, but they don't— we don't talk first of all about the roadmap to get there. You're going to be missing it. So, so if you have a good risk assessment process in place, the output of that risk-driven relationship should be what are some of the big things that we need to be working on? And what I would do is I'd begin to focus the output output of, here's what the risk assessment says, so what? And the so what is, hey, these are 3 major things that we need to get started on. We don't have a budget for them. I think it's going to be this level of complexity. Here's what this typically looks like for clients of your size. Here's what we think the timeline is going to take. Here's some of the resources that we're going to need from you. And ultimately, here's the budget. Can we do this now, or would it be better to wait a couple of months, 2 or 3 months? I'd love to know from you. It's, it's important. We got to get it going. But when is the best time for us to do this? So you see how you gone down this journey of being consultative, that's coming from a source of authority, from a risk-aligned approach, but then you're giving them the output of what they should do about it. And then the, the, the honesty and the transparency to say, when can we get this going? Because I respect you and your business, not just to shove it on you and say you've got to do it right now or all hell's going to break loose. That may happen, but largely that's how we have to approach it.

But the beauty of that budgeting approach that you're talking about is, number one, I get to call out surprises early, right? We can, we can start to show them when they're going to have to spend money next. Our customers are tired knock, knock, I need money, which is the typical IT guy approach. And really what we wanna give them is that, that consultative approach where we say, when does it make sense to address this risk? You used perfect language there. I love it. When did we make— when does it make sense to address this risk? Not, will you please buy my widget? Right? Those two feel like way different things. And, you know, I really wanna be that guy who comes in and has that higher-level conversation who, who does the consulting instead of the guy who they look at as the sales the sales guy, they don't want to come back to another meeting. So if you're hearing things like, you know, we don't really need to have a QBR, everything's okay. You probably didn't deliver value last time. I might turn around and say, Mr. Customer, instead of having a quarterly business review, we need to have a quarterly budget review. And you'll see if you don't get a little less pushback on your customer for showing up, right? And if they push back and say, Wes Spencer, everything's fine, we don't need to meet, then you just respond and say, no, No problem. I'll set your budget for 2024. And I just trust that you're willing to pay for everything that I set up. And I promise you, your customer will want to come back to the table. But, you know, when you're thinking about if something rises to the level of me, of coming to a QBR for that high-level, really strategic conversation, think about this. Is it the kind of conversation you want to have in the server room? Or is it the kind of conversation that you would have in the boardroom? Right? QBRs are boardroom conversations. They're high-level, they're strategic, they're for C-level executives. Executives. If you have internal IT, if you have a point of contact that wants that nerdy stuff, have a regular check-in and tell them, hey, once a week, once a month, once a quarter, whatever, we'll talk about SLAs and ticket levels and patch levels and backups and all that crap. But I don't need the CFO. I don't need half the board of directors. I don't need the CEO in that room. I can have that conversation with my point of contact. Right? And we can, we can just deliver that to the people who it's valuable enough to have their time. But this is the time to set the expectations of communication. During onboarding is when we say, this is how we're going to communicate with you. This is what we expect from you. We need you to show up every quarter to this strategic thing, and I need it not just to be my point of contact. I need it to be everyone with decision-making authority because I'm going to ask you to spend money. I'm going to explain to you where your risk lives. I'm going to show you what we need to do to make sure that we mitigate risk, and we're going to need decision makers in the room to make that happen. So I need your commitment, Mr. Customer, that every quarter you're going to be here for that. And service leadership actually has numbers that says that folks who put that out in the, in the onboarding and establish push it early are generally have 16 to 17% higher EBITDA than folks who don't. I'm sorry, 13% higher EBITDA, not 16, 13%. And along with that, along with the average MSP profitability, actually takes you to about 20% profitability in best-in-class. So, you know, Service Leadership actually has the numbers to back that up. So make sure that you're utilizing that and getting that out there early. If you haven't had that conversation with an existing customer, it's way harder to back into. It's a tougher conversation, but you still need to have it. And you can pick some of those same nuggets about, you know, establishing spend lines, you know, trend lines for spend and making sure that they're making the right cybersecurity decisions versus that low-value conversation and extracting that information and having it on a different conversation.

Yep. Last thing I want to slip in here is what establishes trust. We, we, you see that second bullet point. It, it, like, literally think about that objective. Objectively, how do we— what do we do? What do we say? How do we act to establish trust? You know, I think about, for example, why I might keep my CPA or fire my CPA. At the end of the day, do I really trust not that they're going to give me a great tax return, but they're really going to represent where I'm at to make sure I'm paying as little as possible, to make sure that I haven't missed anything that leads to an audit, that's really done a good job to really like— they care about me and my, my own finances, to, to take care of that and properly steward that. That's just one example. You could use that with any doctor. You could use that with a lawyer, anyone. That, that's where the, the trust relationship comes from. When they say in their mind, this person is representing my best interest. And so we have to think about if you like, we cannot convey trust when we're sticking at things like how many printers do we fix? That doesn't convey trust. That doesn't reflect that I'm here for your best interest. So yeah, I do really encourage you to think think that. And then I would also say dovetail that or offshoot that into that same conversation. If you're a business owner today, I challenge you, sit down with your VCOs, your account managers, those that are in, on the, in the trenches with your clients, and make sure you have consistency across the board with this. Make sure that we're consistently asking the right questions, we're presenting the right data, we're having the right strategic discussions, because you might come out of this webinar being like, yeah, cool, I got it, we're doing that. But are you sure? Are you sure all of your folks are doing that? You may be missing revenue if you're not. You're missing risk if you're not.

Yeah. And a couple of really good comments here. Stephen's talking about just the ability to use that budget as really the big forecasting tool that helps you understand your client's business. I had a client who brought in almost all of their revenue in the beginning of the summer and actually in the spring and summer. They were a retail store, a retail furniture store down the beach. I had to know when I didn't want to be anywhere near them, right? When they were in, in full swing, we couldn't touch anything. We couldn't move a printer. You know, they were, they were in retail Christmas and we left them alone. But I also knew that by actual Christmas, you know, through the holidays, they were dead. And when all my other customers wanted to be out of the office and didn't want to be bothered, I could do all my work at this customer and they would spend all their money because they had made all their money at retail Christmas and they could come back and spend it later. So understanding how your your client, how money moves through your client's organization, and when their, when their retail Christmas is, if they have one, really helps you lay out how to manage their stuff. When they see that you understand their business, that builds trust, right? That builds relationship. And those are the things that really work for you. And Keith's not wrong, right? The ability to strip out all the nerd words, to have a real conversation with your customer, way more valuable than going in talking about your new shiny widget that they, that they need to buy from you. So really great points from everybody there. That's awesome. All right, our favorite, the big boy, incident response planning. We only left 10 minutes for this one, so it's going to be, uh, there's a lot to unpack here. Wes, I'll let you take this one from, uh, let you start with this one. Um, what are we thinking as far as how does incident response planning play into onboarding, right? We're not there yet. We haven't had an incident. We, we, we just took over the keys to this customer, where do we start?

You know, I'd start with just for you as the MSP, how do you know you don't have an incident, right? You know, because if there is something actively active that's happening, um, or there's some amount of misconfiguration and you can actually tell that, you know, there's something that's— that smells off, it could be something as simple as you onboard this client, there's a whole bunch of email forwarding rules that seem like they're going off to weird places, you may have yourself in the middle of an incident. And so I think this is why it's important when we did that tabletop discussion and mentioned at the very beginning of this webinar with, with Huntress and Roberto helped and Chris Laird and others, that's why we introduced the whole sometimes these things happen before you ever finish onboarding a client. And so I think you do have to think about this from the very beginning. Now, you may work on an incident response plan with the client and sort of say like, like, hey, you know, over the next 3 months, now that we've kind of got your shields up and we've confirmed things are in place, we're going to start custom tailoring and building this. But I do think incident response has to be baked into the onboarding process because first of all, starting with your own shoes, like you should say in your incident response plan, here's what we're going to do, here's how we're going to handle this. Here's part of the delineating processes that we're going to have in place should an incident arise while we're onboarding you. Let me give you a case in point. Let's just make a vendor up, a vendor called Buntress, because I don't want to name names and play. Now I'll just call them Huntress. So let's say we onboard Huntress as part of our stack, let's say. Right. And so we onboard and we haven't finished the onboarding yet. But one of the things we tell them is here's the checklist of all the things have to be complete before we can push you into full managed service. Until then, we're going to be billing you for time and materials. And, you know, while we're doing this whole process and one of the things you've done is you've onboarded Huntress Hunter's in. Next day, Hunter's comes back with an alert saying, hey, we're seeing some outbound PowerShell. It's looking pretty suspicious. And looking at this, it looks like 3 machines are impacted. You need to pull them off the machines, off the network and go. Now you have an incident on your hands. So how do you handle that? Part of your checklist that should have been as part of what you're gathering from the client is do they have cyber insurance? Do, do we even have the ability to make a claim?

Do who— how do we contact that insurance provider? Right. I mean, that's at some point, the beginning of incident response is who do we call, right? Who are your critical vendors? Who are— who, who— where is the cyber liability vendor? Who is it? Who's that insurance carrier? Do we have the FBI phone number for their local, you know, for their locality documented? Do we know how to get in touch with the correct authorities and things like that? So part of this is just data collection. And that's a great place, I think, to start this conversation. Mr. Customer, in order to do proper incident response, we have to know all these people and all these things. So we need to collect all this, but here's how we might use that data in the future. God forbid we get to onboarding you and we find that something's already, already compromised or there were to be a compromise in the future.

So. Right. And the way that we can hand— we can sneak, we can steal a little bit from the way enterprise handles this is like, what kind of cybersecurity checklist do we have as part of acquisition, part of M&A? In a sense, as an MSP, we're at— we're operating almost like M&A. M&A, aren't we? Have you ever thought about that before? Like, your operations are— you're actually acquiring in their IT delivery and all the security of it. So I just posted a link from FR Secure. It's really darn good. It's the guys for this, and, and the, the, the thesis in their mind was specifically for M&A. So I don't think you have to use every piece of this checkmark list, but I promise you, go through that and they're going to be some things and they're like, oh, that's invaluable, we need to include this. And so yeah, I think what you need to do is, is understand what goes into the onboarding processes that are going to be specifically utilized in the middle of incident response. So you should be gathering things like who their cyber carrier is. You should know some of the regulatory requirements and who you would contact if some of those events happen. You should have some amount of a call tree and who's responsible for what. If they do have things like a business impact analysis and a starting risk assessment, it should go into all of these things, right? But I think what— that's the important part. You're not going to be able to have a fully fleshed out incident response plan, fully documented, probably during an onboarding session, unless they really want that as part of the engagement and you don't go Shields Up with them until that happens. But I do think you've got to have a strong attention to detail around part of our onboarding with them is going to be us being ready to help them handle an incident because it could happen now or in the next hour. So what would we do?

I think that's important. And the other thing to think about is, you know, what better— what more likely time for you to have an incident than when the other provider's peeling off all their security and yours isn't quite dialed in yet, right? You've rolled out your tools, but some of those tools go out in a monitoring-only mode until such time as you feel like you understand the landscape, and then you can turn them on. You know, there, there's going to be some overlap in there where things are just unsure. Onboardings are full of, of unsure. And Stephen brings up a great point, right? You know, where do we store these incident response plans and this insurance stuff. I'm a huge fan of offline, or at least off the network, right? Somewhere where we have access to this. God forbid the network is compromised. That means it shouldn't be stored on your network either, right? If it's in your critical infrastructure and you lose your, your RMM tool or your documentation tool, the last thing we want is to lose our documentation tool and then lose all of our incident response planning and everything else that goes with it. So just be careful where you put those things as well. Bad guys have been known to read your insurance policy and know exactly how much they can ask for, right? They know exactly how much ransom they can ask for. So your insurance policy probably shouldn't be out there in the network folder called liability insurance and incident response plan. They probably never do that. Never, never. They're very trustworthy, just like Santa Claus. Yes.

Speaking of Santa Claus, Dr. Keith made a great point there too, is I do agree that part of the— again, you've got to standardize your onboarding process of what this looks like. You probably need to add some things in. I think data flow diagramming and understanding some of that business flow, how you make money and how the money flows. We've talked about this. You've been on any webinar with me recently, you know, I've been on this trained for quite some time. I agree. I think those things need to be included because you're going to end up consulting some of those things if you realize an incident is hot and heavy right in front of you.

Yeah, yeah. I think that's a great place to end where we got 3 minutes left. So let's go ahead and wrap up. First off, we want you guys to check out what Wes is doing over at Empath because he's doing some really cool stuff. You know, Wes is, Wes is building out a really cool cybersecurity education platform. If you would like to go check out Empath, Empath. There's a coupon code flashing down there for you. I got to get on my PowerPoint guy because I'm not sure that is the right message, but, um, Dictator 50, right? That'll get you— yeah, we'll get him to chill out just a little bit. But, um, the, um, Dictator 50, this will get you 50% off your first month over at Empath. Um, I'm actually doing some work with Wes over at Empath now. Um, he just gave me the, the, the privilege of bringing some sales content into Empath. So yesterday was the first version of, or the first portion of a 5-stage sales workshop. So really cool. We had some really great feedback on that, but you've got really amazing content over there. I absolutely love it and I participate in it just as often as I can. And then, you know, if you want to, if you want to give us some ideas what we need to talk about either here or over at Empath, you can go hit Wes up on Empath and, or on LinkedIn and tell him what he needs to be putting content in Empath. To talk about. If you want Kyle and I to have other conversations here, ping me on LinkedIn, go connect with me, tell us what you need us to help you unpack and solve. I hope you got a ton of value out of Wes Spencer's and my conversations today. Wes, thank you so much for coming. You're one of my favorite humans in the space to talk to. You've always got an interesting spin to put on everything. How would you like to wrap us up today?

The way I like to always wrap up, which is, you know, take one thing that came out of this that was impactful to you and go work on it. You know, maybe it was just one thing, but go work on it. And I think that's how you can really begin this. And I would just probably encourage you, I'd start at your MSA, make sure you have the protections there. I'd probably begin with that. And then from there, I think you can follow a good framework-aligned journey, you know, some things like CIS to kind of understand what goes into the stack, what the minimum requirements are. I think you can actually trace this backwards from all the things we talked about to how to practically implement, because I know a lot of times in webinars we talk about things but not how to do things. And so those are some of the practical takeaways I think I would focus on first if I'm in your shoes.

Yeah. And I think, you know, the last thing I'll just leave us with is clear and open communication during your onboarding. Make sure that during your onboarding, you set a time every week to have a touch call with your customer to make sure that you have plenty of time for everything to come up. And there's lots of communication and touchpoints here. And then you continue those throughout the client relationship because we spend a lot of time during the sales process to build know, like, and trust so that a customer will do business with us. And then as MSPs, we, the phone starts to ring, things start to happen. We get a little panicked and, and we stop checking in with our customers because we're too busy dealing with the day-to-day and that know, like, and trust begins to erode a little bit. So make sure that we have clear and open communication all throughout the client journey and you'll just have a better experience with your customers. You'll have more raving fans and you'll get more referrals in your business. So I think that's where we'll leave it for today. Thanks everybody for coming. It was a great conversation today and Kyle and I'll be back in 2 weeks. I'm sure we have something to talk about, but I don't even know what it is. So we won't be pitching much in that one, but we'll see you guys back in 2 weeks.

Thanks, everyone.

Thanks, everybody.