MSPs stehen unter Druck. Ihre Kunden erwarten NIS2-Compliance. Gleichzeitig ist unklar, wo Ihre Verantwortung endet und wo die Pflicht des Kunden beginnt.
Das Risiko ist nicht theoretisch. Nach einem Sicherheitsvorfall sucht jeder nach dem Verantwortlichen. Geschäftsführung. Versicherer. Aufsicht. Kunde. Lieferkette.
Wenn Ihr Vertrag nur „IT-Betreuung“, „Managed Security“ oder „Betrieb der Infrastruktur“ sagt, haben Sie ein Problem: Sie arbeiten in einer Grauzone. Und Grauzonen werden im Streitfall gegen Sie ausgelegt.
NIS2 und Lieferkettenhaftung für IT-Dienstleister
NIS2 verschiebt IT-Sicherheit aus der Technik-Ecke in die Geschäftsleiterhaftung. Betroffen sind nicht nur Betreiber kritischer Anlagen. Auch digitale Dienste, IT-Dienstleister, Rechenzentren, Cloud- und Managed-Service-Strukturen rücken in den Fokus.
Für MSPs ist der Kernpunkt klar:
Wer sicherheitsrelevante Leistungen für regulierte Kunden übernimmt, wird Teil der Nachweiskette.
Das BSI denkt nicht in Marketing-Begriffen wie „Full-Service-IT“ oder „Rundum-sorglos-Paket“. Es denkt in Verantwortlichkeiten, Pflichten, Nachweisen und Kontrollrechten.
Die Logik ist bereits aus anderen Regulierungsbereichen bekannt. Das BSI formuliert es im Zusammenhang mit telekommunikationsrechtlichen Pflichten wie folgt: „Werden telekommunikationsrechtliche Pflichten aus §§ 165 und 166 TKG im Auftrag eines Verantwortlichen durch andere Personen oder Stellen erfüllt [...], so hat der Verpflichtete für die Einhaltung der telekommunikationsrechtlichen Vorschriften Sorge zu tragen.“
Übersetzt in die Praxis:
- Ihr Kunde bleibt grundsätzlich verantwortlich.
- Sie können aber vertraglich, operativ und faktisch in die Pflichtenkette gezogen werden.
- Wenn Sie Leistungen übernehmen, müssen Rollen, Grenzen und Nachweise sauber dokumentiert sein.
- Fehlt diese Trennung, entsteht ein Haftungs-Flickenteppich.
Das ist der Punkt, an dem viele MSPs scheitern. Nicht an der Firewall. Nicht am EDR. Sondern an der fehlenden rechtlichen Architektur.
Warum fehlende Trennlinien zum Haftungsrisiko werden
Ein ISO-Template schützt Sie nicht vor einem Kunden, der nach einem Ransomware-Vorfall behauptet: „Unser MSP war dafür zuständig.“
Eine neue Firewall schützt Sie nicht vor einem Vertrag, der Ihre Leistungspflichten schwammig beschreibt.
Ein hübsches Security-Konzept schützt Sie nicht, wenn nicht geregelt ist:
- Wer führt das Risikomanagement durch?
- Wer entscheidet über Patches, Wartungsfenster und Ausnahmen?
- Wer dokumentiert Sicherheitsmaßnahmen?
- Wer meldet Sicherheitsvorfälle?
- Wer bewertet Kritikalität und Meldepflichten?
- Wer trägt das Restrisiko, wenn der Kunde Empfehlungen ignoriert?
- Wer bezahlt zusätzliche NIS2-Maßnahmen?
Genau hier verschweigen viele Anbieter die eigentliche Baustelle: Shared Responsibility ist kein PowerPoint-Modell. Es ist Vertragsarbeit.
Sie brauchen keine weiteren allgemeinen NIS2-Übersichten. Davon gibt es genug. Die meisten sind Papier-Tiger.
Sie brauchen belastbare Klauseln und operative Trennlinien. Sonst übernehmen Sie schleichend Verantwortung, die Sie weder kalkuliert noch versichert noch technisch vollständig kontrolliert haben.
Besonders gefährlich sind diese Formulierungen in MSP-Verträgen:
- „Der Dienstleister sorgt für die IT-Sicherheit des Kunden.“
- „Der MSP stellt die Einhaltung gesetzlicher Anforderungen sicher.“
- „Der Dienstleister übernimmt den sicheren Betrieb der IT.“
- „Der Auftragnehmer gewährleistet NIS2-Compliance.“
- „Der Dienstleister ist für Security Monitoring und Incident Response verantwortlich.“
Klingt kundenfreundlich. Ist haftungsgefährlich.
Denn solche Sätze verwischen die Grenze zwischen technischer Leistung und rechtlicher Gesamtverantwortung. Im Streitfall kann daraus ein Vorwurf entstehen: Sie hätten mehr tun, früher warnen, besser dokumentieren oder eskalieren müssen.
Schritte zur klaren Verantwortungsabgrenzung für MSPs
Leistungspflichten hart abgrenzen: Prüfen Sie jeden MSP-Vertrag auf unklare Sicherheitsversprechen. Streichen Sie Begriffe wie „umfassend“, „vollständig“, „gesetzeskonform“ und „NIS2-konform“, wenn Sie diese Verantwortung nicht ausdrücklich übernehmen wollen. Definieren Sie stattdessen exakt: Monitoring, Patch-Management, Backup-Prüfung, EDR-Betrieb, Log-Auswertung, Reaktionszeiten, Eskalationswege. Alles andere bleibt beim Kunden.
Shared-Responsibility-Klausel einbauen: Verankern Sie schriftlich, dass der Kunde für Governance, Risikobewertung, Meldepflichten, Priorisierung, Budgetfreigaben und Annahme von Restrisiken verantwortlich bleibt. Ergänzen Sie eine Mitwirkungspflicht: Wenn der Kunde Patches blockiert, MFA ablehnt, veraltete Systeme weiterbetreibt oder Budgets verweigert, muss dies dokumentiert und als Kundenrisiko bestätigt werden. Ohne diese Klausel sitzen Sie auf den Legacy-Altlasten Ihres Kunden.
Beweisakte für jede kritische Umgebung führen: Legen Sie pro Kunde eine NIS2-relevante Dokumentationsakte an. Minimum: Leistungsumfang, Verantwortungsmatrix, bekannte Risiken, abgelehnte Maßnahmen, Patch-Ausnahmen, Backup-Status, Incident-Protokolle, Eskalationen, Management-Warnungen. Keine E-Mail-Chaosablage. Keine mündlichen Freigaben. Wenn es kracht, zählt nicht, was Sie getan haben. Es zählt, was Sie beweisen können.
Checkliste: NIS2-Verantwortlichkeiten für IT-Dienstleister und MSPs
Die Checkliste gibt einen strukturierten Überblick, wie Leistungspflichten, Shared-Responsibility-Grenzen und Dokumentationsanforderungen im MSP-Kontext sinnvoll definiert werden können. Sie dient der internen Orientierung und ersetzt keine Rechts- oder Vertragsberatung.