NIS2 für IT-Dienstleister: MSP und Cloud Provider
IT-Dienstleister, Managed Service Provider und Cloud-Anbieter fallen unter NIS2 häufig direkt in den Regulierungsbereich oder geraten spätestens über Kundenverträge unter erheblichen Umsetzungsdruck. Für MSP und Cloud Provider geht es deshalb nicht nur um allgemeine IT-Sicherheit, sondern um Einordnung als Einrichtung, Meldefähigkeit, Lieferkettensicherheit und belastbare SLA-Strukturen.
Letzte Aktualisierung: 23. März 2026
Für die Einordnung ist eine Unterscheidung entscheidend: Nicht jede Agentur, jedes Systemhaus und jeder SaaS-Anbieter ist automatisch NIS2-reguliert. Direkt relevant wird NIS2 aber regelmäßig für Managed Service Provider, Managed Security Service Provider, Cloud-Computing-Dienste, Rechenzentrumsdienste, Content-Delivery-Networks oder andere digitale Infrastruktur- und ICT-Services nach Anhang I, Anhang II und Art. 26 der Richtlinie (EU) 2022/2555. Parallel wächst der mittelbare Druck auf kleinere IT-Dienstleister, weil regulierte Kunden ihre Anforderungen vertraglich weiterreichen.
Wenn Sie die Branche zuerst breiter einordnen möchten, lesen Sie ergänzend die Seite zu NIS2 für digitale Dienste, den Beitrag zur NIS2-Lieferkettensicherheit und unseren Vergleich NIS2 vs. ISO 27001 Schulung. Für die operative Qualifizierung verantwortlicher Rollen ist außerdem die NIS2 Online-Schulung der naheliegende Einstieg.
Warum MSPs und IT-Dienstleister direkt betroffen sind
MSPs und IT-Dienstleister sind direkt betroffen, weil NIS2 nicht nur klassische KRITIS-Betreiber adressiert, sondern auch digitale Infrastruktur und ICT-Service-Management-Anbieter. Das folgt aus Anhang I und Anhang II der Richtlinie (EU) 2022/2555 sowie aus Art. 3 zu den Begriffsbestimmungen. Wer betriebsrelevante IT-Services für andere Unternehmen bereitstellt, bewegt sich damit wesentlich näher an der Regulierung als viele reine Beratungs- oder Projektanbieter.
Für Managed Services ist besonders relevant, dass diese Anbieter typischerweise privilegierte Zugriffe, Fernwartung, Monitoring, Patch-Management, Backup-Verantwortung, Identity-Administration oder Security Operations übernehmen. Genau diese Tätigkeiten erzeugen aus Sicht der Aufsicht und der Kunden ein Kaskadenrisiko: Ein einzelner Vorfall beim MSP kann gleichzeitig viele Mandanten beeinträchtigen. Aus einem isolierten Sicherheitsproblem wird damit schnell ein branchenübergreifender Störfaktor.
Rechtlich entscheidend sind drei Prüffragen. Erstens: Fällt der Anbieter seinem Untersektor nach unter NIS2, etwa als Managed Service Provider, Cloud-Computing-Dienst oder Rechenzentrumsdienst? Zweitens: Werden die Größenkriterien erreicht, also typischerweise mindestens 50 Mitarbeitende oder mehr als 10 Mio. EUR Umsatz beziehungsweise Bilanzsumme? Drittens: Gibt es Sonderkonstellationen, bei denen auch außerhalb der Standardschwellen eine besondere Relevanz angenommen wird, etwa wegen systemischer Bedeutung oder starker Kundenabhängigkeiten?
Praktisch reicht es deshalb nicht, sich als „IT-Dienstleister“ pauschal außerhalb des Regimes zu sehen. Ein klassisches Projektgeschäft ohne laufenden Betrieb ist anders zu bewerten als ein MSP mit 24/7-Monitoring, Domänen-Admin-Rechten und RMM-Tools in Hunderten Kundennetzen. Ebenso ist ein kleiner SaaS-Anbieter ohne kritische Funktion anders einzuordnen als ein IaaS- oder Hosting-Anbieter, dessen Ausfall ganze Kundenlandschaften stilllegt. NIS2 arbeitet hier mit sektoraler und risikoorientierter Differenzierung, nicht mit Marketing-Begriffen.
Hinzu kommt Art. 20 NIS2: Das Leitungsorgan muss Cybersecurity-Risikomanagementmaßnahmen billigen, überwachen und sich dafür schulen lassen. Für IT-Dienstleister bedeutet das, dass NIS2 nicht an der Security-Abteilung hängen bleiben darf. Geschäftsführung, Delivery, Legal, Kundenservice und Vertrieb müssen dieselbe Eskalations- und Nachweislogik verstehen, weil Sicherheitsvorfälle und Vertragszusagen unmittelbar das Geschäftsmodell treffen.
Managed Service Provider als wichtige Einrichtung
Managed Service Provider sind unter NIS2 häufig als wichtige Einrichtung einzuordnen, wenn sie die sektorale Zuordnung und die Größenschwellen erfüllen. Die Einordnung als „wichtig“ folgt in vielen Fällen daraus, dass MSPs in den von der Richtlinie erfassten digitalen und ICT-bezogenen Bereichen tätig sind, ohne automatisch in jede Kategorie der wesentlichen Einrichtungen zu fallen. Für die operative Umsetzung ist das kein kleiner Unterschied, aber auch keine Entwarnung.
Wichtige Einrichtungen unterliegen denselben materiellen Kernpflichten aus Art. 21 und Art. 23 NIS2 wie andere regulierte Unternehmen. Das betrifft insbesondere Risikomanagement, Incident Handling, Business Continuity, Lieferkettensicherheit, sichere Entwicklung und Wartung, Wirksamkeitsprüfung, Cyberhygiene, Kryptografie, personelle Sicherheit, Zugriffskontrolle und gegebenenfalls Multi-Faktor-Authentifizierung. Der Unterschied liegt vor allem in der Aufsichtsintensität: Wichtige Einrichtungen werden typischerweise reaktiv beaufsichtigt, während wesentliche Einrichtungen stärker proaktiver Kontrolle unterliegen.
Für MSPs ist gerade Art. 21 Abs. 2 praktisch zentral. Ein Anbieter, der Kundennetze überwacht, Admin-Rechte verwaltet, Patches ausrollt oder Backup-Infrastrukturen betreibt, muss Sicherheitsmaßnahmen nicht abstrakt nachweisen, sondern entlang seines Betriebsmodells. Dazu gehören unter anderem:
| Maßnahme | Allgemeine NIS2-Pflicht | Spezifische Relevanz für MSP |
|---|---|---|
| Risikoanalyse | Art. 21 Abs. 2 Buchst. a | Mandantenübergreifende Risiken, privilegierte Tools, Fernzugriffe, RMM-Plattformen |
| Incident Handling | Art. 21 Abs. 2 Buchst. b | Eskalation bei kompromittierten Kundenumgebungen und klarer 24/7-Meldeweg |
| Business Continuity | Art. 21 Abs. 2 Buchst. c | Wiederanlauf von Monitoring, Backup, Ticketing und Fernwartung |
| Lieferkettensicherheit | Art. 21 Abs. 2 Buchst. d | Steuerung von Cloud-Plattformen, AV-Tools, MDR-Partnern und Unterauftragnehmern |
| Zugriffskontrolle und MFA | Art. 21 Abs. 2 Buchst. i und j | Absicherung privilegierter Servicekonten, PAM und Break-Glass-Prozesse |
Ein MSP mit hoher Kundenkonzentration oder tiefer technischer Integration muss außerdem seine Kaskadenwirkung realistisch bewerten. Wenn dasselbe RMM-System, dieselbe Backup-Lösung oder dieselbe Identitätsplattform hunderte Kundensysteme verbindet, genügt kein allgemeines ISO-Manual. Entscheidend ist, ob Segmentierung, Mandantentrennung, Monitoring, Vier-Augen-Freigaben, Notfallabschaltung und forensische Nachvollziehbarkeit tatsächlich funktionieren.
Ebenso wichtig ist Art. 23 NIS2 zur Vorfallmeldung. Ein MSP muss nicht nur eigene erhebliche Sicherheitsvorfälle erkennen, sondern oft sehr schnell entscheiden, ob ein Vorfall auch die Dienste für regulierte Kunden erheblich beeinträchtigt. Genau deshalb benötigen MSPs saubere Eskalationsstufen zwischen SOC, Service Desk, Krisenstab, Geschäftsführung und Kundenkommunikation. Wer erst am zweiten Tag klärt, ob der Ausfall einer zentralen Management-Plattform meldepflichtig ist, verliert regulatorisch wertvolle Zeit.
Cloud Provider: IaaS, PaaS, SaaS unter NIS2
Cloud Provider sind unter NIS2 besonders relevant, weil Cloud-Computing-Dienste ausdrücklich in den betroffenen digitalen Untersektoren genannt werden. Für IaaS-, PaaS- und in Teilen auch SaaS-nahe Modelle ist die Einordnung allerdings nicht identisch. Entscheidend ist, ob tatsächlich ein Cloud-Computing-Dienst im regulatorischen Sinn vorliegt, wie die Leistung strukturiert ist und ob die Größenkriterien erreicht werden.
IaaS-Anbieter liegen am klarsten im Fokus. Wer Rechenleistung, Speicher, Netzwerkressourcen und virtuelle Infrastruktur mandantenfähig bereitstellt, erfüllt regelmäßig das Profil eines Cloud-Computing-Dienstes mit hoher Verfügbarkeits- und Lieferkettenrelevanz. PaaS-Modelle können ebenfalls unmittelbar erfasst sein, wenn sie zentrale Entwicklungs-, Datenbank-, Container- oder Laufzeitplattformen bereitstellen, von denen Kundendienste operativ abhängen.
Bei SaaS ist die Lage differenzierter. Nicht jedes Softwareprodukt ist automatisch ein regulierter Cloud-Dienst. In der Praxis prüfen Aufsicht und Kunden aber sehr genau, ob ein SaaS-Anbieter funktional wie kritische digitale Infrastruktur wirkt, etwa weil ganze Geschäftsprozesse, Identitäten, Datenhaltung oder Kommunikationswege darüber laufen. Für den Anbieter macht das einen erheblichen Unterschied bei Nachweisen, Vertragsgestaltung und Incident Response.
Die Durchführungsverordnung (EU) 2024/2690 konkretisiert für mehrere digitale Dienste, darunter Cloud- und ICT-nahe Sektoren, die Erwartung an Sicherheitsmaßnahmen deutlich stärker als der bloße Richtlinientext. Für Cloud Provider werden dadurch insbesondere diese Punkte prüfungsrelevant:
- Multi-Tenant-Sicherheit und belastbare Mandantentrennung.
- Asset- und Komponenteninformationen für Hard- und Software.
- Logging, Monitoring und Erkennung sicherheitsrelevanter Anomalien.
- Härtung, Patch- und Schwachstellenmanagement.
- Kryptografie, Schlüsselverwaltung und Zugriffsbeschränkungen.
- Business Continuity, Backup, Redundanz und Wiederanlaufplanung.
- Steuerung kritischer Unterauftragnehmer und Cloud-Lieferketten.
Für viele Kunden ist deshalb nicht mehr die Frage, ob ein Cloud Provider irgendein Sicherheitsprogramm hat, sondern ob dessen Nachweise zur eigenen NIS2-Compliance taugen. In Ausschreibungen und Vertragsverlängerungen werden daher regelmäßig C5-Testate, ISO-27001- oder ISO-27017-Zertifikate, SOC-2-Berichte, Penetration-Test-Zusammenfassungen, Incident-Playbooks und Angaben zu Datenstandorten verlangt. NIS2 schreibt diese Nachweise nicht als einzelnes Pflicht-Zertifikat fest, aber Art. 25 sowie die allgemeine Nachweislogik der Regulierung machen sie marktrelevant.
Für deutsche Cloud-Anbieter kommt hinzu, dass Kunden zunehmend nicht nur technische Sicherheit, sondern auch rechtliche Steuerbarkeit abfragen. Datenresidenz, Administratorenzugriffe aus Drittländern, Exit-Fähigkeit, Subprozessor-Transparenz und Notfall-Supportzeiten werden dadurch Teil der eigentlichen NIS2-Prüfung. Ein Cloud Provider ohne sauberes Register kritischer Unterauftragnehmer oder ohne belastbaren Meldeprozess wirkt deshalb nicht nur technisch schwach, sondern regulatorisch riskant.
Lieferketten-Sicherheit: Verantwortung gegenüber Kunden
Lieferketten-Sicherheit ist für IT-Dienstleister kein Randthema, sondern ein Kernpunkt aus Art. 21 Abs. 2 Buchst. d NIS2. Die Vorschrift nennt ausdrücklich sicherheitsbezogene Aspekte in den Beziehungen zwischen einer Einrichtung und ihren direkten Lieferanten oder Diensteanbietern. Für MSPs und Cloud Provider bedeutet das zweierlei: Sie müssen einerseits selbst ihre Lieferkette steuern und werden andererseits von Kunden als Teil von deren Lieferkette geprüft.
Diese doppelte Rolle erklärt, warum gerade IT-Dienstleister 2026 so stark unter Vertrags- und Auditdruck geraten. Ein regulierter Kunde muss zeigen können, dass sein MSP, sein Hosting-Partner, sein Security-Tooling und seine Cloud-Plattform kein unkontrolliertes Einfallstor darstellen. Entsprechend werden heute regelmäßig Sicherheitsfragebögen, Nachweisräume, Audit-Rechte, Incident-SLAs und Flow-down-Klauseln verlangt.
Die wichtigste Fehlannahme lautet, dass NIS2 nur den direkten Vertragspartner betrifft. Tatsächlich konkretisiert die Durchführungsverordnung (EU) 2024/2690 die Erwartung, dass kritische Anforderungen an Subunternehmer weitergegeben werden. Für MSPs und Cloud Provider folgt daraus eine belastbare Mindestarchitektur:
| Aspekt | Allgemeine NIS2 | Spezifisch IT-Dienstleister |
|---|---|---|
| Regulierung | NIS2-Richtlinie / deutsche Umsetzung | zusätzlich Marktanforderungen wie C5, ISO 27001, ISO 27017, SOC 2 |
| Haftung | Eigene Compliance und Meldepflichten | Lieferketten- und Vertragsrisiken gegenüber regulierten Kunden |
| Besonderheiten | 24h/72h/1-Monat-Vorfallmeldung, Risikomanagement | Multi-Tenant-Sicherheit, privilegierte Zugriffe, Incident-Response-SLAs, Subunternehmersteuerung |
Ein typisches Praxisbeispiel ist der mittelständische MSP, der Microsoft-365-Administration, Endpoint-Management und Backup für mehrere regulierte Kunden übernimmt. Fällt dessen RMM- oder Backup-Umgebung aus oder wird kompromittiert, sind nicht nur die eigenen Systeme betroffen. Der Vorfall kann Meldepflichten, SLA-Verletzungen und Betriebsunterbrechungen auf Kundenseite auslösen. Entsprechend verlangen Kunden heute oft Vorabinformationspflichten binnen weniger Stunden, forensische Unterstützung und Transparenz über betroffene Mandanten.
Ein zweites Praxisbeispiel ist der Cloud Provider mit Subunternehmern für Rechenzentrum, DDoS-Abwehr, Logging oder Support. Wenn diese Kette nicht dokumentiert ist, kann der Provider weder seine eigene Lieferkette bewerten noch dem Kunden belastbar erklären, wo kritische Dienste tatsächlich erbracht werden. Genau diese Intransparenz ist unter NIS2 ein strukturelles Risiko.
Wer seine Rolle als IT-Dienstleister sauber ordnen will, sollte deshalb parallel auch den Beitrag zur NIS2-Vorfallmeldung und die Einordnung NIS2 für digitale Dienste lesen. Beide Themen hängen operativ direkt mit Lieferkette und Kundenerwartungen zusammen.
Vertragliche Anforderungen und SLA-Anpassungen
Verträge und SLAs werden unter NIS2 für MSPs und Cloud Provider zum eigentlichen Umsetzungshebel. Ein Kunde kann seine Pflichten aus Art. 21 und Art. 23 NIS2 nur erfüllen, wenn Sicherheitszusagen, Meldewege und Unterstützungsleistungen gegenüber dem IT-Dienstleister verbindlich geregelt sind. Deshalb verschiebt sich die Diskussion 2026 sichtbar von allgemeinen Datenschutzanlagen hin zu technischen und regulatorischen Leistungszusagen.
Typische Vertragsbausteine betreffen zuerst die Vorfallkommunikation. Kunden verlangen häufig eine sehr frühe Information über Sicherheitsereignisse, die ihre Systeme, Daten oder Dienste potenziell betreffen. Das muss nicht identisch mit der eigenen externen NIS2-Meldung sein, ist aber funktional daran gekoppelt. Ein MSP oder Cloud Provider braucht dafür klare interne Schwellen, Ansprechpartner und eine belastbare First-Notice-Logik.
Der zweite Block betrifft Audit- und Nachweisrechte. Viele Verträge sehen inzwischen vor, dass der Dienstleister auf Anforderung Prüfberichte, Sicherheitsrichtlinien, Schulungsnachweise, Penetration-Test-Ergebnisse, Business-Continuity-Unterlagen oder Angaben zu Subunternehmern vorlegt. Für größere Kunden reichen allgemeine Marketing-Unterlagen nicht mehr aus. Sie wollen nachvollziehbare Evidenz, idealerweise mit Verantwortlichen, Datumsstand und Behebungsstatus offener Findings.
Der dritte Block betrifft Unterbeauftragung. Unter NIS2 wird es immer schwerer, kritische Subunternehmer ohne Anzeige- und Steuerungsmechanismus einzusetzen. Kunden erwarten Transparenz über wesentliche Unterauftragnehmer, Wechselrechte bei erhöhtem Risiko und die Zusicherung, dass Sicherheitsanforderungen vertraglich weitergereicht werden. Für Cloud Provider ist das besonders sensibel, wenn Support, Monitoring oder Infrastrukturkomponenten aus mehreren Jurisdiktionen eingebunden sind.
Der vierte Block betrifft Sicherheits-SLAs im engeren Sinn. Dazu zählen Reaktions- und Wiederanlaufzeiten, Patch-Fristen für kritische Schwachstellen, Regeln für privilegierte Zugriffe, Backup-Nachweise, Log-Aufbewahrung, forensische Datenbereitstellung und Mitwirkung bei regulatorischen Rückfragen. Entscheidend ist hier nicht, möglichst viele aggressive Zusagen zu verkaufen. Entscheidend ist, dass die zugesagten Zeiten tatsächlich zu Betriebsmodell, Teamgröße und Tooling passen.
Ein pragmischer Zeitplan für IT-Dienstleister sieht meist so aus:
- Innerhalb von 30 Tagen Betroffenheit, Leistungsportfolio und kritische Kundenbeziehungen kartieren.
- Innerhalb von 60 Tagen Standardklauseln für Incident, Audit, Unterbeauftragung und Nachweise überarbeiten.
- Innerhalb von 90 Tagen interne Eskalations- und SLA-Prozesse testen, einschließlich Management-Freigaben.
- Danach quartalsweise kritische Subunternehmer, Nachweisdokumente und Meldewege aktualisieren.
Wer jetzt nur einzelne Vertragsklauseln ergänzt, ohne Delivery, Security und Geschäftsführung mitzunehmen, verlagert das Problem nur in den nächsten Vorfall. NIS2 verlangt keine Formalästhetik, sondern belastbare Steuerung. Genau deshalb sollten Vertragsmuster, technische Betriebsprozesse und Kundenkommunikation aus einem gemeinsamen Governance-Modell kommen.
FAQ: NIS2 für IT-Dienstleister, MSP und Cloud Provider
Fallen alle MSP unter NIS2?
Nein. Managed Service Provider fallen nicht automatisch allein wegen der Bezeichnung unter NIS2. Maßgeblich sind die Einordnung nach Art. 3 und den Anhängen der Richtlinie (EU) 2022/2555, die konkrete Dienstleistung, die Rolle als ICT-Service-Management-Anbieter sowie die Größenkriterien. Viele MSP mit mindestens 50 Mitarbeitenden oder über 10 Mio. EUR Umsatz liegen aber praktisch im Prüfbereich.
Haften IT-Dienstleister für die NIS2-Compliance ihrer Kunden?
IT-Dienstleister übernehmen nicht pauschal die Gesamt-Compliance ihrer Kunden. Sie tragen aber regelmäßig vertragliche Mitwirkungspflichten, Sicherheitszusagen, Vorfallmeldungen, Audit-Unterstützung und Flow-down-Pflichten gegenüber Subunternehmern, weil Art. 21 Abs. 2 Buchst. d NIS2 die Lieferkettensicherheit ausdrücklich verlangt.
Welche Zertifikate verlangt NIS2 von Cloud Providern?
NIS2 schreibt kein einzelnes Pflicht-Zertifikat wie ISO 27001, ISO 27017, SOC 2 oder C5 unmittelbar vor. Art. 25 der Richtlinie behandelt Nachweis- und Standardisierungsinstrumente nur flankierend. In der Praxis verlangen Kunden und Aufsicht aber oft belastbare Nachweise, sodass Zertifikate oder Prüfberichte für Cloud Provider regelmäßig zum Markterfordernis werden.
Was bedeutet NIS2 Supply-Chain-Sicherheit für IT-Dienstleister?
Supply-Chain-Sicherheit bedeutet für IT-Dienstleister, dass direkte Lieferanten, Subunternehmer, Cloud-Regionen, Administratorenzugriffe, Software-Komponenten und Drittlandbezüge strukturiert bewertet, vertraglich abgesichert und im Vorfallfall schnell offengelegt werden müssen. Genau diese Logik folgt aus Art. 21 Abs. 2 Buchst. d NIS2 und wird durch die Durchführungsverordnung (EU) 2024/2690 konkretisiert.
Müssen kleine IT-Dienstleister mit unter 50 Mitarbeitenden NIS2 umsetzen?
Nicht zwingend direkt. Kleine IT-Dienstleister unterschreiten oft die Regel-Schwellen aus Art. 2 und Anhang I oder II der Richtlinie. Sie können aber mittelbar erheblich betroffen sein, wenn regulierte Kunden Sicherheitsanforderungen, Audit-Rechte, Vorfallmeldungen oder Nachweise vertraglich weiterreichen.
Welche SLA-Anpassungen sind für MSP und Cloud Provider typisch?
Typisch sind strengere Sicherheits-SLAs zu Erkennung, Eskalation, Erstinformation, forensischer Unterstützung, Wiederanlauf, Backup-Nachweisen, Patch-Zeiten, privilegierten Zugriffen und Unterbeauftragung. Der Grund ist, dass Kunden ihre eigenen Pflichten aus Art. 21 und Art. 23 NIS2 nur einhalten können, wenn diese Leistungszusagen vertraglich abgesichert sind.
Der nächste Schritt für Ihr Unternehmen
Wenn Ihr Unternehmen als MSP, Cloud Provider oder IT-Dienstleister regulierte Kunden betreut, sollten Sie NIS2 nicht nur als Security-Thema behandeln. Entscheidend sind eine saubere Betroffenheitsprüfung, belastbare Lieferkettensteuerung, realistische SLAs und ein Management, das Eskalations- und Nachweispflichten tatsächlich tragen kann.
Wenn Sie Verantwortlichkeiten, Vorfalllogik und regulatorische Mindestanforderungen kompakt aufbauen wollen, starten Sie mit der NIS2 Online-Schulung. Für die Vertiefung helfen anschließend NIS2 für digitale Dienste, der Leitfaden zur NIS2-Lieferkettensicherheit und der Vergleich NIS2 vs. ISO 27001 Schulung.