Lessons Learned als Pflicht: Der Post-Incident-Review unter NIS2
26.09.2026 post-incident-reviewnis2lessons-learnedir-process
Der Post-Incident-Review galt lange als lästige Pflichtübung nach dem eigentlichen Vorfall: ein Dokument, das irgendjemand schreibt, das im Review-Meeting abgenickt und danach nie wieder geöffnet wird. Genau dieses Muster beschreibt eine aktuelle Analyse, die den Prozess als das am konsistentesten übersprungene Element eines IR-Programms bezeichnet, obwohl er gleichzeitig die günstigste Sicherheitsinvestition einer Organisation darstellt. 2026 ändert sich das grundlegend – nicht aus Einsicht, sondern aus regulatorischem Zwang.
Wenn die Nachbesprechung zur gesetzlichen Pflicht wird
Innerhalb eines Monats müssen Unternehmen eine finale Bewertung einreichen, die einen Post-Incident-Review, Korrekturmaßnahmen und langfristige Abhilfemaßnahmen umfasst. Das ist keine Kann-Bestimmung mehr, sondern eine harte Frist unter NIS2. Parallel dazu löst bei Finanzunternehmen unter DORA Artikel 17 und 18 jeder größere IKT-Vorfall einen Post-Event-Review aus – für NIS2-Artikel-21-Fälle gilt derselbe Standard bei signifikanten Vorfällen. Regulierer verlangen damit nicht mehr nur eine Meldung des “Was”, sondern eine dokumentierte Antwort auf das “Warum” – inklusive nachvollziehbarer Ursachenanalyse.
Für IR-Teams bedeutet das eine Verschiebung der Beweislast: Der Post-Incident-Review ist nicht länger internes Lernmaterial, sondern ein prüfbares Artefakt, das Aufsichtsbehörden, Wirtschaftsprüfer und im Fall börsennotierter Unternehmen auch Disclosure-Committees einsehen können. Wer den Review als Pflichtübung abarbeitet, produziert damit ein Dokument, das im Ernstfall gegen die eigene Organisation verwendet werden kann – etwa wenn eine Behörde erkennt, dass dieselbe Root Cause bereits beim letzten Vorfall dokumentiert, aber nie behoben wurde.
Blameless heißt nicht folgenlos
Der Begriff “blameless” wird in der Praxis häufig missverstanden. Ein blamefreier Review bedeutet nicht, dass niemand Verantwortung trägt, sondern dass Fehler als Symptom von Systemschwächen behandelt werden statt als persönliches Versagen – mit dem Ziel, dass Beteiligte berichten, was tatsächlich passiert ist, statt sich selbst in ein gutes Licht zu rücken. Diese Unterscheidung ist für IR-Teams entscheidend: Ein Analyst, der eine übersehene Eskalationsregel offenlegt, muss dafür keine Sanktion fürchten – die Organisation, die die Regel trotz Kenntnis nie korrigiert, sehr wohl.
Kulturelle Faktoren sind dabei der größte Risikofaktor für den Prozess selbst: In politisch aufgeladenen oder schuldfixierten Umgebungen wird offene Diskussion untergraben, weshalb neutrale Moderation und eine explizit blamefreie Rahmung notwendige Voraussetzungen sind. Ebenso entscheidend ist die Zusammensetzung der Teilnehmer: Wenn die Personen, die den Vorfall tatsächlich bearbeitet haben, und die Systemverantwortlichen nicht gemeinsam am Tisch sitzen, lässt sich die Analyse der beitragenden Faktoren nicht gegen die operative Realität prüfen – der häufigste Grund, warum ein Review am Ende keine Lernwirkung erzielt.
Vom Einzelfall zum Muster
Der eigentliche Wert entsteht erst über mehrere Vorfälle hinweg. Werden Post-Incident-Reviews konsequent in einem Lessons-Learned-Register erfasst und nach Kontrollkategorie ausgewertet, lassen sich systemische Muster erkennen, die ein einzelner Review niemals aufdecken würde – etwa eine MFA-Lücke, die in drei unterschiedlichen Vorfällen über zwei Jahre hinweg jeweils als Einzelfall behandelt wurde, obwohl sie strukturell dieselbe Ursache hatte.
Für IR-Teams heißt das konkret: Ein 15-minütiges Debrief für Sev-3-Vorfälle, ein strukturierter Review mit festen Rollen für Sev-1/Sev-2, verbindliche Fristen für die Veröffentlichung, und ein Register, das über den Einzelfall hinaus ausgewertet wird. Wer diese Disziplin jetzt aufbaut, erfüllt nicht nur NIS2 und DORA – er verwandelt die teuerste Ressource eines Incidents, die gewonnene Erkenntnis, tatsächlich in besseren Schutz für den nächsten Vorfall.
← Zurück zur Übersicht