CISA MSP Guidance; how MSPs are using to sell more & what it means to your MSAs

All right. Welcome everybody to week 67, joined as always, my co-host, Gary Pika, Wes Spencer, and Ryan Weeks. Good to see you guys. How are you? Good. Awesome. Good to be here. Well, it's great to have you back. Um, no, you were here last week, right? Yeah. Gary, Wes about that Was the missing guy. Yeah. Had some family stuff going on. Welcome back. Wes were Way down when they heard you weren't on Wes. I doubt that. Um, hey, so just some feedback, uh, from the audience.

If you could let us know in chat, of course, it's delayed 20 or 30 seconds, but did you guys like the data, uh, flow diagram modeling that we did and things like that? Oh, and then there's Dustin Boland, or Dustin. Let me know if you want to come up. I think those are great questions you posed ironically on contract negotiations, because we have Eric Toltz here with us. Again, well introduce momentarily.

Okay, so let me set the stage first off, uh, if I could ask that you guys actually answer some polls, that would be awesome. I'm gonna make the first one visible. Um, so that would be helpful. Uh, it helps in, in the conversation here. So, um, here's what I wanted to kind lay out. Um, you know, I don't know if you guys have seen, and I put it in the right below, you'll see it in the green there, ceases latest guidance, right?

So this comes out on the heels, what you've been talking about around, uh, post July 4th incident. We're seeing obviously lots of change, something that we've been talking about ad nauseum here on the cyber call. The reason I wanted to spend some time on this is not only have I had conversations with a number of MSPs about the document and those conversations, by the way, Gary go, yeah, my customers will never read it. My prospects will, will never read it.

Um, I know you have a different take on that. Um, and then, um, the other side of the equation, you know, in talking to Ryan next, who I'm gonna come to, and then to Eric, but in talking to Ryan, um, I'm like, Ryan, you know, if MSPs get into litigation, my concern is, you know, someone's gonna say, well, who's the highest authority in the land? And let's take a look at this document, what it says from contract language and what it says, you know, MSP should be doing.

So Ryan, what were some flawed assumptions you saw in it? And again, why should we be talking about this? Yeah, I think, you know, let's, let's recognize CISA is an authority on cybersecurity, but they're not an authority on how MSPs service SMBs. So they don't understand the nuances of how MSPs will select their, their solutions and provide their services. So there are some guidance in here, which, um, I think is at best due to a flawed assumption at worst dangerous.

Um, for example, there's a, a section on, um, managing architecture risk, which says to the SMB, um, you should assure that all traffic from an MSP versus A VPN. And that makes my head wanna explode, because like, no, don't know. There should be no VPNs between MSPs and SMBs. Your network should not be connected. Um, so it's, it's, it's, I think there's just some things like that that could potentially make things worse.

But I think, you know, taking it for what it is, it was an attempt to help SMBs assess and understand the risk of, of MSPs. Um, I think the, some of the guidance is just a bit vague, and that's leading some MSPs to try and interpret it and figure out how do I provide this service in a way that complies with the guidance that SSA gave. Um, and it's getting pretty weird.

Like, you know, people are like, Hey, um, how do you know, how would I go about requesting that I build a V VP N to my SaaS providers? And I'm like, that's not how SaaS works. Like, no one's gonna start building VPNs to SaaS services. Like, right, that's, so again, I put that in the flawed assumption bucket.

Like their histor, their, their understanding of MSP architecture is on-premise RMN, because that's what they've seen from the government hacks that have occurred in New Orleans and Atlanta and Baltimore and Texas, and now this Kaseya thing. All of those have been on premise, right? And so a lot of their architecture guidance is assuming these things that they think are knowns, rms are on premise when in fact there's alternate architectures.

And so I think it's our responsibility as, as MSPs, as security practitioners to help the SMBs understand where the CISA guidance makes sense. I love the shared responsibility piece, which I think we'll talk about quite extensively. Um, but I think we also just need to be careful that some of these, some of the guidance in here is, it is, is not coming from a place of full understanding of MSPS and B relationships. And, and that's okay, right? CI's trying to help, they're not trying to hurt.

We just need to help. Um, you know, it's creating an educational opportunity for us with our customers. Why is the way I deploy services to you as good as, or better than the requirements that cease to laid out, right? Because it's, it's fine when you're trying to adhere to a standard that maybe you don't do exactly what the standard says if you're doing it in a way that is better than what the standard requires. And so, you know, there's just some things that we have to parse through there.

Yeah, I wanna, I, I agree with you Ryan, and I think, um, SMBs by, by and large are still unfamiliar with cisa. You know, maybe they've heard of it, uh, referenced in like a, you know, a news article of some kind when CISA ISS referenced in like a large scale breach, but they don't respect them and they don't, they don't recognize them the way that large enterprise does.

And I don't even, I think CISA needs to even come down this journey themselves, like you said, Ryan, of really starting to say there's some brand recognition that we, ourselves need to do, and MSPs can help in that journey. But I, I agree. Like I don't think slapping a CISA report in front of like a small business owner has the same effect that it does.

Like a mid-size or large bank, you know, mid-size and large banks, just as an example, they're gonna tuck away all those IOCs that have been provided. They're gonna share their responses back to the board. They're gonna document that in the minute, so the next examination cycle, they can say, look how we treated this new CA report with gold, right? With, with like almost religiously, right? And small business doesn't do that.

I think the intent is really good though, in the beginnings of the, the CISA report here, especially in terms of like outlining the risk considerations of like, Hey, small business, the first thing you should do is at least begin to assess who owns the risk and how does this outsource relationship work? I have to have some amount of, um, involvement in it. I can't just shove it to my IT provider way I've done in the past. And so I think it's a good start.

And I hope that we, as MSPs, I think it's our job to come alongside CISA and really help them, you know, in the journey of, Hey, have you heard what CISA has said? You may not even be aware of them, but did you know they're a government organization dedicated specifically to the nation's like security, uh, program? Now I realize they don't have teeth, they're not a regulatory entity.

