Protokolle für Sicherheitsvorfälle: Wie du Protokolle erstellst, die den Anforderungen der GDPR und der Aufsichtsbehörden entsprechen

Der schwierigste Teil eines Sicherheitsvorfalls kommt meist erst nach dem Vorfall selbst: wenn das Unternehmen erklären muss, was passiert ist, wann er entdeckt wurde, welche Daten betroffen waren, wer betroffen war und warum bestimmte Entscheidungen getroffen wurden.

Bei vielen KMU existieren diese Aufzeichnungen nicht in vollständiger Form. Details können über Chat-Nachrichten, Posteingänge, Helpdesk-Tickets, Screenshots und in den Erinnerungen der Teammitglieder verstreut sein. Unternehmen halten sich während eines Vorfalls mit diesen zusammengewürfelten Aufzeichnungen über Wasser, aber sie werden zum Problem, wenn Aufsichtsbehörden, ein Versicherer, ein Kunde oder ein Vorstandsmitglied nach einer klaren Zeitleiste fragt.

Unternehmen jeder Größe brauchen ein gründliches Sicherheitsvorfallprotokoll. Es sollte eine zentrale Quelle der Wahrheit sein, um festzuhalten, was passiert ist, wie der Vorfall behandelt wurde und welche Beweise die im Laufe der Zeit getroffenen Entscheidungen stützen.

Die Aufzeichnung ist wertvoll, auch wenn du keinen Vorfall melden musst. Wir erklären, warum Sicherheitsvorfallprotokolle für dein Unternehmen hilfreich sind und wie du dein eigenes erstellst.

Warum Sicherheitsvorfallprotokolle wichtig sind

Vorfallprotokolle vs. Notfallpläne

Was ein Sicherheitsvorfallprotokoll enthalten sollte

Eine einfache Vorlage für ein Vorfallprotokoll für KMU

Wie du Benachrichtigungsentscheidungen dokumentierst

Was Aufsichtsbehörden von Sicherheitsvorfallprotokollen erwarten

Das Protokoll für Zugriffe auf Anmeldedaten

Warum Sicherheitsvorfallprotokolle wichtig sind

Sicherheitsvorfallprotokolle schaffen Verantwortlichkeit in dem Moment, in dem ein Unternehmen am ehesten den Überblick über Details verliert. Während eines Vorfalls geschehen Aktionen schnell: Passwörter werden zurückgesetzt, Konten deaktiviert, IT-Dienstleister kontaktiert, Kundendaten überprüft und die Führungsebene informiert. Diese Schritte mögen genau das sein, was das Unternehmen im Moment braucht, aber sie lassen sich später viel schwerer erklären, wenn niemand festhält, wann jede Aktion geschah, wer sie genehmigt hat und welche Beweise die Entscheidung stützten.

Für Unternehmen mit Sitz in Europa ist das nicht nur gute Praxis. Gemäß der General Data Protection Regulation (GDPR) müssen sowohl im Vereinigten Königreich als auch in der EU Datenschutzverletzungen bewertet werden, und einige müssen der zuständigen Aufsichtsbehörde gemeldet werden.

Im Vereinigten Königreich erklärt die Leitlinie der ICO zum Melden eines Datenschutzverstoßes(neues Fenster)⁠, dass Organisationen das wahrscheinliche Risiko für die Rechte und Freiheiten von Personen bewerten und die ICO benachrichtigen müssen, wenn dieses Risiko wahrscheinlich ist. Artikel 33 verlangt außerdem, dass Verantwortliche Datenschutzverletzungen dokumentieren, einschließlich der Fakten der Verletzung, ihrer Auswirkungen und der ergriffenen Abhilfemaßnahmen. Dieselben Anforderungen gelten gemäß der EU-GDPR.

