The Tale of Two MSPs

Welcome everybody. We are kicking off a tale of two MSPs. Uh, we got folks still coming in. I can see it as we are, uh, kicking things off here. So, um, as we are doing that, I'll just, um, make a few quick announcements. Number one, um, anybody in the audience attending it Nation by chance? Eric, anybody attending? Can you see? I don't see any comments. No, no comments. Can everybody hear? Uh, let me see. Can you guys hear us? Let's do a quick, um, uh, there we go. So, okay.

Bob's gonna be there. Alright. Um, I'm just putting something in here. You're welcome to join us. We have a, um, an event that we were one of chosen, right? A boom was chosen as one of five communities that, um, uh, they felt strongly were helping the ecosystem. And so we're gonna do a little get together after the Wednesday night vendor showcase. Um, there are lots of drinks. Bob, you're, you. Just let us know what you want and they'll be ready.

Uh, Eric will be there, ready to hand them out to you, uh, on a silver platter. Um, Ollie, are you at, uh, IT Nation this Year? Um, I don't know yet if I'm gonna go. I'm sure we'll have somebody there. I haven't yet decided if I'm personally attending You. I think you, you gotta be in what the top 20 original ConnectWise users, Uh, we're. We were early on. I don't know. Yeah. Yeah. I think oh four maybe. Yeah. Before. Yeah, it had to be. I remember. Yeah. So, um, well good.

Um, alright, so we got a few more people coming in. We'll get, let's get on into it here. Um, first off, um, I'm gonna just set the stage in terms of what today is about. I'll introduce Nom, who is kind enough to raise his hand and say, Hey, I like what you're doing here. Um, I'm happy to let any MSP use our platform. Um, originally it was 30 and now 45 days to do a tabletop and practice their incident response plan. We'll, let Nome tell you really quick what he does, uh, momentarily.

He works with a bunch of MSPs now. Um, but, you know, I was gonna, you know, it, it amazes me. And, and I don't want to be like ever, um, uh, cast dispersions on people that have breaches because it is, uh, for those that have ever been through it or notes some that's been through it, and Oli, I know you work them every single day. Um, it's, it's, it's traumatic.

Meaning there is, um, a tremendous amount of not only emotion, but uh, grief, uh, that is associated with financial loss embarrassment. And no one typically is doing anything malicious in terms of not the bad guys. We know they're doing things malicious in terms of, you know, I'm thinking about MGM as an example, right? That was just really poor. If you think about it. Everything is being hindsight. 2020, their help desk should have had ver better verification steps.

This is something that could have been prevented. And like we hear all the time, typically it's the easy stuff with block and tackling where we miss it. And this could have been a verification block and tackling that could have prevented this phishing in phishing incident that, you know, is probably costing them only calculated based on their, um, revenues and things of that nature. Probably arguably, you know, what, only 6 million a day, give or take, right? Yeah.

I figure by the time they're done, this will cost them 50 to 150 million at, in that range. And their capital hit as of a few days ago, their market cap was already down 800 billion and probably really a billion. 'cause the market had gone up during that time. So they're taking a hit on their, their, uh, valuation too, Right?

And this is the part where, you know, we always talk about, you know, we gotta get away from our conversations with customers and prospects about cybersecurity and more about the language of their business because really the language of their businesses, as you just said, Oli, what's the reputational hit? What's the, you know, um, uh, their, their capital cost structure hit gonna be this. And, and, and, and, you know, we could go on and on and on. So, um, alright.

So with each passing day, knowing things like this are happening, MSPs, um, are on the front lines. Um, you all know that. Um, and so, um, you know, Eric did something, um, similar to this at right of Boom in this past year.

And he was really looking at, you know, you know, his personal experience with MSPs that are prepared left of boom prior to incidences, both from legal, from, uh, policy, from process, from process, um, when they go through an incident, the ones that are prepared, what does the outcome look like versus the ones that don't prepare that go through an incident? And what does that outcome look like both for themselves and their customers?

And, you know, uh, as Eric says, he is a Charles Dickens fan and where, where it came up with the, uh, the title, um, there, there are very different ramifications. So we wanted to kind of dig into that today, but put a little bit of different twist on it, bringing in Oli who has been in the business for a long time, spun out piece of his business, which he'll tell you about who works some of the largest ransomware, uh, cases and incident response cases now.

But before we do, no, I really appreciate you raising your hand. Um, so in doing so, uh, wanted to give you the floor for just a few minutes, tell folks about what Exigence is, what, what you're offering them, and then we'll do intros of Eric and Oli and get right on into it here. So thanks for joining us now. Thank you very much for having me. Um, so Exigence, it's an IR planning and tabletop platform. Uh, it's a multi-tenant platform for, you know, design for MSPs.

And what we provide in the tool, it's a tool-based IR planning, uh, and, and tabletops as I said. But you get an IR plan template that we built with, you know, an industry expert with, with a Chris Lear. Um, and what you're able to do there is you, you know, when you create a customer, you choose a template, you assign an IR template to them, and we're not talking about Word documents, you know, 20 page document that you flip through.

It's a tool base, it's a dynamic template that when you run an incident on the tool, or, or sorry, let's start with a tabletop or an actual incident. But when you run a tabletop, it's a fully hands-on experience. You know, the, the plan takes you through the steps, tells you what you need to do based on, on the inputs that you give it, that it's a fully, I would say war room hands-on a tabletop experience that will prepare your customers for, I mean, for incidents if they, if they happen.

Um, and, you know, will give you the ability to provide the service at a very cutting edge level with, you know, good control and efficiency on, on providing, uh, response plans and tabletops. Yeah. And as we'll talk about today, Noam, you, you've done a great job really listening to MSPs. What you'll hear from Eric and Oli today is there's lots of players.

So, you know, you know, raise your hands out there or say, if you've ever been through an incident like Bob, I know you know, you're, you know this well, Bob Miller who's out there, there's a lot of players involved, right? Eric is i'll, I'll let you in, introduce yourself when there, when there's an incident. Um, if you haven't been through one, you're gonna find out. So the tabletops critical of, of all the different parties, right? That, that get involved in something like this.