So, but US name dropping and referencing and even sharing in the QBR of like, here's how we're taking this report. Seriously, those things will go a long way. And I, I even say us in the cyber call today, it's our job is influencers to bring CISA to bear because it has benefit to all of us when we get small business to finally recognize it. Here.

Here's what I thought when I went to Appendix A and looked the MSP risk configurate, uh, con considerations, the checklist on top, and then the considerations for operators and all those dots. I said to myself, if every SMB was to really follow this to a t, there would be like, instead of, you know, instead of 4,000 MSPs in North America, there'd be four maybe. I mean, literally there's just the majority of MSPs. They can't stand up to all this. And some of it is vague, right? Yeah.

Some of it is vague, but it's, um, it's painting a picture of maybe what things look like in enterprises or in regulated, uh, areas and, um, and a good vision, right? Where things are gonna have to end up. But as we know, it's so far from the reality of, you know, the majority of MSPs today. So I'm glad you all spoke about that because, uh, I had no less than, uh, 10 interactions with the speaker bureau, uh, of csa. And wouldn't you know it, they couldn't find anybody.

I guess there's only three people in csa, they couldn't find anyone to talk on this document that they put out. So, uh, I found that quite interesting. So let's look at this. The other reason I wanted to bring now, so I'm gonna introduce Eric Tilts, who will tell a little about them himself and, and his background with MSPs and what he does. But Eric, after you do that, you know, again, Ryan looked at some flawed assumptions here. What, what are some things high level?

'cause we're gonna get into it and contracts, I mean, they call out contract language in this. So, so let's start off. Yeah. So yeah, so just a bit about my background first, and, and I'll touch on something Gary said that even, you know, the, the largest MSPs in the world, um, you know, can't comply. And I came from one, and I can, I can assure you that we couldn't have complied with, with everything that they laid out.

But, uh, allegedly a non, I've had a bit of a non-traditional legal career. Um, you know, I've spent about 22 of my 23 years practicing law for IT services providers, MSPs, um, and now I exclusively represent, um, IT service providers and MSPs in, uh, for my own firm. But I started as one of you, um, I, uh, I was a partner in a, at the time, it was a very small, uh, var. We became an MSP.

We grew the company to about, from the three of us who were partners to about 250 people, um, before we sold to a company called logis, a very large global IT services provider. Um, and then I spent about nine years as the general counsel for logis, meaning I led their legal department, um, and I was their chief risk officer. Um, I was their head of information security and compliance. Um, I, uh, I did it all before going out on my own, um, and now exclusively representing companies like yours.

Um, and, and like I said, we, um, you know, we would spend a lot of time thinking about things like we're published in the, in the piece of paper. Um, but not only didn't we comply, I don't think, I wouldn't recommend that we would comply. Um, with, with everything that's laid out there. A lot of it just doesn't make sense, Right, Eric? And so, so quick, real quick contract language that you may have saw real quick that stood out to you. And then we'll get into it.

I'll, I'm gonna tee up AC actually, let me tee up Gary and then go to you. So, Gary, talk to us about, even though, you know, we're all sitting here saying, you know, the, the, there's some flawed assumptions, et cetera about, about this document, you see it a little bit differently in that doesn't mean we should, you know, tuck this document away.

Um, you know, this is something that, you know, you're educating people to actually use, uh, as a mechanism because these are the questions they're gonna start getting asked. So you're getting out ahead of it. Is that, is that fair? Yeah, I, I think that anytime we can look, it's very rarely that we get third parties, uh, and, you know, government, you know, agencies that could potentially be a, a, a wedge.

And again, this is just guidance, but, um, I, I'm encouraging people to unders really understand this document and make sure I, I think it's something you can use both with prospects and with customers. Not to ask 'em, maybe to read it, but to have your way of distilling this down overall what it means and just shows that you are, you know, a security first firm when most aren't.

And so, I, I, again, I think it helps with customers kind of explain the journey and, and really using it on the shared risk side. 'cause I think that's important. And I think with prospects, uh, I think it's a way to use it as, as a wedge in terms of uncovering pain. But you gotta be educated and know where you are because you don't want it also to blow up in your face. Yeah. Yeah. Very, very true.

So, so to that, Eric, you, um, you know, I wanted to have you on because, you know, I'm getting questions constantly about MSAs and sows and things of that nature, and thanks for fielding a lot of those. But this document calls out literally contract language in it to look at, and I wanted to get your take before I hand it over to Gary and you and the team to kind of dig in here. Yeah.

So without digging into the specific contract language it calls for, and it does call for some pretty crazy stuff, um, I think we have to look at how it could be used either for or against the MSP community if ever came to shove, right? And when you negotiate an MSA, when you negotiate a sow, you hope to put it in a drawer and forget about it. And as soon as you have to pull it out and look at what it says, then you know that there might be a problem. And why is this important?

Why is this CISA doc important? Well, depending on what your MSA says, it will tell you what standard of care you're going to be held to. Are you gonna be held to the highest degree of care? Are you gonna be held to the standard of of care that's, that's, that's for your industry? Um, is it gonna be the, the, the best highest, you know, pick a superlative that, that your customer and ultimately the court will hold you to.

And the problem is, is that if you ever get involved in litigation with your customer, um, if there's ever a breach, if, if you ever have some sort of a, a, a claim of negligence or claim that your services failed for some reason, um, could someone pull out this document and say, here's the standard you're going to be held to, and if you don't check all the boxes, then you're liable. Um, and, and that number one is, is kind of dangerous.

But if I'm on the other side of the table representing the, the client who was maybe harmed, this is exactly what I'm going to do. I'm gonna find a document like this and say, Ooh, it's a big scary government document, so it's, it's gotta be right. Um, and now I'm gonna hold you to that. Um, and that's, um, and that's tough.

