Meldefristen für Vorfälle

Wenn die Einrichtung Kenntnis von dem erheblichen Sicherheitsvorfall erlangt, nicht wenn der Vorfall begann. Artikel 23 Absatz 4 rechnet sowohl die Frühwarnung (24 Stunden) als auch die Meldung des Vorfalls (72 Stunden) ab diesem Zeitpunkt.

Nach Artikel 23 Absatz 4 Buchstabe a gibt die Frühwarnung gegebenenfalls an, ob der Verdacht besteht, dass der erhebliche Sicherheitsvorfall auf rechtswidrige oder böswillige Handlungen zurückzuführen ist, und ob er grenzüberschreitende Auswirkungen haben könnte. Details folgen in der 72-Stunden-Meldung.

Nein: einen Monat nach der Übermittlung der Meldung des Vorfalls. Dauert der Vorfall dann noch an, ist stattdessen ein Fortschrittsbericht fällig und der Abschlussbericht innerhalb eines Monats nach Abschluss der Bearbeitung.

Ja. Ein Vertrauensdiensteanbieter meldet erhebliche Sicherheitsvorfälle, die sich auf die Erbringung seiner Vertrauensdienste auswirken, innerhalb von 24 Stunden nach Kenntnis statt innerhalb von 72 Stunden.

Nach Artikel 33 DSGVO meldet der Verantwortliche eine Verletzung des Schutzes personenbezogener Daten unverzüglich und möglichst binnen 72 Stunden, nachdem sie ihm bekannt wurde, der Aufsichtsbehörde, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die betroffenen Personen. Nach Artikel 34 sind die Betroffenen unverzüglich zu benachrichtigen, wenn voraussichtlich ein hohes Risiko besteht. NetSenX bereitet für Ihren Datenschutzbeauftragten eine Meldung nach Artikel 33 vor; Entscheidung und Übermittlung bleiben bei Ihnen.

Artikel 14 des Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen, aktiv ausgenutzte Schwachstellen in ihren Produkten und schwerwiegende Vorfälle, die die Sicherheit dieser Produkte beeinträchtigen, in mehreren Stufen zu melden. Stufen, Fristen und Empfänger der Meldungen regelt die Verordnung (EU) 2024/2847, Artikel 14. Diese Meldepflichten gelten ab dem 11. September 2026. Sie betreffen Hersteller, nicht Unternehmen, die die Produkte nur nutzen; ein eigener Vorfall eines Nutzers kann aber nach NIS2 oder DSGVO meldepflichtig sein.

DORA, die Verordnung über die digitale operationale Resilienz (Verordnung (EU) 2022/2554), gilt seit dem 17. Januar 2025 für Finanzunternehmen wie Banken, Versicherer, Wertpapierfirmen und Zahlungsinstitute sowie für danach benannte kritische IKT-Drittdienstleister. Artikel 19 verpflichtet Finanzunternehmen, schwerwiegende IKT-bezogene Vorfälle der zuständigen Behörde zu melden, mit einer Erstmeldung, einem Zwischenbericht und einem Abschlussbericht; die Fristen legen technische Standards nach Artikel 20 fest. Für Finanzunternehmen gehen die DORA-Regeln zu IKT-Vorfällen den allgemeinen Regeln von NIS2 vor; das BSIG nimmt sie entsprechend von seinen Melde- und Risikomanagementpflichten aus (§ 28 Abs. 6). Erbringen Sie IKT-Dienste für ein Finanzunternehmen, erreicht DORA Sie über den Vertrag: Artikel 30 nennt Bestimmungen, die solche Verträge enthalten müssen, darunter Unterstützung bei Vorfällen, Prüfungsrechte und Ausstiegspläne. Rechnen Sie mit detaillierten Fragen und Klauseln.

Ein Vorfall, der schwerwiegende Betriebsstörungen Ihrer Dienste oder finanzielle Verluste für Ihr Unternehmen verursacht hat oder verursachen kann, oder der andere Personen oder Organisationen durch erhebliche materielle oder immaterielle Schäden beeinträchtigt hat oder beeinträchtigen kann. Das ist der Maßstab in Artikel 23 Absatz 3, und nur erhebliche Vorfälle sind meldepflichtig; § 2 Nr. 11 BSIG übernimmt ihn wörtlich. Verursachen kann heißt: Sie warten nicht, bis der Schaden eingetreten ist. Für bestimmte digitale Anbieter wie Cloud-, DNS- und Managed-Service-Anbieter legt die Durchführungsverordnung (EU) 2024/2690 genauere Schwellen fest; für andere können nationale Stellen Leitlinien veröffentlichen. Legen Sie in Ihrem Vorfallverfahren vorab fest, welche Kriterien Sie anwenden, etwa Ausfall über eine bestimmte Zeit, betroffene Kundendaten oder ein krimineller Täter, und wer entscheidet. NetSenX verfolgt die Fristen, sobald Sie entschieden haben; die Entscheidung bleibt bei Ihnen.

