Ep 246 | Silicon Valley Bank; Compliance Advice for MSP Startups; is it time to lower your pricing?

Now some of you may be saying, Charles, what the heck does Silicon Valley Bank have to do with MSP Zone? Are they even related? They're not really related, but I will say this. There's been a fair amount of chatter, mostly on social media, which take it or leave it, it's a mixed bag of accuracy and intelligence depending on who you follow and what you read. But there's a fair amount of chatter on different platforms that are trying to draw a link between Silicon Valley Bank and the tech sector and making kind of insinuations - outright claims, some of them about Silicon Valley Bank's recent events means that the tech sector is in trouble. So I want to address that today, in general to the tech sector, in specific to managed service providers, because I think we need to get out ahead of this and just draw a line around what we in the MSP profession know to be happening, so that elsewhere, outside of our profession, people don't think something that isn't true.

So for those of you who have been kind of out of it and don't really know what's going on with Silicon Valley Bank, they're a Silicon Valley Bank. That's their name, but it's also their location. And they were a bank, I think at the time, as of a few weeks ago, they were the 16th largest bank in the United States, if I'm not mistaken. And Silicon Valley Bank, they didn't go under. They had a run on the bank and they went into basically the federal government, the FDIC, the Federal Deposit Insurance Corporation took over effectively management of the bank because of certain things that happened. So I'm going to explain what happened. I'm going to explain very briefly, by the way, because you can read about this almost anywhere on the planet right now they're talking about Silicon Valley Bank. I'm going to give you my impression. I'm going to try to stay away from the danger areas of politics. I'm going to try to stay straight to the economic policy at play here and just break it down for you guys.

Okay, so what happened? Silicon Valley Bank, 16th largest bank in the United States, heavy in Silicon Valley and therefore heavy with tech startups.

Not all of them by any means in software as a service or managed services but a good number of them. So I mean startups in Silicon Valley certainly are going to impact and have a few MSPs.

In addition to that, Silicon Valley Bank also had a fair amount of leverage meaning that they invested in venture capital firms. Those venture capital firms also were pretty heavily focused on tech, a variety of tech but in tech. And so there is an association of Silicon Valley Bank with the technology sector. I'll admit it, it's fair, it's accurate.

Silicon Valley Bank had made some investments in the last several years specifically in US Treasury bonds, long term US. Treasury bonds which here's where I don't want to get too far into the economic weeds, but basically when we had the pandemic and we had a bunch of forced government, forced business closures and bad economic times, there was a decision to pump a bunch of money into the marketplace as well as lower interest rates.

So making money available and cheap.

So what's a bank to do when it has a ton? I think they went from 60 billion in investments in deposits to over 200 billion. I think those numbers are right. 200 billion by the end of the pandemic under deposit. This is Silicon Valley Bank. So they had to do something with that money in order to make it grow and have a return on the investment. Otherwise their shareholders are going to say hey what are you doing? We want to see a return. So they invested among other things in long term US Treasury bonds when we started last year on this aggressive course of monetary restriction which again here is making money more expensive.

So not only trying to take surplus money out of the system but also making it more expensive to access through rising interest rates. You increase the interest rate of money, you make it more difficult to obtain and there you go. What that did to those US Treasury bonds that Silicon Valley Bank held is it made it worth less, not worthless but worth less than it was when they bought them. So they had a depreciating asset on their balance sheet that was just going down and down and down. Everybody saw it and so everybody said hey well this is not a good thing. Let's start taking our money out.

And it created a traditional run on the bank which is the depositors went to Silicon Valley Bank and said I want my money out, give it to me now. And when you have enough of that happen in a short period of time, there isn't enough liquidity in the bank to be able to cover all of those deposits. And then you have a panic and then the regulators from the federal government come in and say hey we're shutting it down. We're taking over. Okay?

So that's what happened.

And after that, you now have this just kind of a cacophony of people saying oh my god, this is a referendum on tech, on big tech, on general tech.

It's bad, technology is bad, all that stuff.

I think that you could say maybe there was some mismanagement at Silicon Valley Bank. I certainly think that there are plenty of articles written by smarter people than me on issues of economics who write about the fact that they were heavily leveraged not only on US long-term treasury bonds but they are also heavily leveraged in potentially risky venture capital companies. That may or may not be a legitimate claim.