So, Eric, with that backdrop, tell us a a little about yourself, what you do, you're recovering. Yeah. You know, Thanks Andrew. I appreciate you, uh, you, you having me here and, uh, and, and knowing you as well. Um, so I am an attorney. Uh, I've been practicing for about 25 years, and I almost exclusively represent MSPs and MSS ps um, why do I do that? It's because I used to be one of you. I used to own an MSP, um, started back in the late nineties.

We were very, very fortunate throughout, uh, the, the, the, the, the term of our business. And we were able to grow our company to about 250 employees, um, before we exited about a dozen year, actually about 13 years ago almost. Um, so since that time, um, I served as the general counsel, chief risk officer, and head of information security and compliance for a company called Logic, which is a global MSP.

And they're the ones who bought us, um, did that for about eight years before going out on my own. Um, there's not a lot of organizations that need someone like me on a full-time basis, but there's an awful lot of MSPs, MSSP software, SaaS companies that, uh, that use a, a fractional share of my time. So that's what I, uh, do today. Cool. Alright, Eric, awesome. Well, well, I introduce Oli, please feel free to put your email or LinkedIn if people wanna ask you any questions. Um, Oli awesome.

I I can't believe I've known you now, like you said, we were talking before. I think we started, uh, or maybe we had, we had started, you were one of the first ConnectWise, uh, customers and Yeah, we were rolling all or at the time. So I've known you for 20 years.

Um, and, um, you know, I had, I was talking about this, um, on the cyber call this week, and Gary's like, man, if I'm the, if I'm the, uh, um, uh, if I'm the father of MSP, that makes only the God or the grandfather of, so, but he did, but he did point out you're a hell of a race car driver. Thank you. Thank you. Yeah, some, um, I actually got nominated for the crn, um, computer Industry Hall of Fame for my pioneering work in, you know, MS.

P, and then they found out I wasn't retired, so I guess I don't qualify. That's awesome. So tell tell PE people that may not know about aba, you know? Yeah, So I've been in IT services, um, professional services for a long time. And yeah, it was in the nineties where I just, every day I walked into the office, I had too many engineers, not enough. And that's when I figured I gotta get some rational control over the scheduling and the service levels.

And, and I didn't ever know how much money I was gonna make that month. So, um, I started, I was, yeah, I guess I was one of the first people doing managed services and recurring revenue, um, models and all that. Um, so I was early on, um, I still have that business. Um, I, uh, about three years ago we created a new, uh, company within the company that we're planning on spinning out in a year or two as an equity event.

And that is our cybersecurity practice that's focused exclusively on doing ransomware recoveries and, uh, you know, restorations and that sort of thing. And, um, good for us, bad for everybody else. It's growing fast. It's, um, you know, it, it's ransomware's a big problem. Yeah, absolutely. And only the other thing I, as we get into it here, the, the thing that I remember too is, um, you also, I would say pine for our indu for our little piece of the world, right? For IT providers.

You were very early on into co-managed. I mean, you work with some really literal enterprises, um, large mid-market and enterprises. And that was really cool to see that people would be, you know, at industry events. You're like, you're working with who, um, Yeah, it's, um, I like the mid-market space. It has its problems. Um, you know, it's, I, I see people doing SMB all you can eat, and I go, wow, that's a really good bus. You know, the grass always looks greener on the other side.

Um, but, uh, I do like the mid-market space. Um, it's, you know, it's got, its challenges are different than the SMB space. Um, you know, I, you know, we don't have to, it's one key thing about that space is we never have to call our clients up and ask 'em for money. They just send it, right? Um, you know, you send out an invoice, you have your terms, and I, I kid you not 98, 90 9% of 'em just send checks like clockwork.

Um, I remember being in the SMB space, maybe it's still this way, but oh my gosh, it's, we had, yeah, it was a full-time job, just calling everybody, get, begging them to pay. Um, probably everybody else out there doing that is probably a lot better than I was back then. And they probably don't have that problem, but that was a problem for us. Got it.

Alright, so let's get on into it, Eric, you know, before we start digging in, you know, MSP one versus MSP two and customer one versus customer two, I, I, I need to set some kind of, I guess, guidelines or go over some, not, it's not guidelines, but kind of go over the block and tackling, and that's around, you know, cyber insurance and, and MSAs. We need to talk a little bit about that because it's set, it sets the tone, if you will.

And why, from your perspective, um, why does it matter whether an MSP requires their customers to have cyber insurance or not? Like, can you talk to us a little bit about the pros and cons here? Yeah, absolutely. I mean, I, I'll, I'll tell you about the, the pros, right? And, you know, we've all heard, make sure your customers carry cyber liability insurance, right? Write it into your contracts, et cetera, et cetera. But, but does anyone ever ask the question why? Right? Why does it matter?

It's not like as an MSP or MSSP, you can step into your customer's shoes and make a claim on their cyber insurance policy. You can't do that. Um, so, but why does it matter? Um, and there's a few reasons, right? Number one, just from a 30,000 foot view, it tells you if you're, if you've got a customer that carries cyber, um, it tells you that that customer is at least a little bit serious about cybersecurity, right? Otherwise, they probably wouldn't do it.

They probably wouldn't see the value in it. Um, but there are some, but, but there are some things that are, that are good from a financial standpoint for MSPs who do require their customers to be insured. Um, the first one, probably one of the most lucrative is a, as you all know, it's not easy to get cyber liability insurance, right?

You've gotta, you know, fill out these ridiculous applications and give blood samples and all sorts of other crazy stuff just to get, just to get a policy written. But how do you get your customers to that minimum insurable position such that they can get insurance, right? Well, guess what, they're gonna use you to do it, right?

They're, if, if, if you, if they have five gaps and they need to fill those gaps, you're already talking to 'em, they're going to use you to fill those gaps to get to that minimum baseline level. Um, the second piece that relates to, to getting paid, um, is without cyber liability insurance, when they have an incident, and again, not if they have an incident, but when they have an incident, they're going to have the money to pay you, right?