And that's why you've gotta make sure that when you're negotiating your MSA or when you're even drafting your, your first version of your msa, that it speaks to, here's the standard of care I'm going to be held to in case there's ever a problem. Got it. So Gary, I'm gonna turn it to Go ahead. You're, yeah, yeah, yeah. So the first question I would say is, you know, um, week in and week out we talk about using standards, CIS, nist.

And do you think, like today, because this is just general guidance, do you think that the MSP, um, you know, should point to like some standards at least they have that as a standard of care, that's something that's established. Um, so they could, um, I'm, I'm not a huge fan of pointing to standards, particularly in the IT industry because they change so much. And we could agree to something today that three years from now, no one's gonna even know what it means.

So, so I would prefer to, to pick the particular parts of those standards, whether it's CIS or NIST or anything else, and say, here's the standard I'm going to be held to. Um, because that's what might make sense. It NIST might not make sense five years from now when the, the MSA that we've negotiated five years ago is still in place.

So no matter what it seems like now, as soon as you start to put more specific things, like you said it, we could have an MSA and revisit it, you know, once years could go by, right? Yeah. So now what you're saying that MSA is gonna start to have some pretty specific things Mm-Hmm. Both for our protection and and expectations. And to me that means like, it almost like ha has to become a living document.

And that's a, you know, that's a big step from where most MSPs live from a legal environment today. It is, and it is tough. And, and, and if possible, I'd rather see that in a statement of work instead of in the MS A, because a statement of work tends to be a little bit more of like a living document, like you said, than than an MSA does. You know, it changes every year or two or three years just by its very nature.

But, um, but yeah, so, so if it's gonna go somewhere there, if not just a general statement in the MSA that we're gonna deliver services according to the standards of the industry to which they retain or, or something somewhat a little bit more, uh, more generic like that. But, but how do you take Gary that that same language and spin it on the, on the sales that process? So I think you have to as always separated into, you know, prospects looking for new logos and, and customers.

And I think it always starts with customers because that, that's our obligation. And they're the people we've already committed to providing some standard level of care. Probably, like most MSPs, a lot of our customers have been with us so long, the standard of care we promised them when they signed up with us is totally irrelevant, right? And now think about it, MSPs are signing three and five year deals, Eric. Mm-Hmm.

So I signed an agreement four years ago how that doesn't, that didn't really have any, it just said we'd call 'em back within two hours. That was our lev, that's, that's our standard level of standard level of care. So I think, um, one, and I've thought about it from a, you know, we use standards to do this. You can use guidance documents. But from our conversation today, I almost think it has to get into their SOW. And again, I would use them all in the same way.

Hey, we need to have an, you know, updated, uh, you know, scope of scope of work because here's kind of what our, what our guidance is now of, of what you can expect from us. And, um, all of these things are to educate our customers. When you learn to do that, I think it becomes really easy to start to use those as wedge in, in the sales process.

The people that are best at this, from like a, you know, A-V-C-I-O standpoint, those organizations are also the ones that will inevitably be adding customers. And we see 'em now at 200, 2 50, 300 a seat without an issue. Eric, Can I just ask you a question? Clarify something. 'cause you were saying, you know, they do need to be, you know, look at a standard, but the standards change. Would it be wrong though to maybe say, Hey, we look at as an example, CIS because CIS changes.

But if you don't say we are, we are, we're at version seven one, but at least you're now looking and, and, and are very strongly recognized industry standards that we have due care and process internally. Yeah. If, if you as an MSP are actually going to meet those standards as they number one exists today, number two will exist tomorrow, then fine. Um, but just know that it's a little bit more dangerous to do that.

Um, because I mean, you, you, you, you look at, at all of the CIS standards and all of the controls and all of the policies that, that you have to comply with, it's easier from the, when you're sitting on the other side of the table to pick it apart. 'cause there's, there's 300 things and you can say, well, there's here these 12 that you haven't done very well. Sure. So just real quick follow up, and Gary, I'll let you guys take it back, but, so then what is, what do you do?

Where do you call out that we do have due care to some, Some standard. So I can, I can tell you where it should be. It, it should be in a, in a warranty section of a an MSA. It should say that, that we as the MSP are going to perform all of our services in a professional workmanlike manner with conscientious employees according to the standards of the industry to which the services pertain. That's, that's generally speaking, um, how it would go down.

You can get more granular than that if you want. You can mention CIS standards. You can mention this. Ummm, We do. Yeah. Yeah. I'm not sure that's the, the best thing to do though. Okay. Yeah. And then last thing I had was, um, you know, when I read, uh, the piece in there about understanding supply chain risks associated with your MSP, you know, that's a tough one.

If you listen to our call was like two weeks ago, I think, when we were talking about APIs, realizing that MSPs have, you know, 25 sometimes 30 tools now, and they're always looking for APIs integrations. And so, you know, Ryan did a little document, like a little flow chart and it looked like spaghetti really quickly. So when I read that, it gave me a little like, uh, you know, like, wait a minute, that's gonna, that's gonna be a tough one. Any recommendations about how MSPs navigate this?

Yeah, so MSPs are definitely gonna be asked to open the kimono a little bit more than they ever have, especially if, if documents like this ever get down into the, into the SMD space. And, and again, you can handle that contractually, right? You can tell your customers, okay, here's what you're allowed to ask me. Here's how often you're allowed to ask me these questions.

If you wanna come on site and take a look at my stuff, maybe that's okay, maybe it's not, but, but we'll put it in a contract. And, you know, Wes could probably speak to this coming, there's No on site Un understood, but, but from a, a banking perspective, right? So I can't tell you how many times we'd get a, a 200 page questionnaire, you know, via via email saying, Hey, fill this out and tell us all about how you conduct your business, um, from a security standpoint.

And, and that those types of things should all be addressed in your MSA where yes, it's okay to do it. I'll do it for you once a year. I might charge you to do it, right? Because if I'm gonna devote someone to, to fill out this 200 page questionnaire, that means I'm taking 'em out of the field and I can't, I can't bill for their time anymore. So I've gotta bill you. Um, but all of that should be, um, addressed at the very least in your MSA, Uh, that's a really good point.

