Welche Meldefristen gelten bei einem Sicherheitsvorfall nach NIS2?

Bei einem erheblichen Sicherheitsvorfall gilt eine dreistufige Meldung an das BSI nach § 32 BSIG (2025), der Art. 23 NIS2 umsetzt: eine Erstmeldung unverzüglich, spätestens 24 Stunden nach Kenntniserlangung; eine Folgemeldung mit erster Bewertung spätestens 72 Stunden nach Kenntniserlangung; und eine Abschlussmeldung spätestens einen Monat nach der Meldung. Dauert der Vorfall länger an, tritt eine Fortschrittsmeldung an die Stelle der Abschlussmeldung. Diese Fristen gelten für meldepflichtige Einrichtungen — die individuelle Betroffenheit ist im Einzelfall zu prüfen.

Was ist ein 'erheblicher' Sicherheitsvorfall?

Ein Sicherheitsvorfall ist nach dem BSIG unter anderem dann erheblich, wenn er einen finanziellen Schaden von über 500.000 Euro oder über 5 Prozent des Jahresumsatzes verursachen kann, wenn er zum Tod oder zu einer schweren Gesundheitsschädigung einer Person führen kann oder wenn er den Ausfall kritischer Dienstleistungen bewirkt. Gerade im Gesundheitsumfeld ist die zweite und dritte Schwelle relevant: Fällt eine Anwendung aus, die in Behandlungsabläufe eingebunden ist, kann die Erheblichkeit schnell erreicht sein. Die konkrete Einordnung ist im Einzelfall zu prüfen.

Wie hilft ein Monitoring-Tool bei der Meldepflicht?

Meldefristen laufen ab Kenntniserlangung — und die setzt voraus, dass du einen Ausfall überhaupt bemerkst. Ein Monitoring-Tool verkürzt genau diese Zeit: Es erkennt Ausfälle automatisch, klassifiziert die Ursache (SSL, DNS, Timeout, HTTP) und führt eine lückenlose Incident-Historie mit Zeitstempeln. Diese Historie ist die belastbare Grundlage für Meldungen und für Nachweise gegenüber Kliniken und Kassen. Das Tool nimmt dir die rechtliche Bewertung und die Meldung selbst nicht ab, liefert aber die Fakten — wann, wie lange, welche Ursache — die jede Meldung und jeder Lieferanten-Nachweis braucht.

Störungsmeldung für DiGA & Medizinsoftware: Fristen und Nachweise

Q: Muss ein kleiner DiGA-Hersteller Ausfälle selbst ans BSI melden?

Meistens nicht direkt. Die direkte Meldepflicht nach § 32 BSIG setzt voraus, dass ein Hersteller selbst als wichtige oder besonders wichtige Einrichtung unter das BSIG fällt — das hängt an den Größenschwellen des § 28 BSIG (in der Regel mindestens 50 Beschäftigte oder über 10 Mio. Euro Umsatz und Bilanzsumme). Die meisten DiGA-Hersteller liegen darunter und sind nicht direkt meldepflichtig. Sie begegnen den Meldepflichten aber über die Lieferkette: Ihre Klinik- und Kassenkunden sind selbst pflichtig und geben die Anforderungen vertraglich weiter — inklusive der Erwartung, dass der Hersteller Störungen schnell erkennt und dokumentiert.

Q: Ist die NIS2-Störungsmeldung dasselbe wie die MDR-Vigilanzmeldung?

Nein, das sind zwei verschiedene Meldewege mit verschiedenen Adressaten. Die NIS2-/BSIG-Störungsmeldung betrifft IT-Sicherheitsvorfälle und Verfügbarkeitsstörungen und geht ans BSI. Die Vigilanzmeldung nach Medizinprodukterecht (MDR) betrifft schwerwiegende Vorkommnisse mit Bezug zur Produktsicherheit und geht an die zuständige Medizinprodukte-Behörde. Ein IT-Ausfall kann im Einzelfall beide Wege berühren, wenn er patientensicherheitsrelevant wird. Hersteller sollten beide Meldeprozesse getrennt aufsetzen und im Zweifel rechtlich prüfen lassen, welcher Weg greift.

„Unsere App war heute Nacht drei Stunden down — müssen wir das jetzt irgendwo melden?” Diese Frage taucht in Health-IT- und Gründer-Communities regelmäßig auf, oft in Panik und mitten in der Nacht. Seit NIS2 in Deutschland in Kraft ist, hat sie eine ernste Seite bekommen. Dieser Leitfaden klärt, wer bei einem Ausfall wann melden muss, warum die meisten kleinen DiGA-Hersteller den Weg über die Lieferkette gehen — und wie du Incidents so dokumentierst, dass du im Ernstfall lieferfähig bist.