So if without insurance, um, you might not be getting paid. And, and we'll talk about that more in, in, in a little bit, but just knowing that the insurance companies are going to be writing the checks to, to cover your invoices will make your customer feel better, and it should help you sleep a little bit better at night, too. Um, and so those are the, those are the primary reasons why yeah, why You Want your customers to have it.

By the way, I didn't say this, but please, um, in chat, you know, chime in, like this is gonna be a lot more enjoyable. If you guys are asking questions or comments, please, uh, feel free. You know, we got a world of experience here between, uh, Eric and Oli and, um, you know, you know, Ole I'm gonna have you chime in in a second, but before I do, Eric, can you, you mentioned filling out questionnaires and, and it would, and what, and yes, the, these will drive, uh, revenue.

I had an interesting conversation the other day with a gentleman named Manny Minker, um, who has an MSP out of the Midwest and primarily focused in banking and fully, I don't know if you, uh, have, you know, you'd think banking, right? You know, one of the most regulated, you know, industries would have, You Know, Dr. Be driving cutting edges, si, you know, security controls.

But he said, interestingly, it's the insurance questionnaires are driving more of his revenue within the banks than the actual F-F-I-E-C, um, audits. Um, just curious, Oli, before I ask Eric about, uh, the risk MSPs place themselves in when working on filling out questionnaires, oli surprise you at all? And, and do you see that? Yeah, you know, so I just wanna add that a few years ago I thought, uh, insurance companies, cyber insurance, they're, they're gonna be stupid.

They don't understand the space, they're not gonna understand the technology. And I, I'll tell you, they understand risk and they're not stupid. They've got some really smart people. These are big companies, and they've got some really smart people figuring out the risk and how to mitigate it. And with the losses they took in 2020 and 2021, they've gotten even smarter. Um, so, um, anyway, I forgot your question, Andrew.

No, I was just gonna say, are you seeing though the, no, I think it's a great point. You know, everybody's like, oh, the dumb old insurance companies, they are, you know, they, they, they're not in the business to lose money. No, Sorry. And, and I remember your question now, and that is the filling out of the forms. Um, don't, yeah, I, yeah.

Um, I think, um, I'm sure, um, that Eric will touch on it later, but yeah, there's money to be made in filling in, in not filling out the forms, helping the customer comply with the requests from the insurer on the forms. Um, I don't recommend you fill it out and be careful what your guys are doing. We have a large healthcare provider, you know, a multi-billion dollar healthcare provider in this area.

And one of their, IT guys went to, one of my engineers says, said, Hey, I'm filling out the, uh, cyber insurance form, you know, here it is. Hey, hey, you wanna sign it? I swear, the guy, the guy's really pretty slick. And he was wanting to get my engineer to sign off on it, my engineer, fortunately, uh, savvy enough and said, no, no, no, I, I better not. That's for you guys to do. So be careful.

'cause your customers, they're gonna try and get you to take on as much risk as they can trick you into if they're a little bit less than fully ethical. And they might even be more sneaky than that Oli. I mean, you know, I've had, I've had some M-S-P-M-S-S-P clients tell me that they will have calls come into their help desk. And from a a, a longstanding client of theirs who just starts asking 'em a bunch of questions, they don't tell 'em why they're asking the questions.

They just start asking questions. And, you know, you can tell that they're scribing the answers as, as the, the help desk guy, the level one help desk guy is, is answering is, is surreptitiously answering these, uh, these questionnaires. So it's, uh, it can be dangerous, Eric, go into, or can you, can you talk about, like, what is it, like, how do you navigate that be?

And you talk about there's certain ways to, like, even I think zero do, I don't wanna put words in your mouth, but you, you, you really want to enforce your limitation to liability. If I'm, if I'm remember your words, Eric, but there's certain ways in which you wanna help your customers. You don't wanna say, oh, we're not gonna help you, but can you kind of nuance this for us of how you wanna handle this? And where, where can you go wrong? Yeah. And, and that's a good question, Andrew.

And, and, and at the end of the day, what this comes down to is, you know, are you as an MSP contractually bound to help your customers with their cyber applications? And what happens if you're not contractually bound? Well, if you're not contractually bound to do it, then in theory, your MSA won't apply to the work that you're doing to help your customers fill out their applications. And if your MSA doesn't apply to that work that you're doing, and something goes horribly wrong, right?

You make a mistake. 'cause we all make mistakes all the time, right? So you make a mistake, and now you don't have a contractual backstop to help you in the event that you've made a mistake on an application. Somehow you have culpability, um, and someone's coming after you, right? So, so what do you do? Right? Uh, go ahead, Andrew.

Yeah, I was gonna say, Eric, would this be the part just kind of, I know I'm interrupting, I apologize, but just for, for case in point for the, for our audience, would this be like the Traveler's Insurance where the MSP goes? So kind of talk about that. Sure. We have MFA, but is, you know, talk to us about why that was so important there. Absolutely. So, so, so first things first, right?

How do we get as an MSP to be contractually bound to help your customers with their cyber insurance applications? Right? Number one, um, write it into your managed services agreement. If you really wanna help your customers with their, their, their cyber insurance policies, right into your, your managed services agreements that you will help your customers fill out their applications as part of your service or as an additional cost, I don't care, right?

Just write it in there such that now you are contractually bound to do it. Therefore, your MSA applies if you don't do that, or if you don't wanna do that, or if you're in the middle of a three-year agreement with your customer and you can't change it, then put a statement of work in front of them that says, okay, Mr. Customer, here's what I'm gonna do for you. I'm gonna help you with your application. I'm either gonna charge you for it, or I'm not gonna charge you for it. Again, I don't care.

But my MSA applies, therefore, my limitations of liability apply. Therefore, if something goes horribly wrong, I'm not betting my company. So, so how do you help them, right? What, what exactly do you do and what do you not do to help them? Right? Number one is you have to make sure that your customer is responsible for the application. Your customer's responsible for filling out the application to Ollie's point, they're responsible for signing the application, right?