I think that given what they were facing going into the pandemic, when they had a lot of money from depositors and that increased over the few years of the pandemic, and you had wealthy Silicon Valley investors putting their money into Silicon Valley bank. What was the bank to do in order to make money when money was so cheap? You could see their dilemma, you might say.

And this is the counterargument which is to say that the federal government, specifically those in charge of the monetary policy, really caused the problem here. Now this is getting way way into the weeds because there is a direct cause of the monetary restriction that has been taking place and this failure of the bank because the bank had so many US treasury bonds.

Now you may or may not believe that having so much in US treasury bonds is a good thing or a bad thing. That's a completely separate question. I'm not even going to get into that bag of worms. That's something else for regulators and people to discuss.

But what I'm here to say to you is this is not a referendum on technology in general nor is it specific to managed services. A referendum on the health of the MSP community. Not at all.

What happened here and there's a second bank in New York I think is the second one to fail. That there are things going on in our monetary supply and our economy that may or may not be good, but these bank failures are not a cause of the Tech/MSP sector.

Now this is not to say folks, I am not saying that the failure of banks in the United States or anywhere in the world won't potentially have negative economic impacts. Not saying that at all. That's entirely possible.

But what it doesn't say automatically is MSPs are somehow on shaky ground tech is really not a good place to be right now. I think that that's so far from the truth, it's not even funny. I think MSPs are just as healthy as they've always been. They're more in demand.

I mean, go back to our State of the Union, State of the MSP Union a few episodes ago. Listen to that. And we lay out the case of why we think Managed Services is still a really good place to be in. And not just a good place from an investment standpoint, but it's a good, strong, in-demand profession that is very much needed, if only on the fight in cybersecurity, not to mention all the other benefits that MSPs bring.

So I wanted to just present that to you. And again, I apologize for all the heavy economic terms and definitions, but I felt like it needed to be said, at least from the MSP standpoint, right. No matter what's going to happen, even if there are other banks that fail. Yeah. It may have an impact on MSPs, especially if you - I know a lot of our members - not a lot - I know some of our members used Silicon Valley Bank. If you are one of those members, obviously you might be going through panic right now. You might be having some difficulty getting access to your funds. I get that. But that aside, it's really a separate issue of banking and monetary policy. And it's not, like I said, a referendum or an indicator of the health of the managed services profession, which in my opinion at least, is still very strong.

Wanted to say that. Put it out there. If you have some thoughts, any of you fancy yourself casual economists love to hear your thoughts and comments. Feel free to send them.

Which brings us up to topic number two. I was talking to some MSPs last month, I think, and a really important question came up that doesn't get asked that frequently. And I'm kind of surprised now thinking back on it, why it hasn't been asked more frequently. And the question was this: we were talking about certification. We were talking about and they were asking questions about MSP Verify. And they listened to what we said. They accepted it. They said, "This is good if you are a more mature MSP." And he said, "Charles, what advice would you give to an MSP that wasn't as mature, wasn't as mature as they should be in order to obtain an MSP Verify report? Right."

Again, those of you who don't know, we're getting a ton of new listeners on MSP Zone, so I recognize there's a lot of first-time people, you know, joining us - MSP Verify is a report that you get by going through a certification process to evaluate your MSP organization's policies, procedures, controls, practices, etc. And then at the end of that, you get an MSP Verify report.

Back to the question, what guidance? What should a younger startup MSP or an MSP, maybe with a much bigger parent company, but it's a new managed services practice, or you're still fairly young or less mature as a managed services organization, what guidance do we have for you?

And I thought about it, and after about a millisecond, I said, that's a really good question. There's a lot of MSPs that probably wouldn't be able to go fully through the old MSP Verify process to get that full report. But today we actually have a good course of guidance, a good recommendation, and that is Cyber Verify, which is the platform we just launched a few weeks ago.

Even if you are not ready to get a formal certification or audit report, which by the numbers, is the numerical majority of MSPs on planet Earth, well above 95%. 95, 96, 97 ish percent of the MSPs on this planet do not have an audit report, don't have an ISO 27001, don't have a SOC 2 report, have never gone through a formal, external third-party review of their policies and procedures. That's just how the cookie crumbles. And that's what the question was about. What about them? If the less than 5% of MSPs are able to get an MSP Verify report, what about the 95% plus of the rest of them? Cyber Verify.

