NIS2 Directive and the AI Act Regulation: Michael Bartsch on What MSPs to Know

MSPs must make one thing clear to their customers: NIS2 is not simply a “firewall regulation”. It is an organizational standard, and it needs to be understood first and foremost through the lens of liability. If management, including C-level executives, chooses to ignore NIS2 requirements, they may be held personally accountable.

The real focus is supply chain resilience. A company may believe it has built an internal “Fort Knox”, but if the MSP’s maintenance access is compromised, or if an insecure software tool becomes the weak link, the entire structure can collapse. This is why MSPs need to position themselves not only as technology providers, but as risk managers. They are no longer just selling licenses; they are helping customers protect compliance, security, and business continuity.

The biggest hurdle currently isn’t the technology, but governance and documentation. Many SMEs already have processes in place, but they are often informal and undocumented. Under NIS2, “we’ve always done it this way” is no longer enough; companies need to be able to demonstrate what they do, who is responsible, and how decisions are made.

Supplier control is another major pain point. Auditing third-party providers can be extremely difficult, especially because many companies do not even have a clear picture of who has access to their data, systems, or infrastructure. On top of that, incident response remains a serious challenge. The 24-hour deadline for initial reporting is simply unrealistic for many SMEs unless they have a SOC connection or another structured way to detect, assess, and escalate incidents quickly.

NIS2 turns the MSP into a part of the customer’s critical infrastructure. This means customers will, and must, demand proof that their MSPs operate according to recognized security and compliance standards, such as ISO 27001, SOC 2, or ISAE 3402.

At the same time, MSPs cannot look only at their own internal processes. They also need to ensure that their subcontractors, including cloud providers and tool manufacturers, act in compliance with NIS2 requirements. In this sense, the MSP becomes the gatekeeper of security, responsible not only for its own services but also for the resilience of the broader supply chain.

An SME cannot conduct 50-page audits for every supplier. A realistic approach starts with classification: suppliers should be grouped according to their importance, from A suppliers that are critical for operations, to B suppliers that are important, and C suppliers that have little or no impact on business continuity.

From there, companies can use standardized self-assessment questionnaires, for example based on frameworks such as the NIST CSF or CIS Controls, instead of reinventing the process each time. They should also manage certificates and formal proof in a structured way, requesting updated evidence annually. Finally, cyber-security clauses need to become standard in every supplier contract, so that security expectations are not only discussed, but formally agreed and enforceable.

The AI Act does not regulate AI itself, but the risk of its application. For MSPs, this means looking closely at how AI tools are used in practice and what happens to the data that passes through them. If tools such as Copilot or DeepL are used, the key questions become very concrete: where does the data go, who can access it, and is it used for training?

This also creates a new version of an old problem: shadow AI. Just as MSPs have had to manage shadow IT, they now need to prevent employees from uploading sensitive customer data into unlicensed or uncontrolled AI models. The overlap with NIS2 is clear, because both frameworks are built around risk management. If an AI system is used to make critical decisions, for example in logistics or medicine, it may become both a critical asset under NIS2 and a high-risk system under the AI Act.

Definitely, yes. Even if an AI only writes emails, it still needs to be assessed in terms of risk and operational impact. The level of criticality increases significantly when AI is used to automate IT processes, for example by generating patch management scripts or supporting technical workflows that affect customer systems.

For this reason, an MSP should include every AI tool in its asset register and evaluate what could happen if the tool fails, produces incorrect output, or generates a “hallucination.” The key question is not whether the AI looks simple on the surface, but whether an error in its use could disrupt operations, compromise data, or create a compliance risk.

What you should include in contracts with software and cloud providers now is a clear framework for accountability, reporting, and liability. The right to audit should be formally addressed, even if in practice you cannot audit Big Tech companies directly. In those cases, the contract should at least refer to their compliance reports, certifications, and available assurance documentation.

Incident notification SLAs are equally important. Providers should be required to notify you of relevant security incidents within 12 to 24 hours, so that you still have enough time to meet your own 24-hour reporting obligations toward the customer. Finally, MSPs need to review liability caps carefully and make sure their exposure for third-party failures is appropriately limited. Otherwise, they may end up carrying risks that are outside their direct control.

If you are creating a new service offering, the roadmap should look like this.

[For clarity, and to turn the discussion into a practical framework, we developed the chart below together with Michael’s input. This may be faster than reading 5,000 more words!]