Meist nicht als erheblicher Vorfall, aber es kann sein, und freiwillig melden können Sie ihn immer. Die Pflicht aus Artikel 23 betrifft erhebliche Vorfälle: solche, die schwere Störungen, finanzielle Verluste oder erhebliche Schäden für andere verursacht haben oder verursachen konnten. Ein Angriff, der gestoppt wurde, bevor er irgendeine Wirkung hatte, erfüllt das in der Regel nicht; einer, der sehr knapp war, etwa Ransomware, die erst auf dem Backup-Server entdeckt wurde, unter Umständen schon. NIS2 unterscheidet zudem Beinahe-Vorfälle und erhebliche Cyberbedrohungen, und Artikel 30 erlaubt deren freiwillige Meldung, die dem CSIRT hilft, andere zu warnen; in Deutschland regelt das § 5 BSIG. Halten Sie jedes solche Ereignis mit Begründung in Ihrem Vorfallregister fest, damit Sie später erklären können, warum Sie gemeldet haben oder nicht. NetSenX bewahrt die Alarme hinter jeder Entscheidung auf.

Indem es alles, was nicht vom Vorfall abhängt, vorher vorbereitet. Die Frühwarnung nach Artikel 23 Absatz 4 Buchstabe a ist kurz: Sie teilt mit, dass ein erheblicher Vorfall eingetreten ist, und gegebenenfalls, ob ein rechtswidriges oder böswilliges Handeln vermutet wird und ob grenzüberschreitende Auswirkungen möglich sind. Die Einzelheiten folgen in der Meldung nach 72 Stunden. Bereiten Sie daher eine einseitige Vorlage vor, den Meldeweg und die Zugangsdaten für Ihr nationales CSIRT oder Ihre Behörde, in Deutschland das BSI-Portal, eine benannte Person mit Vertretung, die melden darf, und eine interne Regel, wer über die Erheblichkeit entscheidet. Proben Sie einmal im Jahr. Kleine Teams verlieren die meiste Zeit damit, herauszufinden, was passiert ist; sorgen Sie also dafür, dass Alarme auch nachts und am Wochenende jemanden erreichen. NetSenX startet die Fristuhr je Vorfall und hält die Alarme mit Zeit, Geräten und Zielen an einem Ort.

Eine kurze Liste von Fakten, einen bereiten Meldeweg und eine Person, die melden darf. Für die Frühwarnung selbst brauchen Sie: den Zeitpunkt, zu dem Sie Kenntnis erlangt haben; eine einfache Beschreibung, was bisher betroffen ist; ob Sie ein böswilliges oder rechtswidriges Handeln vermuten; und ob andere Länder betroffen sein könnten. Für die folgende Meldung nach 72 Stunden sammeln Sie sofort: Schweregrad und Auswirkungen, betroffene Systeme und Dienste, Kompromittierungsindikatoren wie bösartige Adressen oder Datei-Hashes und die ergriffenen Maßnahmen. Führen Sie ab der ersten Minute eine laufende Zeitleiste, wer was getan hat. Prüfen Sie, ob personenbezogene Daten betroffen sind, denn parallel kann eine Meldung nach DSGVO laufen. NetSenX liefert den Netzwerkteil dieser Zeitleiste: die erste ungewöhnliche Verbindung, beteiligte Geräte, Ziele und Datenmengen sowie die Fristen nach Artikel 23 ab dem erfassten Zeitpunkt der Kenntnis.

Manchmal. Nach Artikel 23 Absatz 1 unterrichten erfasste Einrichtungen gegebenenfalls die Empfänger ihrer Dienste unverzüglich über erhebliche Vorfälle, die die Erbringung dieser Dienste beeinträchtigen könnten. Nach Artikel 23 Absatz 2 teilen Einrichtungen, soweit zutreffend, den potenziell von einer erheblichen Cyberbedrohung betroffenen Empfängern mit, welche Abhilfemaßnahmen sie ergreifen können, und gegebenenfalls auch die Bedrohung selbst. Behörden können solche Unterrichtungen auch anordnen. In Deutschland kann das BSI anordnen, die Empfänger zu unterrichten (§ 35 Abs. 1 BSIG), und Einrichtungen aus Sektoren wie Finanzwesen, digitale Infrastruktur und Verwaltung von IKT-Diensten müssen sie über erhebliche Cyberbedrohungen informieren (§ 35 Abs. 2). Verträge und die DSGVO können eigene Pflichten hinzufügen. Bereiten Sie eine Kundenmitteilung als Vorlage im Notfallplan vor.

