Incident Management: Incident Management ist der strukturierte Prozess, mit dem ein Unternehmen Informationssicherheitsvorfälle erkennt, meldet, bewertet, eindämmt und behebt, bevor der Schaden sich unkontrolliert ausweitet.
Ein Sicherheitsvorfall reicht vom einzelnen Phishing-Klick über einen Ransomware-Befall bis zum unbefugten Zugriff auf Kundendaten. Incident Management definiert dafür feste Abläufe: Erkennung, etwa über Monitoring oder Mitarbeitendenmeldung, Klassifizierung nach Schweregrad, Eindämmung zur Schadensbegrenzung, Analyse der Ursache sowie abschließende Behebung und Wiederanlauf des Regelbetriebs.
ISO 27001:2022 verankert das Thema in Anhang A, Themenfeld 5 (Organisatorische Maßnahmen), konkret in den Controls A.5.24 bis A.5.28: Planung des Vorgehens bei Vorfällen, Bewertung und Entscheidung über Sicherheitsereignisse, Reaktion auf Vorfälle, Lernen aus Vorfällen sowie Sammlung von Beweismitteln für mögliche rechtliche Schritte. Ergänzend regelt A.6.8 die Meldung von Sicherheitsereignissen durch Mitarbeitende.
Entscheidend für ein wirksames Incident Management sind klar definierte Meldewege – wer meldet was an wen, innerhalb welcher Frist – sowie eine dokumentierte Nachbereitung ("Lessons Learned"), damit ähnliche Vorfälle künftig schneller erkannt oder ganz vermieden werden. Ohne diese Nachbereitung wiederholen sich dieselben Schwachstellen häufig unbemerkt. In der Praxis bewährt sich eine einfache Klassifizierung nach Schweregraden, etwa von P1 (Totalausfall, sofortige Eskalation) bis P4 (geringfügig, reguläre Bearbeitung), damit Ressourcen im Ernstfall zuerst dorthin fließen, wo der Schaden am größten wäre.
- Ablauf: Erkennung, Klassifizierung, Eindämmung, Analyse, Behebung
- Verankert in ISO 27001:2022 Anhang A, Controls A.5.24–A.5.28
- Klare Meldewege und Fristen entscheidend für Wirksamkeit
- Nachbereitung ("Lessons Learned") verhindert Wiederholung derselben Schwachstellen
Relevanz für die Zertifizierung
Im ISMS-Audit nach ISO 27001 verlangt der Auditor konkret einen dokumentierten, gelebten Incident-Response-Prozess: Wer meldet einen Vorfall an wen, innerhalb welcher Frist, und wie wird die Reaktion dokumentiert? Eine reine Richtlinie auf dem Papier ohne nachweisbare Anwendung – etwa fehlende Beispiele tatsächlich gemeldeter und bearbeiteter Vorfälle oder Übungen – fällt im Audit häufig als Schwachstelle auf. Auch kleinere IT-Dienstleister oder Handwerksbetriebe mit überschaubarer IT-Landschaft sollten mindestens die Meldewege und eine einfache Eskalationslogik dokumentiert haben, bevor sie das Stufe-2-Audit angehen.
Häufige Fragen zu Incident Management
Ja. ISO 27001:2022 verlangt in Anhang A, Themenfeld 5, mit den Controls A.5.24 bis A.5.28 einen dokumentierten Prozess für Planung, Bewertung, Reaktion und Nachbereitung von Sicherheitsvorfällen. Fehlt dieser Prozess oder existiert er nur auf dem Papier ohne nachweisbare Anwendung, ist das im Zertifizierungsaudit ein häufiger Befund.
Grundsätzlich jedes Ereignis, das Vertraulichkeit, Integrität oder Verfügbarkeit von Informationen gefährden kann – vom einzelnen Phishing-Klick über einen Ransomware-Befall bis zum unbefugten Datenzugriff. Das ISMS sollte klar definieren, ab welcher Schwelle ein Ereignis als Vorfall gilt und wer ihn innerhalb welcher Frist intern zu melden hat.
Die Norm schreibt kein festes Intervall vor, verlangt aber im Rahmen der kontinuierlichen Verbesserung eine regelmäßige Überprüfung. In der Praxis empfiehlt sich mindestens eine jährliche Durchsicht der Meldewege, ergänzt um eine einfache Übung oder einen dokumentierten Testfall, damit der Prozess im Ernstfall tatsächlich funktioniert und nicht nur auf dem Papier existiert.