(Part 2) Onboarding Best Practices and Cyber Risks Associated with Inheriting a New Client

All right. Welcome everybody. Andrew Morgan here live from Denver at the PAX eight event. And Eric and Phyllis are here with me, but they're in their hotel rooms. I'm in the John Strand back doors and breaches lab. We're about to kick this off in about a half hour, which is really exciting. Uh, we've got a, we're starting to get a room packed full of people. Um, we're gonna have, uh, up to 150 in here. Um, we were gonna have, um, it's pretty cool.

We're gonna have CrowdStrike, uh, encounters lab when we hit EDR and back doors and breaches. We've got virtual labs spun up with Metasploit and all sorts of fun stuff, Wes, where we're, uh, we're actually gonna have hands-on, uh, in all of these things. So it's gonna be really cool. Um, so I am going to be handing off the reins to Gary shortly as our moderator. We've got two awesome guests.

Um, I'll introduce them momentarily, but in just setting the stage again, last week, you know, we had a part one of onboarding and cyber risk, uh, involved with onboarding today. We looked at it in many different ways with two awesome MSPs. We looked at the cost of sale, uh, the risk involved. We talked about, we started a tertiary talk about legal, and that's why we have Eric on with us today.

Um, we also, uh, you know, Gary had some, you know, just feverishly jotting down notes on additional implications this would have on, on cost to a business. And so that's why we wanted to Ben, um, Ben Jones on today, who I'll introduce. So one thing I did put in as, as, uh, a URL up in chat, and I'll put it in again or those. So sometimes Crowdcast doesn't allow, yeah, they don't allow you.

But if you look up there, there's a, a recent article in Blue Blink computer, lesser known RMM, called Action one. Again, you know, think about it as you as an MSP inheriting a customer with another MSP, um, in this case action one, again, another legitimate RMM tool, Wes being used.

Uh, your EDR is not gonna pick it up fair because if it's OnPrem and, or sorry if it's used in your stack, uh, and then these threat actors are using it for, you know, persistence, uh, and, um, command and control and deploying, you know, malware or, you know, simply exfiltrating, uh, data until they want to do something about it. So, um, really interesting. Wess. Yeah, it's not changing. That one is interesting because it's legit software, right?

We've seen for years bad guys have leveraged legitimate free demo software. Um, it, and I know Phyllis, what you're thinking, I'm already reading into your brain. If you had a good handle on what your software is and installation of new software, um, that would be absolutely something I could detect and respond. Why did action one get installed on a machine that's super sketchy?

I think we talked about that years ago of like, if you ever have new RMM or any kind of remote access software installed that comes outta the blue, that's a red alert that is absolute red alert. Yeah, it's definitely gonna, you know, you gotta think, Gary. It's gotta be, you know, if I'm you at Kaseya or any vendor, right? With RM, it's gotta be thinking how to our, our, our demo practices, right? Have gotta change over time here. Fair. Like in three trials. Yeah. I, I, I would agree.

Look, this is a whole, this opens up so much. It seems Like we have some folks that are frozen. It looks like Eric and Gary are both frozen. No, no, all good on my side. Just sitting really still. Oh yeah, yeah. Go ahead. Gar. You were saying? No, This is just For me out here. He just done froze.

This just opens up so much, you know, and even what I was thinking, it's one thing, yeah, maybe it doesn't get picked up and, and now you have, you know, you got bad guys in your network, you don't know about it and you're looking for whatever it is they do. But when you talk, you mentioned data exfiltration, there's something you can do over time. You should be able to know what's happening.

But for most MSPs, that's not something that they're really looking out closely of, of what's being, you know, moved or, or downloaded. Like you can stay pretty under the radar, can't you Wes? No. Wes is reconnecting. Alright, so let's do some intros. I understand what I'm saying, right, Andrew. Hundred percent. A hundred percent. Yeah. And hey Andrew, before we do the intros, were you gonna put the poll question up? I'm sorry. You gonna put a poll question up today? Do I have one in there?

I think I do, right, Eric? Lemme do that. Alright, lemme put up the poll question. Uh, and let me do some intros and thank you everybody for bearing with me here. Poll question is avid. All right. We're getting close to 6,000 people. Nice. John, we've been on that s for a while. Yeah, we got the cyber call going. Well. Hello everybody. Yeah. Strange. I see some familiar faces there. Yeah, we're about to kick off the lab in a little bit. Mm-Hmm.

So, um, I'm gonna hand this over to Gary, make some intros and, and we'll be good to go, John, welcome on. Alright. Alright. You got work To do? I got work to do, yeah. All right. So, um, first off, Ben, uh, thanks so much for joining us. Um, really appreciate, always, always say yes. When asked to help out as a peer in this community, tell us a little about yourself, your company, and what you do there at Central.

Um, well, uh, at Central Technology Solutions, we, um, uh, started back in 2005, uh, when Tommy Yvonne, uh, purchased the company and turned it from a, uh, phone company into a, uh, an MSP. Um, I've been in it since my teenage years, so probably about 30 some years now. Um, You mean 20 20, 20 15 ish. Um, but I, um, I, I think I've done a little bit of everything, um, anywhere from a systems engineer, uh, a little bit of programming here and there. Um, but I've really, uh, latched onto security.

Um, I, uh, I love learning new things and, and in this industry you almost, you have to learn something new every day. So I, I've really enjoyed that. Yeah, you do a great job, man. I love the way you've dug into it and, uh, uh, Doug, what, what you've done over the last few years. Alright. And then, Eric, a lot of people, you know, you out there, but I appreciate you joining. This is a really important topic of legal and onboarding, so thanks for filling in.

For those that don't know you, please give a quick overview, if you would. Yeah, thanks for having me back. I am a, uh, an attorney. I've been practicing 25 years. Former MSP owner, um, built a, uh, sizable MSP in the Midwest, exited about 12 years ago. Um, and, uh, then served as general counsel to a, uh, multinational MSP. Um, today, I, uh, am still practicing law, uh, representing MSPs and, uh, organizations in the MSPs. Awesome. Alright, Gary, I'm gonna turn it over to you.

