ISO 22301 — vorbereitet auf den Ausfall

ISO 22301 beschreibt ein Business-Continuity-Managementsystem — also die Fähigkeit einer Organisation, nach einer Störung weiterzuarbeiten oder schnell wieder anzulaufen.

Der Blickwinkel unterscheidet sich von anderen Managementsystemnormen: Es geht nicht darum, Störungen zu verhindern, sondern darum, vorbereitet zu sein, wenn sie eintreten. Die Norm nimmt an, dass der Ausfall kommt.

Was sie nicht verlangt, ist ein bestimmtes Schutzniveau. Es gibt keine vorgeschriebene Wiederanlaufzeit, kein gefordertes Rechenzentrum, keine Pflicht zum Ausweichstandort. Die Norm verlangt, dass Sie wissen, wie lange Ihre Aktivitäten ausfallen dürfen, dass Sie dafür Lösungen bereithalten und dass Sie diese Lösungen geübt haben. Ein Unternehmen, das für eine unkritische Aktivität einen Wiederanlauf nach zwei Wochen ansetzt, kann zertifiziert werden — wenn diese Entscheidung hergeleitet und getragen ist.

Aufbau der Norm

Die Kapitel 4 bis 10 folgen der harmonisierten Struktur. Der Unterschied liegt in Kapitel 8, das bei ISO 22301 ungewöhnlich ausführlich ist und den eigentlichen Arbeitsinhalt trägt.

Bemerkenswert ist Kapitel 8.6: Die Norm verlangt ausdrücklich, die eigene Kontinuitätsdokumentation in festgelegten Abständen zu überprüfen. Damit ist der häufigste Zustand in der Praxis — ein Notfallhandbuch mit Stand von vorgestern — bereits im Normtext adressiert.

Der Kern: die Business Impact Analyse

Am Anfang steht die Frage, welche Aktivitäten wie kritisch sind. Die Business Impact Analyse bewertet für jede Aktivität, wie sich ein Ausfall über die Zeit auswirkt — finanziell, vertraglich, rechtlich, auf die Reputation.

Daraus ergeben sich die Kennzahlen, die das gesamte System steuern:

Wichtig ist die Reihenfolge: Die Werte kommen aus dem Geschäft, nicht aus der IT. Wer die IT fragt, wie schnell sie wiederherstellen kann, bekommt die technische Möglichkeit — nicht die geschäftliche Anforderung. Erst wenn beide auseinanderfallen, wird die Investitionsentscheidung sichtbar. Genau diese Lücke ist das nützlichste Ergebnis einer Business Impact Analyse: Sie macht aus einer diffusen Sorge eine Vorlage für die Geschäftsführung.

Die RTO muss dabei kürzer sein als die maximal tolerierbare Ausfalldauer — sonst ist die Zeitvorgabe in sich widersprüchlich. Auditoren rechnen das nach.

Die weiteren Bausteine

Kontinuitätsstrategien. Für jede kritische Aktivität: Wie halten wir sie aufrecht oder stellen sie wieder her? Ausweichstandort, Ersatzlieferant, manuelle Notverfahren, redundante Systeme, Vereinbarungen mit Dienstleistern. Zu jeder Strategie gehört die Frage nach den benötigten Ressourcen: Personen mit bestimmten Kenntnissen, Räume, Geräte, Daten, Zulieferungen.

Kontinuitätspläne. Konkret, aktuell und verfügbar — auch dann, wenn die Systeme ausgefallen sind, in denen sie gespeichert sind. Ein Notfallplan im Intranet ist im Notfall regelmäßig nicht erreichbar. Ein Plan, der nur die IT-Wiederherstellung beschreibt, deckt außerdem die Hälfte der Fälle nicht ab.

Alarmierung und Kommunikation. Wer entscheidet, wer informiert, über welche Kanäle, mit welchen Rückfallebenen? Auch Kunden, Behörden und Presse gehören in die Planung. Die Norm behandelt Kommunikation als eigene Fähigkeit, nicht als Anhang zum Notfallplan.

