Mehr als eine Momentaufnahme.Ein ISMS, das mitläuft.

Bei einem Vorfall sehen, was mitbetroffen ist.

Ein Sicherheitsvorfall trifft eine Komponente, etwa einen Datenbank-Cluster. Welche anderen Objekte davon mitbetroffen sein könnten, hängt an Abhängigkeiten, die sich ohne Übersicht schwer überblicken lassen.

Du startest die Ausbreitungsprüfung an einem Risikokandidaten und wählst die Richtung: Was braucht das Objekt, was hängt von ihm ab, oder beides? BlueProceedings ISMS folgt den hinterlegten Abhängigkeiten und bestätigten Schnittstellen und schlägt vor, was mitbetroffen sein könnte. Erreichbar heißt nicht betroffen. Über jeden Vorschlag entscheidest du selbst: Du bestätigst ihn als betroffen und beschreibst, wie das Objekt betroffen sein kann und welche Schutzziele es trifft. Du verwirfst ihn und begründest, warum. Oder du markierst ihn als nicht entscheidbar und hältst fest, was dafür fehlt. Erst die Bestätigung macht ein Objekt zum Betroffenen.

Im Beispiel ist der PostgreSQL-Cluster das Startobjekt. Links stehen seine Voraussetzungen, rechts die davon abhängigen Objekte, je Spalte eine Ebene. Drei Objekte sind bestätigt, zwei veraltet, eines verworfen, eines nicht entscheidbar und acht noch zu prüfen.

Von der Ursache bis zum Restrisiko, auf einer Seite.

Ein Risiko, das nur als Zeile in einer Tabelle steht, verrät nicht, woher es kommt, was dagegen getan wird und was am Ende übrig bleibt.

Deshalb hat jedes Risiko eine eigene Seite. Sie zeigt in vier Stationen, woher es kommt, wie es bewertet ist, was dagegen getan wird und was danach übrig bleibt. Die Behandlung verweist auf die zugehörige Maßnahme, die mit Fortschritt, Schritten, Verantwortlicher und Frist direkt daneben steht. Das Restrisiko ist die Einschätzung für die Zeit nach der Umsetzung; es braucht die Akzeptanz des Risikoeigentümers und ein Datum für die nächste Prüfung. Die Risikoakte darunter hält fest, welche Objekte aus welcher Ebene betroffen sind.

Im Beispiel entsteht das Risiko, weil die Anforderung KONF.3.2 (Speicherverschlüsselung) im Kunden- und Marktpartnerportal noch nicht umgesetzt ist: Ein entwendetes Datenbank-Volume oder Sicherungsmedium legt Kundenstammdaten im Klartext offen. Die Behandlung heißt Mindern, die Maßnahme „Volume-Verschlüsselung für Datenbank und Sicherungen einführen“ ist in Umsetzung, zwei von vier Schritten sind erledigt, Frist ist der 18.12.2026. Das Restrisiko ist gering, vom Risikoeigentümer akzeptiert, die nächste Prüfung steht für den 15.02.2027 an.

The ISMS must go on. Sehen, wer fehlt, bevor eine Rolle unbesetzt ist.

Fällt jemand aus, bleibt im Alltag oft offen, wer seine Rolle übernimmt. Das fällt meist erst auf, wenn eine Aufgabe liegen bleibt.

Wer eine Rolle hält, kann für sie eine Vertretung benennen, für jede Rolle eine andere und für einen Zeitraum oder unbefristet. Der Vertretungsplan legt das neben die Abwesenheiten: Je abwesender Person ein Block, darunter eine Bahn je Rolle. Grün steht, wer übernimmt, gestrichelt, dass eine weitere Person dieselbe Rolle hält und anwesend ist, rot, dass niemand die Aufgaben übernimmt. Eine Lücke steht zusätzlich als Warnung über dem Plan, mit Rolle und Zeitraum, solange noch Zeit bleibt, sie zu schließen.

Im Beispiel ist Sam Nordstern vom 10. bis 21.11. abwesend. App-Admin ist durch Alex als weiteren Inhaber der Rolle gedeckt, Compliance vertritt Kim, für die Rolle Auditor gibt es keine Vertretung. Darüber steht deshalb die Warnung „Keine Vertretung für die Rolle Auditor“ mit dem Zeitraum.