Um, I think what I'll do, um, I'll give it a shot. You think it's okay to just exit or, or I'll, I'll Yeah, do whatever you want. Just make sure you mute. 'cause we don't wanna sound Mute. I'm gonna mute and minimize. I'm gonna stay on, so, Good. Alright, Andrew, thanks a lot. Okay, so, um, I wanna start off, like I said, I, I, I sent Andrew a bunch of notes from last week.

Like it was a great call, and I think he covered a lot of 'em in the questions, but there was a couple that, um, you know, I, I was thinking about in terms of, you know, uh, well, Eric, here's the first one I'll ask you around, around onboarding, right? Yep. Um, there's definitely more liability. Now, everybody agreed to that.

We talked to Ryan Vestey from VC three, he almost looks at it as two different backlogs, and then he breaks the onboarding one down into two sections, critical security and the rest. So all of these things that try to shorten the timeframe and mitigate it. And so many times, you know, you get a new customer and then once you're deployed, you find out that there, there's already some compromise that are there. So I want to talk through with you some of the legal pieces of this.

And I, and I think like most things, some of it's legal in case of something bad, but the rest of it is expectation setting. So you can, you know, not kill a good relationship right from the beginning, right? Yeah, no doubt. It is both legal and expectation setting. And, and there's, I'd like to, if I could really take a 30,000 foot view here, there, there's two dates that, that are important here.

One is the date that the MSP signs, their contract signs, their managed services agreement with their customer, right? That's the important date. It gets it out of the sales funnel. It's all good, right? Yeah. The other date is, and, and call it what you want, I call it, and I stole this term from one of my clients, they call it a go live date, right? What is the date where all of your services are ready to be delivered to the customer? Which services?

All the services in your statement of work managed service agreement, whatever the document is that you call your services agreement, that is the date where you're ready to start performing the services. Now, where the problems arise are every day between the effective date of the agreements and the go live date, right? So, so what happens the way that I like to proceed is the MSP should not be responsible for anything that happens between the effective date and the go live date, right?

You should start this implementation well in advance of the prior MSP's contract expiration, such that on the go live date, you're ready to go. Why? Because exactly what you said, right? There's, there's vulnerabilities, there's bad things that happen. You know, three days after you, you sign the new contract, they have a ransomware attack, right? And you weren't providing backups because you haven't gotten to that phase in your implementation, right?

But you also have to consider things like the customer's responsibilities during that implementation phase. Um, you know, they have to cooperate that they absolutely have to cooperate. The prior MSP has to cooperate. All of that stuff needs to go in the contract itself, not in the kickoff meeting, not in your marketing materials, in the contract itself.

And then, you know, the, the other complicating factor is to, you know, to use Eric Woodard, you know, they, they use 66 tools to take care of their customers. Which ones of those tools have finite start and stop dates? Are you signing up for a new 36 month agreement with X, Y, Z tool provider, right? And when are you signing up? Are you signing up effective on the go live date or on the effective date?

And then what happens during the, the interim period and the final thing else, And when you're billing them, because right, we wanna bill them. Yeah, we wanna bill them as soon as possible. That's not an easy conversation. Like, listen, you're gonna pay, but we're not responsible. Well, and there's a couple ways that you can handle that. And, and the problem that I see is that MSPs don't bill a customer, right?

Until, uh, or until they go live, but they start the clock running on the effective date. So what happens? Well, if it takes you two months to onboard a customer, you've lost out on billing for two months because now you have a 34 month contract instead of a 36 month contract. So it's really, really important to, and, and by the way, the, you can, you can slice it and dice it many, many different ways, but you can use the implementation period.

A as, and, and, and I know this, this kind of goes counter to to, to what you sometimes say, Gary, you can use that implementation period and then not start billing until the go live date. Right? You still get your 36 months of billing out of it, your onboarding fee, whatever you charge them, which probably isn't enough if, uh, if, if most MSPs out there, like the contracts that I've seen, but that onboarding fee takes care of the implementation period.

And any expenses that you might have during that time, Hopefully it does. Right? And so some people, you know, uh, more mature sps, that fee is getting bigger and bigger. They don't see it as a sales roadblock, but other m MSPs, they do see it. So they tend to discount it, give it away. I know. And it's getting more and more expensive and they don't have it built in. Yeah.

You know, and, and you could be taking, you know, over three years, you could be taking a 65% agreement and taking it down to 58% before you walk in the door. Correct. You know what I Mean? Correct. And it's almost, I I, I was thinking, you know, and I'm gonna ask, um, Ben, this question later about whether you think this should be co customer acquisition cost or cogs. So we'll, we'll talk about that, you know, in, in a little bit.

Um, so the next thing I wanted to ask you, so we talked about go live day, who will everybody grab that? That's a really good nugget if you just got this out of it. Wes, that one nugget, you got your money's worth already. We, and we still got 45 minutes left.

Um, say you're an MSP losing a customer and have to work with another MSP, uh, that's coming in and they need account credentials, critical servers, the opposite of what you're saying, you know, your customer got bought by a PE company and they're going to their central. Talk about the other side of it, because you know, as the exiting MSP, you have risk. Yeah. You, you do.

And, and, and, and maybe even more risk than, than in the onboarding MSP, because when you're onboarding, there are fewer variables. Right. You know, what it takes to onboard a customer, a new MSP customer. When you're off boarding though, now you're dealing with unfortunately another MSP.

Um, and, and what happens, and, and I was just talking to a client of mine, um, late last week about this, you know, where they had a customer, um, who was leaving them, they were actually bought, like you said, it wasn't by pe but they were bought by somebody else. Um, and then they got a note from the customer saying, Hey, will you turn over all the admin passwords to the new MSP? Right.

While they're still obligated to provide managed services for the next six weeks or whatever the, the length of time was. So a again, and, and I know I sound like a broken record, but it goes to, to what's in your contract. And if your contract isn't clear about onboarding and everything that happens during the onboarding process, it's not too late to make it clear. Right. There's nothing wrong with telling a customer No, no, Mr.

Customer, I'm not gonna give you my ad your your admin passwords because of X, Y, and Z. Look at all the bad things that can happen. And all the finger pointing exercises that'll come of it. If we turn over admin passwords and something bad happens, it's just too hard and too expensive to try to figure out exactly what happened.