Oft ja, wenn personenbezogene Daten betroffen waren, auch wenn nichts gestohlen wurde. Die DSGVO definiert in Artikel 4 Nummer 12 eine Verletzung des Schutzes personenbezogener Daten als Verletzung der Sicherheit, die zur Vernichtung, zum Verlust, zur Veränderung oder zur unbefugten Offenlegung von beziehungsweise zum unbefugten Zugang zu personenbezogenen Daten führt. Die Verschlüsselung durch Ransomware macht Daten unverfügbar, eine Verletzung der Verfügbarkeit, und Angreifer kopieren Daten oft vor der Verschlüsselung. Nach Artikel 33 meldet der Verantwortliche die Verletzung unverzüglich und möglichst binnen 72 Stunden, nachdem sie ihm bekannt wurde, der Aufsichtsbehörde, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für Personen, etwa weil ein aktuelles Backup alles schnell wiederhergestellt hat und nichts das Netz verließ. Dokumentieren Sie die Begründung in jedem Fall. NetSenX kann zeigen, ob vor der Verschlüsselung ungewöhnliche Uploads von überwachten Geräten abgingen, was für diese Bewertung zählt.

Möglicherweise der Behörde, oft aber nicht den Betroffenen. Artikel 34 Absatz 3 Buchstabe a DSGVO sagt, dass Betroffene nicht benachrichtigt werden müssen, wenn der Verantwortliche Maßnahmen wie Verschlüsselung angewandt hat, durch die die Daten für Unbefugte unzugänglich gemacht werden. Die Meldung an die Aufsichtsbehörde nach Artikel 33 ist eine eigene Frage: Sie ist nötig, es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für Personen, und das hängt davon ab, wie stark die Verschlüsselung war, ob auch der Schlüssel offengelegt wurde und ob Ihnen die Daten noch zur Verfügung stehen. Lag der Schlüssel auf demselben gestohlenen Laptop oder war die Verschlüsselung schwach, sind die Daten als offengelegt zu behandeln. Halten Sie fest, welche Daten wie verschlüsselt waren und wo die Schlüssel lagen. Netzwerkbelege, was wann abgeflossen ist, helfen Ihrem Datenschutzbeauftragten bei der Entscheidung.

Ja, schrittweise, und später nur mit Begründung. Artikel 33 Absatz 4 DSGVO erlaubt, die Informationen ohne unangemessene weitere Verzögerung schrittweise zur Verfügung zu stellen, wenn nicht alles zur gleichen Zeit bereitgestellt werden kann, und Artikel 33 Absatz 1 verlangt, einer Meldung nach mehr als 72 Stunden eine Begründung für die Verzögerung beizufügen. Warten Sie also nicht auf das vollständige Bild: Senden Sie innerhalb der Frist eine erste Meldung mit dem, was Sie wissen, der Art der Verletzung, den wahrscheinlichen Folgen, den bisherigen Maßnahmen und dem Kontakt des Datenschutzbeauftragten, und ergänzen Sie, sobald Fakten vorliegen. Halten Sie fest, wann Sie Kenntnis erlangt haben und warum ein Teil später kam. Aufsichtsbehörden bieten meist Online-Formulare, die Nachträge erlauben. NetSenX bereitet aus den Vorfalldaten eine Meldung nach Artikel 33 für Ihren Datenschutzbeauftragten vor; das Einreichen bleibt bei Ihnen.

Wenn dem Verantwortlichen die Verletzung des Schutzes personenbezogener Daten bekannt wird, nicht wenn sie begann. Artikel 33 Absatz 1 zählt die 72 Stunden ab dem Zeitpunkt, zu dem die Verletzung bekannt wurde. Leitlinien des Europäischen Datenschutzausschusses gehen davon aus, dass ein Verantwortlicher Kenntnis hat, wenn er mit hinreichender Sicherheit weiß, dass ein Sicherheitsvorfall eingetreten ist, der personenbezogene Daten beeinträchtigt hat. Eine kurze erste Untersuchung, um das festzustellen, ist erlaubt, muss aber zügig erfolgen; Kenntnis lässt sich nicht hinauszögern, indem man nicht nachsieht. Ein Auftragsverarbeiter, der eine Verletzung entdeckt, muss den Verantwortlichen unverzüglich informieren (Artikel 33 Absatz 2), und dessen Frist beginnt in der Regel, wenn er davon erfährt. Halten Sie im Vorfallprotokoll daher den genauen Zeitpunkt fest, an dem jemand feststellte, dass personenbezogene Daten betroffen sind. NetSenX lässt Sie diesen Zeitpunkt je Vorfall erfassen und bewahrt die Alarme auf, die zeigen, wann die Aktivität begann.

