Read in English
Guides von

NIS2-Monitoring als Managed Service: Whitelabel-Leitfaden für MSPs und Systemhäuser

Wie MSPs und Systemhäuser NIS2-nahe Monitoring-Leistungen für KMU-Endkunden paketieren: § 30 BSIG-Mapping, Whitelabel-Rechenbeispiel, Meldefristen, Grenzen.

Ja, MSPs und Systemhäuser können NIS2-nahes Monitoring als Managed Service verkaufen — aber ehrlich paketiert: als Nachweis-Artefakte plus Betrieb, nicht als Compliance-Versprechen. Kontinuierliche Verfügbarkeitsüberwachung, Heartbeat-Checks für Backup-Jobs und Whitelabel-Status-Seiten adressieren einen klar abgrenzbaren Teil der Pflichten aus § 30 Abs. 2 BSIG — sie ersetzen kein ISMS und machen keinen Endkunden „NIS2-konform”.

Dieser Leitfaden zeigt, wie das Angebot sauber aufgebaut ist: welche § 30-Pflichten deiner KMU-Endkunden Monitoring konkret unterstützt, wie eine Whitelabel-Kalkulation aussehen kann und wo die rechtlichen Grenzen liegen — inklusive der Frage, ob du als MSP selbst NIS2-pflichtig bist. Er ersetzt keine Rechtsberatung.

Warum ist NIS2-Monitoring gerade jetzt ein Geschäftsfeld für MSPs?

Weil das Gesetz gilt und die Umsetzung bei vielen Betroffenen noch aussteht. Das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) wurde am 2. Dezember 2025 ausgefertigt, am 5. Dezember 2025 verkündet (BGBl. 2025 I Nr. 301) und ist am 6. Dezember 2025 in Kraft getreten — ohne generelle Übergangsfrist. Die materiellen Pflichten stehen in der Neufassung des BSI-Gesetzes, dem BSIG 2025.

Drei Fakten machen den Handlungsdruck bei KMU-Endkunden greifbar:

  • Das BSI schätzt rund 29.500 betroffene Unternehmen in Deutschland — viele davon Mittelständler ohne eigenes Security-Team.
  • Die Registrierungspflicht nach § 33 Abs. 1 BSIG greift spätestens drei Monate nach erstmaliger Einstufung; für Einrichtungen, die schon bei Inkrafttreten erfasst waren, ergibt sich daraus abgeleitet der 6. März 2026 als Stichtag. Das BSI formuliert es selbst so: „Die gesetzliche Registrierungsfrist ist bereits abgelaufen” (BSI zu regulierten Unternehmen). Registriert wird über das BSI-Portal mit ELSTER-Organisationszertifikat.
  • Risikomanagement- und Meldepflichten gelten seit dem 6. Dezember 2025 unmittelbar — wer sie noch nicht umgesetzt hat, ist im Verzug, nicht in einer Schonfrist.

Genau diese Lücke — geltendes Recht, überschaubare interne Ressourcen beim KMU — ist der Ansatzpunkt für ein Managed-Service-Angebot. Wie NIS2 einzelne Branchen trifft, haben wir für Medizinsoftware-Anbieter und DiGA-Hersteller bereits im Detail aufgeschlüsselt; dieser Artikel nimmt die MSP-Perspektive ein.

Bin ich als MSP oder Systemhaus selbst NIS2-pflichtig?

Bevor du NIS2-Leistungen verkaufst, kläre die eigene Betroffenheit — denn MSPs sind selbst sektoral erfasst. Anlage 1 BSIG listet im Sektor Digitale Infrastruktur ausdrücklich „Managed Services Provider” (Nr. 6.1.10) und „Managed Security Services Provider” (Nr. 6.1.11) (Anlage 1 BSIG); die Legaldefinition des „Anbieters verwalteter Dienste” steht in § 2 Nr. 26 BSIG.

Wichtig, weil es in vielen Sekundärquellen falsch steht: Für MSPs gelten die normalen Größenschwellen aus § 28 BSIG — eine größenunabhängige Erfassung gibt es hier nicht.