You can help them, you can help them with their answers, but at the end of the day, you're just, you're doing just that. You're providing help. You're not answering the questions for them. Number two, don't lie. Right? And, and this, this goes back to the travelers case, Andrew. So in the travelers case that a lot of us are familiar with, maybe, maybe some might not be, you know, there was a question on a policy. Do you use MFA? Right? And the, the MSP checked the box.

Yes, we use MFA because they used MFA on 365, maybe they used MFA for some remote applications, but whatever, and I don't remember what the exact situation was in the Traveler's case. Whatever the, the bad actors used to get in was not protected by MFA. So what happened? Well, the, the company files a claim, travelers pays out a couple million dollars on the claim, and they go back and they read the questionnaire and they said, well, wait a minute.

You said you used M-F-A-M-F-A would've prevented this attack. Why didn't it prevent the attack? Well, it didn't prevent the attack because they weren't using MFA on this particular application. That's the whole gist of the travelers case. So you come across a question on, on a, a cyber insurance questionnaire of do you use MFA yes or no? Well, the answer is neither yes nor no. Right? Well, you use it on some things, maybe you don't use it on other things. So what do you do in that situation?

Number one, don't guess. Right? Don't, don't, don't say, well, yes, we use it, so therefore I'm gonna check the yes box or no, we don't use it because we don't use it on everything. Put the call, shift the risk, right? Shift the risk to your customer and their insurance broker. And you tell their broker, Hey, look, here's the question. Here's the truthful answer. It doesn't fit with either of these check boxes. What do we do? Right? And make the broker culpable for the answers.

Don't yourself as the MSP be culpable for those answers. Yeah. It's also my observation. You don't have to be in compliance with a hundred percent of the requests on the form just correct. Not accurately. The insurer will make, uh, a risk based decision on what they see. Yeah. Unfortunately, they don't tell you how much you have to be in compliance with. Right. It's a bit of a guessing game.

Um, but, uh, but yes, just because they ask you a question and you think the answer should be yes, don't, don't worry about checking. No. They'll, they'll, they'll tell you. The underwriters will come back and tell you either, A, you're approved or, or B you're not approved, and this is why you are not approved. And then you can always go back and remediate and help your customer remediate. Yeah. Uh, and it's funny, Oli, we were talking about banking earlier.

The core, you know, the core banking solutions, which, you know, were built in the stone ages, the majority of them weren't architected for MFA. So, you know, if you're dealing with a bank that, that's a perfect example, right? Where you'd say, okay, well, the core banking application doesn't natively enforce MFA, so how do you want us to fill that out? Right? That would be a way, you know, where you, you'd probably push back fairly. Yeah.

So, and you end up, and as Eric said, you end up in a negotiation with the insurer. Um, you know, they might raise the rate a little bit, they might just give you a waiver. Um, and they might understand it. It might be something that they expected, but they ask anyway. So, um, yeah. And I think, uh, to the point, Eric, of mentioning brokers, I think that's where having a really good broker comes in too.

'cause they understand what the implications are, and they'll help guide their, they're your Sherpa through that insurance insuring process. Yeah. Because they don't wanna get sued either, right? Yeah. For giving that advice. Yeah. Yeah. So Jesse brings something up, Eric, and, uh, let, let's maybe can touch on Jesse, like, what happens if the broker's like, well, gosh, you know, you, you gotta keep pushing up the chain, right, Eric? Absolutely.

The buck has to stop with the broker or the customer, not with the MSP. If something's not clear and the broker's shrugging their shoulders, then ha then have them broker a call with the insurer or whoever's application it is, and, and get the clarity there. Um, don't, uh, don't give the broker a free pass. Yeah.

And, and Eric, I, I, you know, I, I'm always, you know, 'cause I have the inside skinny, you know, 'cause I've been on enough calls with you and known you, you know, again, for 20 years, like Oli. But it's interesting when people are like, you know, very proud when I see people, MSP's very proud, oh yeah, we do require cyber insurance. I'm like, awesome. That is so great to hear. But the, the follow up is, and we require them to at least have a million dollars. Yeah. Why is that?

The potential death mail they did the first thing, great, but where does that next piece come back to haunt them potentially? Yeah. I'm not a big fan of dictating coverages. And you know, even if they say, you know, maybe not a million dollars, maybe at least a million dollars or at least $2 million or whatever, I still don't like that. And the reason being is, is our friend Murphy's Law, right?

Murphy's Law tells you that, you know, if you require your customer to carry at least a million dollars in coverage, and they do get a policy for a million dollars, their first claim is gonna be for a million and a half or $2 million. Right? And then what happens, right? Are you culpable as the MSP for telling 'em they need at least a million dollars? Why didn't you tell them they need at least $2 million or at least $3 million? Their coverages are not for you to decide.

Their coverages are between them and their broker to decide if they wanna know, you know, the, the average cost of a security incident, you can provide some research to them, right? But, but don't tell them how much coverage or a minimum level of coverage to, uh, to have. I think it's really, really dangerous. That's a, I think again, that's where the broker has to come in and help advise. Yeah.

Um, and on our website or all Baca website, we actually have a ransomware recovery cost calculator that takes into account. It tries to come up with estimates or help guide estimates on what the business interruption costs are, what kind of ransom you can expect. It doesn't recommend what the insurance coverage should be, but it helps try to frame what your losses, your total losses would be.

Um, Ali, so in your experience of dealing with some of these cases, one are, um, are MSPs involved sometimes number one and number and, and whether yes or no, but I'd love to know that. Um, and then what's your experience been on, you know, people being prepared, you know, underinsured over, you know, like typically not over-insured, but like, just the preparation phases of the things that Eric's talking about so far. What do you typically see?

Um, I don't have absolute insight into how well they're insured. Um, but I would say in most cases, I think the clients have been adequately insured. But we've definitely had some that have been, um, underinsured and we just had one that was underinsured. Um, we also do about 40% of our business that are uninsured as well, which is another interesting aspect of the business.