Like, let's, you know, let's fast forward, Wes, what if you're an MSP and you got 60 customers and in the next few years, all of 'em, every time they get their e and o or they get their cyber renewal, have different questionnaires, and now we're getting, you know, eight of these a month of all different flavors and it, it would be unmanageable. It's like almost we have to think about heading this off. Can you imagine that for Yeah, I mean it's onerous right now, no doubt.

And, uh, a few thoughts on it. First, the insurance, uh, industry themselves needs to come together and understand what does it actually look like to be able to define some standard set of security requirements. You know, I even said this at it nation secure of, you know, regulations, some form of fashions coming, insurance will be the ones that drive it.

'cause they're the only ones with the teeth, but we we're still lack a standardization from them or even a declaration of what that standard might be. That's a challenge. And, and Eric, I hear you loud and clear that standards themselves tend to be so fluid that it's hard to adhere, but we've gotta figure that out. That's step one.

And then I think step two is when, when at my bank, I, I sort of noticed there's like this revenue thing that happens where like if I'm much larger than the vendor I'm engaging with, I call the shots and I get to say, this is how you're doing it. You're adhering to all these things. But when I go to like a DNH, I go to like a Jack Henry, one of these big monster companies that's orders of magnitude bigger than me. And I say, this is what I need for my vendor management.

They say, well, here's what we have for you. Um, we have everything you need. You're just gonna have to make sense of it. And that was frustrating, but it's sort of like Gary, it's the end of the day, it's how they operate. They cannot afford to send every one of their thousands of community banks individualized risk assessment pro. They just can't.

So I think there's muddiness here that we're gonna have to go down this journey of figuring out where does the standards lie and, and how should it look so that this is much more, um, defined. Yeah. And I, and I think it will be insurance driven. I mean, we have, you know, we have, uh, GFI outlets in our houses and we have airbags and, and seat belts because of insurance companies, basically. Can I, can I ask a question?

Maybe Ryan, to you here, like, you look at, let's just pick ServiceNow, you know, we westminster's these big companies and, and you know, you go and as an example to their website and they talk all about their security or any of the big players knowing that MSPs are gonna get more third party questionnaires. Are they, should it behoove them to start thinking about, you know, do documenting and doing those things? Yeah.

Because Gary always talks about, hey, if, if we need a process, that means there's people and that means money. So thought on that. Yeah. Uh, it does. I'm, I'm laughing and Wes will know what I'm talking about. It reminds me of bits light, remember Bits light. So bits was this, um, it was supposed to be this standard questionnaire that every person, every entity in the financial services area would fill out, and you would all fill it out.

And then when someone had needed to do due diligence on you, you would just give them bits or bits light, and that would be it. And so there was no more like, I need to answer your custom 200 questions and someone else's custom. The problem is, is now it was like, okay, well you need to answer 'em, but you need 'em. Upload 'em into my form and oh, I have these 10 other questions, so gimme your bits light and then answer these 10. And it, it never really became what it was supposed to.

But I, I had that problem when I was in financial services and I had that problem at Datto. Um, and so one of the things that we did is we basically went through something like the cloud security alliance questionnaire. Um, you know, we stole stuff from bits and we actually started building out a questionnaire database based off of the common questionnaire frameworks and inputting our answer.

So now anytime our sales team gets a request, they can go to that database and get the most UpToDate answer from my team, which is keeping those answers up to date. But the, the crazy thing is I have probably a dozen people supporting that workflow at any given point in time. It is onerous. So yeah, try to come up with a standard, but realize your standard's probably only gonna save you 50%. Um, someone mentioned SOC two that'll make a lot of things go away. Um, but not all of them.

Like there is no silver bullet to dealing with this. And like, this is just part of the pain of growing into vendor due diligence is no one has across all industries come to a standard of what are all the questions we need to ask in order to, to, to be seen as trying to effectively manage our risk. And there's, then there's a whole practical side of this conversation, which is how, how much are you really understanding risk by asking someone 200 questions? Right? Right.

I mean, I'll give you a story. We, we talked to someone last week that we were like, Hey, tell us about your security program. And they're like, security lives in our hearts and minds, and we stamp the big old fail on 'em, right? Like, okay, like that helps. But I mean, this is a hard problem. It's, it's a great segue though, Eric, to your question, I think to Gary about scale. Um, because if you could go Into that.

Yeah, I, I mean, uh, you know, Gary, you mentioned that, that, you know, if, if people take this cease to report seriously, we're gonna quickly go from 4,000 MSPs to four. So number one, what does this mean for the m and a space? And number two, how does the smaller MSP stay viable? Yeah. Um, boy, I, I gotta tell you, Eric, that's a question, um, that I ask myself a lot.

Like, I, I've never, in all my 25 years and owning and working with MSPs, there was never a time when I said, man, I feel like things could look a lot different in five or six years. This is the first time I ever felt that way. And, you know, we don't know right? Until it, until it happens.

But it feels like, uh, a lack of scale, uh, unless there's some other mechanism, right, that comes into place, um, that takes care of some of this stuff and allows an MSP to, you know, a small MSP to do what they do. Um, you know, and, and, and sometimes I wonder whether I know some of the biggest MSPs, and I know some of these, uh, I know most, a lot of the roll-ups, and I'm wondering if there are any better right now, you know, uh, at it.

Um, so I think the, the short, the short answer is I feel like every MSP, and this is the guidance I'm giving my peer members, is to think ahead about like, where we are with this and make your plan. You know, does this mean you might, you don't want to be part of the big MSP, maybe you'd find another one to merge with. Does it mean you need to really hone in on who that customer base is and what you need to do for them and carve out that niche, you know, whatever it is.

But you're gonna have to make some pretty deliberate decisions with the information we have as it changes where I don't think you had to, before you could just come in every day and answer tickets and alerts, and once in a while a new customer landed on you and you know, you made some money and you went on to the next thing. I think, I think those days are now sunset. Does that make sense? Yeah, I agree. Yeah. Wes, what do you think about that?