What does that mean, Charles? And you just can't just say Cyber Verify and expect us to - I get that. I'm going to explain it. This is what Cyber Verify does. But this is what you ought to do. You don't want to use Cyber Verify, fine. Do this yourself. Here's the guidance. Cyber Verify will help you do these things. But if you don't want to go that route, you don't have an excuse. Do it yourself and get it done because this is what you need to do to be a practicing MSP these days.

So now I'm speaking to the 95% plus MSPs on this planet, giving you some guidance on what you ought to be doing for your compliance. Number one, make compliance an everyday part of your business. What does that mean? It means, unlike the old model of you see the large legacy data centers and cloud providers, and they have these fancy SOC 2 reports, they're 50 plus pages in length, and they're really convoluted. They're not really easy to understand, but, you know, they cost a lot. And, you know, that all the mature big guys, the big folks have them. What's a smaller MSP to do?

Don't focus on the report, Number one. Focus on what you do as an MSP every single day and start to incorporate into your everyday movements, the day-to-day process, the procedures you follow. They're common. You know they're common, right? Even some of you chaotic, reactive, break-fix oriented shops who are really trying to get out of that model. You, maybe especially you, understand the value of trying to get out of that chaos. And trying to get to more predictability. And part of that has to be start slow, but incorporate compliance into your everyday life.

What does that mean? It means starting to understand how your day to day best practices, your day to day policies and procedures, the things that you do over and over and over and over again. As an MSP, ask yourself what is the compliance value of that thing that I'm doing? I'll give you a good example. Backup as a service is what you as an MSP sell to your customer. You charge them a fee for it. Everybody gets that.

Every MSP on the planet ought to be backing up its own internal data. Period. There's no excuse. There is no way that I've ever heard where there's a reasonable reason that an MSP shouldn't back up their data. You have to be operational. If you get hit, you are of zero value to your customers. If you get hit by a cyberattack, if your data is made ineffective, it's encrypted, it's locked up, it's exfiltrated, it's whatever. If you can't function as an MSP, you won't be helpful to your customers. So you need to be first and foremost safe.

When you're flying, what do they say if there's a loss of cabin pressure? First, put on your own mask. And then you put on the mask for a child or someone that is dependent on you, right? That's a good way to look at it. As an MSP, you should be backing up your own data. Fine. Is that it? No.

Start to understand that internal MSP operational data backup and preservation - encrypting it, not just backing it up. Encrypting it, making sure that it's available to you. There's some redundancy there. Make sure, maybe this is nice to have. Maybe you can't do it immediately today. Maybe you start to create secondary copies and air gap them so that you know that that air gapped, separated backup set is really protected - network protected from a backup set that might be compromised by malware. And start to document how you do that. Start to just write down. It will take you a matter of a minute or two to document the steps that you take to back up your internal process. Be specific. But you're not writing a book. You're not writing Moby Dick here. Just start small, write it down, save it someplace secure that you can go. Reference it. Talk about what backup platform you use, talk about the frequency, talk about the individual steps that you take to back up your data. Talk about all of it. And you'll probably end up with maybe a paragraph or two. It won't be big, that's fine. But if you have those details written into that section, guess what? You just documented and have provided the necessary steps for a compliance review like Cyber Verify, to be able to come in and look at your internal backup policies to assess whether they're being performed adequately and to be able to, if necessary, for that report. Maybe not now, maybe it's next year, maybe it's way down the road, maybe it's never. But maybe you just want to know that it's being done.

Maybe you're an MSP business owner and you suspect you're doing it right, but you're not sure. There's a lot of you out there. I know you know who you are. There's a lot of you out there who don't have customers banging down your door asking for these reports. But you still want to know because you still want to be able to explain to a customer how you do things and why you're doing things to make them and yourself safe. So what you've done there is you've documented the necessary control level details of how to internally back up your particular MSP operation and all of those steps are necessary to be able to demonstrate compliance around that specific function. Now back to my earlier advice, making compliance part of your everyday business practice. Now that you've documented that process, just follow it.