Um, so, um, yeah, the, uh, uh, But I, I guess what I'm wondering Ollie, though is, you know, when, when do, do you get some insight on going, man, they, they were prepared, like the, this company had an incident response plan. They had their, you know, if they were working with an MSP, you know, the MSP had their ducks in a row. Like what typically do you see once Oh, started? Yeah, we've had, we've worked with at least two MSPs that have been hit by ransomware. So we have at least two, um, MS.

P companies that we've worked with. Um, and we've had more cases where we've worked with clients of MSPs where the multiples of the client's MSPs have been hit. And we've been working some of those cases. Um, I would say as a general rule, everybody is woefully unprepared when these events happen. In what areas? Like really stand out to you?

Like, if you're like, gosh, if I could have gone back in time, I really would've sat down with you and said, you should have done better here and here and here. Like what were the, maybe the one or two big areas? Um, are you talking about from the MSP side or from, yeah, Yeah, yeah. Like, how should they have been better prepared or prepared their client better? What I would Say the MSPs need to make sure that they're patching up their systems, including firewalls.

A number of 'em were, um, compromised a year or two ago during the, uh, Fortinet vulnerabilities that were out there. And those continue to reoccur. But I, I think it was August a year ago, or August two years ago, where there was a whole rage of Fortinet exploits that were successful. Um, and MSPs felt prey to that.

And so, you know, having everything patched, including appliances, um, having MFA and having EDR and then having a monitored, you know, EDR or XDR, whatever you wanna call it, um, I think if you do those three things, you are going to be, uh, tenfold better than where you probably are sitting today in terms of, um, being protected as an org, as an MSP organization. And I wanna add too, uh, the cases we've been getting lately have been SaaS companies.

You know, about every other case it seems that we're getting right now. Is a software as a service provider, Is it a credential hit, usually starting the initial access oli? Like what's starting it? Um, you know, I'd have to go ask exactly how they're getting, you know, the compromises happen all different ways. Sure. Um, you know, I, I don't know that there's a commonality with the SaaS companies, but we're seeing a lot of SaaS companies just in the last two, three months getting hit.

Interesting, interesting. Um, other question I have for you, Oli, that, um, I, I'm always really pleased to hear when an MSP does have this well defined, but it's few and far between, and that is where your managed services end and where IR begins. You know, this is, you know, because when I ask an MSP about this, Hey, how does your customer know? Is it clear? Is it spelled out?

Like, do they, you know, I in one MSPI know that does it really well, you know, they talk about having really defined edges about what they'll do when they have a third party on retainer, that they're gonna get billed for about an hour of their time to come in and validate or invalidated. So can you kind of walk us through your thoughts on this and, and yeah. This, this is a plug for Eric. I mean, good contracts are essential. It all starts with good contracts.

Um, and you need to define who's responsible for what things and activities in a relationship. Um, and if you don't have that well-defined and explained, you're gonna have misaligned expectations. And that's where lawsuits come from. That's where unhappy customers come from.

So it's, uh, job that's, it's incumbent upon your salespeople that they be sophisticated enough to be able to, you know, tell the client what their responsibilities are and what the MSP's responsibilities are, and that everybody's clear on that. Um, and then you better price your services accordingly. If you're gonna take on the responsibility of incident response, boy, you better price that in. Um, that's not really, um, very pragmatic.

And that's, you know, when we get clients pushing on us saying, well, wait a minute, you're managing our system, so you should be responsible for it. If something happens, it's no, we're a service provider managing the system. What you are asking for is risk transfer. There are organizations called insurance companies, and you can transfer the risk of a breach forward to them. We are a service provider. We're not, we're not the only one touching your system. You guys are making changes to it.

Other people are making changes to it. And your vendors, you probably have a hundred different product vendors in here, and they all have vulnerabilities. We cannot be solely responsible for the outcome of your system security. That is the job of an insurance company. And that's essentially, uh, how we consult with our clients when they start pushing onto us. Um, and you better do that before the breach happens. Yeah.

If your contracts are poor and understandings are poor and the breach happens at that point, everybody's looking to figure out how they can get somebody else to pay for it. Yeah. Eric, you want to touch on this a little bit? Because this is an area that I think is really critical for MSPs that where it isn't clear. Like, how do you go back and clean that up?

If you are in the middle of a three year agreement, you're like, wow, I don't have clear delineation where, you know, Hey, we, we think the behavior here, we see anomalistic behavior. This is probably an incident. My client, you know, if I told them, Hey, we're we're gonna bring in a company here, they're gonna bill about 600 bucks an hour to inval, you know, validate or invalidate that they'd probably, their head would spin around like the Exorcist. Yeah.

So how do you go back and deal with this? Yeah. And, and, and, and Ole had a great point. He said, somebody's gotta pay for it. Right? Is it the MSP? Is it their customer or is it the insurance company? Um, you know, and, and this goes back to requiring your customers to carry cyber liability insurance. It's one thing if your contract is not clear and your customer is insured, right?

We at least know the insurance company is gonna pay something and you're likely not gonna get left holding in the bag. But what happens if it's unclear and your customer isn't insured? Right? You've got two possibilities. Either you're paying for it or the customer's paying for it. So your contracts have to be clear. And, and, and to your point, Andrew, about what do you do, right? What do you do if you're in the middle of a, a term a, you're 17 months into a 36 month agreement?

Um, the good news is that most customers understand that the environment is changing, right? So most customers, if you sit down with them and say, Hey, look, I just went through the process of, of aligning my contracts to my services and making sure that, that everybody's clear what we deliver and what we don't deliver and what we're responsible for and what we're not. Um, so would you consider Mr.

Customer, um, looking at this new contract and agreeing to terminate our existing agreements and perhaps offering some incentive for them to do that? Because you always run the risk of them just saying no. And if they say no, frankly, there's nothing you can do at that point as long as you don't have any other outs in the contract.