Jedes Gesetz hat eigene Meldung, Empfänger und Frist, und ein Vorfall kann mehrere auslösen. Ein erheblicher Vorfall bei einer erfassten Einrichtung geht nach Artikel 23 NIS2 an das CSIRT oder die zuständige Behörde, in Deutschland an die gemeinsame Meldestelle von BSI und BBK; sind personenbezogene Daten betroffen, meldet der Verantwortliche zusätzlich nach Artikel 33 DSGVO an die Datenschutzaufsicht; ein Finanzunternehmen meldet schwerwiegende IKT-Vorfälle nach Artikel 19 DORA statt nach NIS2; und ein Hersteller kann Pflichten nach dem Cyber Resilience Act haben, siehe Verordnung (EU) 2024/2847, Artikel 14. Manche nationalen Systeme bieten ein gemeinsames Portal, doch gehen Sie nicht davon aus, dass eine Meldung alles abdeckt. Führen Sie einen Vorfalldatensatz und erzeugen Sie jede Meldung daraus, damit die Fakten übereinstimmen. Artikel 35 NIS2 verlangt zudem, dass NIS2-Behörden die Datenschutzaufsicht über ihnen bekannte Verletzungen informieren. NetSenX verfolgt die NIS2-Fristen und erstellt aus denselben Daten einen Entwurf nach Artikel 33 DSGVO.

Ein Vorfall, den ein Finanzunternehmen anhand der Kriterien aus Artikel 18 DORA und der danach erlassenen technischen Standards als schwerwiegend einstuft. Artikel 18 nennt Kriterien wie Zahl und Bedeutung der betroffenen Kunden oder Finanzgegenparteien, Betrag oder Zahl der betroffenen Transaktionen, Reputationsschaden, Dauer und Ausfallzeit des Dienstes, geografische Ausbreitung, Datenverluste mit Folgen für Verfügbarkeit, Authentizität, Integrität oder Vertraulichkeit, Kritikalität der betroffenen Dienste und wirtschaftliche Auswirkungen. Die Standards machen daraus Schwellenwerte. Nur schwerwiegende Vorfälle sind nach Artikel 19 zu melden; erhebliche Cyberbedrohungen können freiwillig gemeldet werden. Bauen Sie die Einstufung in Ihr Vorfallverfahren ein, damit die Entscheidung schnell, wiederholbar und dokumentiert ist, und vereinbaren Sie mit Ihren IKT-Dienstleistern, wie sie Ihnen die nötigen Fakten liefern. Finanzkunden erwarten das auch von ihren Lieferanten.

Sie stehen in den technischen Standards nach Artikel 20 DORA, nicht im Verordnungstext selbst; lesen Sie für die genauen Stunden und Tage diese Standards und die Hinweise Ihrer zuständigen Aufsicht. Artikel 19 Absatz 4 legt die Abfolge fest: eine Erstmeldung, einen Zwischenbericht, sobald sich der Status des ursprünglichen Vorfalls erheblich geändert hat oder sich die Behandlung aufgrund neuer Informationen geändert hat, gefolgt von aktualisierten Meldungen nach Bedarf, und einen Abschlussbericht, wenn die Ursachenanalyse abgeschlossen ist. Die Standards regeln auch Inhalte und Vorlagen. Da die Fristen an Erkennung und Einstufung als schwerwiegend anknüpfen, zählt die Geschwindigkeit der Einstufung so viel wie die des Schreibens. Sind Sie IKT-Dienstleister eines Finanzunternehmens, verlangt Ihr Vertrag voraussichtlich, den Kunden so schnell zu informieren, dass er diese Fristen einhalten kann.

