Why (unfortunately) MSPs are not always safe – 3 examples

Suppose you ask an SME entrepreneur how his company’s digital security is handled. The answer you often get: ‘my MSP takes care of that.’ There is blind faith that everything is correct. What’s more, the director of the MSP organization often also thinks everything is taken care of. After all, there has been investment in an arsenal of tooling to counter cyber attacks. It must be all right….

But how justified is that trust really?

Unfortunately, there are situations where trust is damaged. In recent years, there have been several cases where companies became victims of cyber attacks precisely because their MSP turned out to be a weak link. Instead of protection, in some cases the MSP actually turned out to be the gateway to all of their clients’ systems. For example, an ICT manager of notaries fell victim to a ransomware attack (source: Tweakers). And nearly 24% of all ransomware victims in 2024 were ICT companies (including MSPs), doubling from 2023. Not figures to sleep easy (source: Dutch IT Leaders). A little longer ago, in 2022, housing associations were affected after a hack at their ICT partner (source: Techzine).

Tooling is not a strategy

In an earlier blog, I wrote that the real power of Microsoft 365 tooling only comes into its own with a thoughtful implementation. Standardization and automation are valuable, but only effective if they are used consciously and incrementally. Personally, I think there is room for improvement precisely in the area of “thinking things through. Let me explain using three examples.

Example 1: ‘Open door monitoring’

Yes, that’s what I call the following phenomenon. It is the situation where everything is being monitored 24/7, when in fact you already knew that the basics are not in order. I like to compare that to securing a block of houses, while everywhere the front door is open. So you have cameras, but no one has ever checked whether the front door is locked.

Tooling without proper basic measures is false security, is my conclusion. The phrase “mopping up with the faucet” also comes to mind in this context, which brings me right to the following:

Example 2: SIEM without direction

Sometimes there is no thoughtful implementation because the bigger picture is not sufficiently considered. A good example is the use of a Security Information and Event Management (SIEM) system. With this, log data is collected, analyzed and suspicious patterns are detected. The promise: higher security through proactive action. But is that really the case? Because once you’ve discovered something, someone has to act on it: it only then begins.

Departments responsible for digital security, such as an internal IT department or an MSP’s SOC, are inundated with reports. But what really has priority? In practice, this often turns out to be unclear. And different opinions can arise about that. A well thought-out implementation therefore also means: thinking in advance about what you want to detect, when you want to take action, how you distinguish between noise and urgency and how much human capacity you have available. Without those frameworks, you mostly have a lot of data and little direction.

Example 3: Wanting to provide one solution for different situations

Another sticking point I often see is the temptation to deploy tooling as “one-size-fits-all. Say you have eight customers and you roll out the same security tool to all of them at the same time. On paper, that seems like an efficient process, but in practice it can be risky.

The reason? Every customer environment is different. Some use legacy software, others run on custom applications. Tooling rolled out without context looks at a standard environment, not the nuances of the customer. As a result, systems can topple, risks are not captured, and promised improvement turns into frustration. In my experience, a platform only really works when it is flexible enough to support about a 15-20% customer-specific situation. Standardization is important, but only if it is accompanied by an understanding of customization where needed.

In conclusion

Security is not a tool or a checkmark on a checklist. It is a process. And that process starts with daring to ask questions. Not only to your customer, but also to yourself. Can your customers trust you blindly?

I would like to talk to you about finding the right balance between standardization, flexibility and continuous optimization. All with one goal: making sure that you as an MSP, without sleepless nights, let your customers work (together) in a truly secure way. Of course I hope that my current insights will help. Then we can always talk about tooling.

Kenneth van Surksum

Owner Secure at Work | Microsoft MVP Intune & Identity and Access