I, First, I have to think about how to come off mute. I agree. The days are changing and there are outside impetus that are forcing changes to happen sooner than the, than we want. So for example, before we jumped live, we were all talking internally just a bit about, you know, even the insurance. Like you're seeing this reported in Reddit and other places about carriers dropping coverage, um, very strange requirements of like, you can't have this vendor, you can't have that vendor.

And anyone that's inside the industry scratches their heads and, and is like, Makes no sense. How does that, how Does that even make sense? Right? Like, like how does, yeah. So, so we have a lot of, like outside if, if it's like a catalyst, right? Like I'm doing like chemistry, there's, we're adding a bunch of stuff into this that's gonna cause some outputs really, really soon that are gonna force us to have changes foisted upon us. And I, for one, welcome those overlords.

I'd rather see a little bit of chaos thrown into system to force us to get better than the current status quo of where we're at right now, because it's not working. Well, I, I, I'll just say this one last thing on it before, um, if Ryan comes back, we'll, we'll go to Ryan, but, um, you know, for me personally, it's one of the reasons why I'm here right now. Okay.

And I mean, he, not just on this call, but here in the MSB space, you know, I feel like I've watched this industry, you know, grow up and I know so many of the good people that have built it. So finding a way to keep that intact so that these entrepreneurs can have what they've had in the past, which is a, you know, chance to grow and control their own destiny. And for the most part, they want to take care of their customers and employees.

And, um, you know, we're doing that through education, through things like this, but we're gonna find, you know, find more ways. It's, it's, um, this probably I feel like is the most important time and the most important cause, uh, in the time that I, I, I, you know, that since I've devoted my life to trying to help in, uh, MSP entrepreneurs. Yeah. Really well said.

So as we turn over to Ryan, Gary, I, I just, I, you know, all the major changes that we've gone through and conversations you, I just, I never recall this feeling ever. No, it's never been like this before. Ryan, over to you. Sure. So Eric, um, the guidance calls for MSPs, um, or SMBs to maintain their own offsite backups and network activity logs to facilitate recovery from a critical incident with an MS. P.

Um, knowing MSPs are typically the ones that are providing the backup and intrusion monitoring and, uh, logging infrastructure for these SMBs, how should MSPs think about, um, contractual language or, or, or kind of meeting the, the spirit of what CISA was after here? Yeah, it, it's a great question.

And, and I, I actually usually use, when I'm developing a new statement of work, uh, with my clients, I usually use managed backup as the example, because, you know, we're all thinking about, well, at least we should be thinking about what happens if it fails, right? What happens if there's an incident and I need to restore from backup and I can't, for whatever reason, right? There could be a hundred different reasons why you can't, but who's responsible for it?

And I can't tell you how many times I come across a statement of work that says, we manage your backups, and that's it, right? And, and it doesn't say what we do and how we do it, and how often we do it, and what's included, what might not be included, what you as a customer are responsible for doing as it relates to your backups, whether we're, we're primarily responsible or secondary. It, it doesn't, it doesn't really talk about that.

And if it ever fails and it will fail, it's just a matter of time when you're trying to restore it from backup, then who's on the hook? So that's why when we're writing our contracts, we have to make doubly certain that things like managed backup are spelled out in, in much more detail than just we manage your backups. So, so Ryan, knowing that, that your mantra is cyber resilience, would you recommend positioning the need for both BCDR along with incident response plans and tabletops? Yeah.

I mean, this, this gets to the whole right of boom, right? Respond, like being able to respond, being able to recover. Testing your backups is really just part of a larger response readiness and restoration to normal operation, right? That's kind of your, your last phase in an ir. So if you're testing your backups, but you're not, you're testing the last step in a thing that has much more steps that you need to practice, right? Practice like you're gonna play.

And so really you need to start with ir. How are you going to respond? What testing do you need to do there, tabletops to understand your readiness? And like, you know, we don't just say tabletops because it's fun, like we do them because that's how you learn, that's how you improve. And frankly, I think if more MSPs were doing IR tabletops, they would test their backups differently, right?

Because how many MSPs test their backups and recovering from their backups in a way they will need to, when they suffer a ransomware incident. Almost none of them we're doing That. Do you know what else they Would be doing, Ryan? What? Um, Charging more. Yeah, probably. I mean, there's a, you know, maybe, maybe you can turn that into a service, um, you know, cyber resilience readiness, uh, assessments, um, as a line item, right? But, uh, yeah, it's, it's just, it's crazy to me.

I think it is important. Like all they're symbiotic. They have to go together. The only thing we never really talk about when we talk about kind of cyber resilience is this concept of crisis communication and crisis management. And I think that's a whole nother discipline. You can tabletop that alone, which is this event has happened. There's the how will we respond technically, how will we recover technically?

But there's a whole separate piece about how will we communicate, who are we communicating to? How frequently are we communicating? And that ties back to our contracts too, right? We, we need to understand what our requirements for disclosure and frequency of communication and type of communication is in our, in our MSAs. And so there's, there's a whole world here of things that needs to happen from a cyber personalized perspective, and it's much bigger than just testing your backups.

Can, can I just ask a quick question to that, Ryan, and rather, rather to Eric, Eric, like, just like communication, like who handles PR and Mm-Hmm. That something does, we could go on and on, but like something that should that stuff, you know, start to get called out like in the event of an incident who, what role responsibility, et cetera, because absolutely. Managing backups, I'm assuming that language you don't see in there too often either.

No, we just don't, doesn't mean it shouldn't be, but we just don't see it. Yeah. So Gary, are, are you having true methods MSPs loop back around in their kind of quarterly reviews with our SMBs, um, to address any of the gaps? Um, that, that we mentioned? A hundred percent. I mean, that's really today mainly from our standpoint, like the, the customer always brings us, you know, business requirements.

And almost every small business has a different business plan now and going forward than they did. So it's a great time to have these conversations, but they're always balanced with where those gaps are in terms of, and again, we have to have a way to determine whether it's a guidance stock, whether it's the standards we use, we have to have a way on our side, you know, to bringing those to bear. 'cause their plan moving forward. Ryan has to do both.