Maybe you create a ticket. Maybe you have a daily ticket, probably be too much. Maybe you do a weekly ticket, maybe a monthly ticket to go back and make sure that you are validating. That, yeah, that daily backup. Maybe it's twice a day. It doesn't matter folks. You can put in the frequency. The frequency is irrelevant. You have a process to be able to validate that you are in fact following that step-by-step process of internal backup.

Maybe you do a monthly test restore just to see if the backup data set is working. Maybe it's weekly, maybe it's quarterly, I don't know. Everyone's going to be different. Whatever you choose, write it down and evidence it. I think tickets are really good. If you're an MSP, if you call yourself an MSP, chances are you've got a ticketing platform. Use that. That's a really good step and a really good direction and a good repository place to be able to evidence things like, yeah, we checked that for the last week we backed up our data and yeah, we checked for this last month of all the data sets that we backed up. We did one sample randomized data set restore just to see did the data work and here's our evidence and here's the ticket evidence to move on.

That is an organic incorporation of what compliance officers, compliance departments and the really, really big MSP organizations, I'm talking about billion-dollar plus organizations, this is what they do. And it's how you as a smaller, less mature MSP can start very quickly to equal those very large MSP counterparts of yours and start to behave very similar to how they behave and how to evidence the things that they for a very, very long time have been able to evidence.

So that's my advice of making compliance an everyday part of your business. Start with your policies and procedures. Start small, don't overthink it. Don't try to write a big book. It's not the goal. Start small, start very specific with the things that you do every day and that's a great starting point.

And then finally, number three, and this is a bit of a sales pitch, but if you feel like that's overwhelming and you can do all this yourself, you could do it with a spreadsheet. It'll be complicated. Yeah, you probably won't do it because it's so complicated. Yeah, but that's what Cyber Verify was designed to do. So it's designed to help you incorporate day to day simple controls, necessary controls, but they're simple that every MSP ought to be performing. And it helps you to organize, to document, and to evidence those important, relevant daily controls. Little bit of advice for early stage startup, early in your maturity model, whatever. It's really good advice. And by the way, it's good advice for the mature MSPs out there. If you're not doing it, you ought to be.

Brings us to topic number three, managed services pricing. And this is a little bit of fun I wanted to have just to see what the temperature of this concept would be. We've been on a successive, probably a five-year run of MSPs raising prices.

And not to wade back into the economic waters of the first segment, but if you raise the price of anything, the laws of economics tell us that the demand for that thing, that good or service is going to go down. If the price goes up, demand will go down. Makes sense. If you lower the price of a good or a service, demand should go up. Fairly simple, straightforward stuff, right? Okay. Basic economics.

I am very aware that for the last several years, specifically the last year or two, with not only the pandemic but also the sharp increase in inflation, mostly here in the United States but elsewhere in the world, that you have natural, economic, financial pressures driving things like the need to raise prices. And I know that a lot of MSPs have raised their prices specifically in the last 12-24 months in chief because of the inflationary pressures that we're all facing. I get that.

But I want to bring your attention to a couple of things. Number one, back to the economics. At least in the United States, we are under a significant, at least as of right now, a significant monetary restriction phase. They're raising interest rates successively. They have been. And they look like they're going to continue to raise interest rates trying to make not revenue, but make the money supply less and less - what's the right term? Less volume of monetary supply, less accessible because it's going to be costing more.

So if we are in that type of a phase or trajectory and there's some other things that I want to get to shortly, you may want to consider at some point in the near future a modification of your current pricing to at least consider what lowering your managed services prices might look like.

Here's an example. If we recognize that there is a lot more to be done when it comes to cybersecurity, meaning there are everyday organizations all around the planet who have really substandard, far below normal, acceptable use of cybersecurity. They don't even have the minimum cybersecurity policies, procedures, and technologies in place. All right, I think we can at least accept that there's a good majority of organizations on the planet that need a lot more cybersecurity.

What's the best way to reach mass adoption of cybersecurity? Best practices, technology use. And you know as well as I that all those organizations, if they were to go down that path and even say, yes, we are going to allocate resources, including money, to improve our cybersecurity. Eight out of ten, nine out of ten, a large percentage are going to say, I'm willing to do it, but I don't know how to do it myself. Can someone help me? Maybe an MSP. You know that that's true. Most of those organizations are not going to do it themselves. They're going to turn to an MSP and say, can you do it for me?

