Business Continuity
KaitoSec verbindet BIA, Wiederanlaufziele, Abhängigkeiten, Pläne und Übungen mit dem bestehenden Sicherheitskontext. Prozessverantwortliche wissen, was zuerst wieder anlaufen muss; die Leitung sieht, was tatsächlich erprobt wurde.
Wo heute Reibung entsteht
Die meisten Business-Continuity-Pläne werden geschrieben, um eine Anforderung zu erfüllen, und dann dort abgelegt, wo niemand hinsieht. Sie nennen Wiederanlaufzeiten, die nie getestet wurden, listen Kontakte, die vor zwei Jahren gegangen sind, und setzen voraus, dass die Leute unter Druck schon wissen, welche Version aktuell ist. Beim ersten echten Ausfall zeigt sich, dass nichts davon trägt.
Continuity funktioniert nur, wenn sie Daten mit dem Rest des Sicherheitsprogramms teilt. Die kritischen Assets in Ihrer BIA sind dieselben, die Ihr ISMS bereits führt. Ein in der Sicherheit erkanntes Risiko ist oft genau das Szenario, das Ihr Recovery-Plan abdecken muss. Liegt Continuity im eigenen Silo, pflegen Sie alles doppelt und vertrauen keiner Seite. Liegt sie neben dem ISMS, bleibt der Plan ehrlich, weil er sich mit dem Betrieb bewegt.
Ein Datenmodell
Module sind Sichten auf denselben Datensatz, keine getrennten Datenbanken. Eine Änderung hier ist die Änderung, die jedes andere Modul liest. Ohne Export, ohne zweite Erfassung.
Dieses Modul
Business Continuity
Gemeinsames Datenmodell
Ein Zielobjekt, ein Risiko, eine Maßnahme, ein Nachweis
Vom Eintrag zum Nachweis
Auditoren fragen selten, was im Register heute steht. Sie fragen, wer es geändert hat, wann und auf welcher Grundlage. Diese Spur entsteht während der Arbeit, nichts muss zum Jahresende rekonstruiert werden.
Eine Änderung
Ein Risiko wird neu bewertet
Wird mitgeschrieben
Wo es auftaucht
Kritikalität
Die BIA legt fest, wie lange ein Prozess ausfallen darf. Der Wiederanlauf ist geübt und belegt. Und weil dieselben Daten das Notfallmanagement tragen, läuft das BCMS im Headstart mit.
Business ContinuityBetriebsfähigkeit
Übung bestandenStörungWiederhergestellt · 2 h 40 minRTO-Budget 4 h
Kritische Prozesse
01
Sie identifizieren kritische Prozesse und Services, modellieren Auswirkungen über die Zeit und legen RTO, RPO, MTPD sowie MBCO pro Prozess fest. Abhängigkeiten zu Assets, Lieferanten und nachgelagerten Services sind Teil desselben Modells, das Ihr ISMS bereits verwendet.
02
Recovery-Anforderungen werden direkt aus den BIA-Ergebnissen abgeleitet. Strategien tragen Ressourcenbedarf, Alternativen, Kosten und Machbarkeit und sind mit den Prozessen, Assets und Lieferanten verknüpft, die sie absichern. Nichts existiert in einem separaten Planungssilo.
03
Sie planen Tabletop- und praktische Übungen, erfassen Befunde und Lessons Learned und verbinden Folgemaßnahmen mit dem getesteten Plan. Der Nachweis entsteht dort, wo das Team die Bereitschaft prüft.
01
Bewerten Sie Geschäftsprozesse und Services anhand klarer BIA-Kennzahlen: maximale Ausfalltoleranz, Wiederanlaufzeit, tolerierbarer Datenverlust und Mindestbetriebsniveau. KaitoSec macht Auswirkungen über die Zeit sichtbar, erfasst kritische Abhängigkeiten zu Prozessen, Services, Assets und Lieferanten und unterstützt BIAs in der passenden Tiefe: strategisch bis assetbezogen.
02
KaitoSec strukturiert BIA-Ergebnisse als konkrete Continuity-Anforderungen: Zielzeiten, Mindestbetriebsniveau, kritische Abhängigkeiten, Ressourcen und Verantwortlichkeiten. Darauf bauen Strategien, Workarounds und Pläne nachvollziehbar auf.
03
Strukturierte Pläne decken Rollen, Eskalation, Kommunikation, Entscheidungsbefugnis und Abhängigkeiten ab. Pläne werden im selben Workflow versioniert, freigegeben, verteilt und bestätigt wie Ihre Richtlinien. Der geltende Plan ist der Plan, den die Beteiligten wirklich gelesen haben.
04
Planen und führen Sie Tabletop-Walkthroughs, funktionale Tests und Großübungen durch. Erfassen Sie Durchführung, Findings, Lessons Learned und Folgemaßnahmen. Verknüpfen Sie Übungen mit BC-Plänen und Recovery-Strategien und validieren Sie, was funktioniert und was nicht.
05
Sie legen Aktivierungskriterien und Eskalationswege von der operativen Störung bis zur Krise fest. Status, Entscheidungen und Kommunikation bleiben protokolliert und können für Melde- und Nachweispflichten weiterverwendet werden.
06
BCM-spezifische Audits werden mit strukturierten Nachweisen und Nachvollziehbarkeit unterstützt. Management Reviews, Übungsergebnisse und Folgemaßnahmen speisen die kontinuierliche Verbesserung. Ihr BCM ist ein arbeitendes System, kein Ordner im Regal.
Eine Business Impact Analyse identifiziert die Prozesse und Services, die laufen müssen, bewertet die Folgen ihrer Unterbrechung über die Zeit und legt Wiederanlaufziele wie RTO, RPO und MTPD fest. Ohne sie ist jeder Continuity-Plan eine Vermutung. Mit ihr hat der Rest Ihres Resilienzprogramms einen belastbaren Ausgangspunkt.
BCMS und ISMS teilen denselben Workspace, dasselbe Asset-Modell, dieselbe Risikofläche und dieselbe Nachweiskette. Ein im ISMS erkanntes Risiko kann eine BIA-Aktualisierung auslösen. Ein kritisches Asset speist Maßnahmenauswahl und Recovery-Planung. Keine Doppelregister, keine Silo-Übergaben.
Nein. Das BCM-Modul ist mit und ohne Zertifizierung nützlich. Wenn Sie ISO 22301 anstreben, unterstützt KaitoSec den gesamten Lebenszyklus. Wenn nicht, erfüllt dasselbe Modul die Continuity- und Resilienzanforderungen von NIS2, DORA, BAIT, VAIT und Kunden-Due-Diligence.
Ein BC-Plan deckt die Gesamtreaktion ab: welche Prozesse weiterlaufen, wer entscheidet, wie die Organisation kommuniziert und wie eskaliert wird. Ein Disaster-Recovery-Plan deckt die technische Wiederherstellung der Systeme ab. KaitoSec führt beide und hält die Beziehungen explizit, damit kein Plan vom anderen abweicht.
ISO 22301, NIS2 und DORA erwarten regelmäßige Tests, in der Regel mindestens jährlich für kritische Pläne und häufiger für besonders kritische Prozesse. KaitoSec plant, dokumentiert und verfolgt Übungen am selben Ort wie die Pläne selbst. Die Frequenz ist ohne manuelle Buchführung belegbar.
