Zum Hauptinhalt springen

Guide

Risikoreview im ISMS: Wann musst du neu bewerten?

Wann ein Risikoreview nötig wird: Änderungen, neue Erkenntnisse und fehlende Wirksamkeit erkennen, die Bewertung prüfen und Entscheidungen nachhalten.

Risikoreview im ISMS: Wann musst du neu bewerten?
Julian Köhn
|Lesezeit: 5 Minuten

Ein Risiko braucht einen Review, wenn seine Bewertungsgrundlage nicht mehr trägt. Das kann der geplante Prüftermin sein, aber auch ein neuer Dienstleister, ein fehlgeschlagener Test oder eine veränderte Nutzung. Warte in solchen Fällen nicht darauf, dass das Jahresreview fällig wird.

Ein Review bedeutet zunächst prüfen. Er führt nicht zwangsläufig zu einer anderen Risikostufe. Entscheidend ist, ob die bisherige Bewertung und Behandlung weiterhin begründet sind.

Was unterscheidet Review und Neubewertung?

Im Review prüfst du die bisherige Einschätzung gegen aktuelle Informationen. Bei einer Neubewertung passt du die Einschätzung an, wenn sich ihre Grundlage verändert hat. Beides sollte nachvollziehbar sein: Was wurde geprüft, mit welchem Ergebnis und durch wen?

NIST SP 800-30 beschreibt die Pflege einer Risikobewertung als fortlaufenden Schritt. Neue Informationen aus der Überwachung sollen in die Bewertung einfließen, etwa zur Wirksamkeit der Behandlung oder zu Änderungen an Systemen und ihrem Umfeld. NIST SP 800-30, Abschnitt 3.4

Ein unveränderter Score kann daher ein sinnvolles Ergebnis sein. Ein unveränderter Score ohne Prüfung sagt dagegen wenig über den aktuellen Zustand. Falls eure Bewertungskriterien noch nicht feststehen, beginnt mit der Risikomatrix und einem durchgerechneten Beispiel.

Welche Ereignisse sollten einen Review auslösen?

Definiert Auslöser dort, wo Änderungen bekannt werden: im Betrieb, im Einkauf, in Projekten und bei den Verantwortlichen für Geschäftsprozesse. Die folgende Tabelle ist ein Vorschlag für eure Arbeitsweise, keine abschließende Normvorgabe.

AuslöserWas du prüfen solltest
Ein Dienst wird für einen weiteren Geschäftsprozess genutztSind Auswirkung, Datenumfang und Abhängigkeiten noch richtig beschrieben?
Ein Lieferant oder Unterauftragnehmer wechseltGelten die bisherigen Annahmen zu Leistung, Zugriff und Wiederanlauf noch?
Ein Sicherheitsvorfall oder Beinahevorfall tritt aufWurde das Szenario unterschätzt oder fehlte eine wirksame Maßnahme?
Eine relevante Schwachstelle wird bekanntBetrifft sie eure tatsächlich eingesetzte Version und Konfiguration?
Eine Maßnahme wird abgeschlossenGibt es einen Beleg für ihre Wirkung unter den relevanten Bedingungen?
Ein Test scheitert oder ein Nachweis fehltIst die bisher angenommene Schutzwirkung noch begründet?
Eine befristete Risikoentscheidung läuft ausSind Bedingungen und Entscheidungsbefugnis weiterhin gegeben?

Nicht jede externe Meldung erfordert eine vollständige Neubewertung aller Risiken. Prüfe zunächst die Betroffenheit und halte fest, warum ein Ereignis relevant oder nicht relevant ist.

Prüfe die Bewertung in fünf Schritten

1. Anlass und Umfang festhalten. Benenne das betroffene Szenario, den Informationswert oder Prozess und die konkrete Änderung. „Allgemeine Prüfung“ hilft später wenig.

2. Annahmen vergleichen. Welche Daten, Nutzungen, Abhängigkeiten und Schutzmaßnahmen lagen der bisherigen Einschätzung zugrunde? Welche davon stimmen noch?

3. Aktuelle Belege prüfen. Ein eingerichtetes Backup ist etwas anderes als eine erfolgreich geprüfte Wiederherstellung. Unterscheide geplante Wirkung von nachgewiesener Wirkung. Der Leitfaden zu aktuellen und überprüfbaren Nachweisen zeigt, woran du ihre Eignung beurteilst.

4. Bewertung begründen. Verwende die vereinbarte Methode. Dokumentiere Änderungen bei Eintrittswahrscheinlichkeit und Auswirkung sowie verbleibende Unsicherheiten. Fehlende Informationen sind kein Beleg für ein geringes Risiko.

5. Behandlung und Entscheidung nachführen. Ergänze oder ändere Maßnahmen, Zuständigkeiten und Fristen. Wenn eine Entscheidung außerhalb deiner Befugnis liegt, eskaliere sie an die dafür benannte Stelle. Soll das verbleibende Risiko getragen werden, halte die Risikoakzeptanz als eigene Entscheidung fest.