Zum Beispiel erwartet die ICO nicht, dass jedes KMU Systeme in Unternehmensqualität hat, aber sie erwartet angemessene Aufzeichnungen. Ihr Rahmen für Reaktion auf und Überwachung von Verstößen besagt, dass Organisationen Verfahren haben sollten, um sicherzustellen, dass Vorfälle mit personenbezogenen Daten und Verstöße erkannt, verwaltet und angemessen dokumentiert werden. Das bedeutet, ein Vorfallprotokoll sollte nicht erst erstellt werden, wenn bereits ein schwerwiegender Verstoß stattgefunden hat. Es sollte Teil des normalen Reaktionsprozesses sein.

Gute Aufzeichnungen unterstützen auch Versicherungsansprüche. Cyber-Versicherer können nach Beweisen dafür fragen, wann der Vorfall entdeckt wurde, welche Eindämmungsschritte unternommen wurden, welche Konten betroffen waren und ob das Unternehmen seinen Notfallprozess eingehalten hat. Ein gut geführtes Protokoll kann zeigen, dass das Unternehmen schnell und konsequent gehandelt hat.

Es hilft dem Unternehmen auch zu lernen. Erinnerungen und mündliche Aufzeichnungen sind nicht zuverlässig, aber eine Aufzeichnung, die zeigt, dass der Vorfall mit einem wiederverwendeten Passwort, fehlender Multi-Faktor-Authentifizierung (MFA), Anbieterzugriff oder verzögertem Offboarding begann, gibt dem Unternehmen etwas Konkretes, das es beheben kann, und eine klarere Richtung für die langfristige Stärkung der Sicherheit.

Vorfallprotokolle vs. Notfallpläne

Ein Sicherheitsvorfallprotokoll und ein Notfallplan hängen zusammen, sind aber nicht dasselbe Dokument.

Ein Notfallplan erklärt, was das Unternehmen tun sollte, wenn etwas schiefgeht. Er weist Rollen, Eskalationswege, Eindämmungsschritte, Kommunikationsverantwortlichkeiten und Wiederherstellungsverfahren zu. Das Vorfallprotokoll hält fest, was tatsächlich passiert ist. Es ist die Zeitleiste, die Beweiskette, das Entscheidungsprotokoll und die Nachverfolgungsakte für ein bestimmtes Ereignis.

Diese Unterscheidung ist wichtig, denn selbst ein guter Plan kann ohne Dokumentation scheitern. Ein Unternehmen kann die richtigen Schritte befolgen und trotzdem später Schwierigkeiten haben, sie zu belegen. Das Protokoll sollte es ermöglichen, praktische Fragen zu beantworten: Wann wussten wir es, wer hat gehandelt, was haben wir eingedämmt, welche Daten waren gefährdet, was haben wir entschieden und was hat sich danach geändert?

Notfallplan: Was dein Unternehmen tun sollte	Sicherheitsvorfallprotokoll: Was tatsächlich passiert ist
Wer die Reaktion leitet Wer IT, Recht, Versicherer oder Aufsichtsbehörden kontaktiert Wie man eindämmt, wiederherstellt und kommuniziert	Wann der Vorfall entdeckt wurde Welche Systeme und Daten betroffen waren Welche Aktionen ergriffen wurden, von wem und wann

Was ein Sicherheitsvorfallprotokoll enthalten sollte

Ein nützliches Vorfallprotokoll muss konsistent genug sein, damit ein Unternehmen das Ereignis später rekonstruieren und die während der Reaktion getroffenen Entscheidungen erklären kann.

Datum und Uhrzeit der Entdeckung

Halte fest, wann das Unternehmen den Vorfall erstmals bemerkt hat, wer ihn bemerkt hat und wie er entdeckt wurde. Wenn die Zeit ungefähr ist, markiere sie als ungefähr. Der Zeitpunkt der Entdeckung ist wichtig, weil GDPR-Meldefristen und Versicherungsanforderungen oft davon abhängen, wann das Unternehmen von dem Problem erfahren hat.

Art des Vorfalls