KategorieSchwelle (§ 28 BSIG)
Wichtige Einrichtungab 50 Beschäftigten oder über 10 Mio. € Umsatz und über 10 Mio. € Bilanzsumme
Besonders wichtige Einrichtungab 250 Beschäftigten oder über 50 Mio. € Umsatz und über 43 Mio. € Bilanzsumme

Ein Systemhaus mit 60 Mitarbeitern ist also selbst wichtige Einrichtung — mit eigener Registrierungs-, Risikomanagement- und Meldepflicht. Ein Fünf-Personen-MSP darunter ist in der Regel nicht direkt pflichtig, wird die Anforderungen aber über die Lieferkettenpflicht seiner NIS2-pflichtigen Kunden (§ 30 Abs. 2 Nr. 4 BSIG) vertraglich durchgereicht bekommen. Für die Einzelfallprüfung stellt das BSI eine anonyme, nicht rechtsverbindliche NIS-2-Betroffenheitsprüfung bereit.

Der Nebeneffekt ist ein Verkaufsargument: Ein MSP, der die Monitoring- und Nachweisdisziplin selbst lebt, die er verkauft, ist glaubwürdiger als einer, der sie nur weiterreicht.

Welche § 30-Pflichten des Endkunden kann Monitoring konkret unterstützen?

§ 30 Abs. 1 BSIG verlangt geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen gegen Störungen der Verfügbarkeit, Integrität und Vertraulichkeit — inklusive Dokumentationspflicht. Absatz 2 konkretisiert das in zehn Mindestmaßnahmen. Monitoring liefert für fünf davon belastbare Nachweis-Artefakte:

§ 30 Abs. 2 BSIG — Pflicht des KMU-EndkundenWas der MSP mit Monitoring konkret liefert
Nr. 1 — Konzepte zur Risikoanalyse und IT-SicherheitDokumentierte Überwachungsabdeckung: Welche Dienste, Endpunkte und Jobs werden mit welcher Frequenz überwacht — als Baustein des Risikokonzepts
Nr. 2 — Bewältigung von SicherheitsvorfällenAutomatische Incident-Erkennung mit Zeitstempel, Alarmierung in definierten Kanälen, lückenlose und durchsuchbare Incident-Historie
Nr. 3 — Aufrechterhaltung des Betriebs (Backup-Management, Wiederherstellung, Krisenmanagement)Kontinuierliche Verfügbarkeitsüberwachung der Kundendienste plus Heartbeat-Checks für Backup-Jobs: bleibt der Ping nach dem Backup-Lauf aus, wird alarmiert — der Nachweis, dass Backups tatsächlich laufen
Nr. 4 — Sicherheit der Lieferkette, einschließlich der Beziehungen zu unmittelbaren AnbieternDokumentierte Sub-Processor-Kette des Monitoring-Stacks selbst: EU-Datenhaltung, AVV, Jurisdiktion des Betreibers — der Monitoring-Dienst ist Teil der Lieferkette des Endkunden
Nr. 6 — Konzepte zur Bewertung der Wirksamkeit der MaßnahmenKontinuierliche Verfügbarkeits-Reports und Uptime-Historie als laufende Evidenz, ob die Betriebs- und Incident-Maßnahmen wirken

Ebenso wichtig ist die ehrliche Gegenseite: Die Nummern 5, 7, 8, 9 und 10 deckt Monitoring nicht ab. Schwachstellenmanagement, Schulungen, Kryptografie-Konzepte, Zugriffskontrolle und MFA sind eigenständige organisatorische und technische Maßnahmen — Monitoring liefert dazu keinen Beitrag. Wer seinem Endkunden das Gegenteil suggeriert, verkauft Scheinsicherheit und riskiert die eigene Vertragsbeziehung.

Was bleibt beim Endkunden — und was darfst du nicht versprechen?

Zwei rechtliche Leitplanken definieren, was du als MSP verkaufen kannst — und was nicht:

Erstens: Die Verantwortung ist nicht delegierbar. Adressat der Pflichten aus § 30 BSIG und der Bußgeldtatbestände aus § 65 BSIG bleibt die verpflichtete Einrichtung selbst. Daraus folgt als juristische Ableitung: Der Endkunde kann die operative Umsetzung an dich auslagern, seine rechtliche Verantwortung aber nicht. Die Bußgeldrahmen sind erheblich — für besonders wichtige Einrichtungen bis 10 Mio. Euro bzw. bei über 500 Mio. Euro Umsatz bis 2 % des Gesamtumsatzes, für wichtige Einrichtungen bis 7 Mio. Euro bzw. 1,4 %.