Über die zentrale Meldeplattform, die die ENISA für den Cyber Resilience Act betreibt. Nach Artikel 14 der Verordnung (EU) 2024/2847 melden Hersteller von Produkten mit digitalen Elementen aktiv ausgenutzte Schwachstellen ihrer Produkte und schwerwiegende Vorfälle, die deren Sicherheit beeinträchtigen, über diese Plattform; die Meldung geht an das als Koordinator benannte CSIRT im Mitgliedstaat der Hauptniederlassung des Herstellers und an die ENISA. Zu Stufen, Fristen und Inhalten siehe Verordnung (EU) 2024/2847, Artikel 14. Diese Pflichten betreffen Hersteller, auch Softwareunternehmen, die Produkte auf dem EU-Markt bereitstellen, nicht Unternehmen, die die Produkte nur nutzen. Nutzer können nach demselben Ereignis eigene Meldungen nach NIS2 oder DSGVO zu machen haben. Entwickeln Sie Software, richten Sie einen Prozess für den Umgang mit Schwachstellen ein und klären Sie den Zugang zur Plattform, bevor Sie ihn brauchen.

Oft ja, aber das ist eine eigene Entscheidung neben den Meldepflichten. Ein Ransomware-Angriff, Datendiebstahl, Betrug oder Erpressung ist meist eine Straftat, und eine Strafanzeige kann bei Versicherungsansprüchen, beim Rückruf einer betrügerischen Überweisung durch die Bank und bei Ermittlungen helfen, die Ihren Fall mit anderen verbinden; manche Versicherer verlangen ein polizeiliches Aktenzeichen. Eine Anzeige ersetzt keine Meldung an CSIRT, zuständige Behörde oder Datenschutzaufsicht, und diese ersetzen keine Anzeige. Viele Länder haben spezialisierte Stellen für Cyberkriminalität, in Deutschland etwa die Zentralen Ansprechstellen Cybercrime der Polizeien. Stimmen Sie vor der Anzeige mit Anwälten und Incident-Response-Dienstleister ab, welche Beweise Sie übergeben und wie Sie sie sichern, damit nichts zerstört wird, was Ermittler brauchen. Die Frühwarnung nach NIS2 fragt ohnehin, ob Sie ein rechtswidriges oder böswilliges Handeln vermuten; diese Antwort und die Anzeige sollten zueinander passen.

Die Grundlagen sind überall gleich: was geschah, wann, was betroffen ist, wie schwer es wiegt, was Sie getan haben und wer Ansprechpartner ist. Nach Artikel 23 Absatz 4 NIS2 sagt die Frühwarnung, ob ein böswilliges oder rechtswidriges Handeln vermutet wird und ob grenzüberschreitende Auswirkungen möglich sind; die Meldung nach 72 Stunden ergänzt eine erste Bewertung von Schweregrad und Auswirkungen und, soweit verfügbar, Kompromittierungsindikatoren; der Abschlussbericht ergänzt eine ausführliche Beschreibung, Art der Bedrohung oder Ursache, Abhilfemaßnahmen und grenzüberschreitende Auswirkungen, wie es auch § 32 BSIG vorsieht. Nach Artikel 33 Absatz 3 DSGVO beschreibt eine Meldung die Art der Verletzung, Kategorien und ungefähre Zahl der Betroffenen und Datensätze, die wahrscheinlichen Folgen, die ergriffenen Maßnahmen und den Kontakt des Datenschutzbeauftragten. Trennen Sie Fakten und Annahmen klar. NetSenX liefert aus dem Netzwerk Zeiten, Geräte, Ziele und Datenmengen.

Ja, wenn er erheblich war oder eine meldepflichtige Verletzung des Schutzes personenbezogener Daten betraf; die Behebung hebt die Pflicht nicht auf. Artikel 23 NIS2 knüpft die Meldepflicht an den erheblichen Vorfall, ob er noch andauert oder nicht, und die Fristen laufen ab Kenntnis. Stellen Sie erst jetzt fest, dass der Ausfall im letzten Monat ein Angriff war, beginnt die Uhr mit dieser Feststellung, und Sie sollten zügig melden und den Ablauf erklären. Nach der DSGVO ist eine Verletzung, die voraussichtlich ein Risiko für Personen birgt, auch nach ihrer Eindämmung zu melden; die Eindämmung kann das Risiko senken und den Inhalt der Meldung beeinflussen. Ein behobener Vorfall lässt sich meist direkt mit den bereits bekannten Fakten melden, folgen Sie aber dem Format Ihrer Behörde. Halten Sie Datum des Eintritts, der Kenntnis und der Behebung getrennt fest.