Der Plan zeigt, was eingetragen ist. Abwesenheiten, die niemand einträgt, kann er nicht kennen. Sie tragen die Person selbst oder die Personalabteilung ein.

Wiederanlauf und Wiederherstellung planen, bevor es ernst wird.

Fällt ein Standort oder ein Objekt aus, muss schnell entschieden werden, was zuerst wieder anlaufen soll. Mit begrenztem Personal gibt es dafür viele mögliche Reihenfolgen.

Du wählst die ausgefallenen Standorte oder Objekte und gibst das verfügbare Personal an. BlueProceedings ISMS plant über die Abhängigkeiten, in welcher Reihenfolge Notbetrieb und Wiederherstellung anlaufen, und vergleicht fünf implementierte Planungsverfahren, von einfachen Heuristiken (Greedy) bis zur exakten Suche (Branch-and-Bound). Als Maßstab dient der modellierte Verlust auf Grundlage der hinterlegten Annahmen, verglichen mit dem Fall, dass im Planungszeitraum nichts wieder anliefe. Das Ergebnis ist ein modellbasierter Planungsvorschlag, keine Entscheidung des Krisenstabs. Unvollständige oder falsche Eingaben verändern es; der Krisenstab prüft die tatsächliche Lage und entscheidet selbst.

Im Beispiel eines Übungslaufs liegt der modellierte Verlust des besten berechneten Planungsvorschlags bei 1.027.530 Euro im Planungszeitraum, gegenüber 3.531.600 Euro, wenn kein betroffener Prozess wieder anliefe. Die fünf Verfahren liefern drei verschiedene Ergebnisse, jeweils mit dem Abstand zum besten berechneten Vorschlag.

Die Berechnung ist ein modellbasierter Planungsvorschlag. Sie verwendet die im System hinterlegten Abhängigkeiten, Zeiten, Kapazitäten und Verlustannahmen. Unvollständige oder falsche Eingaben verändern das Ergebnis. Der Krisenstab prüft die tatsächliche Lage, Nebenbedingungen und Folgen und trifft die Entscheidung selbst.

Notfallvorsorge auf demselben Bestand.

Notfallvorsorge besteht oft aus getrennten Unterlagen: Analyse, Verfahren, Personal, Übungen. Ob sie zusammenpassen, sieht man selten auf einen Blick.

Business-Impact-Analyse, Notfallszenarien und Übungen beziehen sich in BlueProceedings ISMS auf dieselben Prozesse, Komponenten und Standorte wie das übrige ISMS. Das Gesamtbild fasst die Notfallvorsorge in fünf Stationen zusammen: Für welche Prozesse ist festgelegt, wie lange ein Ausfall höchstens dauern darf (die tolerierbare Ausfallzeit)? Gibt es für die zugehörigen Objekte ein Wiederanlauf- und ein Wiederherstellungsverfahren? Reichen Personal und Mittel? Sind Organisation und Kontakte benannt? Und wann wurde zuletzt geübt? Lücken und Hinweise erscheinen genauso deutlich wie das, was vorhanden ist. Eine Gesamtnote gibt es bewusst nicht.

Im Beispiel steht unter den fünf Stationen, was die letzte Übung gezeigt hat und wer im Ernstfall führt und wer vertritt. Das zweite Bild zeigt ein Planspiel zur Verschlüsselung der zentralen Plattformdienste mit Beteiligten, Annahme, Abbruchbedingung, Soll-Zeiten und Erfolgskriterium.

Ein Plan ohne Übung sagt wenig. Der Lauf zeigt, was er wert ist.

Wer seinen Wiederanlauf nur auf dem Papier geplant hat, merkt oft erst im Ernstfall, wie schnell aus einer Stunde Verzug eine überschrittene Frist wird. Bei Abläufen mit vielen Schritten in mehreren Teams ist es ohne Werkzeug schwer, nach Stunden noch zu überblicken, was geplant war, was läuft und was überfällig wird.