So, But if I'm your, but if I'm an, if I'm a customer and both of the MSPs, the one coming in and leaving are both your customer, Eric, neither of 'em want responsibility during that time period. Exactly. Exactly. But then, then it goes back to what does the contract say? And if the contract doesn't say, then what does the amendment to the contract say about onboarding?

In other words, I'm perfectly, if I, if I'm the outgoing MSP, I'm perfectly happy turning over your admin passwords, but only if you sign a hold harmless agreement and an indemnification agreement and everything else whereby if something bad happens, I'm not responsible. Yeah. Right. Why should I be responsible if someone else has the keys to the kingdom? Um, so, so again, it just all goes back to, to what your contracts say.

And again, if they don't say what they need to say, it's not too late, go back to the customer. If they really want those admin passwords and say, okay, I'll turn 'em over, but you have to do X, Y, and Z. You know, I think this is conversations that need to be part of your pro early on talking to a prospect, Hey, assuming we get down the line, let me have you thought about these things and use it as a competitive advantage.

The other MSP you're talking to, have they had this conversation with you? Right. Right. So all of these things that we learn and do better, we can use, you know, as ammunition and ways to create separation in the sales process. I had one more question for you, Eric, then I have a couple for Ben, and we're gonna move to, uh, well, the fillage, if she comes back. If not, it'll be me and, uh, Wes. Yeah.

Um, but I wanna ask you about those conversations with new customer about shared, not just shared risk, but shared responsibility. And one example is, you know, you're telling 'em they have to have MFA, but they have to be there and enforce it and be So talk to me about that idea of a shared, that shared concept. Yeah. And, and, and that's a great question. And you know, I look at, and I write, and I, and I, I redraft a lot of managed services agreements for my clients clients.

And when I first get ahold of 'em, most MSPs out there are, are decent about telling their customers what they're gonna do for them. Right? They say, we're gonna do this, we're gonna do that, we're gonna do the other thing. Right? Unfortunately, that's where it stops. Right? And, and there are two more big components to a, a managed services agreement that are usually missing or at least deficient. One of those is, what are you not doing right?

What am I, what are you not gonna do for the customer from a managed services perspective? What could you do if they wanna pay you on a time materials basis, but what's not included? And the third piece that I rarely see in a managed services agreement is, to your point, what's the customer responsible for?

In, in, in this relationship, there are two parties, yes, the MSP is delivering the service, but in order for it to be successful, in order to, in order for it to go as expected, the customer has to have some responsibility. They have to have some skin in the game.

And again, it can't be something that you talk about in your introductory meeting, and it shouldn't be something that, that, that waits until you put the contract in front of them, you should be talking to them about it well in advance of the contract. And you gotta write it down.

It's gotta be part of the contract that way, in the unfortunate circumstance, and it happens all the time where the customer isn't meeting their shared responsibility, then it'll dictate some, some outcomes that, that are, are more favorable to the MSP than if they don't have those things in there.

You know, the other note I made from last week is based on all this conversation, and maybe this would be a good transition over to Ben before I ask you the, the first question, you know, like, is there a certain, well, this is rhetorical. 'cause the answer is yes, there's gotta be for every MSPA certain minimum MRR amount, like we'll deal with any customer, but they got, if they're not gonna spend, you know, 3000 a month or 4,000 a month, can you manage all of this?

Ben, do, do you, do you know what I'm saying? Like, there's so much now and it's not that much different of all the things we have to think about for a 15 user customer than a 30 user customer. Yeah, I agree. Um, I think our minimum is around, um, 10 endpoints.

Um, we're trying to get more into kind of the a la carte, um, situation so that, you know, we come to a customer and say that, you know, that they, uh, they already have an IT department or something, you know, can we sell them something that, you know, they can use to protect their email? And along with that comes the management fee. Um, so we're trying to be flexible. 'cause we know there's just a lot of companies out there that do have their own IT departments as well.

Um, or that work with an MSP that's just not capable of supporting everything in that 60 some, um, toolbox. Yeah, I mean, listen, we're having these conversations mainly talking about a traditional full fix fee. But co-managed is the biggest growing sector of revenue. And Eric, I'll just pop back for one second to you. That opens up a whole nother can of worms. Yeah. Co co-managed is a, is a whole nother Yeah.

Co-manage is a whole nother candle worms, especially with the shared responsibilities. Um, but, but I did wanna chime in just on the last question that, that you asked Ben about the minimums, because it's, it's important to not just think about contractual minimums going into the deal.

Think about month two and month three and month 35, because again, most MSP managed services contracts that I see, they say, well, look, we're gonna true up your users every month and we're gonna charge you for the actual usage. Well, what if you've just signed a 36 month agreement and your customer for some reason, wants to get out and you just sign this brand spanking new 75 seat deal that that's a great deal for you?

And what if they call you up the next month and say, well, now we just want you to manage one seat and it's the office manager. Right? Does your contract allow that? The vast majority of MSP contracts that I see do allow that. So yeah, you essentially can allow an implied termination for convenience just by not being explicit about the minimum number of users throughout the entire agreement, not just when you're, you're onboarding them.

So back to, back to the, the shared services and co-manage it's, it, it's, it's a lot more complicated with a co-managed deal than saying, well, we're not gonna provide level one support. You know, we're not gonna support users. That's, that's, that's internal. There's so much more to it and to, to make it successful because there's a ton of risk that's involved when, uh, you're, you're, when you aren't wholly responsible for the success of the environment. Yeah.

Um, so then at, at snoozefest, we asked five or 600, you know, MSPs to raise their hand if they were using MDR, and we were surprised at the small percentage. Why do you think that is? And how does your organization look at the need for third party eyes on glass? Um, I think the main reason that, that that number was low is that, um, it's like you said, just the amount of tools that we're having to support, um, and having to put in our stack.

Um, it, well, like I said, it went from like two or three to, to 60 in a couple of years. Um, and so with those tools comes, you know, the budget and everything. So we're trying not to come to our customers and, and saying, you know, okay, well now we have to have this tool and this tool and this tool. So a lot of MSPs are just throwing that in there saying they need to be protected. If they're not protected, you know, we're gonna get in trouble because they think that we're doing everything.