Vor allem, was Sie davor und danach getan haben: rechtzeitige Meldung, echte Schadensbegrenzung und Zusammenarbeit. Artikel 83 Absatz 2 DSGVO nennt die Faktoren, die Behörden abwägen, darunter Art, Schwere und Dauer des Verstoßes, Vorsatz oder Fahrlässigkeit, Maßnahmen zur Minderung des Schadens für die Betroffenen, die bereits getroffenen technischen und organisatorischen Maßnahmen, frühere Verstöße, den Umfang der Zusammenarbeit mit der Behörde, die betroffenen Datenkategorien und die Art, wie die Behörde von dem Verstoß erfahren hat, insbesondere ob Sie ihn gemeldet haben. Für die schwersten Verstöße können Bußgelder nach Artikel 83 Absatz 5 bis zu 20 Mio. EUR oder 4 % des weltweiten Jahresumsatzes erreichen. Praktisch heißt das: fristgerecht mit Fakten melden, die bestehenden Schutzmaßnahmen belegen, die Verletzung rasch eindämmen, Betroffene benachrichtigen, wo erforderlich, und jeden Schritt dokumentieren. NetSenX hilft bei der Zeitleiste und mit einem Entwurf nach Artikel 33 für Ihren Datenschutzbeauftragten.

Ja, als Entwurf für Ihren Datenschutzbeauftragten; Entscheidung und Einreichung bleiben bei Ihnen. Aus den Vorfalldaten erstellt NetSenX einen Entwurf mit dem, was das Netzwerk zeigt: wann das Problem erkannt wurde und welche Geräte und Ziele beteiligt waren. Artikel 33 Absatz 3 verlangt außerdem Angaben, die nur Sie haben, etwa Kategorien und ungefähre Zahl der betroffenen Personen und Datensätze, die wahrscheinlichen Folgen, die ergriffenen Maßnahmen und die Kontaktdaten des Datenschutzbeauftragten. Netzwerkbelege haben Grenzen: NetSenX sieht Verbindungen, Datenmengen und Ziele, nicht welche Dateien oder Datensätze abflossen; der Datenschutzbeauftragte muss den Inhalt aus anderen Quellen ergänzen. Der Entwurf spart Zeit am Freitagabend, wenn die 72-Stunden-Frist läuft, und hält die Fakten im Einklang mit Ihren NIS2-Meldungen. Prüfen, ergänzen und reichen Sie ihn selbst bei Ihrer Aufsichtsbehörde ein.

Ja, für den Teil der Kontrollen, der das Werkzeug selbst betrifft. Abschlussprüfer und ISO- oder SOC-2-Prüfer testen IT-General-Controls: wer Zugang zu Systemen hat, wie Änderungen genehmigt und dokumentiert werden und wie Betrieb und Vorfälle überwacht werden. Das Audit-Log eines Sicherheitswerkzeugs liefert Nachweise für seinen eigenen Ausschnitt: wer Konten hat, wer Erkennungseinstellungen oder Benachrichtigungsregeln geändert hat, wer welchen Alarm geschlossen oder entschieden hat, und wann. In jedem Plan führt NetSenX ein solches Audit-Log, mit einer Aufbewahrung, die mit dem Plan wächst. Änderungen in Ihrem ERP, auf Dateiservern oder in anderen Systemen zeichnet es nicht auf; dort brauchen Sie eigene Protokolle. Exportieren Sie den Auszug für den Prüfungszeitraum und legen Sie ihn neben Ihre Berechtigungsprüfungen und Änderungstickets, damit der Prüfer ein stimmiges Bild sieht.

Mit einem Audit-Log, das jede Änderung, die ändernde Person und den Zeitpunkt festhält und so aufbewahrt wird, dass es sich nicht unbemerkt bearbeiten lässt. Für Ihre eigenen Systeme heißt das: Änderungsprotokollierung auf Firewalls, Verzeichnisdiensten, Cloud-Konsolen und Sicherheitswerkzeugen einschalten, die Protokolle an einen zentralen Ort mit beschränktem Zugriff senden und Änderungen mit genehmigten Tickets verknüpfen. Gemeinsame Administratorkonten machen einen Nachweis unmöglich; geben Sie jeder Person ein eigenes benanntes Konto mit Multi-Faktor-Authentifizierung. Prüfen Sie die Protokolle auf unerwartete Änderungen, besonders außerhalb der Arbeitszeit. Für NetSenX selbst hält das Audit-Log in jedem Plan fest, wer Erkennungseinstellungen, Benachrichtigungsregeln oder Teammitglieder geändert und wer über Alarme entschieden hat, mit Zeitstempel; den Auszug können Sie für Prüfer exportieren. Es deckt Änderungen in NetSenX ab, nicht Einstellungen Ihrer anderen Systeme.