Übungen und Tests. Der Prüfstein. Die Norm verlangt, die Lösungen zu üben und die Ergebnisse auszuwerten. Übungen reichen von der Schreibtischübung bis zum vollständigen Umschaltversuch. Entscheidend ist nicht der Aufwand, sondern der Auswertungsbericht: Was hat nicht funktioniert, wer hat daraus welche Änderung abgeleitet, bis wann?

Der Weg zum Zertifikat

Der Zertifizierungsablauf ist der übliche. Die Reihenfolge der inhaltlichen Arbeit liegt allerdings weitgehend fest, weil jeder Schritt auf dem vorigen aufbaut.

1. Anwendungsbereich festlegen — welche Produkte und Dienstleistungen, welche Standorte.
2. Aktivitäten erfassen, die diese Leistungen erbringen, samt Abhängigkeiten.
3. Business Impact Analyse durchführen und die Zeitvorgaben mit der Leitung abstimmen.
4. Risikobeurteilung für die Szenarien, die zu diesen Ausfällen führen können.
5. Strategien auswählen und die Lücke zwischen Anforderung und heutiger Fähigkeit beziffern.
6. Lösungen umsetzen, Pläne schreiben, Alarmierung einrichten.
7. Übungsprogramm starten — mindestens eine ausgewertete Übung muss vor dem Audit vorliegen.
8. Internes Audit und Managementbewertung durchlaufen.
9. Stufe-1- und Stufe-2-Audit, danach jährliche Überwachungsaudits.

Zeitbedarf und kritischer Pfad

Der kritische Pfad ist nicht die Technik und auch nicht die Dokumentation. Er läuft über die Business Impact Analyse und die Abstimmung der Zeitvorgaben. Diese Werte kann kein Projektteam allein festlegen — sie sind Geschäftsentscheidungen, weil aus ihnen Investitionen folgen. Interviews mit den Fachbereichen, Konsolidierung widersprüchlicher Angaben und die Freigabe durch die Leitung brauchen mehrere Abstimmungsrunden.

Der zweite unverkürzbare Posten ist das Übungsprogramm. Eine Übung lässt sich planen, aber ihre Auswertung und die daraus abgeleiteten Korrekturen brauchen Zeit — und beides will der Auditor sehen, nicht nur den Übungstermin. Wer die erste Übung kurz vor das Stufe-2-Audit legt, hat den Nachweis formal, aber keine Wirksamkeit zu zeigen.

Die häufigsten Feststellungen

RTO-Werte ohne Herleitung. Runde Zahlen, die niemand begründen kann, meist von der IT gesetzt.

Pläne ohne Übung. Das Dokument existiert seit drei Jahren, geübt wurde nie.

Kontaktlisten veraltet. Der schnellste Weg, ein Notfallkonzept unbrauchbar zu machen.

Abhängigkeiten übersehen. Der Ausweichstandort hängt am selben Rechenzentrum, der Ersatzlieferant bezieht vom selben Vorlieferanten.

Nur IT betrachtet. Personalausfall, Gebäudeschaden und Lieferkettenunterbrechung fallen unter den Tisch, obwohl sie häufiger vorkommen als der Totalausfall der IT.

Die Übung wird nicht ausgewertet. Es gibt ein Protokoll, aber keine Feststellungen und keine Maßnahmen. Eine Übung, in der alles funktioniert hat, war meist zu leicht angelegt.

Abgrenzung zu verwandten Regelwerken

Wer sowohl ein ISMS als auch ein BCMS braucht, sollte beide von Beginn an integriert aufbauen: ein Anwendungsbereich, eine Risikomethodik, ein Auditprogramm, eine Managementbewertung. Die Zeitvorgaben aus der Business Impact Analyse lassen sich direkt für die Verfügbarkeitsanforderungen der ISO 27001 weiterverwenden — umgekehrt liefert das ISMS die Bedrohungsszenarien für die Risikobeurteilung.