If your pricing trajectory is to go up and up and up, don't be surprised if your attempt to reach mass adoption of your existing and potential customer base doesn't go exactly as planned. Now, I'm not saying that raising prices is going to be good for everybody. I'm not saying that we should treat cybersecurity as a commodity either. But I am just raising the concept that maybe, especially here in the US, or anywhere around the world, where you are dealing with a quantitative restricting trend, right? Interest rates are going up, the monetary supply is shrinking. The value of the money, the accessibility of the money is going to get tighter. You may be forced into a position where, in order to achieve further client acquisition, you might have to modify your pricing approach.

Now, what goes along with this is a whole set of additional questions that must be tackled. Things such as are you an advocate and a follower of risk-based pricing and managed services and things like that, which I fully still support. And I believe that that is the best pricing methodology for MSPs, period. Risk-based pricing is the way to go.

I think that security standardization, cybersecurity standardization is a must across any organization. But specifically, if you are a customer of a managed service provider, that MSP has an obligation and a need to make sure that you are meeting a minimum requirement of cybersecurity, if only because if you're not, you make that MSP more at risk and they ought to raise your rates if you're not behaving in a secure way.

So we talked about cybersecurity tax in an episode or two ago, and I made my points, my views pretty clear on that. I'm not in favor of a cybersecurity tax, but I would be in favor of some sort of pricing incentive in managed services where MSPs began to reward their managed services customers, where the more they purchased managed IT and security solutions that made the organization less risky, that the MSP reward, maybe through some modified pricing. The more they consume, the more they save type of concept.

You don't want to price out an organization from achieving the best cybersecurity they can get. That's really my point. Security standardization should be the goal. We may not ever get there, but that should be the goal. And I just don't know, especially now if you're looking at doing another or if you're thinking about a significant price increase in the next twelve months. I'm not sure if that's going to be plausible. I could be wrong. The economic winds could shift completely the other way and we could go in a very different direction. But right now they're blowing in a direction that says managed services price increases may not be the thing of the future.

Now some of you may be saying you're probably squirming in your seats. Charles, what are you doing buddy? You're telling me to not raise prices. You're telling me to lower prices. What are my margins going to do? My margins are going to shrink. I don't want that. You don't want that. And that's not what I'm suggesting at all. Margin preservation is very critical because you don't want to end up like a Silicon Valley Bank. You want to be solvent. And first step of being solvent as an MSP is you need to protect your margins.

Now this is a completely separate episode, but I'll tease it up right here at the end. If you are thinking, yeah, I guess this does make sense. Charlie, what you're saying about the economy, about interest rates going up and quantitative restrictions and all that stuff, I get it. Price increases maybe not in the cards this year. What other way could we not raise prices, lower prices, whatever, keep prices the same and still protect our margin? Because you still have inflation out there at least as of now, which is still inching up. Automation.

You have to be doing something around automation. If you are still relying on old traditional manual steps for reasons I don't even have enough time in this episode to go into, you're never going to get there. I'm just sorry, I'll just say it. It's not only risky, it's less secure, but you're never going to achieve process automation and that fine-tuned engine effect of a highly repeatable managed services mechanism that is fueled in part not entirely, but in part by automation and automation types of tools.

Whether you are talking about machine learning AI, whether you are talking about robotic process automation, RPA and things like that, there's a number of ways that you can automate and streamline existing practices to make them less costly to produce and deliver and have a meaningful impact on your bottom line. And all those things should be considered all the time.

But I'm bringing this up again because I think that we're going to be maybe revisiting this pricing issue this year more than we realize. And I'm just raising the issue. I'm not saying that everyone's going to be destined for a price decrease. I'm not saying that. I'm just saying start to think about it. Start to think about what all of these different economic factors might mean for you and your MSP practice and for your customers. And don't be caught off guard because you never thought about it, you never contemplated it. That's really the point here.

But I think still, we're in a very good position as managed service providers in our profession. I think the work that you MSPs do is incredibly valuable. Keep it up. It's in constant demand, and that's always a good thing.

Until next time. Thanks for listening. If you enjoyed today's episode, please give us a like. Make sure you are subscribed to the podcast so you will get notified when future episodes are released. We will see you next time in the MSP Zone.