Beschreibe in einfacher Sprache, was passiert ist. Vermeide vage Bezeichnungen wie „Sicherheitsproblem“ oder „möglicher Verstoß“ ohne Kontext. Das Protokoll sollte erklären, welche Systeme betroffen waren und ob der Vorfall Anmeldedaten, E-Mail, Dateien, Kundendaten, Zahlungssysteme, Endpunkte oder Drittanbieterzugriff betraf.

Betroffene Daten

Wenn personenbezogene Daten betroffen sein könnten, halte fest, welche Art von Daten betroffen war: Namen, E-Mail-Adressen, Telefonnummern, Adressen, Kontodetails, Finanzinformationen, Mitarbeiterunterlagen, Kundenkommunikation, Anmeldedaten oder jede andere relevante Kategorie. Schätze, wie viele Personen betroffen sein könnten, und stelle klar, ob die Zahl bestätigt ist oder noch untersucht wird.

Wahrscheinliche Ursache

Halte die bekannte oder vermutete Ursache fest, auch wenn die Untersuchung noch läuft. Wenn neue Details auftauchen, kann das Protokoll von „Ursache unbekannt“ zu „Phishing-E-Mail führte zur Kompromittierung von Anmeldedaten“ oder „ehemaliges Auftragnehmerkonto blieb aktiv“ aktualisiert werden. Das Protokoll sollte zeigen, wie sich das Verständnis des Unternehmens im Laufe der Zeit verändert hat.

Sofortige Eindämmungsmaßnahmen

Dokumentiere, was getan wurde, um den Schaden zu begrenzen. Dazu können Passwortzurücksetzungen, Sitzungswiderruf, MFA-Durchsetzung, Kontosperrung, Entfernung von Postfachregeln, Geräteisolierung, Entfernung von Anbieterzugriffen, Firewall-Änderungen oder vorübergehende Dienstabschaltungen gehören. Gib nach Möglichkeit den Verantwortlichen und den Zeitstempel für jede Aktion an.

Benachrichtigungsentscheidungen

Halte fest, ob das Unternehmen die zuständige Aufsichtsbehörde (die ICO im Vereinigten Königreich oder die nationale Datenschutzbehörde anderswo in der EU), betroffene Personen, Kunden, Lieferanten, Versicherer, Rechtsberater oder Strafverfolgungsbehörden benachrichtigt hat. Wenn die Entscheidung war, nicht zu benachrichtigen, dokumentiere die Begründung. Diese Erklärung ist oft genauso wichtig wie die Benachrichtigung selbst.

Behebungsschritte und Zeitplan

Eindämmung befasst sich mit dem unmittelbaren Vorfall. Behebung verringert die Wahrscheinlichkeit, dass dasselbe Problem erneut auftritt. Halte Folgeaktionen fest, wie die Durchsetzung von MFA, das Entfernen gemeinsam genutzter Anmeldedaten, die Aktualisierung von Zugriffsrichtlinien, die Verbesserung des Offboardings, die Behebung einer Fehlkonfiguration oder die Änderung des Schutzes von Sicherungen.

Erkenntnisse

Schließe damit ab, was das Unternehmen gelernt hat und was sich ändern wird. Das sollte nicht als Schuldzuweisung geschrieben werden. Es sollte die Schwachstelle, die notwendige Verbesserung und den Verantwortlichen für die Nachverfolgung benennen.

Eine einfache Vorlage für ein Vorfallprotokoll für KMU

Spezialsoftware ist für die Dokumentation von Vorfällen nicht notwendig. Eine Tabelle, ein sicheres internes Formular, ein Ticketsystem oder ein gemeinsames Register können funktionieren, wenn der Zugriff kontrolliert und die Einträge konsistent gehalten werden.

Ein effektives Vorfallprotokoll sollte diese Felder enthalten:

• Vorfall-ID: Eine eindeutige Referenznummer.
• Datum und Uhrzeit der Entdeckung: Wann das Unternehmen den Vorfall bemerkt hat.
• Gemeldet von: Mitarbeitende, Anbieter, Kundschaft, Lieferanten, Überwachungswarnungen oder externe Stellen.
• Vorfalltyp: Phishing, Malware, Gefährdung von Anmeldedaten, Datenverlust, unbefugter Zugriff, Ransomware, Lieferantenvorfall, Geräteverlust, fehlgeleitete E-Mail oder Sonstiges.
• Zusammenfassung: Was passiert ist, in einfacher Sprache.
• Betroffene Systeme: Beteiligte Anwendungen, Konten, Geräte, Datenbanken, Posteingänge oder Drittanbieter-Dienste.
• Betroffene Daten: Ob personenbezogene Daten betroffen waren, welcher Art und wie viele Personen betroffen sein könnten.
• Wahrscheinliche Ursache: Bekannt, vermutet oder in Untersuchung.
• Eindämmungsmaßnahmen: Was unmittelbar unternommen wurde.
• Benachrichtigungsentscheidung: Aufsichtsbehörde, betroffene Personen, Kundschaft, Versicherer oder keine Benachrichtigung mit Begründung.
• Beweislinks: Screenshots, Tickets, Protokolle, E-Mails, Zugriffsaufzeichnungen, Exportdateien oder Anbieterberichte.
• Behebungsmaßnahmen: Schritte, die nach der Eindämmung unternommen wurden.
• Verantwortlich: Person, die für die Nachverfolgung verantwortlich ist.
• Status: Offen, in Überwachung, eingedämmt, behoben, geschlossen.
• Erkenntnisse: Was sich ändern sollte.

Benachrichtigungsentscheidungen dokumentieren

Benachrichtigungsentscheidungen verdienen einen eigenen Bereich in einem Sicherheitsvorfallprotokoll, weil sie nach dem Vorfall oft überprüft werden.

Sowohl nach der UK-GDPR als auch nach der EU-GDPR müssen Organisationen das wahrscheinliche Risiko für die Rechte und Freiheiten der Menschen bewerten, wenn es zu einem Datenleck mit personenbezogenen Daten kommt. Wenn ein Risiko wahrscheinlich ist, muss die Aufsichtsbehörde so schnell wie möglich und, sofern machbar, innerhalb von 72 Stunden benachrichtigt werden – im Vereinigten Königreich die ICO(neues Fenster), in jedem EU-Mitgliedstaat die nationale Datenschutzbehörde. Wenn das Risiko hoch ist, müssen auch die betroffenen Personen unverzüglich benachrichtigt werden. Die Schwellenwerte und die Frist sind auf beiden Seiten gleich; nur die Behörde ändert sich.

Ein gutes Vorfallprotokoll sollte zeigen, dass das Unternehmen diese Bewertung vorgenommen hat. Es sollte festhalten, ob personenbezogene Daten betroffen waren, welcher Schaden entstehen könnte, welche Schutzmaßnahmen vorhanden waren und warum sich das Unternehmen dafür entschieden hat, den Vorfall zu melden oder nicht zu melden.

Beispielsweise kann ein Vorfall mit einem offengelegten Administratorpasswort nicht sofort erkennen lassen, ob auf personenbezogene Daten zugegriffen wurde. Das Protokoll sollte diese Unsicherheit widerspiegeln. Es kann die anfängliche Besorgnis, die Untersuchungsschritte, die Überprüfung der Kontoaktivitäten und die endgültige Schlussfolgerung festhalten, sobald Beweise vorliegen.

An diesem Punkt im Prozess konzentrieren sich viele Unternehmen darauf, die technische Behebung zu organisieren, und vergessen, die Compliance-Begründung zu dokumentieren. Passwörter werden zurückgesetzt, Konten werden gesichert, und der Betrieb läuft weiter. Wochen später kann das Unternehmen nicht erklären, warum es entschieden hat, dass der Vorfall nicht meldepflichtig war.

Was Aufsichtsbehörden von Aufzeichnungen erwarten

Aufsichtsbehörden schauen nicht nur darauf, ob ein Datenleck gemeldet wurde. Sie können auch fragen, wie das Unternehmen:

• den Vorfall identifiziert hat
• das Risiko bewertet hat
• entschieden hat, ob eine Benachrichtigung erforderlich war
• die ergriffenen Maßnahmen dokumentiert hat

Eine gute Aufzeichnung sollte die Geschichte des Vorfalls von Anfang bis Ende deutlich machen. Sie sollte zeigen, was passiert ist, welche personenbezogenen Daten betroffen waren, welcher Schaden entstehen könnte, was das Unternehmen unternommen hat, um das Problem einzudämmen, und warum es das Datenleck gemeldet oder nicht gemeldet hat.

Der Detaillierungsgrad sollte der Schwere des Vorfalls entsprechen. Eine fehlgeleitete E-Mail benötigt nicht dieselbe Aufzeichnung wie ein Ransomware-Angriff, muss aber dennoch dokumentiert werden, um zu zeigen, dass das Unternehmen sie ordnungsgemäß bewertet hat.

Diese Aufzeichnungen sollten außerdem sicher gespeichert werden. Vorfallprotokolle können sensible Details über betroffene Personen, offengelegte Systeme, Mitarbeiteraktionen, Screenshots, Zugriffsprotokolle oder Behebungsschritte enthalten. Der Zugriff sollte auf die Personen beschränkt werden, die ihn benötigen, und die Aufbewahrung sollte mit der weiter gefassten Datenaufbewahrungsrichtlinie des Unternehmens übereinstimmen.

Das Protokoll für den Zugriff auf Anmeldedaten

Viele Vorfälle betreffen Anmeldedaten: Sie können durch ein wiederverwendetes Passwort, ein gemeinsam genutztes Konto, einen kompromittierten Posteingang, eine offengelegte Administratoranmeldung, eine verdächtige MFA-Aufforderung oder einen Mitarbeiter ausgelöst werden, der nicht ordnungsgemäß abgemeldet wurde.

Aus diesem Grund können Zugriffsaufzeichnungen auf Anmeldedaten zu einer direkten Eingabe für die Dokumentation von Cybersicherheitsvorfällen werden. Wenn ein Vorfall eine gemeinsam genutzte Anmeldung oder ein sensibles Konto betrifft, muss das Unternehmen wissen, wer Zugriff hatte, wie der Zugriff geteilt wurde, ob sich Berechtigungen geändert haben und ob die Anmeldedaten nach dem Vorfall rotiert wurden.

Ein Passwort-Manager für Unternehmen⁠ wie Proton Pass for Business hilft Teams, Anmeldedaten in verschlüsselten Tresoren zu verwalten, eindeutige Passwörter zu generieren, das automatische Ausfüllen zu nutzen, Anmeldedaten sicher zu teilen, Passkeys zu verwalten und die integrierte Zwei-Faktor-Authentifizierung zu verwenden. Für die Dokumentation von Vorfällen liegt der größte Wert im Zugriffspfad rund um Anmeldedaten: wer Zugriff auf gemeinsam genutzte Tresore/Konten hatte, wie der Zugriff verwaltet wurde, wer ihn genutzt hat und was sich nach dem Vorfall geändert hat.

Ein Passwort-Manager für IT-Teams bietet Administratorfunktionen wie Richtlinien, Berichte, Protokolle, rollenbasierte Zugriffssteuerung, SCIM-Bereitstellung und SSO-Integration. Diese Funktionen können Unternehmen dabei helfen, zu zeigen, wie der Zugriff auf Anmeldedaten kontrolliert wird, und Beweise liefern, wenn ein Vorfall im Zusammenhang mit Anmeldedaten untersucht wird.

Ein Passwort-Manager kann kein Vorfallprotokoll, keine rechtliche Bewertung, keinen behördlichen Benachrichtigungsprozess oder keinen Reaktionsplan für Vorfälle ersetzen. Aber er liefert Beweise zu Anmeldedaten, die in diese Prozesse einfließen können.

Führe mit einem Passwort-Manager für Unternehmen⁠ einen vollständigen Prüfpfad für den Zugriff auf Anmeldedaten.