It has to help them get their business where they want to get to and operate in the way they wanna operate. But it also is gonna have to address, you know, the, the changing guidance and the changing, uh, security, um, security landscape. You know, um, I did a little survey on a call that I was on with 80 MSPs about threat intelligence, you know, 'cause we just, you know, talked about it.

And, um, and the reason I did was I talked to a four or $5 million MSP who when I mentioned, uh, M-S-H-T-M-L, like they weren't aware of it, right? And I was like shocked for a second. And so I asked how many people here have a process, somebody assigned and, and a process for doing some type of basic threat intelligence. And, um, more people didn't than than did.

And so, uh, Ryan, if you don't have that, if you're not doing those kind of things, I think the things we're talking about today are probably a long way from home. I mean, it's crazy to me because like, I mean, maybe this is me being too security purist, but like, that's not even threat intelligence. No. That's, That's, that's vulnerability management. That's, that's, that's understanding the technology you have and what vulnerabilities exist in it.

Like that's even more basic and fundamental than threat intelligence, right? Granted, if you were plugged into more threat management, um, you know, threat intelligence communities that might have come up for you. Um, so it's, it's a way to get exposed to kind of some of the more serious vulnerabilities that are being exploited. And there has been emerging of threat and vulnerability management over the years.

Like now you see a lot of job postings are like, you're gonna be the threat and vulnerability manager because like we've, we've kind of combined these two things, which are distinct. But yeah, that to me is crazy. And like, you know, we say threat intelligence, we don't mean like sticks and taxi feeds or indicator compromise or feeds of IP addresses and file hashes and domains.

I'm saying like, log into the cyber nation and like see what other people are posting about vulnerabilities that are affecting MSPs. Like, that is a simple way to accomplish yo and Andrew even has labels in there. This is vulnerability management. This is threat intelligence. Like, you know, there's, there's all sorts of ways that you can subscribe to that information, but yeah, it's, it's, it's crazy to me that like, just some of these basic things are, are, are missing. Yeah.

And it keeps coming up. Almost every week we hit on something else and, you know, I take it back and I socialize it, you know, to, to my, to my true methods members. And it really is starting now. Um, like my last message was, have you heard enough yet? Literally that was the, that was the, the name of, of the little podcast, uh, you know, that I do. So it's, it's piling up. I had a question. It wasn't Eric, uh, the number one related to legal.

The number one question I get every single week, I get this question multiple times is, um, you know, should they have a, um, you know, like a, a letter that, that someone has to sign when they don't take a recommendation? Yeah. So you could, um, some of my clients do, but we have to look beyond that. And, and what's number one is anything that you have in there enforceable.

And, and you can write it in such a way that it's enforceable, such that you're making a recommendation, the client is refusing and you don't stop there. You, you keep going and you say, if something happens as a result of this, then you'll hold me harmless. You'll release me from a Phone. Right? Identify me. Right? And you think that all MSPs now should be using some type of a hold harmless for customers that aren't accepting, let's say, their core recommendations from a security standpoint.

Well, that's the, that's the second part of my answer. And, and that is, what are you going to do if the customer says, no, I don't wanna accept your recommendation. Do you want them as a customer? Right? If the answer is yes, you want them as a customer, then I would not operate without such a, a hold harmless agreement. Um, but a lot of my clients are saying, no, if you're not going to use MFA, I don't want you. Um, and, and they're willing to to walk away from that.

But if you're still willing to take on the business and still win, willing to take on the risk, then you absolutely need something in place. Um, that's, that's not just a document they sign, acknowledging that they, that you've recommended it. It's gotta go a lot deeper than that. So, great stuff. Wes, can I kind of maybe work with you on, on a few questions here to kind of key 'em off and, and so, so some good ones. So let, let, let me just start and I'll go.

I won't go in a specific order, but, um, I like dumpster fires 'cause he, his, he says, uh, or I'm assuming it's a he, uh, because we don't know dumpster, um, will vendors hold their peers to higher standards? And this is something that we talk a lot about offline. So I know Ryan's excited to talk about this and I can't even see Yeah. This window ahead. But Wes starting with you, man. Well, yeah, let me say a couple things.

So keep in mind, um, I'm, I'm sort of external on the security program at ConnectWise, so I do know that, uh, they have a dedicated vendor management group that is responsible for that and cybersecurity is inside of how those motions work. Um, I can tell you at perch, this is critically important to us. Um, even to the point where we provided evidence in our due diligence packages of the vendor review.

We didn't provide all of the high level review, but we would, we would provide evidences and even soc two reviews of our critical vendors. And, um, we did many other things as well in that. But there, there needs to be some visibility and confidence that fourth party to you, your third party, are doing the responsible motions that they need to have in place as well.

Now we know, we all know that there's a fair amount of trust inherent in those, those, those motions, but I think the more we go through a formalized process of this, the better off we are. And, and you know, Ryan, I know what you're about to say and I'm gonna preempt it a bit and let you chat.

I would expect if I'm the CISO at Datto, that Datto would be doing a ton of stuff, like to a very deeper degree than even the MSP would do to really ensure, and one of those reasons why is because you have the muscle power to do it. You have the size and complexity and buying power to go to those third parties and say, look, we know what we're about to spend with you. You're going to be doing these things and we want evidence of it.

Do You just, Ryan, before you answer, do you, I think the question, the spirit could be also though, like data holding perch and ConnectWise and ConnectWise holding Exactly What I mean. Yep. So go ahead Ron. Yeah, I, we all need to be in this fight together. Um, and we need to be talking more.

Um, there are active efforts offline to, you know, we, you've heard Wes drop this concept of a fusion center before, and, and you know, he, he reminded me of, of days past and in financial services when CISO's at competing banks would, would collaborate more. And it reminded me like, well, if I'm not seeing that, like I'm not just gonna sit here and be like, oh, well I wish someone would do that.