ISO beschreibt ein ISMS als einen Ansatz, der Menschen, Regeln und Technik zusammenführt und Risiken passend zur Organisation behandelt. Eine Risikobewertung sollte deshalb auch organisatorische Veränderungen berücksichtigen. ISO/IEC 27001

Beispiel: Aus einer Nebenanwendung wird ein wichtiger Dienst

Fiktiver Fall: Eine Anwendung verwaltete bislang interne Schulungstermine. Jetzt nutzt ein Geschäftsbereich sie zusätzlich für verpflichtende Kundentermine. Die Technik bleibt gleich, die Folgen eines Ausfalls ändern sich.

Im Review stellt das Team fest, dass die bisherige Auswirkungsbewertung nur den internen Einsatz abdeckt. Es ergänzt den neuen Geschäftsprozess und prüft, welche Termine bei einer Unterbrechung betroffen wären. Die vorhandene Sicherung ist bekannt; ein getesteter Ersatzablauf fehlt.

Das Team bewertet das Risiko anhand der bestehenden Methode neu und schlägt einen Ersatzablauf samt Test vor. Die verantwortliche Person entscheidet über Behandlung und verbleibendes Risiko. Eine neue Zahl im Register allein hätte den Kundentermin nicht abgesichert.

Bewahre die alte Begründung auf

Eine Arbeitszeile für den beschriebenen Fall kann so aussehen. Die Rollen sind beispielhaft und müssen zu eurer Organisation passen.

ÄnderungBetroffenes RisikoPrüffrageZuständigDokumentiertes Ergebnis
Anwendung trägt jetzt KundentermineAusfall verhindert TerminabwicklungDecken Bewertung und Ersatzablauf die neue Nutzung ab?Prozessverantwortliche mit IT und ISMS-VerantwortungNeue Nutzung bewertet; Ersatzablauf samt Test als Behandlung vorgeschlagen; Entscheidung noch offen

Überschreibe eine frühere Einschätzung nicht so, dass ihre Grundlage verloren geht. Für den späteren Vergleich braucht ihr mindestens Anlass, Datum, verwendete Methode, vorherige und neue Einschätzung, Belege und Entscheidung.

Wenn sich die Methode selbst ändert, sind Werte möglicherweise nicht direkt vergleichbar. Kennzeichne diesen Bruch. Ein niedrigerer Wert auf einer neuen Skala ist noch keine nachgewiesene Verbesserung.

Lege den nächsten Prüfanlass fest

Verbinde einen geplanten Termin mit konkreten Ereignissen. Zum Beispiel: „Erneut prüfen nach dem Wiederherstellungstest, spätestens zum festgelegten Reviewtermin.“ Entscheidend ist, dass jemand für das Erkennen und Bearbeiten des Anlasses verantwortlich ist. Fehlen Ressourcen oder muss die Leitung Prioritäten setzen, bereitet das Ergebnis für das ISMS-Management-Review auf.

Mit Kopexas Risikomanagement-Software könnt ihr die Risikobewertung mit der Maßnahmenarbeit verbinden. Nachweise liegen an Maßnahmen; Maßnahmen werden auf Controls gemappt. Damit lässt sich die Umsetzung belegen. Ob diese Belege für eure Risikoeinschätzung ausreichen, muss fachlich geprüft werden.

Ein abgeschlossener Review hinterlässt eine begründete Bewertung, eine klare nächste Handlung und einen weiteren Prüfanlass. So bleibt aus einer einmal erstellten Risikoliste ein nutzbares Arbeitsmittel.

Kurz beantwortet

Häufige Fragen

Noch eine Frage offen? Hier findest du die Antworten zum Nachlesen.

Muss nach jedem Risikoreview der Score geändert werden?

Nein. Wenn die geprüften Annahmen weiter gelten, kann die Bewertung bestehen bleiben. Dokumentiert Anlass, geprüfte Informationen, Ergebnis und nächsten Prüfanlass.

Wann sollten wir außerhalb des regulären Termins prüfen?

Wenn sich die Bewertungsgrundlage ändern könnte, etwa durch neue Nutzung, Lieferantenwechsel, Vorfälle oder fehlgeschlagene Tests. Prüft zuerst die konkrete Betroffenheit.

Darf eine abgeschlossene Maßnahme automatisch das Risiko senken?

Ein Abschlussstatus allein belegt die Wirkung nicht. Prüft das Ergebnis und begründet eine Änderung mit eurer festgelegten Bewertungsmethode.

Quellen

  1. Guide for Conducting Risk Assessments, SP 800-30 Rev. 1 — NIST [Abgerufen am ]
  2. ISO/IEC 27001:2022 — ISO [Abgerufen am ]