Um, so honestly, I think it's, it comes down to price. Um, and, and managing those tools. Um, Yeah, Our, ourselves, you know, we, if we do see a product and we're saying, okay, they need this, um, we're not gonna go to the customer. We're gonna put this on there and we're gonna talk to them, um, next business review. And that's where, um, we're trying to do the a la carte thing and have a more, a automation automated process that updates those numbers.

You know, so if a customer does go from this number to that number, uh, you know, that we're not trying to constantly manage that. Yeah. A absolute, absolutely. Uh, Phyllis, I'm gonna hand it over to you. Okay, great. Thanks. Sorry, I was just paying attention to, I'm just so fascinated, um, by this topic. Um, so Ben, I wanna follow up with you. Um, so has your MSP implemented policies with clients around account management, which is of course CIS control five.

Um, because as their service provider, um, we need to pay be taken into consideration. And the reality is, your client is more than likely going to be asked by their customer or their customer's customer to provide how this process is handled, um, when they're being audited. Um, we do try to keep a very close eye on that. Um, I think as MSPs, we're kind of the last people to know when accounts are being changed or people are being, you know, let go or whatnot.

Um, so we do have a couple of, um, tools in place that do monitor for age of accounts, and we reach out to the customer and try to be, um, I hate to say proactive, but it's almost a little reactive. 'cause you know, the, the person's already gone. So, um, but we do try to reach out and keep tabs on everything. Um, as far as account management is concerned, I mean, I have a question as an MSP, I mean, can you require your customers to tell you that?

Like, how, how does that work since you would be liable, right? So if there were a breach based on the fact that there is a dangling account, credentials are compromised, can you somehow manage that? I don't know that MSPs, that we have the authority to say, you know, you have to do this. Mm-Hmm. Um, I think we can encourage them. I think it's very similar to security awareness.

You know, we, we can provide it all along with say, you need to do this, you need to do this, you know, this is gonna help you. But it it, in the end, it, I think it does come down to defining customer responsibilities. Like Eric said, Eric, you're gonna jump in on that. I can tell. Yeah, I was, I was jumping up the bit, you can absolutely require that from your customers, right? And just like we talked about a few minutes ago, customer responsibilities, right?

What is the customer responsible for to make this a, a, a, a successful engagement? Right? And, and if you need to know as an MSP, within 24 hours of them offboarding an employee or, or onboarding employee, whatever it is, put it in your customer responsibilities. If they don't do it, they're in breach. Their hands won't be clean. And if something bad happens because of it, then it, it'll, it should absolve you from risk.

And Eric, I wanted to, we Can do it right, but we can make him responsible for it, Eric, now, no Doubt. I wanted to jump into that a bit more. Even. What about Misconfigurations? What about risks for, um, may maybe the, like the MSA doesn't dictate how the channel of, of how we actually request what needs to be done. So it's a phone call to like one tech, and then the tech doesn't do this. Correct.

You, you, now you have a problem on your hands of, um, you know, even, uh, e and o kinds of issues, right? 'cause something's been misconfigured that has to be con calculated. Yeah. And, and actually along along those lines, Wes, what I've started to do actually somewhat recently in my managed services agreements is, you know, again, every MS. P says, you know, you can call me at this number or go online and here's my portal, or send me an email. Right?

But there are certain things that happen or that can happen where I need you, Mr. Customer, to both call me and send a, a, a notice through the portal or call your executive, your account exec and send them an email. And you can dictate certain things that they have to do, certain methods of communication they have to use in certain situations. You know, an an easy one is a P one ticket, right? If your site is down, don't just leave a voicemail, right?

If your site's down, you should be, you should be using the portal, using email and wait until you talk to someone on the phone. Um, so, so I've started recently writing those types of things into managed services agreements for that very reason, right? Things will go wrong. The MSP didn't know about it for whatever reason. Um, so just trying to mitigate that risk. That's awesome. You know, that reminds me of what I really liked.

What, um, during last year's conversation, last week's conversation where you said, you know, have your guiding principles, figure out what you're willing to accept and what you're not willing to accept. And when you onboard a client, and let's say they say, no, I'm not gonna do that. That's not a part of, um, my process. Be strong enough to be able to walk away, as Gary always says, like, you're just not telling the right story. Yeah. Right. You, you can get these things done.

You can charge for all these things. So, um, you know, I love the message, And, and also, and Phyllis just one step further, it's how you train a customer of what your relationship is like. If they're used to knowing that what you say there's a reason for it, everything seems to go smooth. Once you're letting them make every choice or backing off, then they run rough shot over you. That's interesting. Train your customer on what to expect, right? Mm-Hmm.

Train your customer on what the relationship is supposed to be. That's, I really like that. That's really interesting. Um, okay, so Ben, um, you know, we're talking about account management, of course, you know, MFA, everyone talks about MFA as the number one thing you can do, um, to defend, um, against compromises.

We have statistics from cis a, um, at, at the enterprise and SaaS alerts at the MSP level, both suggest that only around 32% of organizations, um, fully implemented for the Microsoft stack. So what's going to change that? And is this a, we will walk if a potential customer won't implement MFA? You know, we're just talking about all of this. Um, we've actually used SaaS alerts.

Uh, they have a report that shows, you know, all the different IP addresses that have attacked your individual accounts. Um, we usually pick like 30 days, and most of the globe is have little red dots, and they're almost all of it's red. Um, so we've used education to, to really encourage people to say, you know, you're not too small, um, to be attacked. Um, these people right here would love to get into your accounts and love to get into your clients.

Um, and I think out of all of our clients, I think 80 to 90% just said, turn it on right now, right? Like today we're, we're going for it. Um, and the other ones, we've, we've had to, we've had to look at them and say, okay, so if they're not willing to do MFA, which is really a, a basic step and, and, and easy to set up, you know, I don't think they're gonna be a good fit for us, um, because they're not concerned about even the most basic of security.