So it's a matter of, of having that relationship with your customer where you can come to them in the middle of a term, just like they can come to you in the middle of a term and say, Hey, look, my business has changed significantly. Here's why. And can we talk about it? It's the same conversation just coming from the other end. Yeah.

And, and don't wait for, I would say don't wait for something because I, I, I, I, again, MSP comes to mind, Eric, that it wasn't massive, but one of their clients were, it was ambiguous. Mm-Hmm. And they were, they, they had quote unquote M 365 monitoring in the agreement, got hit with the BEC for about 17 K. Yeah. Guess who paid 17 K? Yeah, Exactly. And now all of a sudden it's like, shoot, we better, you know, go back And, and you can get down to these nitty gritty issues.

I just had, and, and I think I shared with you the story a couple weeks ago, Andrew. I had a client whose customer got popped through A BEC, but they got popped through a contractor, right? Not one of the customers employees, but through a contractor who the customer had given it a customer email address to, right. So to the outside, it didn't look like a contractor to anyone, but they had a contractor who had a company email address. Right.

And whenever there's a BEC, and whenever it's one of my clients involved, I always ask my client, tell me about what you've committed to for training, for security awareness training and things like, things like that. Do you train, do you provide security awareness training to anybody at the customer site who has a customer email address? Or do you only provide training to the customer's employees, right? Mm-Hmm. And there's risk both ways.

And, and the answer was, it, it wasn't clear, um, from their contract whether they were responsible for providing security awareness training to everybody who had a company email address or not. Right. So, and, and the problem is, to your point, whenever something happens, it's too late. Right. Your, your contracts are locked in at that point in time. There's nothing you can do to change it. Now it's just a matter of, uh, of figuring out where the liability lies. Yeah.

Can, can I add to that, Eric, too, that there's the case, I think it's out of Minnesota, where an MSP in their marketing said, we're the only, you know solution, the only service provider you'll ever need. We'll take care of everything for you. Yeah. And then when the client had a breach, they were saying, well, we're not responsible for that. But, um, but It says you are. Yeah. Yeah.

The contract also didn't say that they were responsible for everything, but, uh, exhibits were made with the, uh, client's marketing material saying, we're the last stop. We're the only people you'll need to deal with. Yeah. And the court found them, uh, responsible for a pretty big breach. I, I will tell you that at least half of my new clients, when I first get ahold of their statements of work, they have a ton of marketing language like that in their statements of work.

And they get really upset with me when I make 'em take it out. Right. Because they said, but then we're not gonna be seen as the, the, the kinder, gentler, friendlier MSP and well, you know, you gotta be honest, right? You have to be honest with your client. Well, then you better be seen as the empty walled, uh, yeah, exactly. Exactly.

Well, it, it's funny, if we could, you know, just beam in, uh, Spencer P*****k, for those of you that may have heard of who he is, he is a breach attorney at a large firm called McDonald Hopkins. They're one of the, um, you know, again, big ones out there, right? Oli that's on most, um, you know, you're gonna see them on, on most of the big, uh, panels. Panels. And, um, Spencer tells me, you know, now he represents a lot of MSPs. He's not a bad guy.

So he goes in before there's, he helps MSPs get their ducks in a row. You should probably have a breach attorney relationship if you don't. Um, but Eric, he tells me when he's simply representing a customer and customer, and he's not now representing, obviously he can't do both. But when there's an MSP involved and there, the customer's popped, do you know where the first place he goes to Their contracts? Yeah.

Well, yes, but aside for asking that, he told me, he goes right to their website immediately before they can change anything on their website. Sure. You literally screenshots every facet of their website about how they market. And a lot of MSPs like the, I know one in particular, and this is where MSPs get themselves in trouble. 'cause all you brought up the FortiGate issues, right? And it'll be like, we handle all network security.

Well, I know a lot of MSPs when I've talked to them about their vulnerability management programs and asked them, okay, well, how are you guys continuously monitoring for infrastructure? What tools do you have for infrastructure vulnerabilities? And a lot of times you get a blank stare, right? And I'm like, but your website says you're doing it. So Eric, is that where things can go horribly wrong? Yeah, definitely.

And, and, and, you know, like I used my example, I see all the time, forget about the website, forget about the marketing. I see where people write that into their contracts that, that we will take care of you. You will be 100% satisfied. We will handle every facet of your it, leave it to us. Right? Mm-Hmm. I, I see that in contracts all the time. But, but you're right.

Even if it's not in the contract, if it is on the websites, um, I wouldn't wanna be that MSP in the event of a security incident. Gotcha. Um, Eric, should we talk briefly about carve outs? Are they important at all in MSAs or should we move on? Uh, you tell, tell me if that's an important piece here. Yeah, I, I mean, look, just in, in, in general, it's, forget about carve outs for a minute, but it's important to understand your own MSA, right?

Make sure not just that you have a limitation of liability provision in your MSA, but that it's well written, that it's been reviewed, that it's industry standard, that it contains everything it needs to contain. Just because you have a limitation of liability provision in your MSA, it doesn't mean you're safe. It doesn't mean that you're protected in the event something goes wrong. So just make sure you're having someone qualified review those for you. Got it.

Well, I'll add, I have great counsel for my agreements, um, really use it for a number of years. He's a former programmer turned lawyer, great guy. But I just started having Eric, uh, do reviews of our agreements to get good second opinions and, and good additional insights.

And although I have total trust and faith in my guy, Eric, is bringing up some good alternate perspectives on our agreements about what should be covered and how we should approach things, and we're gonna be making changes accordingly. Interesting. Oli, um, let's go into the heart now of an MSP one versus an MSP two. You, you've been in pure groups for years, and again, you've seen a lot of different things. So, you know, most, let's take an MSP that they've done a good job, right?

Let's just say they truly understand business impact analysis. They've sat down with a customer, in essence, mapped out data flow, right? Um, you know, and, and, you know, have good understanding of how that would impact, you know, how, how they would handle an incident response around this. They, maybe they've table topped it, how it impacts business continuity. Another MSP and, and I would say unfortunately more so than not, are not doing those types of things.