Mit einer einfachen Abdeckungsaussage, die durch Belege gestützt ist, einschließlich der Lücken. Führen Sie jeden Standort und jedes Netzsegment auf, ob ein Sensor oder Agent es beobachtet, seit wann und was er abdeckt; markieren Sie dann, was nicht beobachtet wird, etwa Gäste-WLAN, eine Filiale oder eine Cloud-Umgebung, und wie Sie das stattdessen behandeln. Legen Sie Belege bei: die Sensorliste, einen aktuellen Alarm aus jedem überwachten Segment und die Netzwerkkarte. Prüfer vertrauen einer ehrlichen Aussage mit bekannten Lücken mehr als einer Behauptung vollständiger Abdeckung, die bei der ersten Frage zerfällt. Bei NetSenX beobachtet ein Agent am Spiegelport eines Switches (SPAN) oder an einem Netzwerk-TAP ein ganzes Segment, und das Dashboard zeigt, welche Agenten wo laufen; Verkehr in einem Segment, das Sie nicht spiegeln, bleibt unsichtbar, und NetSenX tut nicht so, als wäre es anders.

Alles, was nur innerhalb dieses Segments geschieht. Ein Sensor sieht den Verkehr, den er erhält; wird ein Switch-Port nicht zu ihm gespiegelt und läuft kein Agent auf den dortigen Hosts, bleiben Verbindungen zwischen Geräten dieses Segments unsichtbar, etwa ein Angreifer, der von einem PC zum Dateiserver daneben wechselt. Verkehr, der das Segment über einen überwachten Punkt verlässt, etwa ins Internet oder zu einem anderen Standort, sehen Sie unter Umständen noch, doch gerade die internen Schritte eines Einbruchs sind oft das Entscheidende. Entscheiden Sie nach Risiko: Spiegeln Sie zuerst die Segmente mit Servern, Verwaltung, Finanzen, Personal und Produktion, dann den Rest. Wo Spiegeln unpraktisch ist, lassen Sie den Agenten auf den wichtigen Hosts selbst laufen. NetSenX zeigt, welche Segmente seine Sensoren und Agenten beobachten, sodass Lücken sichtbar sind.

Genug, um jeden Vorfall und jede Entscheidung ohne Rückgriff auf jemandes Gedächtnis nachzuvollziehen. Pro Eintrag: ein eindeutiges Aktenzeichen; wann der Vorfall begann, wann und wodurch er erkannt wurde und wann Sie ihn als erheblich eingestuft haben oder nicht; eine kurze Beschreibung und die betroffenen Systeme, Dienste und Daten; die Bewertung des Schweregrads und wer sie vorgenommen hat; ob, an wen und wann gemeldet wurde, mit Kopien der Meldungen; Schritte zu Eindämmung, Beseitigung und Wiederherstellung mit Zeiten und Verantwortlichen; die Ursache; und die Lehren und Änderungen danach. Erfassen Sie auch Beinahe-Vorfälle mit dem Grund, warum nicht gemeldet wurde. Halten Sie das Register manipulationssicher und zugriffsbeschränkt. NetSenX liefert den Netzwerkteil automatisch: Alarme mit Zeit, Geräten und Zielen, NIS2-Fristen je Vorfall und das Audit-Log, wer was entschieden hat.

Mit einer Aufzeichnung, die jeden Alarm mit einer Entscheidung, einer Person, einem Zeitpunkt und einer Begründung verknüpft. Prüfer wollen sehen, dass Alarme nicht verschwinden: Jeder wurde angesehen, als harmlos, in Untersuchung oder als Vorfall eingestuft und mit Erklärung geschlossen. Eine Tabelle reicht für eine Handvoll Alarme, versagt aber bei wachsender Menge und lässt sich leicht nachträglich ausfüllen. Nutzen Sie, wo möglich, den Ablauf im Werkzeug selbst, schreiben Sie kurze Begründungen statt Ein-Wort-Status und prüfen Sie jedes Quartal eine Stichprobe geschlossener Alarme auf die Qualität der Entscheidungen. In NetSenX werden Entscheidungen zu Alarmen in jedem Plan im Audit-Log festgehalten, mit wer und wann; ab dem Starter-Plan können Sie PDF-Berichte für den Prüfer exportieren.