Zweitens: Die Geschäftsleitung des Endkunden ist persönlich in der Pflicht. Nach § 38 BSIG muss die Geschäftsleitung die Risikomanagementmaßnahmen umsetzen und ihre Umsetzung überwachen (Abs. 1), haftet bei Pflichtverletzung nach den Regeln des Gesellschaftsrechts (Abs. 2) und muss regelmäßig an Schulungen teilnehmen (Abs. 3). Ein sauberes MSP-Angebot gibt der Geschäftsleitung genau das Material, mit dem sie diese Überwachungspflicht erfüllen kann: regelmäßige Verfügbarkeits-Reports, Incident-Zusammenfassungen, dokumentierte Abdeckung.

Daraus ergibt sich die richtige Positionierung deines Pakets: Du verkaufst Nachweis-Artefakte plus Betrieb — Überwachungsabdeckung, Incident-Historie, Reports, Alarmketten und deren laufende Pflege. Du verkaufst keine Compliance. Formulierungen wie „NIS2-konform mit unserem Paket” gehören nicht in dein Angebot; „unterstützt die Nachweise zu § 30 Abs. 2 Nr. 2, 3 und 6” schon.

Wie sieht ein Whitelabel-Rechenbeispiel aus?

Die Werkzeugkosten sind der kleinste Posten der Kalkulation — das macht das Modell attraktiv. Das FoundersDeck-Scale-Tier kostet 39 € pro Monat und enthält 50 Monitore, 10 Status-Seiten mit Whitelabel-Option, 30-Sekunden-Checks und 365 Tage Datenaufbewahrung.

Eine Beispielrechnung (deine Preise kalkulierst du selbstverständlich frei, und nichts hiervon ist ein Erfolgsversprechen):

PositionBeispielwert
Endkunden über einen Scale-Account10 KMU
Setup je Endkunde5 Monitore + 1 whitegelabelte Status-Seite
Ausgelastete Kapazität50 von 50 Monitoren, 10 von 10 Status-Seiten
Beispielpreis „Verfügbarkeitsnachweis-Paket” je Endkunde25–49 €/Monat
Beispielumsatz gesamt250–490 €/Monat
Werkzeugkosten39 €/Monat

Die Differenz ist kein Reingewinn: Sie muss deine Einrichtung, das laufende Incident-Handling, das monatliche Reporting an die Geschäftsleitung des Kunden und deinen Vertrieb tragen — genau diese Betriebsleistung ist aber auch das, was der Endkunde bei dir kauft und selbst nicht leisten kann. Ein sinnvolles Paket umfasst typischerweise: Überwachung der kundeneigenen Dienste, Heartbeat-Checks für Backup-Jobs, eine Status-Seite unter dem Branding des Endkunden (oder deinem eigenen), definierte Alarmketten und einen monatlichen Verfügbarkeits-Report als § 30-Nachweis-Baustein.

Wächst der Bestand über 10 Endkunden, skalierst du mit weiteren Accounts — die Kostenstruktur bleibt linear und planbar.

Welche Meldefristen musst du für deine Kunden im Blick haben?

Tritt beim NIS2-pflichtigen Endkunden ein erheblicher Sicherheitsvorfall ein, gilt nach § 32 BSIG eine dreistufige Meldung an die gemeinsame Meldestelle von BSI und BBK:

StufeFristInhalt
Erstmeldungunverzüglich, spätestens 24 Stunden nach KenntnisErste Einordnung des Vorfalls
Aktualisierte Meldungspätestens 72 Stunden nach KenntnisBestätigung/Aktualisierung, erste Bewertung
Abschlussmeldungspätestens 1 MonatAbschließende Darstellung und Bewertung

„Erheblich” ist ein Sicherheitsvorfall nach § 2 Nr. 11 BSIG, wenn er schwerwiegende Betriebsstörungen oder finanzielle Verluste für die Einrichtung verursachen kann oder andere von erheblichen Schäden betroffen sein können.