Eine Störungsmeldung im Sinne von NIS2 ist die fristgebundene Meldung eines erheblichen Sicherheitsvorfalls an das BSI. Rechtsgrundlage ist § 32 des BSIG 2025, das die europäische NIS2-Richtlinie (EU) 2022/2555 in deutsches Recht umsetzt. Die Meldung läuft in drei Stufen — und die erste Frist ist knapp.

Die drei Fristen: 24 Stunden, 72 Stunden, ein Monat

Für meldepflichtige Einrichtungen sieht § 32 BSIG bei einem erheblichen Sicherheitsvorfall eine dreistufige Meldung ans BSI vor:

Erstmeldung — unverzüglich, spätestens 24 Stunden nach Kenntniserlangung; mit Angabe, ob eine rechtswidrige oder böswillige Handlung bzw. grenzüberschreitende Auswirkungen vermutet werden.
Folgemeldung — spätestens 72 Stunden nach Kenntniserlangung; Bestätigung oder Aktualisierung der Erstmeldung samt erster Bewertung des Schweregrads und gegebenenfalls Kompromittierungsindikatoren.
Abschlussmeldung — spätestens einen Monat nach der Meldung. Dauert der Vorfall länger an, tritt eine Fortschrittsmeldung an ihre Stelle; die finale Meldung folgt nach Abschluss der Bearbeitung.

Der entscheidende Punkt: Alle Fristen laufen ab Kenntniserlangung. Wer einen Ausfall erst Stunden später bemerkt, hat einen erheblichen Teil des 24-Stunden-Fensters bereits verloren, bevor die Uhr für ihn gefühlt überhaupt zu ticken begann. Schnelle Erkennung ist damit keine Komfortfrage, sondern der Anfang der Frist.

Ist ein Ausfall überhaupt „erheblich”?

Nicht jede Störung ist meldepflichtig. Erheblich ist ein Sicherheitsvorfall nach dem BSIG unter anderem, wenn er

einen finanziellen Schaden von über 500.000 Euro oder über 5 Prozent des Jahresumsatzes verursachen kann,
zum Tod oder zu einer schweren Gesundheitsschädigung einer Person führen kann, oder
den Ausfall oder die erhebliche Beeinträchtigung kritischer Dienstleistungen bewirkt.

Im Gesundheitsumfeld sind die zweite und dritte Schwelle keine theoretischen Randfälle. Eine Anwendung, die in Behandlungs- oder Versorgungsabläufe eingebunden ist, kann die Erheblichkeit bei einem längeren Ausfall schnell erreichen. Die konkrete Bewertung bleibt eine Einzelfallentscheidung — im Zweifel rechtlich prüfen.

Der Regelfall für kleine DiGA-Hersteller: die Lieferkette

Die gute Nachricht für kleine Teams: Die direkte Meldepflicht nach § 32 BSIG trifft dich meist nicht. Sie setzt voraus, dass du selbst als wichtige oder besonders wichtige Einrichtung unter das BSIG fällst — abhängig von den Größenschwellen des § 28 BSIG (in der Regel mindestens 50 Beschäftigte oder über 10 Mio. Euro Umsatz und Bilanzsumme). Die meisten DiGA-Hersteller liegen darunter.

Die weniger gute Nachricht: Über die Lieferkette kommt das Thema trotzdem zu dir. Deine Klinik- und Kassenkunden sind häufig selbst meldepflichtig und müssen nach § 30 Abs. 2 Nr. 4 BSIG die Sicherheit ihrer Lieferkette steuern. Sie geben die Anforderungen vertraglich weiter — über Fragebögen, SLAs und die schlichte Erwartung, dass du bei einem Vorfall schnell und belastbar lieferst: Was ist passiert, seit wann, wie lange, mit welcher Ursache. Wer das nicht binnen Stunden beantworten kann, wird zum Risiko im Meldeprozess seines Kunden. Den vollständigen Weg über die Lieferkette haben wir in DiGA & NIS2: Bist du betroffen? und im NIS2-Deep-Dive für Medizinsoftware-Anbieter aufgeschrieben.

Was du liefern können musst — und wie Monitoring dabei hilft

Ob direkt meldepflichtig oder über die Lieferkette: In beiden Fällen brauchst du für jeden relevanten Ausfall dieselben Fakten. Ein Monitoring-Tool liefert sie automatisch:

Nachweisbedarf	Was Monitoring beiträgt
Kenntniserlangung (Fristbeginn)	Automatische Ausfallerkennung — die Frist beginnt so früh wie möglich, nicht erst bei zufälliger Entdeckung
Zeitpunkt & Dauer	Zeitgestempelte Incident-Historie mit Start, Ende und Gesamtdauer
Ursache / erste Bewertung	Klassifikation nach SSL, DNS, Timeout, HTTP-Fehler statt „irgendwas war kaputt"
Nachweis gegenüber Kunden	Öffentliche, cookie-freie Status-Seite und exportierbare Historie als Transparenzsignal

