Guardian360
Start free trialBecome a partner
← All posts

Opinion

MSP, NIS2 raised your client's duty of care. It also raised yours.

By Jan Martijn Broekhof ·

While preparing for a webinar on the Cyberbeveiligingswet, the Dutch implementation of NIS2, I spoke with Henk Bijsterbosch of Samen Digitaal Veilig. He mentioned something that stuck with me: the double duty of care comes up in nearly every conversation he has with MSPs. Not as a hypothetical risk they might one day face, but as something already quietly shaping how clients and MSPs argue about who was responsible for what.

That conversation is worth having properly, because it is not a Dutch problem. The Cyberbeveiligingswet has been in force in the Netherlands since 15 August 2026. Belgium transposed NIS2 into national law back in October 2024. Germany’s NIS2UmsuCG entered into force on 6 December 2025. France, at the time of writing, still has not completed its transposition and has been referred to the Court of Justice of the EU for the delay. Four markets, four different timelines, and one thing that does not wait for any of them: the civil-law duty of care that has applied to professional IT and security providers for decades, long before anyone had heard of NIS2.

What is the double duty of care, exactly?

There are two layers, and MSPs tend to notice the first one and miss the second. The first is the client’s statutory duty. NIS2, and its national implementations, put the responsibility for risk management, registration and incident reporting squarely on the organisation itself. ENISA’s technical implementation guidance is explicit that managed service providers and managed security service providers fall within scope of these requirements too, which is a useful reminder that this is not purely a client-side story.

The second layer is older and easy to overlook precisely because it predates the regulation. In the Netherlands, Article 7:401 of the Civil Code obliges a professional service provider to act with the care of a competent practitioner, and Dutch case law has repeatedly held IT suppliers to a heightened information and warning duty because of the expertise gap between them and their clients, as Dirkzwager’s overview of the relevant rulings sets out. Belgium has its own version of this doctrine: the Hof van Cassatie ruled as far back as 2006 that an IT supplier has a duty to inform, advise and warn its client, a principle still cited in Belgian legal writing today. Germany reaches a similar conclusion through its own case law. When the OLG Schleswig held an IT service provider liable for failing to properly advise a client before contracting, and the Bundesgerichtshof declined to hear a further appeal, it confirmed a comprehensive pre-contractual duty to inform and advise. France’s Cour de cassation has held the same, that a supplier of complex IT products owes its client a duty of advice, since at least 2006, and the Cour d’appel de Rennes applied that principle directly to a cybersecurity dispute in November 2024.

Four countries, four legal systems, the same underlying idea: NIS2 did not invent this duty. It just raised the stakes of ignoring it.

Why can’t the client’s responsibility simply become the client’s problem?

This is where the paradox sits, and it is worth sitting with it rather than rushing past it. NIS2 puts the client in the driver’s seat. The client decides what risk it accepts, what it invests in, and how it prioritises. An MSP can advise, but it cannot force a client to act on that advice. So far, that sounds like it should insulate the MSP.

It does not, and the reason is consistent across every jurisdiction I looked at: the more expert party carries the heavier duty, regardless of who signs the compliance paperwork. A Dutch Court of Appeal, ruling in a case discussed by Elferink & Kortier Advocaten, went further still, holding that a professional IT supplier must actively investigate whether a client’s own choices are actually justified, not simply issue a warning and move on. Being right that the decision was the client’s to make does not automatically mean the MSP did enough.

When a client declines your advice

This is the pattern most MSPs recognise instinctively, and it plays out roughly the same way everywhere. You recommend a measure, EDR, patch management, multi-factor authentication, something you would consider basic hygiene. The client declines it, for cost reasons, convenience, or simply because “we’ve never had a problem.” Months later, a supervisory authority conducts a check, or worse, an incident happens. The client, now facing its own statutory exposure under NIS2, looks for someone else to share the blame, and the MSP that gave the advice is the obvious candidate. As Critical.Matters points out, this dynamic is already visible in the Netherlands even before the Cyberbeveiligingswet’s obligations have fully bedded in: clients pass security demands down the chain to their suppliers well ahead of any enforcement action.

When a client won’t invest in certification

The second pattern is slightly different but ends up in the same place. A client refuses to pursue a recognised security certification, whether that is a NIS2-aligned supply chain framework, ISO 27001, or a sector-specific standard. To be clear, certification is not a legal requirement for demonstrating that you are in control of your own security; plenty of organisations can show this through documented policies, audits and a credible risk management process. But a certificate is a fast, external way to prove it, to a supervisory authority, to an insurer, or to a nervous client of your own. Without it, and without an equally convincing alternative, an organisation is more exposed when a large client walks away or a contract falls through after a security review. Once again, the MSP that flagged the gap can find itself accused of not having pushed hard enough.

The sceptical view, and why it doesn’t hold up

It would be fair to ask whether this is simply fear dressed up as thought leadership, a convenient way to sell certification services or compliance consulting. I understand the scepticism. But the pattern described above is not speculation; it is documented in court rulings from four different legal systems, spanning nearly two decades. What the case law also shows, consistently, is that MSPs who can point to a paper trail, documented advice, recorded client decisions, a clear account of what was recommended and what was declined, come out of these disputes in a much stronger position than those who cannot. The risk is real. It is also, in most cases, manageable.

What actually reduces the risk?

This is the reassuring part, and it deserves as much attention as the warning. Three things consistently make a difference.

Document your advice, and document the client’s decision when they decline it. Not a vague note in a CRM system, but something specific enough to stand up months or years later: what you recommended, why, and what the client chose to do instead.

Set minimum security requirements before you take on a client, or before you renew, rather than discovering the gaps after something goes wrong. This is not about being difficult; it is about being honest, early, when the relationship still allows for a straightforward conversation.

Do not let “the client didn’t want it” go unrecorded. It is the single sentence that determines whether a dispute becomes a shared conversation about risk or a one-sided argument about blame.

None of this requires an MSP to become a legal department. It requires treating documentation as part of the service, not as paperwork that gets done if there is time.

If you would like to go deeper on this, on 8 October I am hosting a webinar for the Dutch market on the Cyberbeveiligingswet, covering what it actually requires and, just as importantly, how to demonstrate that your security measures work in practice rather than only on paper. You can register here.

So here is the question worth asking yourself this week: if a client challenged you tomorrow on a piece of advice you gave eighteen months ago, could you actually produce it?

Sources