So they're not gonna go with advanced security. They're not gonna, you know, look at Zero Trust or any of the other technologies that we can put in place. So I think you have to walk for your own safety. And, and I think also, you know, it serves as a wedge, doesn't it?

I remember at, um, uh, IT Nation Secure last week, Eric Woodard, when he was telling his story, he said, you know, in the, he had a local competitor that would come by, go to his clients and pop in net stat and be like, look at all these bad guys that are in your network. And I mean, it's just total cringe moment.

But I think you can use some of those best practices and configuration standards to say, not only is it the right thing to do, but I use that as a wedge defensively to know that I built out best practice. So I can't have someone come in as a competitor and say, look, I can do all this cheaper, and you didn't have this set up and that set up and this done this way. Right? Um, so I think it's useful in that way too.

So you, you kind of already answered the next question, so I'm gonna like, follow up in a, in a different way. So, um, you know, I I think it's great. You're like MFA everywhere, and then if not, it's up, you know, you are willing to walk away. Um, so is there kind of a, I would call it like a tear line. When you talk about MFA everywhere, do you say only on external components, like, you know, kind of externally facing, um, um, applications.

Do you think MFA everywhere, like where do you draw the line as an MSP and how do you explain that to your customer? Um, I think it comes down to, um, uh, I think just education and showing them the benefits of MFA. Um, it's easier for us to enforce that on the products like, you know, office and, and Salesforce and stuff.

But, um, in the end, it's just really about teaching the, the person that you're working with, you know, good practice, have them be an advocate for you and say, this protected me. Even if it's something as basic as putting an MFA on your Facebook account, um, that can, you know, really get speak volumes to how well it does protect you. Um, but we do, we do what we can as far as, you know, just teaching people the best practice. It's really up to them to, to enforce it.

I hate to be the bearer of reality all the time, but if you think about two factors, one is, and I'm not talking about authentication, uh, but if you talk about two factors, the first is that half of msp statistically after true owner salary or at or below break even, it's hard to walk away from any customer no matter how crappy they are. Like that's the reality of it.

And two, sometimes these customers to push back on you, the ones that where the tail wags the dog are your biggest customers, they're the ones that are 3, 5, 8, 10, 15% of your business. And so we can't get away sometimes from the fact that we have to change the way we push back and manage accounts. 'cause we don't always have the convenience of, of just firing them.

Would you say, could you stage it and be like, well, at least on your external facing apps, let's use MFA and then like slowly migrate, kind of then increase it. Do you know what I mean? Like, do you have enough, um, do you have enough knowledge to understand their exposure? And then maybe you could stage it out that way Yeah. And take responsibility for how you got there. It's not the customer's fault, it's your fault. I think that's where it starts. Would you agree with that, Ben?

Like we just didn't explain things to them e either in pre-sale or in the time they've been a customer in a way that they could understand their risk. Yeah.

And getting in front of them and just explaining it to them, you know, sometimes you have face-to face is much better than, you know, sending just a random video that MFA's important and, you know, but, you know, show them, show them examples of, of real life problems that other companies have experienced because they didn't have the basic, uh, you know, MFA installed, you know, reference, you know, even like the pipeline, you know, the, the reasoning that there was no MFA as VPN, you know, hacker got in from easy password.

Um, just show them that it can happen. Yeah. Just a funny story this morning in the, um, in one of the talks here at p PAX eight, one of the panel members was like, how many people have heard MFA for everyone at EP c-suite? Because it's too much for them to, to, you know, to implement that, you know, except The people that need it most. Yeah, Right. Say that They'll fire you first. Yeah, right. Exactly. Alright. Right. Lemme pass it off to you, Wes. All right.

So, uh, something Eric that's been in my mind a little bit is, you know, this shift towards, you know, this zen of zero trust, right? Where identity becomes all important and a compromise of identity leads to loss of data, it leads to compromise of that data. It leads to all kinds of issues. How in the heck do you design an MSA to protect you as the MSP around your identity and the use of that identity?

In other words, how do, do you, how do you describe away your responsibility of that client being stupid with like, what they signed their SSO into what they owe off and give away all their email to, like, those are things that I think by default, I don't think clients are like that. They, I think they point their finger by default, BMS being say, that's your fault. That data got stolen. You host it for me, you support it for me even though I gave it away. So how do you, how do you handle that?

So, so SaaS companies and software companies have been this for a while, right? And, and what they say to their, their customers is, look, we're gonna give you the credentials to access our stuff, but you're responsible for those credentials. You're responsible for who you give those credentials to. You're responsible if those credentials are lost. You're responsible if someone leaves your company and they still have their credentials, right? Those are all your responsibilities.

So we're starting to see that migration into the MSP world because it's the same thing, right? It's we're giving them credentials to use the things that we are providing for them, but we don't have control over those credentials. So, so software companies have been good at that for a really, really long time.

And we're starting to see that trickle down into the MSP world And the lack of that can that lead to, I guess that really can lead to, um, issues around litigation or any other kind of, like, if we're not doing those things, I think that's really important to make sure that we tuck up our MSP in light of this world of cloud. And I, I don't know how much we've given a fresh look any el anything else.

I know I'm putting you on the spot, Eric, but anything else that stands out to your brain in terms of like areas or MSA needs some, some review in this age of SaaS, everything. Yeah. And, and it's hard. And, and I'll give you a real world example. Something that came up last week where a, a client of mine, a good size, MSP, um, they have a client with US operations and Australian operations, and they use a shared 365 instance for, for both of those operations.

Well, of course, what happens, well, they wanna sell their Australian entity and, and the whoever they sold their Australian entity to wants to bring in their own MSP, right? So the, these are things that we've never had to think about before. Um, you know, in, in terms of, all right, I'm gonna bring in a new MSP, the only way that I can, that we can allow them to manage their own customers 365 instance is to give them access to my customers 365 instance.

So, you know, again, it goes, it goes back to the fact that, that that MSAs and, and, you know, statements of work and things like that are not immutable, right? If you come across a situation where your agreements don't cover whatever it is that your customer is asking you to do, then stop talk to your attorney and figure out how to fix it, right? Don't just do it because your customer asks you to do it.