Für dein Angebot heißt das: Die Meldepflicht bleibt beim Endkunden (und bei dir selbst, falls du erfasst bist) — aber die 24-Stunden-Frist ist ohne automatische Vorfall-Erkennung kaum belastbar einzuhalten. Ein Monitoring-Setup mit Zeitstempel der Erkennung, Alarmkette und durchsuchbarer Historie liefert dem Kunden die Rohdaten für Erstmeldung, 72-Stunden-Update und Abschlussbericht. Genau das gehört als Leistungsbaustein („Melde-Unterstützung: Zeitstempel, Vorfalldaten, Historienexport”) ins Paket — die rechtliche Meldung selbst gibt der Kunde ab.

Welche Rolle spielt FoundersDeck — und welche nicht?

Ehrlich eingeordnet: FoundersDeck ist das Werkzeug unter deinem Managed Service, nicht der Service selbst. Was es für das MSP-Modell leistet:

  • Whitelabel-Status-Seiten im Scale-Tier (39 €/Monat, 50 Monitore, 10 Status-Seiten, 30-Sekunden-Checks, 365 Tage Datenaufbewahrung) — die Status-Seite trägt das Branding deines Endkunden oder deines Systemhauses, nicht unseres
  • Uptime- und Heartbeat-Monitoring in einem Tool — inklusive der Backup-Job-Überwachung für § 30 Abs. 2 Nr. 3
  • Saubere Lieferkette für Nr. 4: FoundersDeck ist ein inhabergeführtes deutsches Unternehmen, alle Daten liegen bei Netcup in Nürnberg, ohne US-CLOUD-Act-Exposition; den AVV gibt es sofort als Download, ohne Sales-Call. Wie andere Tools nach Jurisdiktion und CLOUD-Act-Exposition dastehen, schlüsselt die EU Jurisdiction Database auf — nützlich auch als Argumentationshilfe im Kundengespräch.
  • 365 Tage Datenaufbewahrung — genug Historie für Jahres-Reports und Wirksamkeitsnachweise nach Nr. 6

Was FoundersDeck ausdrücklich nicht tut: Es macht weder dich noch deine Endkunden NIS2-konform. Es deckt die monitoringnahen Nummern aus § 30 Abs. 2 ab und liefert die Nachweis-Artefakte — Risikoanalyse, Schulungen, Kryptografie, Zugriffskontrolle und die übrige Organisation bleiben Aufgabe des Endkunden und gegebenenfalls deiner weiteren Beratungsleistung.

Betreust du Endkunden im Gesundheitswesen — Praxen, MVZ, Pflegeeinrichtungen oder deren Software-Lieferanten —, findest du die branchenspezifische Einordnung auf unserer Gesundheitswesen-Seite.

Häufige Fragen

Bin ich als MSP oder Systemhaus selbst von NIS2 betroffen?

Möglicherweise ja — und zwar direkt. Managed Services Provider (Anlage 1 BSIG, Sektor Digitale Infrastruktur, Nr. 6.1.10) und Managed Security Services Provider (Nr. 6.1.11) sind eigenständig als Einrichtungsart erfasst; die Legaldefinition des „Anbieters verwalteter Dienste” steht in § 2 Nr. 26 BSIG. Entgegen einer verbreiteten Fehldarstellung gelten dabei die normalen Größenschwellen aus § 28 BSIG — nicht eine größenunabhängige Erfassung: Ein MSP ist ab 50 Beschäftigten oder ab mehr als 10 Mio. Euro Umsatz und zugleich mehr als 10 Mio. Euro Bilanzsumme selbst wichtige Einrichtung. Kleinere Systemhäuser unterhalb dieser Schwellen sind meist nicht direkt pflichtig, treffen NIS2 aber über die Lieferkettenanforderungen ihrer Kunden. Die Einstufung ist im Einzelfall zu prüfen, etwa mit der BSI-Betroffenheitsprüfung.

Macht ein Monitoring-Paket meine Endkunden NIS2-konform?