Have you been in incident re restorations where you do see whether it's, again, MSP or customer where they do have that well documented versus don't Yeah. Happens? Yeah. We've been in situations where the documentation has been virtually non-existent and things are just kind of a, a mess and it's hugely problematic. Um, significantly complicates and slows the recovery process.

Um, having good documentation for BIA and, uh, you know, disaster recovery and business continuity is essential and is very, very helpful. Um, but I will point out that after the first shot's fired, you know, as they say, everything changes. So it's never perfect.

Um, but, um, having the, the BIS and the other, you know, preparedness, you know, helps the outcome and it results and it's, I dunno if it's the result, the better outcomes, outcomes might be the result of higher operational maturity level within the client organization and the MSP. Um, but the outcomes are always better when they have that.

Um, and I'll add that, I think doing that whole process helps everybody learn about the deficiencies on the systems, and they gain a clearer understanding of the infrastructure, um, when they do the bis and, um, and if, if, if there isn't a, a business impact analysis done, um, my company Al Vaca, we're doing that on the fly, right? During the middle of the recovery, we're having to do it on the fly, right? And, and it's a problem.

Um, so, and this is where I'll give a plug for G no's, you know, product, um, a lot of what he does with his service product and, and, uh, you know, I, I was not brought on here to do a plug for gnome. Um, but I'm familiar with his product. And for companies using a, a product like his, they're gonna be better prepared, um, in the event that, um, you know, if these things happen, or as Eric said, when it happens, you really have to prepare for when it happens.

If you're in business long enough, you're gonna get hit. Yeah, yeah. Yeah. And you know, to that point, um, Oli, you know, when you think about, um, doing a BIA, what I often hear is, you know, like, who, who needs to, you gotta go, who's involved, right? And then all of a sudden you get players. Now again, you have to charge for these types of things, right? And, and this is something that a lot of MSPs go, how do I charge for, I have never charged for bia.

But what, so what often comes out is, you know, and I can think of this one in particular case where they sat down and they were mapping out, you know, the critical processes and systems and somebody in marketing popped up and says, oh, you know, we put all our contracts back up in Salesforce, right? And literally it was like, again, like everybody like turned and looked and they, they were like, you do what? Like, yeah.

And, and it was, it was at that moment, like, like literally 75% of the company had no idea about something very critical. You know? So one that's, you know, things you find out and, and you know, Eric, what are, what are some of the ramifications of that? If you don't know those things until you know the, you know, what's hit the fan Yeah. It, It, it's too late. Right. And, you know, to to paraphrase Mike Tyson, you know, everyone's got a plan until they get punched in the mouth. Right? Right.

And, and once you get punched in the mouth, um, you know, all bets are off, right? If, if you, if you don't have a plan, it's bad. It's not quite as bad as if you, you know, compared to having a plan, but not exercising the plan, right? 'cause you're not gonna be prepared to exercise the plan in the heat of the battle. Mm-Hmm.

Um, and then, you know, for, for those, I would say very few companies that have a plan, exercise the plan via tabletops or something else, preferably with a third party, right? Mm-Hmm. Whether that third party is an application or a person, it's really, really easy to lie to yourself, right? And they we're prepared, right? Oh, we have an incident plan, we've even printed it out on paper. Right? That's what you always hear. It's gotta be printed on paper.

'cause you might not be able to access your systems. But, but, but too often companies lie to themselves and they say, okay, we have this plan and we've, we've exercised it internally. Right? But until you have a third party come in and ask the hard questions and really make you think about it, then you're just not prepared. Mm-hmm. Yeah. I'll add to that.

Having a third party, um, qualifying for a third party trustmark type certification, um, also gets you outta your comfort zone because you can't fool yourself right now. You gotta be con convinced. That's kind of one step maybe on the insurance company, um, because there's a certain level of compliance there, but complying with, um, trust marks that, you know, certify that you're a safe partner to do business with, that's an extra level.

And then we also have a third party that does constant vulnerability assessment on our systems. Um, you know, we certainly are capable of doing those things, but we pay for a third party to do that, and we have meetings with them every week. Hmm. Interesting. Um, so Oli, uh, I'd like your take on this and then Eric, um, have you ever had a customer, you know, when you start to talk about incident response, Ollie like their plan, they go, well, you, you guys do that for us, right?

Like, don't you have the plan? Um, have you had that experience? Do you know MSPs that have had that experience? If you're an Ms P listening, do you, have you ever had a customer say, well, you have the incident response plan. Um, talk to us about, I Can't say that our clients have come to us, uh, that I'm aware of. I'm saying you asked them and they said, oh, you have it. You know, you do it. Yeah, Yeah, yeah. Yeah.

So, um, yeah, no, I, we help, we help clients put together incident response plans, but, uh, I think our consultation with them is pretty, um, adequate enough that, uh, that they're not expecting us just to have that whipped out, out on the fly. Yeah. You also have bigger customers, to be fair. We do that, that, that aren't gonna just, but Eric have you, and it's interesting, Mark Wilkins says all the time, you know, you, you, you got the plan, Eric, have you had that through MSPs?

Yeah, Mark's absolutely right. It's not, oh, you have the plan, Mr. Ms P, it's, I don't need a plan 'cause I have an MSP, right? So, um, so yeah, it's a big deal. And then, you know, you, you get the, oh, can you just give me a form incident response plan and that's what we'll use, right? Right. And, you know, to some people that sounds okay. You know, number one, it's better than nothing. Um, but it really needs to be tailored to your business.

Um, just like your MSA needs to be tailored from your business, for your business, your managed services statement of work needs to be tailored to your business. IR plans are exactly the same way. Um, I will not give a client of mine an IR plan. Right. I've got oodles of them. Right. But I'm not gonna give it to 'em because I know if I give it to 'em, they're just gonna use it. Right? Mm-Hmm. They're not gonna put any brain power behind it to, to come up with their IR plan. Yeah.