Like Wes and I are going and starting to, to collect our peers and start difficult conversations and figure out how to interact more. And I think as, as your vendors mature, because they're on a maturity journey themselves too, right? Datto is not in the same place now that it was five years ago when I joined much different company, but we're still on a maturity journey ourselves as we mature our standards for what good looks like mature.

And as those mature, when we do things like integrations with other vendors, our architecture standards and requirements become more stringent. We get to push back on some of those integrations, be like, listen, we would love to do an integration with you, but like what you're requesting of us to provide you does not meet our architecture standards. And we would love to work with you on a, on a better way for you to do that.

Um, and so I think there's like the kind of the tactical, like as you're building strategic relationships, but there's also like this, forget about the actual like, products development day, day-to-day stuff. What are we as CISOs in the channel doing to better collaborate with one another? And, and we're, we're actively working on that.

Like, um, it's, you know, we've got a bunch of new players, um, in the space, uh, and we're, we're right now getting to know each other and I can say there's a lot of interest in figuring out how to, to support each other, not just hold each other accountable. I think that's, that's kind of the stick side. I think the carrot side is how do we support each other to create a more secure ecosystem for all of us to exist within?

Because Allstate, in his example, when Kaseya gets breached, it's bad for all of us vendors and MSPs alike. So we, we can't tolerate that anymore. We, we have to work together more. I remember that weekend, well, all of us, we were on the call, we were on the phone together, and Brian, you were slammed. I mean, like beyond, like it took you weeks to dig out just from that. So it's not, I, I, I'm glad Dumpster asked the question.

Um, and, you know, so to to that, um, n next one if I could, um, this is kind of to, to, to Eric. Eric, um, question comes up, should we have legal doc, a legal document that we send our clients that lists out specific things we're doing to them? So, um, you Know, um, I, I think that you need to, to contract with your customer and tell them what you're going to do. I'm not sure you need to contract with your customer and tell them how you're going to do it. If, if that makes sense, right?

Your, your, your SOW should cover everything that you are going to, to manage and monitor, um, and take care of for your customer. But the methods and methodologies you choose to deliver that service should be up to you. If for no other reason, then they might change over time. And, and you never want to be, to be looped into to one particular solution just because that's, that's what the contract calls, Right?

I think what you can do to, in regards to this, I was talking with Carl Bickmore about this from Snap Tech and we were talking about trust centers and um, you know, we have one, and, and Carl was like, we were just talking about it. He is like, I think this is great. He is like, I think some transparency here and commitment to like what you're doing is really valuable, even on a public side. It's not a legal document, but it's more just a, here's what we have in place.

And Carl, I'm putting words in his mouth here, I don't even know if he's on the call today, but he's like, we're gonna do that at Snapchat. We're gonna create a trust center and it's gonna be valuable for us to really assess what we're truly doing and then output that into a client facing, um, section of our website that really explains it.

And he's like, I'm, I'm excited about the outputs to that for myself to even look at it and say, are we comfortable with this to say this is what clients are gonna see. We're like pushing this online. Um, so I think that's a great way that you can sort of start in the middle that doesn't replace due diligence. It doesn't replace third party risk management, but it does output publicly some of the things that you're doing, uh, and I think is a good journey for, for any MSP to explore.

But the vendor, to Ryan's point, and there's a lot of work to do at some point, the, you know, the largest vendors in this space are gonna have to bear some of the burden, right? They're gonna have to, if they want this industry to stay healthy for all the reasons we talked about with these, uh, you know, many small, you know, providers with, you know, one to 50 employees as MSPs, um, some of that has to come, has to come off of them there. That's gotta be part of the solution.

So, so two, so real quick here, um, we'll come back to some questions. Um, you reminded me, Gary, to ask the question, if you guys could just throw a yes or no in chat, would you, we've had conversations with like Abel's latest, uh, newest ciso, who's awesome. Would you guys like to have an ask the CISO session here on the cyber call and, um, just give a quick yet Y or why or n um, and then The answer's yes. You don't have to do a poll. P why, why would you not be interested?

Even if it wasn't what you thought it would be interesting no matter what, even if it wasn't the most helpful thing, right? So yeah. So E Eric, as I hand this over to Wes, just, just to kind of think about this. So the first two polls are MSA sold new security solutions since the pandemic mm-hmm, 97%. Yes. Second question. Our MSP has updated our MSA since selling these new and it's pretty much 50 50. Yeah. Why is that an issue? 'cause your contracts are all you have, right?

If there's ever a problem, all you have is your contract between you and your customer. And the problem is, is that if, if there ever is a problem and there isn't a good contract, the person who's gonna be trying to interpret this as a judge who knows nothing about it, nothing can't, doesn't know what an MSP is. So they have to look at the contract, they have to look at the con, what the contract says.

There's something, something called the four Corners says if in four of the contract, then it is what it is, as long as it's clear. So, so you've SA you more than constantly have to update your, so with all of these new issues, um, you know, again, in my logical days, we would update our MSA about three times a year, and our SOS were under constant review. Um, so it's, it's something that if you haven't done, um, do it and do it quickly.

Andrew, can you ask another poll question about the cadence by which MSPs review and update their s Maybe the cadences should be like none quarterly or more recent. Um, semi-annual. Annual, like whenever, not defined. Never. Yeah, I think, I think that'd be good. I think what we're gonna find is it's probably very undefined. Um, and that's something that should be thought through.

I really like the way these poll questions are sort of addressing, um, some pain points here that we probably didn't know existed. So you got a few questions here. Thank you for yeah. Rolling today with us 'cause we went a little bit, but I thought it was just great questions. I'm we'll try, maybe if you guys want, even wanna stay a few minutes after if you can. We've got a few extra questions. Well, How about Andrew?

Can I just, can I just adjust address, uh, Derek's comment that he made about the, uh, the rub with large companies and endless resources and stacks and stack of money to, uh, to do this. It, it is not expensive to review and update your MSA. It is not expensive to review and update your statements of work. And frankly, make sure all of your contracts that you use with your customers, all your contracts that you use, with your, your vendors and suppliers are, are in line.

