Sicherheitsvorfall: Ein Sicherheitsvorfall ist ein tatsächlich eingetretenes oder mit hoher Wahrscheinlichkeit bevorstehendes Ereignis, das die Vertraulichkeit, Integrität oder Verfügbarkeit von Informationen beeinträchtigt oder gefährdet.
Abzugrenzen ist der Sicherheitsvorfall von der Schwachstelle: Eine Schwachstelle ist ein potenzielles Einfallstor, ein Sicherheitsvorfall bedeutet, dass tatsächlich ein Schaden eingetreten ist oder unmittelbar droht. Diese Unterscheidung ist wichtig, weil beide Kategorien im ISMS unterschiedlich behandelt und priorisiert werden.
| Beispiel | Typische Auswirkung |
|---|---|
| Erfolgreiches Phishing | Zugangsdaten oder Daten abgeflossen |
| Ransomware-Befall | Systeme verschlüsselt, Betrieb steht still |
| Unautorisierter Zugriff | Vertrauliche Daten eingesehen oder verändert |
| Verlust eines Notebooks | Mögliche Offenlegung gespeicherter Daten |
ISO 27001 verlangt in Anhang A (Controls 5.24 bis 5.28) einen strukturierten Prozess für das Management von Informationssicherheitsvorfällen: klare Meldewege, eine Bewertung und Einstufung des Vorfalls, eine geplante Reaktion sowie eine Nachbereitung mit Lessons Learned, damit sich vergleichbare Vorfälle künftig vermeiden lassen. Auch das Sammeln von Beweismitteln für eine spätere Analyse gehört dazu.
Zusätzlich zur ISMS-internen Meldung können gesetzliche Fristen gelten: Bei personenbezogenen Daten schreibt Artikel 33 DSGVO eine Meldung an die Aufsichtsbehörde binnen 72 Stunden vor, wenn ein Risiko für Betroffene besteht. NIS2-betroffene Unternehmen unterliegen zusätzlich gestuften Meldefristen an das BSI (Stand: September 2026).
Eine gängige Klassifizierung unterscheidet Sicherheitsvorfälle zusätzlich nach Schweregrad, etwa gering (lokal begrenzt, kein Datenabfluss), mittel (einzelne Systeme betroffen) und hoch (unternehmensweite Auswirkung oder Datenabfluss). Diese Einstufung bestimmt, wie schnell eskaliert und wer informiert werden muss.
Auch ein sogenannter Beinahe-Vorfall – ein Ereignis, das ohne eingetretenen Schaden nur knapp verhindert wurde, etwa ein rechtzeitig blockierter Phishing-Link – liefert wertvolle Erkenntnisse und sollte in vielen ISMS dieselbe strukturierte Nachbereitung durchlaufen wie ein tatsächlicher Sicherheitsvorfall, auch wenn die Norm dafür keine eigene Meldepflicht vorschreibt. Ein zentrales, chronologisch geführtes Vorfallsregister erleichtert zudem sowohl die interne Nachbereitung als auch spätere Nachweise gegenüber Auditoren oder Aufsichtsbehörden erheblich.
Relevanz für die Zertifizierung
Im ISO-27001-Audit reicht eine Richtlinie auf dem Papier nicht aus – Auditoren prüfen, ob tatsächlich gemeldete Vorfälle dokumentiert, bewertet und nachbereitet wurden, oder zumindest, ob der Prozess in einer Übung durchgespielt wurde. Für Unternehmen, die zusätzlich unter die DSGVO oder NIS2 fallen, lohnt es sich, den ISMS-internen Meldeprozess von vornherein mit den gesetzlichen Fristen abzustimmen, statt zwei getrennte Abläufe zu pflegen, die im Ernstfall zu widersprüchlichen Reaktionen führen können. Eine jährlich geübte Tabletop-Übung mit fiktivem Vorfall zeigt zuverlässiger als jede Richtlinie, ob Meldewege und Verantwortlichkeiten im Ernstfall tatsächlich funktionieren.
Häufige Fragen zu Sicherheitsvorfall
Eine Schwachstelle ist eine potenzielle Angriffsfläche, etwa eine ungepatchte Software – sie muss nicht zwangsläufig ausgenutzt werden. Ein Sicherheitsvorfall liegt vor, wenn tatsächlich ein Ereignis eingetreten ist, das Vertraulichkeit, Integrität oder Verfügbarkeit von Informationen beeinträchtigt oder unmittelbar zu beeinträchtigen droht.
Intern verlangt ISO 27001 immer eine Meldung über den ISMS-Prozess. Extern gilt bei personenbezogenen Daten Artikel 33 DSGVO mit 72-Stunden-Frist an die Aufsichtsbehörde, sofern ein Risiko für Betroffene besteht. NIS2-betroffene Unternehmen melden zusätzlich gestuft an das BSI (Stand: September 2026).
Mindestens klare Meldewege und Verantwortlichkeiten, Kriterien zur Einstufung der Schwere, definierte Sofortmaßnahmen zur Eindämmung, eine Kommunikationsregelung sowie eine Nachbereitung mit dokumentierten Lessons Learned, damit der Vorfall die Grundlage für Verbesserungen im ISMS liefert. Sinnvoll ist zusätzlich eine vorab festgelegte Liste externer Ansprechpartner, etwa IT-Forensiker, Rechtsberatung und gegebenenfalls die Cyberversicherung, damit im akuten Ernstfall keine Zeit mit der Suche nach Kontakten verloren geht.