Zur Ehrlichkeit gehört die Abgrenzung: Ein Monitoring-Tool nimmt dir die rechtliche Bewertung und die Meldung selbst nicht ab. Ob ein Vorfall erheblich ist und an wen gemeldet wird, bleibt deine Entscheidung — im Zweifel mit rechtlicher Beratung. Was das Tool leistet, ist die Faktengrundlage: Es sorgt für frühe Kenntniserlangung, eine lückenlose, klassifizierte Incident-Historie und einen belastbaren Verfügbarkeitsnachweis gegenüber Kostenträgern. Genau das trennt eine kontrollierte Meldung von einer hektischen Rekonstruktion aus Log-Fetzen. Warum ein ISMS oder GRC-Tool diese Messung nicht ersetzt, steht in Verfügbarkeitsnachweis für DiGA.

Ein weiterer Aspekt, der oft übersehen wird: Wo deine Monitoring- und Incident-Daten selbst liegen. Sie beschreiben deine Infrastruktur und Vorfälle — im Gesundheitskontext heikel. Für DiGA gilt zusätzlich § 4 Abs. 3 DiGAV zum Verarbeitungsort. FoundersDeck verarbeitet ausschließlich in Nürnberg, ist ein inhabergeführtes deutsches Unternehmen ohne CLOUD-Act-Exposition und als Sub-Processor sauber einbindbar. Welche Tools jurisdiktionell wie dastehen, zeigt die EU SaaS Jurisdiction Database (57 Tools, zuletzt verifiziert am 9. Juni 2026).

NIS2-Störungsmeldung ist nicht MDR-Vigilanz

Ein verbreiteter Irrtum: Die NIS2-/BSIG-Störungsmeldung sei dasselbe wie die Vigilanzmeldung im Medizinprodukterecht. Ist sie nicht. Die NIS2-Meldung betrifft IT-Sicherheitsvorfälle und Verfügbarkeitsstörungen und geht ans BSI. Die MDR-Vigilanzmeldung betrifft schwerwiegende Vorkommnisse mit Bezug zur Produktsicherheit und geht an die zuständige Medizinprodukte-Behörde. Ein IT-Ausfall kann im Einzelfall beide Wege berühren, wenn er patientensicherheitsrelevant wird. Setze beide Prozesse getrennt auf und prüfe im Zweifel, welcher greift.

Checkliste: in 30 Minuten meldebereit

Automatische Ausfallerkennung einrichten — für jede DiGA-Komponente und jedes Hintergrundsystem, damit die Kenntniserlangung nicht vom Zufall abhängt.
Alert-Kanäle festlegen — wer wird bei einem Vorfall wie schnell erreicht (E-Mail, Slack, Discord)?
Incident-Historie führen — zeitgestempelt, mit Ursachenklassifikation, exportierbar.
Meldeschwelle vorab klären — ab wann ist ein Vorfall bei euch „erheblich”? Mit Rechtsberatung definieren, bevor er eintritt.
Lieferanten-Anforderungen kennen — welche Fristen und Nachweise erwarten deine Klinik- und Kassenkunden vertraglich?
Status-Seite bereithalten — als Transparenzkanal gegenüber Kunden während eines Vorfalls.

Fazit

Die NIS2-Meldefristen — 24 Stunden, 72 Stunden, ein Monat — laufen ab Kenntniserlangung. Für die meisten kleinen DiGA-Hersteller besteht keine direkte Meldepflicht, aber über die Lieferkette müssen sie Störungen schnell erkennen, einordnen und belegen. Ein Monitoring-Tool macht dich nicht rechtssicher — aber es sorgt für frühe Erkennung und die lückenlose, klassifizierte Incident-Historie, die jede Meldung und jeder Kunden-Nachweis braucht.

Mehr zum Zusammenspiel der Pflichten auf Monitoring für DiGA-Hersteller und Monitoring für das Gesundheitswesen. Verwandt: BSI TR-03161 für DiGA-Hersteller und der Verfügbarkeitsnachweis für DiGA.

Dieser Artikel gibt den Rechtsstand zum Stand Juni 2026 wieder und dient der Orientierung, nicht der Rechtsberatung. Maßgeblich sind die jeweiligen Gesetzes- und Verordnungstexte sowie die individuelle Prüfung — im Einzelfall rechtlich prüfen. Quellen: § 32 BSIG (2025), § 30 BSIG (2025), § 28 BSIG (2025), NIS2-Richtlinie (EU) 2022/2555.