NIS2 legt keine einheitliche Aufbewahrungsfrist fest; bestimmen Sie also selbst eine und schreiben Sie die Begründung auf. Mehrere Regeln weisen in dieselbe Richtung. Die DSGVO verlangt, jede Verletzung des Schutzes personenbezogener Daten zu dokumentieren (Artikel 33 Absatz 5), damit die Behörde die Einhaltung prüfen kann, was eine Aufbewahrung so lange nahelegt, wie eine solche Prüfung vernünftigerweise kommen kann. NIS2-Aufsichten können Nachweise zu früheren Vorfällen und Meldungen verlangen, Versicherer prüfen Schäden mitunter lange nach dem Ereignis, und Verjährungsfristen für vertragliche und Haftungsansprüche laufen in vielen Ländern über Jahre. Branchen- und Landesrecht können eigene Fristen setzen. Üblich ist, Vorfallregister und Meldungen mehrere Jahre aufzubewahren und Rohprotokolle kürzer, unter Löschung nicht mehr benötigter personenbezogener Daten. Die Aufbewahrung von Alarmhistorie und Audit-Log bei NetSenX hängt vom Plan ab; exportieren Sie, was Sie länger behalten müssen.

Ja, für die überwachten Segmente, und sie ist oft genauer als ein gezeichnetes Schaubild. Eine Karte aus beobachtetem Verkehr zeigt, welche Geräte es gibt, welche Namen sie melden und wer mit wem spricht, auch Verbindungen, die niemand dokumentiert hat, etwa ein Arbeitsplatz, der einen Server erreicht, den er nicht erreichen sollte, oder die Fernsitzung eines Lieferanten. Sie zeigt nicht, was nie Verkehr sendet, Segmente ohne Sensor oder das beabsichtigte Design; behalten Sie also Ihr Architekturschaubild und prüfen Sie es mit der beobachteten Karte. In jedem Plan erstellt NetSenX eine solche Netzwerkkarte aus dem überwachten Verkehr, mit dem ersten und letzten Zeitpunkt jedes Geräts. Bedenken Sie vor dem Vorzeigen bei externen Prüfern, was sie verrät: Gerätenamen können Namen von Beschäftigten enthalten, und die Karte beschreibt Ihre interne Struktur; zeigen Sie sie daher am Bildschirm oder unter einer Geheimhaltungsvereinbarung.

Ja. Artikel 33 Absatz 5 DSGVO verpflichtet den Verantwortlichen, jede Verletzung des Schutzes personenbezogener Daten einschließlich aller damit zusammenhängenden Fakten, ihrer Auswirkungen und der ergriffenen Abhilfemaßnahmen zu dokumentieren, ob sie der Aufsichtsbehörde gemeldet wurde oder nicht. Damit soll die Behörde die Einhaltung später überprüfen können, auch Ihre Entscheidung, dass eine Verletzung voraussichtlich kein Risiko für Personen brachte. Halten Sie daher zu jeder Verletzung fest, was geschah, welche Daten und Personen betroffen waren, warum Sie eine Meldung für nötig oder nicht nötig hielten, wer wann entschieden hat und was Sie geändert haben. Führen Sie ein Register der Datenpannen, getrennt vom Sicherheitsvorfallregister, aber mit ihm verknüpft. Behörden können es bei einer Prüfung oder nach einer Beschwerde verlangen, und ein fehlender Eintrag zu einer nicht gemeldeten Panne wirkt schlechter als die Panne selbst. NetSenX bewahrt die Alarmbelege zu jedem Eintrag für die Aufbewahrungsdauer Ihres Plans auf.

Wenn die Verletzung voraussichtlich ein hohes Risiko für ihre Rechte und Freiheiten zur Folge hat. Artikel 34 DSGVO verlangt dann vom Verantwortlichen, sie unverzüglich in klarer und einfacher Sprache zu benachrichtigen, mit der Art der Verletzung, den wahrscheinlichen Folgen, den ergriffenen oder vorgeschlagenen Maßnahmen und dem Kontakt des Datenschutzbeauftragten. Hohes Risiko bedeutet meist Daten, die echten Schaden anrichten können, etwa Ausweisdokumente, Bank- oder Gesundheitsdaten, Passwörter oder Angaben, die Betrug ermöglichen. Artikel 34 Absatz 3 nennt Ausnahmen: Die Daten wurden unzugänglich gemacht, etwa durch starke Verschlüsselung; nachfolgende Maßnahmen sorgen dafür, dass das hohe Risiko aller Wahrscheinlichkeit nach nicht mehr besteht; oder Einzelnachrichten wären mit unverhältnismäßigem Aufwand verbunden, dann tritt eine öffentliche Bekanntmachung an ihre Stelle. Die Aufsichtsbehörde kann die Benachrichtigung auch verlangen. Sagen Sie den Betroffenen, was sie tun sollen, etwa Passwörter ändern oder auf Phishing achten.