Nein, und genau das solltest du auch nie versprechen. § 30 Abs. 2 BSIG listet zehn breite Mindestmaßnahmen — von Risikoanalyse über Kryptografie und Schulungen bis Zugriffskontrolle und MFA. Kontinuierliches Monitoring adressiert davon einen Teilbereich: Verfügbarkeitsüberwachung, Vorfall-Erkennung mit Zeitstempel, Incident-Historie und Verfügbarkeits-Reports als Nachweis-Artefakte. Was du als MSP verkaufst, sind diese Nachweise plus deren Betrieb — kein ISMS und keine Compliance. Die Gesamtkonformität bleibt eine organisatorische Leistung des Endkunden.

Kann der KMU-Endkunde seine NIS2-Verantwortung an mich als MSP auslagern?

Die operative Arbeit ja, die rechtliche Verantwortung nein. Adressat der Pflichten aus § 30 BSIG und der Bußgeldtatbestände aus § 65 BSIG bleibt die verpflichtete Einrichtung selbst — daraus folgt als juristische Ableitung, dass sich die Verantwortung durch Beauftragung eines Dienstleisters nicht abgeben lässt. Hinzu kommt § 38 BSIG: Die Geschäftsleitung des Endkunden muss die Risikomanagementmaßnahmen umsetzen und ihre Umsetzung überwachen und haftet bei Verletzung dieser Pflicht nach den Regeln des Gesellschaftsrechts. Für dich als MSP heißt das: Du lieferst Umsetzung und Nachweise, dein Vertrag sollte die Verantwortungsverteilung aber sauber dokumentieren.

Welche Meldefristen gelten nach § 32 BSIG?

Bei einem erheblichen Sicherheitsvorfall gilt eine dreistufige Meldung an die gemeinsame Meldestelle von BSI und BBK: Erstmeldung unverzüglich, spätestens 24 Stunden nach Kenntnis; aktualisierte Meldung spätestens 72 Stunden nach Kenntnis; Abschlussmeldung spätestens einen Monat nach der Meldung. Wann ein Vorfall „erheblich” ist, definiert § 2 Nr. 11 BSIG — im Kern schwerwiegende Betriebsstörungen oder finanzielle Verluste für die Einrichtung oder erhebliche Schäden für Dritte. Für die 24-Stunden-Frist zählt jede Minute: Eine automatische Vorfall-Erkennung mit Zeitstempel und durchsuchbarer Historie ist die praktische Grundlage, damit dein Endkunde überhaupt fristgerecht melden kann. Die Meldepflicht selbst bleibt beim pflichtigen Endkunden.

Was kostet der Einstieg in ein Whitelabel-Monitoring-Angebot?

Überschaubar wenig — das ist der Reiz des Modells. Das FoundersDeck-Scale-Tier kostet 39 Euro pro Monat und enthält 50 Monitore, 10 Status-Seiten mit Whitelabel-Option, 30-Sekunden-Checks und 365 Tage Datenaufbewahrung. Ein Beispiel-Setup: 10 KMU-Endkunden mit je 5 Monitoren und einer whitegelabelten Status-Seite passen in einen einzigen Account. Wie du dein „Verfügbarkeitsnachweis-Paket” bepreist, kalkulierst du frei — üblich sind bei Managed Services Aufschläge, die deine Einrichtungs-, Betriebs- und Reporting-Leistung abbilden. Das ist eine Beispielrechnung, kein Erfolgsversprechen: Dein Deckungsbeitrag hängt an deiner eigenen Arbeitszeit und deinem Vertrieb.


Dieser Artikel dient der Orientierung, nicht der Rechtsberatung. Maßgeblich sind der Gesetzeswortlaut des BSIG 2025 — insbesondere § 2, § 28, § 30, § 32, § 33, § 38, § 65 und Anlage 1 — sowie die individuelle Prüfung der eigenen Betroffenheit. Weitere Quellen: Bundesgesetzblatt (BGBl. 2025 I Nr. 301), BSI zu NIS-2-regulierten Unternehmen, BSI NIS-2-Betroffenheitsprüfung. Stand: Juli 2026.

Engin Yildirim – Gründer von FoundersDeck

Engin Yildirim

Gründer von FoundersDeck. 13+ Jahre Erfahrung in der Softwareentwicklung. Entwickelt EU-First-Tools für Gründer und Indie-Hacker.

Mehr über mich →