Im Lagezentrum steht der Plan eines Krisenlaufs neben dem, was im aktuellen Durchlauf tatsächlich geschieht. Jede Zeile ist ein Schritt, gruppiert nach Team mit verantwortlicher Rolle: oben die Planspur, darunter das Ist des laufenden Durchlaufs, also was tatsächlich begonnen, beendet oder gescheitert ist. Schraffiert ist der Verzug, ein früher beendeter Schritt als Vorsprung gekennzeichnet, ein gescheiterter Versuch bleibt sichtbar. Die rechnerische Fortschreibung des aktuell erfassten Stands weist darauf hin, welche tolerierbare Ausfallzeit voraussichtlich überschritten werden könnte. Sie ersetzt keine Lagebeurteilung: Die Anwendung hilft beim Überblick, die Lage beurteilt weiterhin der Krisenstab.

Das Beispiel ist bewusst nicht einfach: eine Funktionsübung „Löschgasauslösung im Rechenzentrum Nord“ fünfeinhalb Stunden nach Beginn, zehn begonnene Schritte in mehreren Teams, ein gescheiterter Versuch, ein Prozess mit überschrittener Frist und eine Information, die überfällig ist.

Ein Vorfall, Schritt für Schritt nachvollziehbar.

Nach einem Sicherheitsvorfall bleibt selten Energie für Berichte und Klärung. Wird der Ablauf schon während des Vorfalls festgehalten und von der Anwendung unterstützt, muss nachher nichts aus dem Gedächtnis rekonstruiert werden.

Ziel ist, dass der Abschlussbericht aus der Zeitlinie mit einem Klick entsteht, statt Tage zu kosten. Eine passende Berichtsvorlage ist dafür vorgesehen. Jeder Sicherheitsvorfall hat ein nur anhängbares, hashverkettetes Ereignisprotokoll, das als Zeitlinie lesbar ist. Die Anwendung prüft die Kette auf rechnerische Brüche; das Protokoll ersetzt weder einen externen Vertrauensanker noch eine Aufbewahrungsentscheidung des Betreibers. Zu jedem Ereignis stehen Uhrzeit, die Zeit seit Beginn, die handelnde Person mit Rolle und die Gruppe, etwa Feststellung, Eindämmung oder Kommunikation. Eine Hypothese, die sich als falsch erweist, wird nicht überschrieben, sondern durch eine Korrektur ersetzt, und beides bleibt lesbar. Kennzahlen am Kopf zeigen Erkennung bis Lösung und Anzahl der Korrekturen.

Das Beispiel ist eine gezielte Phishing-Kampagne gegen den Kundenservice: 49 Ereignisse von vier Personen, von der ersten gemeldeten Mail bis zur freigegebenen Nachbesprechung. Eine Hypothese erweist sich als falsch und wird durch eine Korrektur ersetzt. Die Meldeentscheidung an die Aufsicht wird zuerst zurückgestellt und später begründet entschieden.

Die Berichtsvorlage für Sicherheitsvorfälle ist noch nicht Teil der Pre-Alpha. Ob ein Bericht vollständig ist, prüfen die Verantwortlichen.

Erledigt ist nicht wirksam.

Aus „erledigt“ wird schnell „wirksam“, ohne dass jemand geprüft hat.

Maßnahmen entstehen aus Risiken, Sicherheitsvorfällen, Audit-Feststellungen, Kennzahlen oder neuen Vorgaben. Abgeschlossen ist eine Maßnahme erst, wenn vorab festgelegte Kriterien geprüft sind und ein gültiger Nachweis vorliegt. Bis dahin bleibt der Abschluss gesperrt und sagt, was fehlt. Die Schließung gibt eine zweite Person frei. Im Kleinunternehmen-Modus entfällt nur die personelle Trennung, nicht die Prüfung.

Im Beispiel stammt die Maßnahme aus einer bestätigten Audit-Feststellung und ist in Umsetzung. Die Wirksamkeitsprüfung ist noch offen, mit dem Hinweis „Kriterien festlegen“. Der Abschluss bleibt gesperrt, bis die Wirksamkeitskriterien festgelegt und gespeichert sind.