Um, it's, it's so important to, uh, to, to, to make happen. Um, don't think it's only the big companies that are, that are doing that or should be doing that on a regular basis. Cool. Wesley, you there? Or did you freeze? He looks a little frozen. He looks frozen. So while we try to get we, why, maybe, you know, I could have you, uh, talk about this. 'cause this is really interesting around himself at the station.

That, that one kind of like jumped out at me Because I know if you could Oh, there you are. We there? Okay. Wow. Um, second, trying to find the question. Yeah, it's towards the bottom. Tampa just got internet like three weeks ago. It we're having a heat wave. Gary, the, the internet can't handle it. I don't see the question. Andrew, can you read it to me? Yeah.

So it's like, you know, one thing that you know, stood out in that CISA guidance is, you know, it recommends that organizations require self attestation from MSPs to validate the use of industry standards, uh, and best practices. Um, so I'm just wondering, you know, we've talked a lot about this so far, but again, if this document makes its way into a courtroom, which it, it very well could, if you're a litigator, 'cause I would, if I'm the litigator, I'm going to this. Yeah.

What are the, you know, what are your thoughts? And Eric, yours, I mean, I'll do you one better if why, why self attest to following CIS controls. If you're gonna do it, put it in your contract, put it, put it as part of the shared responsibility model, it is my responsibility that I I will maintain compliance with CIS version eight controls implementation group one or better. That's an attestation and it's now documented as part of the shared responsibility model. What you are gonna do.

The problem with self attestations is like, it basically is what it is, right? I, I promise, boy, you know, um, you know, boy scouts promise that we're doing security for real, right? At the end of the day, that's, you know, I don't think that's gonna, that's gonna tread water. And how does an SMB really know whether or not to take that attestation?

If I was an SMB, I would want to see some standard of care documented in the MSA and I think if you can educate right from C'S guidance to the SMB, hey, they said it would be good for us to self attest to you that we're doing things for real. We're gonna do you one better. We're gonna self attest and we're gonna put it in our contract. Right? Done.

You've, you've addressed the CSA guidance and you've done one better and you've moved on with your life because you've already decided that you're gonna be a secure MSP. Yeah. And If you're gonna put it in your contract, then you have to make sure that you abide by it. Yeah. Right. For, for a lot of reasons.

But, but, but one that, that a lot of people don't think about a lot is that if you're putting something in an agreement or if you agree to anything in a, in a MSA and a so, and you know that it's not true, then not only are you gonna be in a breach situation, but if you're dealing with a somewhat sophisticated party on the other end of the contract, there are gonna be carve outs in your limitation of liability for fraud, misrepresentation, gross negligence, things like that.

So if you say you're doing it and you're not doing it, you know that you're not doing it, not only are you gonna be in breach, but now the liability caps that you previously negotiated so you don't lose your business or going out the window. Yeah. Uh, What if you don't know you're lying. Different story, different day. Ignorance is a whole different conversation. By the way, uh, Wes I'll give you the last question here for have 'cause share responsibility.

By the way, for those of you guys that a ask questions, um, I will get those to the team here if you want to email me if you are one of those people and I'll get you the answers. I'm putting my email in. Um, So Andrew, how about I, I turn it into a quick statement instead of a question just 'cause we're one a minute from bingo and I've gotta jump to my next call anyway.

So, um, on on page two is, uh, a reference from CISA on the shared responsibility model and CISA recommending that MSPs explore that. And there's multiple sources that you can go pull that from. They link to AWS's, Microsoft has their own as well. Um, I do think it's really important for you to go down that journey and create and, and reference inside of your MSAA shared reference model just to say, we adhere to this.

And I think that's important because it will describe for you where your risks are, what the responsibilities you maintain and help eliminate some of that risk. Um, should, you know, an incident come up in which there's discussion of I thought you were doing that for me, it gets rid of that whole discussion of who is responsible for what. Wes, I will, if I could close on this, I'll give you a real, real res real world scenario on this too. And, uh, Eric, you can close with this.

Um, you know, I have an MSP that I know that, you know, part of their business is implementing DY historically ms. Microsoft Dynamics. You know, now m well, I think it's all MS 365 or something, forget what it is. But the customer, after they implemented dynamics on their, you know, accounting side of their business, not the MSP, the, the customer says, Hey, we're good. We're in the cloud, we're under Microsoft stuff.

Again, you look at the shared responsibility model, it calls out what they're responsible for, what they're not. And you know, here's, you know, one of those things, Eric, how do you, how do you make sure the customer clearly is signing off?

And where do you kind of draw the line If you'll, yeah, so it it, it's a great question and, and it's one of the biggest deficiencies I see when I first engage with my clients and that, you know, typically the first point of engagement is an MSA, the second point of engagement is a statement of work. And when I look at the first draft of a statement of work before I've gotten my hands on it, I can't tell you how many times all the statement of work says is, here's what we're gonna do for you.

And it doesn't even mention what responsibilities the customer has, um, in, in this to make the relationship work. So you've got to document the, the customer responsibilities and you do it in the statement of work. Um, and depending on the statement of work, it might change a little bit. But, you know, I, I've seen statements of work that have literally pages and pages and pages of customer responsibilities. Forget about what the MSP is doing for their customer.

What does the customer have to do to make this relationship work? Gary, any closing thoughts? And we'll let everybody go and see everybody next week. No, I would just say if, um, we're, we're, we're working hard here right? Every week to try to put information in MSP's hand that hopefully, uh, is gonna help them with where they are and where together. Um, we all, we all have to go. So, um, we just hit 3,900, um, four thousands next.

Um, if you got a friend or even a competitor, uh, who's an MSP, 'cause again, I, I, this is, this is, I think this is one of those situations where we're, we're all, we're all in this together. Yeah, well said. Alright, everybody, have a fantastic week. Thanks Eric.