So I know we only have about five minutes left, left, Eric. So we'll go with some big, hopefully some big, uh, hits on the way. You, you know, you're obviously always reviewing MSAs. If there's one or two things you see MSPs taking on risk where they don't need to, what would those be? So, um, let me shift away from Ms. MSAs to statements of work. Right? Okay. Managed services statements. Sorry. Statements of work. I should've said. Yeah.

So, um, there are two huge categories where I see MSPs falling on their face every single day. Number one, and this is probably the most important, and that is when do the services start, right? Every time I bring on a new client, I look at their, their managed services agreement. It says, services start on the effective date. And I know for a fact that as soon as they get a, a signature on that, that statement of work, they're sending out a bill for the first month. Right?

Which isn't necessarily bad, but now the customer has a piece of paper that says, all right, my MSP is going to gonna do all these things for me, right? I signed it today, it says it's effective today. I've paid 'em for the first month. Well, what happens tomorrow when there's a security incident and there's a ransomware attack and you need to restore from backup, and they come to you as their new MSP and say, Hey, we need to restore from backup. And you say, well, wait a minute.

We haven't even started managing your backups yet. Right? We haven't figured that out yet because you just signed yesterday. Well, the problem is you have a piece of paper that's signed by the customer that says you're gonna manage their backups and the customer's already paid you for it. So who's responsible? The MSP is responsible.

So being excruciatingly clear with your customer, both coming and going right on the coming side, it's making sure when exactly are you as the MSP responsible for delivering all of the services that the customers signed up for, um, versus offboarding, right? And that is when do you draw the line in the sand and say, all right, Mr. Customer, I'm not responsible for anything anymore. 'cause you're transitioning to the new guys. 'cause they've already turned over their admin passwords, right?

So very, very, very few MSPs put any thought into that at all. So it's, it's the coming and the, the going And, and the good news now for a lot of MSPs, Eric, is because of the economy, we're seeing more and more outsourcing, we're seeing better deals. Yeah. Which creates backlog. Is this part of the issue? It's Absolutely part of the issue. And, and the issue is twofold, right? One of them is backlog for the MSP.

How long does it take you from the minute a customer signs an MSP an A managed services agreement with you until the time that you're prepared to fully deliver your services? From what I hear, it's somewhere between three and six weeks, right? On average. But that's something that you can't control. Why can't you control it? You can control parts of it, but you've gotta rely on your customer for parts of it too. And what happens if your customer isn't cooperating?

And I know every MSP on this call has had situations where they haven't fully onboarded a customer for six months after the customer signs a managed services agreement with them because they can't get the customer to cooperate. So writing those contingencies into your agreements for not only when are you responsible for delivering services, what happens if the delay is not caused by you?

And then how do you gracefully off board, um, are things that, uh, that MSPs in my opinion, really, really need help with in their statements of work. The other thing, and I know we're running outta time, but the other thing is service descriptions and telling your customer what you're gonna do. It's not good enough to tell your customer, I'm going to update and patch your servers. I'm going to update and patch your desktops. That's just not good enough.

You need to be so explicit into the, you know, we're taught in the third grade when we start writing essays, the who, what, when, why, how, how often, et cetera. You've gotta have that level of detail because you're gonna be held responsible for it. Right? If you ever have to enforce your managed services agreements in court, it's not gonna be me behind the bench. Someone who who knows anything about it.

It's gonna be some 80-year-old guy who can't even spell it, who's trying to sort out these contracts. And if it says that you're responsible for patching and updating someone's systems and you didn't do it, and well, maybe you didn't do it because the patch came out 36 hours before the incident happened, well, it doesn't say you're, you're gonna wait 36 hours, just says you're gonna update it.

So, so being explicit for every, every piece of managed services that you are delivering to your customers is, is the second biggest place where I see my, um, new clients falling down. Got it. Really good stuff. Oli, how about closing us out, and we'll wrap things up and see if anybody has any questions.

But on the MSP side, are there areas, whether it's tools, processes, people where you feel MSPs, again, are taking on too much risk, um, where they could maybe clean things up a little bit, um, in your opinion? Yeah, I, I would say in the context of what we're discussing here today, it all starts with really good contracts and agreements with the clients. Um, and good consulting to make sure that, uh, both parties know who understands which responsibilities.

Um, and then make sure your security stack matches responsibilities and the obligations that you're promising to the client, right? Um, yeah. And, um, and then take a look at your marketing literature and make sure that that matches your, your contracts and your security stack that you're actually able to deliver on, on what you promise on. Um, and then make sure you have the right team that's actually capable of delivering on all of that.

Um, and, uh, you know, so that's kind of the, you know, tools, processes and, and people, you know, um, you know, package that you need to execute with a high level of operational maturity and everybody will be happy at that point. Yeah. And Erica, and I know we didn't get to to touch on it, but I, as, as, as Ole kind of talked about too, you know, again, I hope MSPs are starting to think more about their vendor agreements. Is that fair? Yeah, a hundred percent.

Um, in my experience, most MSPs will assign anything a vendor puts in front of them. Um, they generally don't negotiate vendor agreements either because they don't want to, they don't wanna pay a lawyer for it. They think that the, the, the OEM won't negotiate it. Um, but you really have to pay attention to those because, you know, things will go wrong with your vendors and you, you don't wanna get left holding the bag. Yeah. Good stuff. Well, hey, I know we're at the top of the hour.

First, I wanna thank the audience. Um, thanks. I hope you guys found this, uh, worthwhile and valuable. Maybe give us a yes, a why in in chat. Um, Eric, if you want to put your email, Oli, you wanna put yours in no one more time if they, if you need to get ahold of any of these gentlemen. Um, really appreciate it. Um, Oli, thanks so much for giving, you know, your years of wisdom in there and, um, Eric, always thank you for, for your stuff.

Noam, thanks for jumping in and, and being so generous with the, uh, with the offer and, uh, wishing everybody thank you a fantastic, uh, day. Thanks for giving us a an hour of your time and, uh, make it a great day everybody. Thanks everyone. Thank Everyone. Bye.