I understand that we wanna help our customers, we wanna be customer friendly, all that stuff. But if it's gonna add undue risk to us, if it's gonna let another MSP into a 365 instance that I'm managing, um, I think that's just crazy without something else that, that, that protects you. So, so yeah, the, the, the SaaS is, is certainly adding a, a complexity that that just simply wasn't contemplated, you know, pick a number years ago That, you know, what that m and a point is great.

I don't know that anybody gets through a year without some m and a in their customer base. Yeah, No doubt. And it's the number one reason that that MSPs lose customers, I think, And gain, Yeah. And gain, no doubt. Yeah. So Ben, I guess that question over to you then, um, I'd love to, just from the practical boots on the ground side of the house, right? How are you guys dealing with SAS and communicating client responsibility around their usage of it and their abuse of it?

Um, that's a great question. I've actually taken a couple of notes from, from Eric, uh, about just, uh, setting expectations as far as, you know, who is responsible for what. Um, thankfully most of our customers, um, they've, they've been of the opinion of, of, you know, we've, we're paying you to do the, to do this. So we're not really jumping too much into, um, getting access to, to systems like that. So we've been fortunate. Yeah, totally fair.

Um, I was having the same conversation with John Harden at Secure last week, and, and I was just asking him how things going for you guys? And he's like, you know, the area that we're seeing a lot of growth towards is, you know, this shadow it, you know, that's the term that we use a lot of times for like, how are our users lurking around all this stuff that we don't have our hands on and we're not aware of?

And he is like, you know, we've seen a lot of growth around this where like MSPs are introducing shadow IT monitoring for their clients because they have to, and, and actually the way they leverage this, and Gary, I'm curious to hear what you think about this. The way they leverage this is you'll fail if you go into the client conversation being like, well, we need to bill you for shadow it.

And the client's thinking, why should I pay you yet more for something that we're doing on our own to do business? I think the actual conversation needs to be around, Hey, did you know you guys have some risk of like a lot of your data being leaked out in places like Dropbox? And could you imagine the kind of litigation that you might have when that data gets leaked as a law firm, as a CPA firm, whatever it may be.

And, and, and you had some users just doing what they did and they had it on their iPad and it, they, you know, it was open up for everybody. Like, that could be stuff that's gonna really cause you problems. You probably got sprawl everywhere. And we need to monitor for that. That's not free. I think this world of like shadow IT monitoring is big. Gary, can you unpack that a bit? Yeah, a hundred percent.

And if something was to happen and we're not doing it, then that falls outside of our responsibility. Like you're kind of left out there on your own. And I don't, I can't tell you what happens with insurance. Like I'm not an ex, I'm not the expert to tell you on that. Yeah. Uh, I just, you know, play one on, you know, on tv. So I, but see the way that you approach that was, rather than telling them, Hey, we're gonna charge you for something more. Hey, here's the risk you have.

Here's what's involved with us, the cost for us to mitigate that risk, what would you like to do? And here's the consequences of that risk. Just so you know, here's what we're responsible for, here's what you're responsible for. So you're fully responsible for that. And, and I just think folks that are listening today, this is becoming more and more important.

Um, all of these SaaS apps that we use today, like, I was playing with a couple of these AI ones this morning and exploring some stuff, and all of 'em are like, click to get sign up. I pushed the button. There's no account creation. It's literally just SSO from Google or Microsoft. And off I go. And while that is like, is pain free and easy to use as possible, it's ridiculously scary to me as the security person of how we've made the doors open for our employees.

Just step through this, step through this. Everything's easy to get into and we gotta watch out for that, because those are things I think, again, in the MSA, Eric, as you point to, and then even practically as the MSP builds for the monitoring of this, it's, it's too important to ignore.

Um, Eric, any, I don't, again, I'm putting you on the spot here, but any stories, any conversations that you've had with clients or, or, or others where this, like this whole world of just open door of SaaS and accounts and signing into everything is just becoming a, a nightmare? Yeah. And, and, and, and, and I have conversations with my clients all the time about that.

And I, and I can't share the really, really scary stories, but, you know, I can tell you that, that it, that it does it, it does come up. But it all goes back to the, the three tenets of your, your agreements with your customers. You know, what do you do, what do you not do? And what are they responsible for to make it a successful relationship? And if you have all those in place and, and again, tomorrow there's gonna be something different. There just is. Right?

Just like we're seeing things that are different than, than they were yesterday. Um, but if you can start with a good agreement, and I tell my clients all this, this all the time, right? I can come up with a contract that mitigates 100% of the risk in their business, right? But, but they're not gonna be able to do any business. 'cause no one's gonna sign those contracts. So it, it's a matter of what is the risk that the SP is willing to take?

Um, how much risk is the MSP willing to take and drafting agreements appropriately? Okay, that's good. Let, let's get back to onboarding a little bit. I know Gary asked the question to you, Ben, earlier of like the minimum thresholds, and you kind of said 15 seats is about the minimum for us, but less, my guess my question is less about the seats and more just about how you guys go about that onboarding that's led you to the 15 minimum.

Like, do you guys have, one of the questions we asked last week, uh, to a few of our folks was like, do you have checklists that you go through? Like how, how do you standardize that process of onboarding to where not only do you know it's a 15 seat minimum to be, you know, to, to survive, but also just to make sure that you're doing onboarding consistently and correct. Give us some, some thoughts on how you guys handle that.

Um, so for us, we have kind of, we put that as a minimum just because, um, sometimes we find that, you know, the smaller organizations use a lot more, you know, help desk and, and everything that than some of the bigger guys. Um, and so we just, we found that to be kind of our, you know, our bare minimum start number. We don't want to get too many clients that are just like, you know, small office or something because they can eat up a lot of our, a lot of our time there.

But as far as, um, you know, our standards, we've come up with, you know, what we call like the CTS way, uh, which is just kind of a list of basic security standards that they have to meet too. And we find that typically around that number, um, and above are able to actually invest into those security features. Okay. Yeah. Uh, that, that's good. I, I think this is something that we've gotta visit, right? And you can't approach onboarding, um, you know, willy-nilly.

The more process you drive into that, the more automation you drive into onboarding the, the less room for accidental configuration, uh, errors. And, and, and c Phyllis, I'll even point to you, CIS talks about this, don't you in best practices both around configuration standards, both around, um, you know, onboarding least privilege. These are things that are built into the CIS control framework.

And if you're not going through those things and you haven't built that into your MS P, not only your not framework aligned, but you're introducing in a lot of risk that comes through onboarding. Yeah, I agree. I mean the, these are basic things that really should be in your policies. Mm-Hmm. Quite honestly.

Um, when, when you're just thinking about accounts, when you're just thinking about, you know, all these things, but you Know, It's always like that one of all those, um, all No, I was gonna say, sorry, go ahead.

You know, Wes, we're talking so much about onboarding, but what I see is, and this is the reason why we have to charge enough to people, not just for onboarding, but what we charge 'em each month because it's not, listen, if you do all this work and the day you finish onboarding is the most secure there're ever gonna be. It's a problem. 'cause everything we're looking to align in onboarding needs to stay in alignment.

So if our user onboarding or offboarding, if the way we create account, if all of these things are not tight and we don't have some mechanism, you know, and I've been preaching technology alignment now for, you know, 15 years, alignment, compliance, governance, whatever you want term you want to use.

But if you're not building in roles in process to do that over time, then it just starts to drift on day one and in three months they're less secure and in six months they're less secure until something goes wrong. We've seen this happen with like, uh, security awareness.

You know, they start out really strong, everybody's taking the courses a couple months later, less people are taking the courses, phishing simulations are getting through and you know, you know, a year down the road, it's like nobody's taking the courses. All the phishing simulation is successful. Great example.

And we've, We've yet to figure out, like, other than getting in front of them and actually talking to 'em in person, um, a way to, to combat that, but putting it in the contract is actually not a bad idea. So a good question just came into chat, I wanted to mention came from Jason, um, and Eric, I'm gonna let you take the first swing at it.

Um, but Gary, I'd be curious to hear what you think too is, you know, what, what happens in a situation where an MSP's been providing managed service for some amount of time, you know, year or more, and all of a sudden the client wants to bring in local, like a, or they're hiring their first IT person, right? They're like, maybe it's fear that they've outgrown you. Maybe it's regulation that's forcing 'em to focus on it.

Maybe that's just a liaison of sorts to a client that's growing and they just want someone to control the IT conversation and not the CEO anymore, right? Mm-Hmm. How do you deal with that in terms of roles and responsibilities and protection for the MSP? So that's a perfect example of when whatever the contract was you signed with them originally just doesn't apply anymore, right? You, you have to get out in front of it and say, okay, you're bringing on this new person. What are they doing?

Right? How much control, and these are conversations over this IT person's head, but how much Mr. Customer control do you want this IT person to have? Right? Do you want me to turn over the keys to the kingdom? Okay, that's one conversation. Do you want me to keep the keys to the kingdom? That's another conversation. Too many times MSP is only distinguished between co-managed and, and fully managed by level one help desk, right?

If you've got an IT person there, they take the first call, then they call you for level two, level three, right? But there's so much more to it than that where you really have to make sure that your contract lines up with, with not only what your customer wants, but with, with what you're comfortable providing. That's less.

I I would say today of new deals that I see co-managed, getting signed, less of them fall into the category that all of them mostly used to fall into, where they basically were just hiring support people. It's more correct, way more complicated than that now. Yeah, No doubt. It's gotta be because in co-manage, like what's, what do they want to co-manage, right?

Like my friend David Powell says when he was at Corsica, I don't remember the quote exactly, he would give, but it was something along the lines of, they, they sold a lot of co-manage and they would tell the client, look, there's five things you gotta do. Usually you're good at three and bad at two. And they've mentioned like, you know, like endpoint kind of stuff, telephony, security, cloud configuration, and then whatever else, like maybe network switching, I don't know, remember.

And he's like, you pick three that you're great at and you, and let us know the two and we'll handle the two. Right? But that by nature means that in a co-managed relationship, you're sticking yourself into potentially different product stacks that you're not used to. Yeah. Potential different, everything from identity management that you're not used to what the security configurations and standards might or might not look like and what happens if you're co-managing it, but not security.

Like, there's so much to me that, like, as much as I love co-manage, and I agree like with Gary, that that's the future for a lot of MSPs. Um, you, I just feel like it's twice as risky in terms of the contractual side. No doubt. And it's going to get more confusing as we go forward. 'cause I see the sector growing and I think that a lot of people are taking on deals and they have more risk and they're, they haven't gotten there yet to understand they, they've gotten more, more risk.

And the, you know, the more mature MSPs, they've productized some things that are really tight containers, they don't say yes to everything. Like if we have these three containers that we offer to those customers with these agreements around those and whatever margins they think they need to protect on them.

So I think Gary, then that means that if you're gonna start doing co-manage, even if some of the things that are not in the co-managed relationship are your responsibility, and even if they've been contractually described to not your responsibility, I still think then that means there's gotta be minimum standards in the tech stack or the approach or the employee size or whatever it is that the MSP has to dictate and say, mm-hmm, I would love to do co-manage, but because you guys are operating in x, y, Z way, we can't do this.

It's too much risk to us. Yeah. You know, and underlying all the things we're saying is MSPs to grow and mature are gonna have to grow and mature their sales and marketing because you're gonna have to be, have more prospects to choose from. Like, if you are someone who lives on referrals, you know, a, a majority of those referrals might not hit your new determination for what you expect from a customer.

When I started in this business, if they had a pulse and a credit card, they were potential customer, customer criteria. And I don't even really care about the pulse that much. You know what I mean? Uh, but, but now we have to be able to pick and choose. And so if we want to grow, we're gonna have to be out there and educating and, and drawing people in. Um, you know, we, we got about seven minutes left. I thought maybe as a group, um, unless you had another question, Wes. No, go for it.

I'd love to. I was gonna say, can we just talk about, um, the, the poll question? 'cause it came in like basically 50 50, uh, our MSP has changed our onboarding process to mitigate threats, uh, in a new client in, in our backlog. Uh, so think, uh, you know, what does everyone think about that? Like, 'cause we'd like to say a hundred percent of people, right, should have made at least some changes based on what we talked about for two weeks.

And I don't know, Eric, you deal with a lot of MSPs as well. What's the, what's the thinking there? Is it just so much going on right now? You can't get to everything. No, because this is a really important thing and, and I contend that backlog doesn't matter, right?

It doesn't matter if you have a one week backlog or a nine week backlog, because as long as there's a gap between the time you enter into the agreement and the time you start performing services, and I don't know of any MSPs out there that will start performing services same day a contract is signed, then as long as there's that gap backlog or no backlog, you need to write it down. You need to have something in your agreement that speaks to what happens in that gap.

And it doesn't have to be, as I described it, my recommendation is usually you're not responsible for anything, but if you wanna be gradually responsible or milestones or whatever you want, well, I'll help you write it down. Um, but there's gotta be some discussion and, and you gotta make sure the customer is aware that they're not getting your full boat of services on day one as soon as they sign the contract. We think it goes without saying, but it doesn't.

Eric, do you see any MSPs or do you advise MSPs to say, as part of that onboarding, we want to see them get before we start managing the service, that they get cyber insurance as a stop gap? Because what happens in that backlog to this? The whole reason we're talking about this is what happens if there's threats there that cause a problem, right? Yeah. Do you, do you see that, do you advise that as a, as a minimum standard before managed service begins?

I would say yes, but, and I hate to sound like a lawyer, but it depends and it depends on, you know, you're gonna run into customers as a, as a managed service provider who can't get cybersecurity in or cyber liability insurance and they can't get it. And that's why they hired you. They hired you. Exactly. I was thinking To that minimum standard of insurability. So what do you do there? Right?

So I'm a big believer in, in putting the requirement in the MSAI, I really am, and every one of my clients will, will, will acknowledge that, but you have to be prepared for the two outliers. The one outlier is your customer who came to you because they need to get that insurance and get up to that standard. And you fix that by saying, all right, Mr.

Customer, I'll take the risk, but I'm only gonna take the risk for 120 days, or 90 days or six months, whatever you want it to be such that I'm gonna onboard you, I'm gonna get you going, then you better go out and apply. And if not, I'm gonna terminate the agreement. The other side of that is those customers who just don't want cyber insurance for whatever reason, it's too expensive, they don't see the value in it, they wanna go after you.

Any of those reasons, um, those are the tougher customers to deal with because what do you do? Do you take 'em on and assume the risk or do you walk away, you know, there and there's problems with both and there's some intermediate things you can do. Um, but, but, but, but none of them are great options. What, Oh, go ahead Gary.

No, I was gonna say, what's funny is all these things that we touch on every week about having to push back on prospective clients and on current clients that scare many MSPs, right? Are the things that build the most positive relationship and they also build the most valuable relationships where people are willing to make the right investment.

And we see it show up because by far now the deals that I see getting closed every day and I get a ticker tape of deals getting closed are mainly the ones that are closing at the highest seat price. So what that tells me is the, the things you need to do that may be concerning are the things that are gonna make your business better and your relationships better, and your clients happier. Iva, can I ask a quick question?

This is kind of like on the other side, we always say like, we've been talking about onboarding and then how you have to make sure the prior MSP, um, has, you know, agrees to some sort of coverage. What if you're the prior MSP, I mean, how long should you agree to, to provide that coverage? Like how much liability do you wanna take on? Yeah, and and every MS P is different, right? Every MSP is has a different risk profile.

Now, if the customer is willing to pay my full monthly price for something less than my full monthly service, then I'll probably write a contract for that, right? And say, fine, we'll, we'll do that. Um, sometimes I see customers ask the MS P to agree to in advance to a certain length of offboarding. And again, it, this is kind of the flow from the SaaS companies down to MSPs.

You see it in SaaS contracts all the time, where at the end of a a three year agreement for the SaaS company, the customer can get up to three or six or nine months of, of transition services. We're starting to see that trickle down to the, uh, the MSPs as well. So there is no rule of thumb, Phyllis, it's a great question.

Um, but it's just a matter of number one, how much, how much you want to do it, how much you wanna deal with a customer that that, that you're trying to get rid of, maybe, um, mm-Hmm. And then making sure that you write it down and making sure that both sides are crystal clear with respect to who's responsible for what. Yeah, It's really good. I, and I hope that, I'm glad we had those 50% of people that haven't looked at this and maybe more critically that this will be a good impetus for them.

Uh, if that happens. That's why we're here every week, right? As uh, as soon as we start doing polls every week and everyone says they're doing everything, Wes I say, we sign off at that point. What do you say? Yeah. 'cause they got other work to be going to do. Is that why? Yeah. That that's our vow. We we're done here. Everyone's doing everything. Yeah, everyone's doing everything. There's no, there's no need for the si the cyber call anymore. Yep. Yep. But we're not there. It's very True.

Not quite. We've got some time to go for sure. Yeah. At least another couple Weeks. Every time we think we're gonna get there with one question, there's another question. That's great. This was awesome. So I wanna, I want Thank you. Uh, and Phyllis, if you have any last comments or, or Wes you wanna have any last comments before I thank our guests?

I just think that I, I think like I know Eric, it's so good to have you on and, and like I just hear from MSPs all the time that are going up around this that have said, best thing I've done and in the past year is have a qualified attorney that has helped me with all of this that understands the risk of cyber. It's not just a regular business attorney, it's just thinking about, you know, what does liability look like? But actually mm-hmm. How does cyber implement into this?

And I, I, I get no dollars by telling you this, right? But you've just been so helpful to so many MSPs and just wanna say thank you in particular because, um, you know, you giving back has really been so helpful to all of us to recognize that this is about saving our business and doing these things now are the things that keep us survivable when that event happens. Yeah. I appreciate that, Wes. Thank you. And, and you know, we've said it over and over again.

This is a community and, and we're here to, to help each other. And if I can do that and play my little role, then, then that's great. Eric, I wanna thank you. And Ben, thanks so much for taking the time today. Uh, another action pack. Call Phyllis, Wes always awesome. Turns out we don't need Andrew, Don't tell Him that. I'll See in a minute. I know. Alright everybody, have a great week. Thanks Everyone. Thanks.